XBee question

Wireless & IoT
1

Greetings and happy holidays,

I have a potentially silly question/observation, as well as a question.

I’m working on the standard path: interfacing a couple of XBee’s to a PIC and a PC and have been struggling.

Hardware is usb explorer + regulated explorer + level shifter, all from Sparkfun.

The first thing I did after configuring 1 as ZNet 2.5 Coordinator AT and 2 as ZNet 2.5 Router/Endpoint AT and updating their firmware was run a rangetest.

On the endpoint I crossed DIN/DOUT and started the test. Lots of errors, which I found odd. I clicked the RSSI checkbox, few to no errors, what gives? I thought RSSI was just an indicator, does it do more?

I moved to interfacing levelshifter/pic to the endpoint. Is this advisable? I attempted the same test: cross at the HV side of the level shifter (having both sides powered properly and grounded). I find that the test fails with no received packets. A scope shows something happening however.

Putting a 12F683 on the HV side of the level shifter, I find that I can pretty consistently RX bytes from the USBExplorer to the PIC over Znet (I’ve got it driving an LCD and printing the output), however, I rarely, if ever, receive a byte from the PIC to the USBExplorer connected coordinator. I’m basically eating the character that’s sent from the terminal, and writing it back out; so I backed up to test a loopback at the level shifter and had the results described.

I am using Software Uarts (MikroC Pro), so, I thought I’d sort out the hardware for certain before fighting the software end.

I know the XBee’s see one another OK, I guess. an ATND shows the endpoint XBee, and, as mentioned, I can get mostly reliable from the PC Terminal to the PIC, just not the other way 'round. But, at this point, mostly concerned with the role of the level shifter.

Thanks,

Joe

2

Do you have an O’scope to look at the signals levels at the XBee’s DIN pin?

This would tell you if the level shifter is working correctly.

Also, on the regulated break-out board there is a series diode on the XBee’s DIN pin (check the schematic) and the DIN pin’s internal pull-up must be enabled. On another forum some people have been having some difficulty with sending data the an XBee on a regulated break-out.

I’ve measured the signal levels at the XBee’s DIN and found that with a PIC driving the break-out’s DIN the logic low was 0.5V. The XBee data sheet specs a low as <0.6V with Vcc = 3.3V. So there is a possibility that the XBee’s DIN is not being pulled low enough to be a valid logic low.

Try:

1-Check that the XBee’s DIN has the internal pull-up enabled.

2-Remove the level shifted as the diode prevents the PIC’s 5V logic from getting to the XBee.

Lets us know if either of these solutions help.

3

Hey waitr

Quick answer is: I do have a scope, and the level shifter seems to be OK. Initially I tried no XBee and just put each side high and measured the output with a VOM. I believe I got less than 3.3v on the one side, maybe 2.5? I didn’t scribble it down. This is when I began to suspect DIN not being tickled.

After your suggestions, I discovered a couple of other posts with folks having difficulty with the regulated explorer here and elsewhere.

Try:

1-Check that the XBee’s DIN has the internal pull-up enabled.

ATPR reports 1FFF, which should mean all pull-ups are enabled. So, in this configuration, I could put 5V right on DIN…which I tried.

2-Remove the level shifted as the diode prevents the PIC’s 5V logic from getting to the XBee.

So, level shifter removed for DIN only (left DOUT going through it to drive RX on the PIC, since that’s been working tolerably all along). I didn’t have much additional joy. I’m puzzled as to why I can go one way without much trouble, but the return trip is a problem.

As I mentioned, I am using MikroC and a SoftUart lib with a 12F683. Perhaps I could use a 16F88 with a real uart and see if there are issues there.

The only oddity that I notice is a correlation with the RSSI led. If I send a stream of characters from the coordinator which is tied to X-CTU, I don’t have any RX on the R/E node until RSSI pops up. At that point, Coordinator → R/E side works, however, the only time I seem to get a byte from R/E to coordinator (and not always a correct byte, usually not) is when RSSI first lights, and then squirt a single byte may make it through and appear in X-CTU terminal. I wonder if the modules aren’t sleeping at some point.

The Digi docs are somewhat convoluted given that they seem to have so many variants. I believe I have XB24-B’s (Series 2.5 XBee). I’ve configured them with 1 coordinator and 1 router/endpoint. I see others are doing 1:1 with 2 nodes talking directly to each other. I’m not certain if I’ve configured the nodes properly as it is, and I can’t find a really good example of the various types of configurations, so, part of me also wonders if there is an error, however, I can tie DIN/OUT together on R/E and then send a stream at it from the Coordinator and have few, if any, drops.

Thanks,

Joe

4

I agree about Digi documentation. It does take some effort to sort it through for an understanding.

I’m using XB24-ZB modules/firmware. These are the same hardware but with ZigBee firmware. My 5V PIC UART pins are directly connected to the Regulated Break-out board. This works with out problem.

When sending data to the XBee what are the high and low voltage levels at the XBee’s DIN pin (after the series diode).

