While we're discussing xbees

I have a few of these devices (series 2) that I'm experimenting with and have come up with a question that I can't find any answer to.

Once the xbees talk to each other, if the coordinator radio goes offline for a period of time, the network quits working. I can't get it to start up again unless I go to a particular router and reset it. Then the router will start talking to the coordinator again. The network reset AT command doesn't seem to do anything and resetting the coordinator doesn't help either. This could present problems if the router is in the attic and hard to get to. I know that the devices stop trying if they can't communicate for a few tries, but it looks like they never try again and ignore any radio signals I can figure out how to send.

Currently I only have two radios on the network and turning off the coordinator (like if the power failed) while the router (on batteries) is left alive will kill the communications. The associate lights behave normally, however the coordinator always thinks it is associated since it sets up the network and the router thinks things are fine since it talked to a coordinator a while back. This could be a showstopper since intermediate radios that serve only to forward data to and from a remote could lose comm also. These things could be hidden or extremely inconvenient to get to.

These little guys could be extremely useful moving data around, but they need to be somewhat self healing.

Oh, I started another thread on this subject to keep from hijacking the other persons. These are different problems.

I got so annoyed I was ready to just throw the xbees in a box and forget them. They lose their network and can't reestablish. If you reprogram them for another function, kiss the network good bye. Their actually working anything like they are touted to do was seemingly impossible.

Then I found (at least one) of the problems. These things have to be commissioned. If you pulse the commission pin like a push button 4 times, they exit whatever they have gotten hung up in and reestablish a network. The coordinator has to be running so it can respond, but they start working and keep on that way until you have a problem or change and have to reflash them. They actually forward from distant nodes and everything. The various breakout boards and usb adapters don't have a commissioning button and some of them don't have an association indicator. Without these, you don't get a clue on what may be going on.

So far, my perfect board would have a commissioning button, association led, xbee reset button, rssi led as well as tx-rx leds. This is the minimum one needs to actually even start to understand these little guys. I'll be doing some modifications when a few parts come in the mail.

I know there are folks out there that have given up on making these work because every time they try something new, the xbees stop working. I still have about a thousand things to try out but some code in the arduino startup script that pulses the commission pin 4 times on startup should cure a whole lot of headaches. For unattended repeaters, a button would go a long ways to solving network problems.

Do you really need commissioning? The only config setting you need to get two xbees to talk is the pan id:

ID=1AAA

Do a factory restore (RE) first to clear any lingering settings.

I'm using Series 2 running zigbee router and coordinator AT software with the modem programmed as XB24-ZB. I spent hours reprogramming, resetting to factory defaults and reprogramming and they were extremely inconsistent until I discovered the commissioning pin. Now I can program them once and cycle power as much as I want on the devices and they come up every time. If I reset the coordinator, it loses comm with the other devices and I have to recommission them to get the net talking again. Note that I can reset the routers as much as I want and there is no problem, just the coordinator blows the network away. This happens if I issue a NR1 command as well, it blows off the entire network and I have to commission each of the routers. I haven't tried the end device yet.

I also saw the action of restoring to factory defaults and then changing the PAN id causing them to work. This is because it makes the device recommission when it comes online. Sort of a roundabout way of doing the commission. If you look closely, you'll notice that nothing has changed in the configuration, it just seemed to quit working and a restore and reprogram got it working. I actually wrote down ALL the settings trying to find out what was making them mess up. Painful process and didn't lead to any conclusions. Next time I'll copy and paste the data instead. I learn slowly sometimes.

I'm going to spend some time reading the documentation for the various levels of software because I'm still seeing some inconsistency at times. For example, I have named the devices and a commission restores the node, but not the name. I have to reset the node to get the name to come back. To make a really robust network you can't rely on hard coded addresses, you need some kind of naming system. If the names don't come back there will be problems later. In simple node to node transparent operation where the addresses are hard coded into each device there are less problems, but they still occasionally disappear.

When they work though, they work great. I can send a broadcast from the coordinator and each node responds; even nodes that have two hops to make the distance. These things have the potential to really open up a network of sensors and controls if I can get them to work reliably. Slow doesn't matter, they just have to work consistently.

I'm starting to solve the xbee mystery to some degree. What people don't tell you is that reprogramming the devices removes the settings that make them work. There are 4 of them that will make your xbees stop talking and all of them can be affected by reprogramming, especially if you get an error while the software is setting the AT commands; this happens frequently.

OP Read the operating 64-bit PAN ID.
OI Read the operating 16-bit PAN ID.
CH Read the operating channel.
ZS Read the stack profile.

Now, most of us don't mess with the ZS command and zero seems to work fine so I leave it alone. The OI is set by the coordinator and we don't get to choose it when we first start up. The CH (channel) is also chosen by the coordinator. The only one we are usually told to mess with is the OP when we set the ID. So, what you have to do is record these when you get a working network and then keep them around to fix the network when you reprogram a coordinator or accidentally issue a network reset.

I can now reliably reprogram the coordinator and get it working on the network every time. Once you have the coordinator working, you can mess with any of the nodes and then get them to rejoin properly by using the commissioning pin and then reset the xbee to reread NI parameter if you are using it.

The scan channel is confusing because it is a bitmask of channels you want to allow to be scanned or in the case of the coordinator allowed to be used. So, I just chose a channel and then set the bitmask to match.

The problem now is that going from AT mode to API mode will always cause the coordinator to lose these items and they cannot be set with at commands because you just switched modes. Still working on that problem. Power cycles, unplugging, hardware resets (like grounding the pin) don't change the settings and the devices will work fine under these conditions.

I have never, ever seen any of this on a tutorial or in any of the books that are supposed to teach us about these things. In a week or so when I understand this better I'll put it on my site. These little devices (once you have them working) are way cool.

I posted the results of my trials and tribulations with XBees on my site. There's also some sample code to help newcomers to these devices get over the hurdle that caused me to pull some of my little remaining hair out over.

So, if you are having trouble getting them to talk after you do something to them, take a look.

It looks simple, but it took me DAYS to find enough information and actually work through it.