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:
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?
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.
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?
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.
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?
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.
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.
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.
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).
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.
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.