XBee question

Projects Networking, Protocols, and Devices
1

So just to get started with XBee, I bought two series 2 Xbees with wire antenna, 2 breakout boards, and ONE explorer module. I figured an easy first project (instead of Chat, since I only had ONE explorer module, which I've since rectified and have a second) was to follow this:

http://examples.digi.com/sensors/joystick-with-xbee/

I know that's a series 1, but I did figure out I needed to use series 2 addresses criss-crossed and one needed to be Router and one Coordinator. What I wasn't sure of was the AT versus API issues. Anyway, I wired up one switch between ground and a digital input (configured as such in XCTU).

Then I did the other XBee according to this:

http://examples.digi.com/lights-motors-more/802-15-4-digital-output-with-an-led/

Same pin configured as Output HIGH with an LED connected across to ground.

So I did that, but first just tried with one as Coordinator AT and the other as Router AT. Then I tried combinations of API firmware, too. But I could see NO change on the LED ever. It just came on bright. I was using XCTU 6.0.0 on a Mac and I was seeing occasional hangups while writing and occasionally would "brick" one and have to do the "recovery" write of the firmware. But then my computer found XCTU 6.1.1 and all that bricking seemed to stop. BUT I still could never get anything to work.

I was pulling my hair out. So then I bought two more Xbee units and one more explorer module. And just now I connected both at the same time to separate computers. I configured both to Chat and BOOM, flawless operation. I then discovered the button in XCTU that let's you "discover" other Xbee's over the wireless connection, and that works perfectly between the two new XBees.

So then I tried the original two. NOTHING. I can connect them up and load up configs. I can re-flash them with the latest Router AT and Coordinator AT firmware. I can reset them to default settings. Then I change them to a new PAN ID and put in the destination address as the opposite. But they never find each other in XCTU using wireless discovery, and connecting to them with a terminal and sending characters yields nothing on the other side, either direction.

So then I swapped a good XBee for one of these and tried again. Nothing. Then I swapped the OTHER direction. Still nothing. Then I put my two new ones back in, and they still work fine to each other. So it's like BOTH of the original units are dead in terms of wireless communication, even after having been as reset as I can reset them.

The only thing different is they've each had a switch connected to an input and ground on the other side, and each has had an LED connected across to ground. I left pullup resistors enabled in all cases. I did try turning OFF pullup resistors and installing physical pullup resistors at some point, however. And none of that worked.

Now I'm afraid to try the new Xbees in my breadboards with the switches and LEDs. Did I screw the two originals up? Or get a bad run somehow? Both the first ones came from Sparkfun, but for other reasons the second two came from Adafruit.

Anyone shed any light on what happened?

--Donnie

2

Simplest way I've found:

3

Good article, but...

One thing I noticed with my two working Xbees is that if you use default Router and Coordinator destination addresses (zero on the Router so it talks to the Coordinator, and FFFF on the Coordinator to broadcast), I could NOT chat both directions. I could only get text to go from the Router to the Coordinator, but not the other direction. But when I switched back to hard coded destination addresses, text flowed both ways (with NO other changes to the XBees or the terminal emulators). Is that normal?

And that doesn't address communication using i/o pins. Should what I describe (and what the Series1 articles I link describe) "just work" with a Coordinator AT and a Router AT? Because in one instructional video I found, it seemed to imply anyway that one was going to need to be API and one AT, but I forget which it said. I think the one with the switch was supposed to be API and the one with the LED could be AT. Something about serial I/O being fine with both AT, but if you wanted I/O from input pins then it was going to need to send it using API frames. I'm still a bit fuzzy on that part.

And so even if you are saying pin based I/O should work based on your article (one Coordinator AT with a single pin as "digital input" and one Router AT with the same pin as "digital output HIGH"), is there any chance I hosed my two XBees, or should they work just like the series 1's in the article above? By that I mean with the same "circuit" on each end, I know the setup is different.

I totally get the Pan ID situation. And I have no other XBee interfaces locally that I know of, anyway.

--Donnie

4

djb_rh:
One thing I noticed with my two working Xbees is that if you use default Router and Coordinator destination addresses (zero on the Router so it talks to the Coordinator, and FFFF on the Coordinator to broadcast), I could NOT chat both directions. I could only get text to go from the Router to the Coordinator, but not the other direction. But when I switched back to hard coded destination addresses, text flowed both ways (with NO other changes to the XBees or the terminal emulators). Is that normal?

I sure would think I'd have noticed if I couldn't transmit in both directions. Is everything set to factory default values?

And that doesn't address communication using i/o pins. Should what I describe (and what the Series1 articles I link describe) "just work" with a Coordinator AT and a Router AT? Because in one instructional video I found, it seemed to imply anyway that one was going to need to be API and one AT, but I forget which it said. I think the one with the switch was supposed to be API and the one with the LED could be AT. Something about serial I/O being fine with both AT, but if you wanted I/O from input pins then it was going to need to send it using API frames. I'm still a bit fuzzy on that part.

The 802.15.4 modules (fka Series 1) have a facility called "I/O line passing" that the ZB modules (fka Series 2) do not have. If you do not already have them, get the product manuals here and here.

The ZB modules can send I/O data sample frames at regular intervals. To receive these, the receiving node must be in API mode. Also, remote AT commands can be sent to control the I/O pins on a remote module (among other things). This requires the module sending the remote commands to be in API mode.

And so even if you are saying pin based I/O should work based on your article (one Coordinator AT with a single pin as "digital input" and one Router AT with the same pin as "digital output HIGH"), is there any chance I hosed my two XBees, or should they work just like the series 1's in the article above? By that I mean with the same "circuit" on each end, I know the setup is different.

I am not saying that. Whether your modules are hosed, I cannot say but certainly there is some chance that they are. The pinouts between the two types of modules are only mostly the same, so I would certainly not wire one type of module into a circuit designed for the other without studying the product manuals and the circuit long and hard.

5

Well now we're cooking with gas. It is that "I/O line passing" mode that I wrongly assumed was present in Series 2. Dammit. That's why I couldn't find ANY examples of what I wanted to do that didn't include an Arduino on one end or the other (but obviously doesn't need to be BOTH, at least).

I'll test that broadcast/coordinator ID chat again soon. I assumed it was going to work and was a bit surprised when it didn't, but didn't dig further. The only settings that had been touched were PAN ID and the Destination addresses, but maybe I screwed something up there and just didn't notice.

I wasn't trusting the pinouts of the Series1 articles in any way, just using them as a guide. I know I connected power/ground correctly from my 2xAA battery pack. The only other thing I connected was on one of them a switch that was pulling an input pin to ground (DIO pin 0 configured as a digital input) and on the other DIO pin 0 was connected to the long leg of an LED with the other end connected to ground and it was configured as "digital output HIGH". I assumed the HIGH/LOW part was just what state to put it in as bootup and that from then it would flip it however it was told to. (And I was using two Sparkfun breakout boards, which have the pinouts labeled where you can see it easily over the breadboard.)

Given that, I can't see how I could have hosed them. I would think it would be especially odd to hose them such that they both APPEARED to work fine as far as XCTU was concerned but simply wouldn't talk over the radio. I would have assumed total annihilation, or just for the input/output pin itself to quit working. But obviously with these things anything is possible, I guess.

So my application is pretty simple. I'd like to make a long range gate trigger. I could probably drop back and punt to Series1 devices, but I was hoping to use Series2 in case I need to put a router in to extend my range. I own a lot of property BEFORE you get to the gate I want to trigger (which only needs to close a relay on the receiving side, so that's dead simple), so I could get a router further out. Basically the gate is SLOW and I'm impatient. I can actually open the stupid thing with my cellphone already, but that's not reliable due to cell coverage in the area.

And I was HOPING to do it without an Arduino in the mix, since it's really a simple button press on one end to flip a relay on the other. I'm guessing I can still do it, but it sounds like it's a good bit more involved using Series 2, and may be easier to just add the Arduino on the receiving end (I do want to have multiple senders and was planning to add the encryption layer for security).

--Donnie

6

djb_rh:
I'll test that broadcast/coordinator ID chat again soon. I assumed it was going to work and was a bit surprised when it didn't, but didn't dig further. The only settings that had been touched were PAN ID and the Destination addresses, but maybe I screwed something up there and just didn't notice.

PAN ID doesn't matter, as long as they are both the same of course. But be sure DH and DL are set to their default values, OR set DH and DL to zero for the router (which is the default) and set the coordinator's DH and DL to those of the router. That'll get things into a unicast situation which is what I would want anyway.

I wasn't trusting the pinouts of the Series1 articles in any way, just using them as a guide. I know I connected power/ground correctly from my 2xAA battery pack. The only other thing I connected was on one of them a switch that was pulling an input pin to ground (DIO pin 0 configured as a digital input) and on the other DIO pin 0 was connected to the long leg of an LED with the other end connected to ground and it was configured as "digital output HIGH". I assumed the HIGH/LOW part was just what state to put it in as bootup and that from then it would flip it however it was told to. (And I was using two Sparkfun breakout boards, which have the pinouts labeled where you can see it easily over the breadboard.)

Given that, I can't see how I could have hosed them. I would think it would be especially odd to hose them such that they both APPEARED to work fine as far as XCTU was concerned but simply wouldn't talk over the radio. I would have assumed total annihilation, or just for the input/output pin itself to quit working. But obviously with these things anything is possible, I guess.

Always, always, always use a series current-limiting resistor with an LED. Further, the XBee I/O pins have very limited current source/sink ability, only a few mA. I usually use a 1K resistor for LEDs with XBees. If the LED was still working, maybe things are OK, maybe not.

So my application is pretty simple. I'd like to make a long range gate trigger. I could probably drop back and punt to Series1 devices, but I was hoping to use Series2 in case I need to put a router in to extend my range. I own a lot of property BEFORE you get to the gate I want to trigger (which only needs to close a relay on the receiving side, so that's dead simple), so I could get a router further out. Basically the gate is SLOW and I'm impatient. I can actually open the stupid thing with my cellphone already, but that's not reliable due to cell coverage in the area.

