My ultimate aim is to wirelessly network several Arduino based platforms with a centralized Raspberry Pi controller. There is much for me to learn to get this operational, not the least of which is the radio device I plan to use, the Xbee.  To get up to speed on the Xbee, I found the tutorials at AdafruitSparkfun, and Parallax helpful.   More detailed references are listed at the end of this post, but the very first challenge is to configure the XBee radios for operation.  This post provides insight on how this can be done, and my main mission, create a few simple utilities that make that job easy.

I purchased two XBee Series 1 Module (Freescale 802.15.4 firmware) from Adafruit.  These are manufactured by Digi and are low-power module with wire antenna  (XB24-AWI-001).  They have a 250 kbps RF data rates and operate at 2.4 GHz.  These radios use the IEEE 802.15.4 networking protocol and can perform point-to-multi-point or peer-to-peer networking , but as configured here, they do not mesh.  The Digi models that handle meshing are Digimesh, ZNet2.5 and Zigbee (ZB).  Digimesh is a version of firmware that runs on Series 1 hardware. So, if you choose to, you can upgrade these modules to Digimesh firmware to get meshing.

Along with the XBee radios, I purchased adapter boards designed to make it easier to work with the radios. The adopter provides on-board 3.3V regulator power from a 5 volt source, voltage level shifting circuitry so you can connect  5V circuitry to the XBee, commonly used pins are brought out along the edge (making it easy to breadboard), and engineered to be interface via FTDI cable to a computer via USB.  The image and the text below describe the pin-out for the Adafruit  XBee Adapter:

1. 3V pin - This is either an input power pin (if 5V is not provided) or an output from the 250mA regulator if 5V is provided
2. DTR - "Data terminal ready"  is a flow control pin used to tell the XBee that the microcontroller or computer host is ready to communicate.
3. RST - "Reset"  pin can be used to reset the XBee.  By default it is pulled high by the 10K resistor under the module. To reset, pull this pin low.'
4. Ground - common ground for power and signal
5. CTS - "Clear to Send" this is a flow control pin that can be used to determine if there is data in the XBee input buffer ready to be read
6. 5V - This is the power input pin into the 3.3V regulator. Provide up to 6V that will be linearly converted into 3.3V
7. RX - "Receive Data" is the XBee's serial recieve pin. Serial data is sent on this pin into the XBee to be transmitted wirelessly
8. TX - "Transmit Data" is the XBee's serial transmit pin. Serial data is sent on this pin out of the XBee, after it has been transmitted wirelessly from another module
9. RTS - "Ready to Send" is a flow control pin that can be used to tell the XBee to signal that the computer or microcontroller needs a break from reading serial data.
10. see pin #1
The DTR, RTS, RST and RX pins (going into the XBee) pass through a level converter chip that brings the levels to 3.3V. Adafruit claims you can use pretty much anywhere between 2.7 to 5.5V data to communicate with the XBee. The breakout pins on the bottom of the board are not level shifted and you should try to keep data going directly into the XBee pin under 3.3V

## XBee Initial Configuration and Testing

You need a way to communicate withe the Xbee, via it adapter,  to set it up.  This can be done via Adafruit's  USB FTDI TTL-232 Cable, and the Digi X-CTU serial terminal program.  By the way, the X-CTU user guide describes the many more things it can do beyond the configuration shown here.

