So lately I’ve had a need to include wireless communications in some projects and after much research I chose to tackle the XBee platform. This was for many reasons but to just name a few; robust, reliable, industry standard, well supported and simple to utilise with even the most basic understandings. Anyone who has dealt with wireless technology will understand that it is inherently SH%$#T and packet loss is always a probable outcome. I recall installing wifi into hotels and finding strange black spots and all sorts of issues that where often difficult to overcome, so no wireless installation will be troublefree but XBee does their best in ensuring their data gets to the other end. This post is intended to give a quick guide to the Series 1 802.15.4 XBee platform and all of my “messing around” is done using the Arduino platform (ATMEGA328 / ATMEGA2560).
The device has a very small footprint, with only 10 pins each side at a 2mm pitch it makes for a very small module. The pinout is “upgradable” with other XBee modules so if the need arises for more juice (Xbee Pro with the 802.15.4 firmware extends range) or similar you can just swap the thing out. As far as function goes I am only using it as a “serial” link between two devices so I’m not going to cover this however it has a number of ADC inputs and some outputs too that can be accessed and configured over the air which is very cool.
The Exciting stuff (Addressing and packet management)
This is where the XBee comes into it’s own, as far as a robust Point to Point system goes you can’t beat the XBee. It has a 0 – FFFF range for addressing in its 16Bit Address mode, which allows for an astonishing 65,535 different addresses. And ontop of that it has a 0 – FFFF range for Area Network ID’s so another 65,535 Networks can be configured. The device has two modes of communications. Unicast which is where the device is programmed with a destination address (DL), an area network(ID), and a address for itself (MY) the system will communicate only with the destination address(DL) that it is told to when being configured. In this mode the XBee system will also reply with ACK or Acknowledgement messages to indicate that the message was recieved and a number of retries will be performed to ensure the message has every chance of getting to the other end or the DL. This mode is great for Point to Point Serial Communications, queue Bill Porters EasyTransfer a couple of Arduino’s with Xbee modules and you have yourself all sorts of cool wireless ideas!!
The Other mode for communications is BROADCAST mode, in this mode a XBee’s DL address is programmed with FFFF which changes its operation to have no destination for its communications. When it sends a packet now it will send it to ALL XBee’s in range that are in the same area network, the fun part of this is that even if a device in the same network is in UNICAST mode it will also receive the broadcast messages! So you can effectively back multiple UNICAST XBee’s talking to one “master” which replies to ALL the UNICAST Xbee’s at once. The downside to BROADCAST mode is that there will be no ACK or acknowledgement reply message, so the device broadcasting will not attempt to resend a message if it was lost or not completely received at the other end as it will not know the status of the received message, this is a no brainer Consider this, a Wireless network with hundreds of Xbee’s, one Xbee sends information to the entire network in BROADCAST and then gets absolutely saturated with SCK messages! It would just not work or would have massive delays and packet loss). This can be overcome to a degree by increasing the retries in the XBee module that is configured for BROADCAST or even just sending your packets multiple times with an incrementing variable attached and some smarts in your program at the other end to recognise the “repeat” messages, this will serve to increase the likelihood of information getting through. Also another thing to note, from my understanding an XBee device WILL send an ACK message to another XBee that is in UNICAST. IE if a XBee in UNICAST sends its packets to a “Master” XBee that is in BROADCAST the XBee in BROADCAST will send an ACK.
Setting up the XBee
I would strongly advise that prior to hooking up the XBee to anything you plug it into an XBee Serial programmer then connect it up to your PC/Mac and run the X-CTU software available from DigiInternational (the manufacturer of the XBee). Using this software is the simplest way to program the device and also opens your eyes to all the other functions that I won’t cover here.
Programing the XBee is a simple task, once hooked up and connected to your PC/Mac you run the X-CTU software, pick your COM Port for the Xbee that is connected and go to the Modem Configuration Tab. The default 9600 Baud and other settings will be correct should the XBee be brand new. In the modem configuration screen you simply click “Read” and it will read the current settings from the XBee module connected. The settings we are interested in are the following
ID – PAN ID
This is the Area Network ID a value from 0 – FFFF can be entered here, I would advise picking a number at random for your network. You will need to enter HEX here unless you keep your numbers less than 9999
DH – Destination Address High
This we will set to ‘0’. By assigning this to zero we are configuring the device to use 16-Bit Addressing, this is the mode I’ll cover here.
DL – Destination Address Low
This is the Destination address for communications. It is to be the MY address of the device we are trying to talk to! Unless you want Broadcast mode, in which case enter FFFF here.
MY – 16-bit Source Address
This is the source address or I refer to it as the physical address of this device a figure between 0 and FFFF.
Points to remember;
- The ID (PAN ID) of each device to talk to each other MUST be the same.
- the DH should be ZERO as a digit 0.
- The DL Address is the DESTINATION for your information. Effectively the MY address at “the other end”. Unless you are in BROADCAST mode.
- The MY should be an address that is NOT used by any other module in the network.
A few other things to consider here. There is a value called RR which refers to XBee retries. The 802.15.4 protocol covers 3 retries by default from my understanding, each additional retry you add here will execute another 3 retries, someone correct me if I am wrong here. This can be a value between 0 and 6, if you are sending large packets of data over Serial and you have a high retry rate you can cause delays in sending and receiving while the XBee is still performing retries, I typically try to keep my packets smaller with a increase in retries (about 2 or 3 in here).
Next is the Baud Rate, if you scroll down to “Serial Interfacing” you will be able to modify default serial settings, the XBee S1 can do all sorts of Baud rates, even non typical ones if you use a serial terminal to configure it! I typically change this to either 19200 or 38400 as I’ve found the XBee is a little unreliable when my code is putting it into ATMODE and the Baud rate is above 38400. I ended up settling on 19200 which is plenty for my applications.
To perform all of these configurations above using a Serial Terminal OR even from your code you need to enter AT Mode. I will cover this in a later Guide as this one is getting a bit long 😐
Ok so you have a couple of XBee S1 802.15.4 modules and you want to get them working for you. First off is something to remember and this is VERY important, XBee modules operate at 3.3V!!
Remember this when setting it up. Many of the available shields and whatnot come with a VREG on-board so this is often the safe route to go. Provide ground, power and hook up your RX and TX to your chosen device for prototyping (Arduino in my case for these tests). remember that RX for the XBee will go to TX from the MCU and TX from the XBee will go to RX from the MCU. Once you have configured your XBee’s with the appropriate addressing and you’ve hooked them all up it is time to use your wireless network! I would recommend starting off with one of the XBee modules hooked to the computer and in the X-CTU you can select the Terminal tab which will show you the data being received, this is handy for debugging communications, I often will configure an XBee up to check on communications by watching the information coming through.
I hope this was helpful, I haven’t gone into as much detail as could be for these very clever and very reliable/robust devices as there are many many page documents out there covering it all, but I hope this helps peeps get a handle on Serial communications over wireless and can get your projects under way! I’m thinking wireless RFID scanners talking to a computer to verify ID’s, or wireless Christmas lights running from an Arduino Mega and being controlled by a computer, I don’t know what your ideas are but share them in the comments! PS for Arduino to Arduino communications I urge you all to check out Bill Porters EasyTransfer library, it is incredible and easy to use!