And I was HOPING to do it without an Arduino in the mix, since it's really a simple button press on one end to flip a relay on the other. I'm guessing I can still do it, but it sounds like it's a good bit more involved using Series 2, and may be easier to just add the Arduino on the receiving end (I do want to have multiple senders and was planning to add the encryption layer for security).

Very much doable and straightforward with the ZB modules. The difference is at least one microcontroller will be required, which may not be the case with the 802.15.4 modules. Just off the top, having just an XBee at the gate, and an Arduino/XBee combo for the control should work fine. Basically the Arduino would just send a remote command to set a pin high or low on the gate XBee. Add an Arduino at the gate and then it could transmit its status back to the control node. Actually that might be doable without an MCU too, just by enabling periodic I/O transmissions. That would be cool because as soon as the control was in range of the gate you could have a notification of that fact, plus the current status of the gate, i.e. open or closed. Add a limit switch to tell when the gate is really closed and it could be a fairly robust system.

Good luck!

7

It wasn't a huge LED, but it was a fairly high output white one. I saw that it claimed internal pull-up resistors, so I didn't think I needed one. Plus the circuit in the Series1 tutorial didn't use one. Ugh. There was a time when I would have never considered not using one, but I've seen more and more examples of not needing them lately that I got sucked in.

I can't do anything more than ask the gate to open via the relay, but still like the idea of the heartbeat. I guess I can use a mini arduino on the sending side to keep things small.

