Marco's XBee Tutorial


This tutorial explains how to quickly set up a configuration to send data wirelessly from a sensor to your computer, for use of the data in Max/MSP, Processing,  etc.  Total parts cost about $100, plus sensor of choice.  I have tried to include absolutely everything necessary, down to batteries and solder.  This is a configuration requiring *NO* Arduino boards.  I found it to be simpler to do away with the Arduino entirely for this project.


Recommended main parts list:

2 XBee 1mW Chip (2 x $23):

1 XBee Explorer USB ($25):

1 Lilypad XBee ($15):

1 mini breadboard ($4):

1 Voltmeter (~$15):  (e.g. )

1 Soldering iron ($6) and solder ($6):  (e.g.  &  )

1 mini USB cable



(a) AAA:

1 2xAAA battery holder ($2)

2 AAA batteries


(b) Coin battery:

1 20mm coin cell holder ($2)

1 20mm coin cell battery ($2)


Sensor example:

1 Flex sensor ($13)

1 8K resistor, (e.g. from this kit: )


Step 1:  Configuring the XBee's


In this process you will connect and configure both XBee's, one at a time, to your computer.  First you will configure the one used remotely.  This is done by setting some registers using "X-CTU", a program provided by the manufacturer.  The remote configuration will tell the XBee that it should continuously transmit analog sensor data to other XBees in the area.  Then you'll pop that out and configure the computer-side XBee, which really doesn't need much configuration at all.  It just listens and sends the data to the computer on a simulated serial port, so your Max code just needs to read the serial data.


Configuring the remote XBee

First download the X-CTU software:


The "XBee Explorer USB" is how you connect XBee's to your computer.  Choose one of your two XBee’s to be the “remote XBee” and the other to be the “local XBee”.  Pop the remote XBee into the "XBee Explorer USB", then plug it into your computer.  You'll need a mini USB cable.  At this point you'll need to follow the following XBee-configuration program in detail:

(starting with the text "You'll need to figure out which...")


Note if you're using a Mac you'll need to make some adaptations.


I suggest setting the data rate to 19.2kbps.  The default 9600 baud talks better with Arduino, but since we don't care about that here, we want a better bitrate.

Continue to the bottom of that configuration tutorial page.  Now the XBee should have the latest firmware, and be configured to the desired data rate.


OK, now it's time to change the configuration.  See the screenshot:



You'll want it to look like that.  (Ignore the "diagnostics"). 


Probably the only two things you'll have to change (assuming you already set 19.2kbps above) are (1) the register that tells XBee to read pin D2 as analog (register D2 = 2), and (2) the register to set the sampling rate of every 16ms (IR = hex 10 = decimal 16).  Make sure to "write" the new configuration to store it on the XBee.



Configuring the local XBee

Pop out the remote XBee, and pop it into the Lilypad XBee for later.  Now pop the local XBee into the "XBee Explorer USB".  Go through the same initial configuration steps as above.  Then modify your configuration to look like this:



This may not require any modification at all.


Note that these configurations use default settings for XBee identification and networking.  If there may be other XBees in the area, you'll want to set the network and individual id's for each XBee.  For details on that, read pp. 16-22 of the manufacturer's doc below; then the bottom of p. 15 for their example; and also examples on the "XBee analog pins" page below and the "Tweet a Watt" sample at the bottom.



Yes, there's a little bit of soldering.  You could probably test this by wrapping wires around the Lilypad XBee leads, but it'll be frustrating as they keep disconnecting.  Just solder wires onto the "+", "-" and "d2" pads, and you'll be forever happy.


I suggest using the mini-breadboard below.  Plug your battery power into one row.  Also plug your Lilypad "+" into that row so it can receive its power.  (Lilypad "+" can take many volts and convert them to the 3.3V that the XBee chip needs.)  Plug the battery ground into another row, and plug the Lilypad "-" into that row.  The Lilypad power LED should now be on.



