I'm working on a project where I need to be able to send and receive information between a bunch of different Arduinos, so I picked up some version 1 XBees (802.15.4) and the XBee shields and hooked them up. I'm trying to use broadcast mode to send data back and forth between the devices, and have had no problem sending from one and receiving on the other. The problem I am having is trying to send and receive on the same device... I'm using the XBee library that Andrew Rapp put together (GitHub - andrewrapp/xbee-arduino: Arduino library for communicating with XBee radios in API mode) in order to program them.
I guess I'm wondering if it is possible to both send and receive using the same XBee? Or can you only set them to either send or receive?
Any help would be great!
I guess I'm wondering if it is possible to both send and receive using the same XBee?
Absolutely. If you're using Andrew Rapp's library, I assume the XBees are in API mode?
I am in API mode, but for some reason whenever I try and send a reply after reading a message, it comes in the form of an I/O Sample Response, when I am looking to get an RX64 response. Like I said before, I’m using broadcast mode, so I the address I’m sending to is (0, 0xFFFF) High and Low, respectively. I’m trying to make the code on every device be the same, with the only difference be their personal ID number…
Also, would I have to create an XBee object for both sending and receiving? Or can I use the same object to handle both...
Not quite sure I'm with you here:
...but for some reason whenever I try and send a reply after reading a message, it comes in the form of an I/O Sample Response, when I am looking to get an RX64 response.
So one XBee does a TX request, and an RX never shows up on the other XBee(s)? Is IR set to some non-zero value?
It may make no difference right now, but broadcasts can be quite inefficient, requiring a lot of network discovery overhead. Why not do unicast?
The same XBee object can both send and receive.
Okay, so here's what I do on one XBee:
- Send broadcast out with board ID and no (saying there is no match yet)
- Wait a couple seconds for a reply saying message was received
- If message was received by another XBee, wait for another message(RX64)
- Print out data, Send a reply message
The other XBee basically does the same thing, with just different delays.
What is happening is the first message is getting received by the other XBee as an RX64 response, but when I try to send out a reply message, the other XBee is receiving it as an I/0 Sample response...
I can post some code if you think that would help...
Also, I'm using broadcast mode because in theory there will be many other XBees around, so I want to make sure everyone gets my message, because I want to compare data on each device with each other device. I'm trying to make a state machine by just having the XBees parse the first couple of bits to see which state the other one is in. I thought that going from broadcast to unicast would be a little slow, so that's why I've just decided to do it all in broadcast mode.
Thanks for the help!
If every device needs to know the state of every other device, then broadcast may be one way to do it. There may be some delays, though. Still it should work, if with some lag. But I'd never "wait a couple seconds" for a reply. I'd read the XBee as frequently as possible, first thing at the top of loop(). If there's no incoming data, then there's nothing to do. Also have each unit broadcast its status on some fixed schedule, every 10 seconds or whatever (don't know your requirement, but beware that too many broadcasts too frequently can congest the network, so start conservatively and work up). Top priority for each unit is reading and processing incoming traffic. Broadcasting status is secondary. Transmit status responses will normally be returned quickly, probably in milliseconds. You say you want to be "sure" every node gets every broadcast message, better check the XBee product manual, there may be no guarantee there. I think only a certain number of retries are attempted for broadcasts, and there is no acknowledgement at the individual node level. Your XBee read routine needs to be able to handle both the TX status responses and incoming data from other nodes. Do not assume things will come in any particular order. Take it as it comes, read the XBee absolutely as frequently as possible.