Anyway, great insight. Thanks. My life would have been a lot easier if I had never seen those series 1 tutorials, but I think you got me straight. Again, many thanks.

--Donnie

8

djb_rh:
It wasn't a huge LED, but it was a fairly high output white one. I saw that it claimed internal pull-up resistors, so I didn't think I needed one. Plus the circuit in the Series1 tutorial didn't use one. Ugh. There was a time when I would have never considered not using one, but I've seen more and more examples of not needing them lately that I got sucked in.

Size doesn't matter :wink: much, even a small LED will draw a lot of current given the chance, the V/I curve is pretty much exponential. Lots of bad practices out there, some in books even.

I can't do anything more than ask the gate to open via the relay, but still like the idea of the heartbeat. I guess I can use a mini arduino on the sending side to keep things small.

Or just set the XBee up to transmit once a second or something. No MCU needed then.

Anyway, great insight. Thanks. My life would have been a lot easier if I had never seen those series 1 tutorials, but I think you got me straight. Again, many thanks.

You bet. Good luck again, hope your XBees are OK. I'd start by reloading firmware then checking them out. Great little devices.

9

[quote author=Jack Christensen link=topic=230258.msg1661634#msg1661634 date=1396407512]
You bet. Good luck again, hope your XBees are OK. I'd start by reloading firmware then checking them out. Great little devices.[/quote]

I'll try once more. I thought I did, but thinking back, I may have only reloaded one of them completely. I did definitely reset the settings back to factory default on both, and I did test each one against one of the new ones, too. And NEITHER of them would be seen by the new units in any way. AFAIK, if you reset everything to factory, set a PAN ID the same on both, and set the opposite Destination addresses (and one is Coordinator AT and the other Router AT), they should always be able to "discover" the other via the RF link between them using XCTU (that "mesh" icon button under the X on the locally discovered device).

And I know before I got the new ones and was trying to get the two to talk with no Arduino, I did swap them on the breadboards, which means BOTH have been exposed to the same unprotected LED output. I did that trying to figure out if it was just that I had Coordinator and Router reversed and needed to swap those (so I didn't have to reflash each one, all I had to do was switch the output/input designations for that pin). So if that was enough to fry something, it definitely could have done it to BOTH of them.

Outside of the time wasted, well, it's a $45ish mistake. I've made much worse. :slight_smile:

So should a smaller but bright white LED be fine as long as I put a 1K resistor on it? Or dig out an old red LED and stay with the 1K? And to drive a pretty tiny relay would I also still want to use a transistor? Guessing so.

--Donnie

10

djb_rh:
So should a smaller but bright white LED be fine as long as I put a 1K resistor on it? Or dig out an old red LED and stay with the 1K? And to drive a pretty tiny relay would I also still want to use a transistor? Guessing so.

Any LED is OK with a 1K resistor. A white LED might end up not being all that bright though, as their forward voltage tends to be higher. Absolutely do not try a relay without a transistor.

11

Just to confirm, I tested two XBees as follows and chat works both ways just fine. With the coordinator transmitting in broadcast mode (the default), sending too much data too fast can bog things down (see the product manual for an explanation of the evils of broadcasts). Throughput can get choppy but eventually will catch up as long as the buffer hasn't been completely overrun. Setting the coordinator's DH and DL to the router's address avoids this.

  1. Load the ZigBee Coordinator AT firmware (20A7) in one and ZigBee Router AT firmware (22A7) in the other.
  2. Restore both modules to factory default settings.
  3. Set the PAN ID on both modules. This was necessary so as not to interfere with another XBee ZB network I have running. With the default setting (PAN ID 0), the router will join any available network.