XBee issues

Hi all,

I'm a bit stuck with some of the XBee stuff.

My aim is to get 6 XBee modules, each connected to a switch and powered by battery, to send their switch data (1 or 0) to another XBee which is sat on an Arduino (on an XBee shield). Like the pic below:

Switch Switch Switch Switch Switch Switch XBee XBee XBee XBee XBee XBee || || || || || || || || || || || ||

\/ \/ \/ \/ \/ \/

|| || \/ XBee || || \/ Arduino || || \/ Computer

All the tutorials I can find only address programming the arduino wirelessly.

Could someone tell me which attributes of the XBee I need to change in the X-CTU software to get them all transmitting to the one receiver on the arduino?

Thanks, Chris

EDIT: I'm using the XBee series 2

This is really easy. You can use change detect with I/O samples on the remote xbees. The remotes will send a packet to the main (coordinator) whenever the i/o pin goes low.

I’m not sure why you have a arduino between the xbee and computer, unless you are just using it as a usb-serial (unchipped). You can use this software http://code.google.com/p/xbee-api/ to collect the samples on your pc or this http://code.google.com/p/xbee-arduino/ to collect the data on an arduino/xbee. The dev guide talks about i/o samples and change detect http://code.google.com/p/xbee-api/wiki/DevelopersGuide


Hi Andrew,

Thanks for your reply. I'm sure it is easy but there is something i'm not getting atm. Here is what i'm doing, maybe you can point me in the right direction?

From X-CTU, i've set one XBee as the "ZNET 2.5 COORDINATOR AT" with the default settings (CH - 10, OP-234, ID-234, SC-1FFE, DH-0, DL-FFFF etc.)

I've then plugged this one into the XBee sheild ontop of the Arduino. I tried uploading the "Series2_IoSketch" with the sheild on (jumpers in the USB position) but got an error so I removed the sheild and uploaded the sketch (maybe the sheild and XBee need to be connected when uploading?). Then put the jumpers back to XBee positions.

Again, from X-CTU, I set the second XBee as the "ZNET 2.5 ROUTER/END DEVICE AT" with the default settings (same as the coordinator). Except I changed the D1 - AD1/DIO1 Configuration to "DO LOW". Which I presume should send the DIO1 as LOW to the coordinator XBee.

I open up the serial window in Arduino and see only a "ü". Thats it. I've also tried setting the DIO1 of the router to HIGH and shorting it to emulate a swith but still nothing. Can you see what i'm doing wrong?

Thanks for any help, Chris

Hi Chris,

The I/O samples feature requires API firmware. With API firmware you communicate with the radio by sending/receiving packets. Just load the API firmware on there and you should be good.

Even with AT firmware, you should not have gotten any errors when uploading. When the jumpers are in the usb pos., the xbee is not involved. I think you may need to unplug the usb cable before switching the jumpers.


Hi Andrew,

Thanks again. I've tried to upload the API firmware but with little luck. The "ZNET 2.5 COORDINATOR API" function set uploaded after a fre resets but the "ZNET 2.5 ROUTER/END DEVICE API" will not work. I keep getting the error:

"Error setting AT parameters. Either parameter is not supported or value is out of range."

Am I correct in thinking that the standard XBee series 2 modules need the modem XB24-B?

While writing this, I got it to upload. Even so, I still get the same ü in the arduino serial window. Any other thoughts?

Thanks, Chris

Whoa, don't short your radio! You need to set D1 to digital input, not DO low. DO low would just set the pin at GND and nothing would ever happen -- not interesting.

First do the basic config here http://code.google.com/p/xbee-api/wiki/XBeeConfiguration Now your radios should be talking.

Then look at the I/O samples section here http://code.google.com/p/xbee-api/wiki/DevelopersGuide and configure your remote radio for i/o samples and change detect.

Now when you connect D1 (or whatever pin you configured) to ground, it should send a sample to the coordinator, and when you remove GND it will send another sample, indicating D1 is high (technically it's floating).

I'd like to interject here - chris is having similar problems to mine with X-CTU; you are right in using XB24-B for series 2, but I think I damaged my end device when just connecting 3.3, gnd and sensor (off for now) to D0 (you are using D1). I am trying to track down what to do with the din/dout pins. Digi says to connect them (to what?) but then they say idle pins need not be connected.

I've tried uploading the "ZNET 2.5 COORDINATOR API" time and time again but still I get the same error:

"Error setting AT parameters. Either parameter is not supported or value is out of range."

After I click away from the error, various settings are highlighted as ERROR.

ZNET 2.5 COORDINATOR AT seems to uploaded with less problems but I always get the error:

"Detected baud rate difference. Make sure PC and modem baud rate is set correctly"

I've checked and checked and both the baud rate in PC settings and in the parameters are set to 9600.

@Andrew: i typed it incorrectly before but i'm not setting DO to LOW. It was D1 that I was setting to LOW.

Can I do what I want with the AT function set instead of API?

Thanks, Chris

All the errors you are seeing match what I saw when I was trying to get my xbees working. I had ordered series 2 radios, but was sent series 1 radios.

None of the stuff I tried to do worked, until I realized the mistake.

Are you sure you have Series 2 radios?

Hi Paul,

They say Series 2 on the front of them so I presume they are ;)

Just seen this: http://forum.sparkfun.com/viewtopic.php?t=14664&highlight=xbee

Now i'm thinking that maybe I should get some series 1's instead?


I had thought series 2 radios always have the sif header. See photo at top of this doc http://ftp1.digi.com/support/documentation/90000866_C.pdf

In case that's not 100% correct, you can also look at the command set. Series 1 support the EC command, series 2 do not.

But the safest method is to always use the "Read" feature first and let X-CTU determine the radio type, then it will display the allowable commands/firmware versions.


Mine look exactly like the one in these pics:


Going to try using the ZIGBEE function set's now but I think i'm just going to order the series 1 models. They look a lot easier to use for my purposes (no need for mesh).


So, what are you going to do with all those Series 2 xbees that you have? If you need a good home for them...

They are not mine to give away i'm afraid Paul. I've not quite given up yet anyway. This must be possible. There must be something that i'm just not quite getting.

I solved my x-ctu problems as follows: a)if your device is set to sleep, then ground pin 9 to pin 10; this was outlined elsewhere and prevents the xbee from sleeping while being programmed. b) if the chip is already in api mode you must have api enabled; if it is using escaping, you must have escape enabled. c) if the chip is not using api and you program to use api, then you must clear api before writing, then set api enable before reading it; if api escape is programmed, make sure api escape is set, otherwise it must be off.

I can actually get the xbee's to communicate. I've followed a few tutorials and can get a ROUTER/END XBee to send data from an adruino sketch to a COORDINATOR XBee. What I cannot figure out now is how to set up the digital IO pins so that the COORDINATOR receives data once the switch connected to the ROUTER/END XBee is pressed.

We are both dealing with the same problem - except I have the coordinator on an arduino and the end device on a little sensor board I built. As soon as Andrew lets me know he fixed the bug he had in his library I will try listening on the coordinator for beeps from the sensor using his API libraries. I can let you know.

So how far have you got Mike? Are they not communicating at all?

I first made sure the associate led’s blink at the appropriate rate - without that there is nothing. Coordinator: 2/sec, end device 4/sec.
Now his library does not get a return for the first command and the (expected) error return for the second (due to the bug.) My home-brew sensor board’s led stopped working - have to check that now.

I’m testing with his RemoteAtCommand.pde, then I’ll progress to the Series2_IOSamples.pde once that’s totally clean.