1. Plug in the USB FTDI TTL-232 Cable into a PC USB port.  If drivers are not installed automatically (it didn't for me), follow the steps at the FTDI site.
2. Download the X-CTU, double click on the executable file, and follow the instructions to install the program.
3. Now connect the USB FTDI TTL-232 Cable to the Xbee Adapter as shown in the picture to the right and insert the USB end of the cable to you PC.  Start the X-CTU.
4. To connect, configure and upgrading the Xbee, follow the Adafruit instructions for the Xbee Adapter board. Note that if you follow the instructions (I didn't - I kept it at 9600 baud), the modem's serial interface is now set to 19,200 baud, not the default 9600 used by X-CTU.  Remember this next time you use X-CTU with this Xbee.
5. If your instructed by X-CTU to reset the Xbee, you can do this by shorting the reset pin, RST pin,  to ground.
The configuration can be touchy, it can go badly, or not at all.  In my case, I seem to have one Xbee Adapter that can reliably perform a firmware upgrade but the other one took some time due to a lose fitting between the Adaptor and  Xbee.  If you run into configuration problems, check out these sites: Using XCTU to Invoke the BootloaderThe Unofficial XBee FAQ,  How to recover from a failed firmware upgrade.

## Quickly Getting the Xbee's Communicating

The next step for me was just do a basic test of getting two XBee device communicating with each other. This is just a sanity test to see evidence of communication between the devices. Basically, I just followed the instructions provided by Adafruit.
1. Using the X-CTU, set the PAN ID to the same value on the two Xbee's.
2. Select an Ardunio that has been programmed to send repeated brief messages to its serial port.  I used the standard LED Blinking sketch but put in some write statements in the loop.
3. Using an Arduino and breadboard, connect +5V and ground to provide power. Make sure the XBee's LED is blinking.
4. Connect the RX line (input) of the XBee to the TX line (output) of the Arduino. Connect the RX line (input) of the Arduino to the TX line (output) of the Xbee. Plug the Arduino into your PC's serial port.
5. Now take the second Xbee and connect the  USB FTDI TTL-232 Cable to the Xbee and the PC.  The cable is doing nothing but appling power to the Xbee.
6. Now you should see the receive LED periodically light on the USB FTDI TTL-232 Cable tethered Xbee.
7. You now got proof that the two Xbee's are communicating.  The Arduino connected Xbee is sending data to its serial port and the USB FTDI TTL-232 Cable tethered Xbee is receiving it.
Above you'll find a picture of the configuration, and below is the Arduino sketch I used.

/*
*  Xbee Test via Blink LED
*
*Turns on an LED on for one second, then off for one second, repeatedly.
*Also increase brigthness of analog LED.
*
*The circuit:
* LED1 connected from digital pin 13 to ground.
* LED2 connected from analog pin 9 to ground.
* Note: On most Arduino boards, there is already an LED on the board
* connected to pin 13, so you don't need any extra components for this example.

*Created 1 June 2005
*By David Cuartielles
*based on an orginal by H. Barragan for the Wiring i/o board
*Modified by Jeff Irland in December 2012
*/

int ledPin1 =  13;    // LED connected to digital pin 13
int ledPin2 =  9;     // LED connected to analog pin 9
int brightness = 0;

// The setup() method runs once, when the sketch starts
void setup()   {
Serial.begin(9600);
pinMode(ledPin1, OUTPUT);     // initialize the digital pin as an output
Serial.println(&quot;Arduino done with setup()&quot;);
}

// the loop() method runs over and over again,
// as long as the Arduino has power
void loop()
{
digitalWrite(ledPin1, HIGH);   // set the LED on
Serial.println(&quot;LED set HIGH.&quot;);
delay(1000);                   // wait for a second

digitalWrite(ledPin1, LOW);    // set the LED off
Serial.println(&quot;LED set LOW.&quot;);
delay(1000);                   // wait for a second

brightness = brightness + 5;
analogWrite(ledPin2, brightness);
Serial.println(&quot;LED brightness increased.&quot;);
}


## Installing XBee Python Tools for the RPi

While the MS Windows based Digi X-CTU tool is just fine, I want to use the RPi's and Python to access the XBee serial communication API, and its advanced features, for one or more XBee devices.  I prefer simple utilities, that can be scripted within the Linux shell.  Call me a Linux snob if you wish, but I don't care for MS Windows!

In my post "Selecting XBee Radios and Supporting Software Tools", I referenced a Python package that could be used to create my utilitiesd, call python-xbee, and I will be using it here. It claims to provides a semi-complete implementation of the XBee binary API protocol and allows a developer to send and receive the information they desire without dealing with the raw communication details. It also claims the  library is compatible with both XBee 802.15.4 (Series 1) and XBee ZigBee (Series 2) modules, normal and PRO.

First, we need to load some additional required Python Packages, that being pySerial and Nose. pySerial extends python's capabilities to include interacting with a serial port and Nose is a package providing a very easy way to build tests, based on the Python class unittest.  (Don't let this all scare you away, these are necessary but your not going to use them directly).  To load these package:

sudo pip install pySerial
sudo pip install nose


Download the python-xbee tools from Google Code or Python Org and place them into the RPi's $HOME/src. The README file provides installation instructions. It states that the following command automatically test and install the package for you: sudo python setup.py install  There is a simple to use RPi platform tool that I have modified for my needs, that is a XBee serial command shell for interacting with XBee radios. It performs the core functions of the official configuration tool, X-CTU, which only runs on Windows. (There happens to be a cross-platform version of X-CTU called moltosenso Network Manager but I don't need all this horse power.) I'll use this X-CTU-alternative to configure the individual XBee radios. With the X-CTU, you can update firmware, etc. but most of the time you need the program to do simple configuration tasks. You could use Linux's minicom, but I prefer a simpler tool which can be scripted so I can configure several XBee radios identically. I found much of what I wanted in an existing Python XBee tools for configuration. I made some modification/improvements, I call it the XBeeTerm, and its listed below: The XBeeTerm.py module imports functions from the pretty.py package, specifically to colorize the output for xterm on the Raspberry Pi. This package is provided here: ## Identifying the RPi USB device used by the XBee Since the python-xbee library wants to talk to the via a Linux serial devices, I'm using the USB FTDI TTL-232 Cable (FTDI is the USB chip manufacturer) used in the XBee configuration step done earlier. I connected the cable to the RPi USB port and then we need to find the serial tty the cable is associated with. To do this, it takes a bit of detective work. Run the commands: lsusb dmesg | grep Manufacturer dmesg | grep FTDI  A better command might be (but I'm not sure it will work every time): dmesg | grep -i usb | grep -i tty  The interpretation of the output tells us the cable is attached to serial device /dev/ttyUSB0. See the output below. Another possibility is to use udevadm to gather information about specific devices but I never figured out exactly how to use it to answer my question. Python also has a package called PyUSB that might provide some help, but also here you'll still need the vendor and product identification information. Chances are that when you plug the cable into the same USB port the next time, it will default to the same tty but there is no certainty. To assign a permanent tty name to the device, and never do any of this again, check out Persistent names for usb-serial devices. ## Configuring the XBee Radios for API Mode The configuration and testing of the XBee's done earlier was done in AT Command mode (Transparent Mode). In AT mode, everything sent to the RX line of the XBee radio will be sent out via the antenna, and all the incoming data from antenna will go to the XBee's TX line. This is why we could check the sanity of the XBee radios in the earlier section, XBee Initial Configuration and Testing using a simple Arduino sketch. We sent junk to the XBee and it transmitted it! Now we'll configure two XBee radios (with a Coordinator and a single End Device) to form a network using API Mode. In API Mode, XBee won't send out anything until it received the correct form of commands from the serial interface. The XBee AT Command Set (page 27), specifically the ATAP 2 command, allows you to configure the XBee radio for API Mode. So why API Mode, consider the following: • When sending a packet, the transmitting radio receives an ACK, indicating the packet was successfully delivered. The transmitting radio will resend the packet if it does not receive an ACK. • Receive packets (RX), contain the source address of transmitting radio • You can configure a remote radio with the Remote AT feature • Easily address multiple radios and send broadcast TX packets • Receive I/O data from 1 or more remote XBees • Obtain RSSI (signal strength) of an RX packet • Packets include a checksum for data integrity The XBeeTerm utility will easily configure the XBee radios for API mode and set the appropriate network parameters. To get a deeper appreciation of configuring the XBee radios, see the References at the end. For here, I'll just run through the steps using the XBeeTerm.py tool and the configuration commands used, documented in file scripts. Coordinator Configuration File: Config-Coordinator.txt End Device Configuration File: Config-End-Device.txt As they stand right now, these files could not be processed by XBeeTerm.py because of the comments (included to make the contents understandable). To clean this up, the command sed '/^#/d; s/([^$])#./\1/'will remove all shell type comments from a file and sed 's/[ \t]$//'will remove unneeded white space. Putting this all together and you can use this to prepare the above files for XBeeTerm.py: sed '/^#/d; s/$$[^]$$#.*/\1/' Config-Coordinator.txt | sed 's/[ \t]*$//' > coord.txt
sed '/^#/d; s/$$[^]$$#.*/\1/' Config-End-Device.txt | sed 's/[ \t]*\$//' > endd.txt


