Xbee communication

I've had some odd problems with the XBee modules I have.

tl;dr I changed them from ZIGBEE (coordinator/end) to ZNET 2.5 (coordinator/end) and it seems to have fixed it.
If you want to know more, read on.

As it happens, when I went to buy them from littlebird electronics, they only had series 2.5 modules. I did read that they are not compatible with series 1, but thought that it was likely that 2.5 would be overall better. As it turns out, series 1 may have been better, at least where one is communicating in a transparent serial way, between just two nodes. Later, the features of 2.5 may come in more useful.

Another bugbear of the 2.5 series is that they don't do I/O line passing, ie the serial control signals like RTS, CTS etc, which means you can't treat them like a full transparent serial interface. Which means you can't set them up to be able to upload arduino code wirelessly. This is not essential as my car will not be inaccessible, but would have been nice. There may be ways to do it by sending a reset command at the right time, then hitting upload at the right time, but meh.

Back to my problem. When I originally configured them, I followed a tutorial, and was delighted to see they worked very well, fast and reliable! Later they started doing odd stuttering things, where the car would just stop responding, then maybe several seconds later suddenly start moving, like it had some of the commands buffered and had just gotten to them. This may be partially due to power issues I had. Then I stopped receiving any data at all from the car, which was annoying as I needed to debug the controls (the car would send back what action it had just performed).

I had, as per the tutorial, configured the modules as "ZIGBEE COORDINATOR AT" and "ZIGBEE ROUTER/END DEVICE AT". What this means is that they use the Zigbee protocol, one is the coordinator and the other is the end device, and they interface using the AT protocol. In a mesh, there can be multiple end devices which can either talk both ways with the coordinator, or use the broadcast address to talk to all at once. For a single peer to peer connection, imitating a wired serial connection, the devices are configured with eachother's high and low serial numbers, so they only talk to eachother. The AT protocol is the way one configured the old dialup modems. The other option is API which I won't go into here.

Another tutorial contradicted this and said I should configure it as "ZNET 2.5 COORDINATOR AT" and "ZNET 2.5 ROUTER/END DEVICE AT". I was dubious that this would fix it, because it had worked earlier, and the whole coordinator/end thing sounded basically the same. Also I had real trouble reconfiguring one of them; it seemed to not respond to attempts to rewrite the firmware. I eventually found a post here which worked for me; without having to wire up a reset switch or something, this was a lot simpler. It boils down to:

1. pull the module out of the usb or breakout board
2. write the firmware with X-CTU
3. it will complain that it can't find the device. when this happens, smoothly reinsert the module (don't miss or bend any pins).
4. it will write the firmware, and possibly complain about not being able to set the AT commands. but the important part is done.
5. re-read the module, and you will need to configure it again as it has had defaults written.

I configured the modules to talk to eachother peer-to-peer again, and it's worked great since!

Here is a page with a lot of useful notes about XBee modules in general:
Xbee Znet and gps (RoboSci Blog)