A sleeping End Unit would show a delay on receiving data from the coordinator. That could be it. Pin 13 can be set for SLEEP indicator and pin 9 as sleep control.

Sleep can also be disabled by setting SM = 0.

The RSSI indicator is interesting. A short on the break out board??? or node waking from sleep??

You may wish to check in on Digi’s support forum. If you haven’t been there read through all the post on XBees, not just the ZNet 2.5 threads.

http://www.digi.com/support/forum/listf … sible=true

5

Hmm, so

Does this mean I use the ZNet options when I configure my XB’s? That bit is a bit confusing, since it’s not clear to me yet what’s happening. I couldn’t decide if it was spewing firmware for different bits onto the micro embedded under the shell of the XBee that actually talks to the ZB, or what. I’ve been able to put ZigBee Network or Znet config/firmware onto mine, though, now they’re both running ZNet Coordinator or Router/Endpoint.

I will check on sleep; that seems to be a very likely candidate at this point. Basically I’ve got 1 Bee sticking on a USB Explorer, no connections but USB, and then another Bee with just DIN/OUT, 5V In/GND and nothing else.

I’ll report back if I make any progress.

You know what, the more I think about this, the more I don’t believe this to be a radio problem. I can get nearly 100% if i just fire up the terminal and wrap DIN/DOUT on the second unit; outside of the rangetest. This, now, works if I use the level shifter on DOUT and tie it back to DIN on the HV side, now that I know about the diode on DIN.

I think I’m going to revisit the ditch Software UART library on MikroE and do this quick with a pic with hardware uart.

Thanks again!

J

6

Ok, what I think is the definitive answer, and I’ll document my config incase somebody else needs a clue as to “what works”.

Hardware Laundry List

2 XBee 2.5

1 USB Explorer (C)

1 Regulated Explorer (RE)

1 Level Shifter

X-CTU Software

  1. 2 XBee 2.5, ID by X-CTU as XB24-B. They are now C and RE (Coordinator, Router/Endpoint).

  2. Configure C with XB24-B as ZNet 2.5 Coordinator AT; check Always Update Firmware. I ended up with 1047

  3. Configure RE with XB24-B as ZNet 2.5 Router/Endpoint AT; check Always Update Firmware. I ended up with 1247

At this point you should be able to test with X-CTU. Plug C in to the USB Explorer, plug RE into the Regulated Explorer. Power the Regulated Explorer apropriately. Tie DIN/DOUT together.

Run a range test. You should get packets. If not, verify your settings/firmware configuration above.

I had been using a 12F683, using MikroC Pro’s Software UART libraries. I believe I was either mis-using them, or, something. I had a 16F88, which has onboard USART RX pin 8, TX Pin 11.

XBee C, i just left plugged into the USB Explorer.

XBee RE I put on the breadboard as follows:

I put DOUT into the LV side of the Level Shifter, picked it up on the HV side and sent it to Pin 8/RX on the 16F88. I took Pin 11/TX on the PIC and dropped it straight into the DIN on the Regulated Explorer. As waitr has pointed out, the Regulated Explorer has a diode on DIN that is pulled high by default. waitr also was helpful to this poster, and there is another description of this here:

viewtopic.php?t=18139&sid=2e4713d9fc9a9 … bcb26291f8

The thing to take away, in the absence of absolute values from Digi, is that you should only feed DIN this way when you’re ensuring 3.3V max input, which the Regulated Explorer does.

I’d have to verify, the minimums on the PIC, but, you may be able to feed the RX on the PIC without the Level Shifter, but, I didn’t just to make sure it wasn’t too low.

Beyond the normal power connections (I pulled 3.3V off for the LV side of the level shifter out of Pin 2 on the Regulated Explorer, which is 3.3V out) and conditioning (Caps on the output of your 5v regulator, I used a 78L05).

That is all I’ve done. I have a simple while() that runs and waits for data to arrive on the USART, after I’ve initialized it. When I see data, I turn right around and send out what I’ve seen.

Rerunning the rangetest without the loop back against my PIC and I have similar low loss (typically 1-2% loss or so, and i think most of this is the delay in X-CTU being 1000MS and not longer).

I still need to work out the RSSI stuff in my previous post. I’ll read the Digi docs and look at the Explorer schematics a bit more. My initial understanding is that the RSSI as indicated in X-CTU, is just an indicator. A pin is high, which SparkFun have just tied to an LED. There is an adjustable timeout for it in X-CTU, that is all. I’m also uncertain if there is some sleep going on with the units. The only setting I can find in X-CTU for a Coordinator is how long to hold packets for sleep. It seems to me that the Coordinator doesn’t sleep. The RE’s have more sleep options, but, it seems that it’s disabled. I’m uncertain how to look at that bit of info. I spose one method would be to do SL/SH DL/DH configuration and just configure two Router/Endpoints in Point to Point mode. I think I need to get another 2.5 XBee so I can play with mesh :).

Thanks waitr.

Joe