Now execute the following python XBeeTerm.py coord.txt and you get the output below:

The yellow text is responses back from the XBee serial terminal and the red text is from the XBee radio itself.  Since all the red text is "OK", all the commands took and the XBee radio is now configured as a Coordinator.  Now repeat this for the End Device XBee radio.

In this example, I have one End Device but what if you have multiple devices, do you need a Config-End-Device.txt file for each end device?  The only change within the configuration file is the radio's address, which is established via the ATMY command.  Here is a trick to avoid the need for multiple files.  First, configure all your End Devices using the configuration file.  Then, for each radio, modify the ATMY use the following:

echo -e "baudrate 9600\nserial /dev/ttyUSB0\n+++\nATMY AAA1\nATWR\nATFR\nexit" | python XBeeTerm.py


but for each End Device radio, increment the ATMY address by one (e.g. AAA2, AAA3, ...).

## Querying XBee for Configuration

Now that we believe the XBee radios are properly configured, lets verify that by query the radios.  You could use XBeeTerm to perform this function by including only the AT Command without the parameter but I wanted a more informative tool. For this, I have created another utility that can take a list of AT Commands as arguments and query the XBee radio for the AT's parameter value.  This utility, call XBeeQuery.py, is listed below:

Here is a sample output for the XBeeQuery utility:

## References

Configuring the XBee Radios General Documentation