I’ve been using the Digi International Xbee radios in a project at work, and I thought I would share a few findings that weren’t always clear on some of the internet guides I found. I use the Series 2 (or ZB) version, which you can get at Mouser for $17. These have the ability to use the mesh networking feature of the Zigbee protocol.
The first bit of disinformation I have found regards the use of API or Transparent mode. The first uses a packet of bytes to tell the radio what data to send, how to send it, and where to send it. The second allows serial data to be transmitted directly, without the need of a frame. Most tutorials indicate that all your radios should be set up in one mode or another. This is incorrect. Dave over at Desert Home tipped me off to this, and has a bunch more excellent examples of using Xbees. I guess I should warn any readers that this discussion is for those who have some knowledge of Xbees already, and understand terms like API, transparent, Router, Coordinator, and PAN ID. Otherwise, Dave’s site is a great place to get started, as is Jeremy Blum’s tutorial.
I can think of a very valid reason for using a mix of transparent and API modes, and it has to do with the how easy it is to change the settings in each mode. In transparent mode, changing the destination address, or any other setting for that matter, requires entering command mode. This is not too bad if you’re connected to a serial port display like Putty, but can be a bit cumbersome when using a micro-controller or some other programmed interface. In API mode, however, the packet can be constructed to change the settings on the fly rather easily, because you don’t have to put the radio into a special mode, you just have to know how to build the right packet (something that micro-controllers are very good with).
So why would you ever use transparent mode with an Arduino, for instance? Because there are plenty of times that you don’t need to change anything. You just need to configure it once to send serial data to a known destination (usually the Coordinator, but the other most common destination is Broadcast, which sends the data to every radio on the network). And yes, you can use an API Router with an transparent Coordinator, if you’d like. The point is that you can mix and match the radio setups.
That leads into the next bit of disinformation, that the radios have to have the same baud rate, API mode, etc. The truth is that only some of the settings on the radio regard how it communicates on the network: PAN ID (both 16 bit and 64 bit), serial number, destination address, operating channel, and the like. In the X-CTU software, these are grouped together under the Networking and Addressing categories. Security is another big one, but not often used.
But the category of Serial Interfacing, which is where settings are most often changed, only deals with how the radio communicates with it’s host, whether that’s a computer or an Arduino. If you have one radio transmitting in API enable 2 set, you must provide escape characters when you assemble your packet. But if the receiving radio has API enable 1 set, that data will be read out with no escape characters.
And one last thing to remember, which I haven’t seen anywhere else: Xbees want to be on a network. They will seek out whichever is available unless they think they are already on one (which has burned me a few times). And if they are a Router, they don’t need a Coordinator in the network to get new nodes to join. According to the Xbee data sheet:
A coordinator has the following characteristics: it
•Selects a channel and PAN ID (both 64-bit and 16-bit) to start the network
•Can allow routers and end devices to join the network
•Can assist in routing data
•Cannot sleep–should be mains powered
•Can buffer RF data packets for sleeping end device children.A router has the following characteristics: it
•Must join a ZigBee PAN before it can transmit, receive, or route data
•After joining, can allow routers and end devices to join the network (emphasis mine)
•After joining, can assist in routing data
•Cannot sleep–should be mains powered.
•Can buffer RF data packets for sleeping end device children.
An end device has the following characteristics: it
•Must join a ZigBee PAN before it can transmit or receive data
•Cannot allow devices to join the network
•Must always transmit and receive RF data through its parent. Cannot route data.
•Can enter low power modes to conserve power and can be battery-powered.
In other words, if you are working on a set of radios, and decide to set up a different network nearby, even if you remove the Coordinator from it’s power, your new radios will try to join the first network if any of the Routers are still powered. It can cause all kinds of fun and hours of entertainment! The best bet is to remove all power to the first network, set up the second network, and make sure the second is configured properly before powering up any Router or Coordinator on the first network.
I’m sure there’s lots more to learn about these great little radios, but I thought I’d pass along these tips now.
Gnardo Polo 