In preparation for my next project (an XBEE powered rain gauge) I have been investigating how to collect sensor data with just Digi XBee modules. So far all my sensor projects have used an Arduino to collect data then use either WiFi or XBee to send the data to my server for processing. It turns out that the XBee modules have 12 digital input/output and 4 analog input pins that can be used directly. For basic sensor projects it should be possible to use an XBee to collect sensor data without the need for an additional micro-controller such as the Arduino.
There is plenty of information on the web about using digital IO with Series 1 XBee, but I have the Series 2.x ZB modules. Digital IO works quite differently on Series 2.x than to Series 1, so I thought I’d share how I got a basic setup working.
For this setup I used:
- Two XBee Series 2.x modules
- Sparkfun XBee Explorer USB
- Sparkfun Explorer (Regulated)
- Digi’s X-CTU software
- FTDI Serial USB driver
- Breadboard and jumper wires
- Push switch, LED and a resistor
Setup X-CTU and FTDI drivers
Both XBees are going to need upgrading and extra configuration. For this you need to have Digi’s X-CTU software running on a Windows PC. I have the XBee connected to the PC a the Sparkfun Explorer USB.
If you haven’t used the Explorer with X-CTU before you will first need to install the FTDI Serial USB driver on your PC. Download and unzip the driver archive from here to a temporary directory. The drivers don’t have an installer. Carefully plug an XBee module into the Explorer USB (make sure you get it the right way round) and plug that into a free USB port on the PC. Windows will probably complain it can’t find an appropriate driver. Open Windows’ Device Manager and look for a USB device with a yellow exclamation mark. Right click the device and update the driver, choose the directory where you unzipped the archive when prompted for a driver location. I had to repeat this a couple of times to get rid of all the exclamation marks.
Download and install X-CTU from Digi’s web site. It does have a regular installer so installation is straightforward. After installation has finished, run X-CTU and you should see the USB port with your XBee Explorer listed. Select that port and click the test button to ensure everything is configured OK.
Upgrade XBee firmware
By default, XBees come with the Router firmware installed. On both my Xbees the firmware version pre-installed was not the latest version so I updated both. One module needs to be configured as a Coordinator. For digital IO to work, the Coordinator must use the API version of the firmware. The other module I just upgraded to the latest Router AT firmware.
Configure the Sensor XBee (with Router firmware)
Although you can use the XBee’s command mode and AT commands to configure the module, it is much easier to configure the module using X-CTU.
- PAN ID (under Networking)
This identifies the network to use. If you don’t set this, the modules are supposed to negotiate a common PAN ID but I haven’t had much luck with that. I find it simpler to just choose a number a set all XBees to that number.
- DH and DL (under Addressing)
This is the destination address where this module will send all its data. Each module has a unique number which is made up of a high and a low value. As a convinience the Coordinator can also be addressed as 0/0, so make sure both DH and DL is 0 (zero).
- D0 (under I/O Settings)
Setting this to 3 enable the D0 input pin for Digital Input.
- Digital IO Change Detection (under I/O Settings, I/O Sampling)
Using Change Detection means that the XBee will send a message to the DH+DL (i.e. the Coordinator in our case) whenever the reading at the pin changes. This setting is a bit field, where each bit represents an individual pin, that allows you to enable Change Detection on specific pins. I’m lazy so I just enabled it on all pins by setting it to FFFF 🙂
Configure the Server XBee (with Coordinator firmware)
The only configuration change I had to make to the Coordinator was set the Pan ID to be the same as the Router XBee.
Prepare the Explorer (Regulated)
In theory I could just connect a few wires to an XBee to make this work, but the break out board has a few benefits. Firstly it means I can swap an XBee in or out of this project without breaking anything. Secondly the break out board has a built in 3.3v voltage regulator so I will have more options for powering the project later. It also has a few status LEDs so I can see what’s going on. To use the break out board with a breadboard you need to solder on some pin headers. I decided to put two full strips of pins on mine just give me a few more options for experimentation.
Build the circuit
With the extra pins soldered to the Explorer it’s simple enough to build a simple test circuit on a breadboard. The diagram below shows the layout on the breadboard but with out the XBee fitted so its easier to see the wires.
There are four connections to the Explorer; 5V, 3.3V, Gnd and D0. The regulated 3.3V is used to drive the switch circuit. Never, ever put more than 3.3V directly into an XBee (thanks go to N8 for pointing this article out). D0 is connected to the switch circuit between the LED and the resistor. The resistor will pull the pin LOW when the switch is not being pressed.
Power Up and Test
All that remains is to power everything up and test it. Ensure that the Coordinator module is in the XBee Explorer USB and connected to the PC and that the Router module is in the Explorer (Regulated) on the breadboard. X-CTU should be running on the PC and the Terminal tab selected. Connect a power supply to the breadboard and you should see the power LED light up on the Explorer. When you press the switch you should see the RSS LED light on both the Regulator’s and Coordinator’s Explorers, and you should see the received data displayed in X-CTU. When you release the switch you should see another message in X-CTU. After a short while of inactivity the RSS lights should go out to show that the modules have disconnected.
Interpreting the Data
X-CTU displays the complete API frame as received by the Coordinator. The message starts with a delimiter byte, 0x7E. The next 14 bytes are header information that mostly describe message length, 64bit and 16bit message sender addresses. The next 6 bytes are what interest us. I have laid them out in a table below and provided values for when the switch is down (pressed) and up (released).
|Bytes||Name||Notes||Switch Down||Switch Up|
|1||Sample Sets||Samples in packet, always 1||0x01||0x01|
|2||Digital channel mask||Which digital inputs have sampling enabled||0x00 0x01||0x00 0x01|
|1||Analog channel mask||Which analog inputs have sampling enabled||0x00||0x00|
|2||Digital IO data||Actual data values||0x00 0x01||0x00 0x00|
The final byte is a checksum byte to help verify message integrity.