For my example I use a flex sensor.  This is a variable resistor.  Connect one end to the "Battery +" row above, and the other end to a *new row*.  Then connect an 8K or 10K resistor from that new row, to the "Battery ground" row.  If you have a pile of resistors and aren't sure of the 8K one, check the resistor table link at the bottom.  Finally, plug the Lilypad "d2" line into the "new row", which you'll remember is connected to both the flex sensor and the 8K resistor.  This row should be producing a variable voltage depending on the flex position.


As a sanity check, you should connect your voltmeter.  Touch the "-" to the "Battery ground" row, and the "+" to the "new row".  This will give you the same variable reading that the Lilypad is getting.


Reading the data:

Great, almost done.  The Lilypad/XBee should now be reading sensor data and sending it to the local XBee (which should once again be connected to your computer via the USB link.)  On your computer, make sure the X-CTU program is closed, since it'll be hogging the serial port.  I suggest opening my Max patch:  XBeePatch.html

Click the "print" button in the patch and it'll output a list of your serial ports.  The XBee will probably be the last on the list, so you'll see something like "Serial: COM 7 port g". Change the Max element that says "port h" to say "port g" (or whatever the COM port is on your computer).  Now click the checkbox to start the timer, and data should start flowing.  You'll see there are a few Max objects to unpack the data.  For this simple configuration, the packaging is straightforward.  There are 14 byte blocks and each one starts with #126.  The actual 2-byte data is in bytes 12 & 13 (counting 1->14).  So just take byte 12 times 256 and add byte 13.  Note that there are actually 10 bits, so if your signal varies all the way from 0 to 3.3V, you'll see values from 0 to 1023.  So if you’re not a Max user, you should be able to easily do this in Processing or your tool of choice.  (If you end up sending more or different types of data in the future, you’ll need to dive into the packet structure more.  A few of the links below have details on that.)


Great, you should now see a graph of your wireless sensor data.  OK, you're done!


Multiple XBee Senders and Receivers


Receivers: It's easy to receive your XBee data at multiple stations.  Just program a second receiver XBee the same as the first.  So, for example, two computers at different ends of the room could each be receiving information from the same sensor.



Data Rate:  When using two simultaneous sending XBee’s, you may want to increase the total data rate to make sure there’s not a backlog of data being received (which will result in big delays and dropped data.)  I experimented with 54kbps at 10ms sample rate from both senders, versus 38kbps at 16ms sample rate from both senders.  The 38kbps seemed more stable.  So to program your XBee for 38.4kbps, use the X-CTU program again (described above), but this time, for all sending and receiving XBee chips, the Interface Rate should be 5 instead of 4, indicating 38.4 kbps instead of 19.2 kbps.

Configuration:  Also in the X-CTU program, for senders only, you want to change the “MY – 16-bit Source Address” attribute.  For the first sender, leave it as “0” (the default).  For the second sender, change it to “1”.

Code Changes:  The XBeePatch Max code provided above will also need a change.  Open the big “Unpack” object with all the zeroes.  Make a connection from the 5th outlet to an integer object.  That value will be 0 when receiving from sensor 0, and 1 when receiving from sensor 1.  Be careful because Max fires the final data outlet first, so it’s good to use a “set”:


Distances:  For either multiple senders or receivers, keep in mind that XBee (using the Zigbee protocol) operates on similar frequencies as the popular 802.11b wireless protocol.  And like 802.11 (I believe), a multiple-XBee configuration suffers (in terms of data rate) when even one of the nodes is at a distance.  For example, if two of three nodes are close to each other, but the third is at the extreme distance range, it will degrade the communication between the first two.  So, when possible, monitor these distances in your application.


Other good references:

Choosing the right XBee for the job:

Common XBee mistakes:

XBee analog pins and resulting packet data:

XBee detailed doc (manufacturer):

Basic LED project:

"Tweet a Watt" XBee configuration sample:

Energy Monitor project:

Resistor table:


HTML Comment Box is loading comments...