next topic »

[on:]

I've been researching ways to establish XBee to XBee communication using Arduino 2560's, and I think I know how to do what I want.

What I want: Several Arduino (clients/slaves) to talk to a (server/master) Arduino with XBee radios (I can deal with a situation where any XBee talks to any other XBee, I'm not overly concerned about only one being able to receive from all the others).

How I plan to do it: Using the XBee Explorer USB (from sparkfun), program the XBee radios to be in Broadcast mode. Then, attach the XBee radios to the Arduinos via a PCB I am building (a custom PCB since there are many other components I have attached to my Arduino). To my understanding, all I need is the TX/RX and 3.3v and ground pins on the XBee radio to be connected to the Arduino. I can then use the SoftwareSerial library in my sketch to send and receive data between XBees.

I have yet to find a code example, but I know enough how to use SoftwareSerial (I've used bluesmirfs before), so if its as simple as using that library to send and receive data, I should be alright.

Is there anything I'm missing? Am I right in believing that I can program each XBee separately, and whatever mode I set them in via the XBee Explorer will persist when plugging them into the Arduino via my PCB?

Thanks in advance for reading this...

[Reply #1 on:]

I can then use the SoftwareSerial library in my sketch to send and receive data between XBees.

Why would you use SoftwareSerial on the Mega, which has 4 hardware serial ports?

program the XBee radios to be in Broadcast mode.

You want all the XBees to act like a bunch of kindergarteners, all screaming at once?

Am I right in believing that I can program each XBee separately

You got that right.

and whatever mode I set them in via the XBee Explorer will persist when plugging them into the Arduino via my PCB?

Yes.

[Reply #2 on:]

A bunch of kindergarteners indeed! I can always configure them more specifically with the explorer later.

Instead of SoftwareSerial, I suppose I would just use Serial? Doesn't that default to the USB Serial?

Thanks.

[Reply #3 on:]

Instead of SoftwareSerial, I suppose I would just use Serial?

Or Serial1, Serial2, or Serial3.

Doesn't that default to the USB Serial?

Serial does. Serial1, Serial2, and Serial3 do not.

I can always configure them more specifically with the explorer later.

What kind of XBees are you using?

[Reply #4 on:]

I am planning on using https://www.sparkfun.com/products/8665?, with the following programmer: https://www.sparkfun.com/products/8687

I will look into Serial1, etc. I imagine they have ways to specify what pins to use (which TX/RX pins to use - when I get a moment I will check the Arduino reference page).

[Reply #5 on:]

I've got both of those. Good choices.

I will look into Serial1, etc. I imagine they have ways to specify what pins to use (which TX/RX pins to use - when I get a moment I will check the Arduino reference page).

Or, just look at your Mega. Says right on it.

[Reply #6 on:]

I need to step in here and clarify a couple of things so you don't have a huge set of problems to over come.  First, if you're going to use the XBee library, be sure to get the very latest one.  The previous versions would NOT talk to the additional serial ports on the 2560.  Paul Stoffregen has modified the library to work really well using the Serial1, Serial2, etc look here:

http://code.google.com/p/xbee-arduino/

Seems the work he did to make softwareserial better translated into something great.  Take a look at his blog post here for more information.

http://www.pjrc.com/teensy/td_libs_AltSoftSerial.html

I recommend using this library because it leaves the Serial port open for debugging and monitoring status, and you don't have to worry about the various things that can happen using digital pins.  I have an example of using it on my site that is specifically targeted to the mega2560 and using its additional serial ports:

http://www.desert-home.com/2012/10/using-xbee-library.html  and http://www.desert-home.com/2012/11/using-xbee-library-part-2.html

Feel free to steal them.

Next, broadcast is a bad idea if you have too many nodes.  I did this and ran into trouble when I reached about 7 or so nodes transmitting data.  What happens is that the remote nodes get retransmitted by the intermediate nodes and this increases traffic and chance of collision.  With increased transmissions and collisions, comes retransmissions which increase traffic and collisions.  The whole network will bog down and bad data becomes the norm.  This happens because the XBees work very hard to make darn sure all broadcasts get to all the nodes on your network, something that is usually not needed.  When I switched to having the nodes transmit directly to my concentrator using the address, the problem went away completely.  My concentrator, the device that gathers the data, is NOT my coordinator.  My coordinator is a device that does almost nothing except coordinate and broadcast (yes broadcast) the time for the other nodes to use.  This way, the coordinator has plenty of time to ... well ... coordinate.

Last (at least for now) API mode is the way to go.  If you use transparent mode, you can fall into the trap of sending partial data.  Especially if you use strings to carry the data.  I use strings that have the data in ascii for the most part since I want to set up a sniffer and watch what is going on from time to time to be sure the entire network is doing what I want.  Things like, "device1,on" and "temp1,76" fly around my network.  This makes it, relatively, easy to see what is happening.  So, the strings can get cut in half by the transmission priority and various timing factors in the XBee software.  I saw "tem", "p1,76" in two separate packets with other devices data interspersed between many times when I was using transparent mode.  Switching to API mode fixed that entirely.  I still get occasional collisions and bad checksums from time to time, but it's the exception, not the rule.

These things allow me to have a network that is essentially a "bunch of kindergarteners, all screaming at once" because the XBees themselves try very hard to ... coordinate ... (love that term) their activities.  They automatically sense traffic and have built in retries that self-correct for many problems.  See, I want devices to report changes when they happen, not when something gets around to asking for it. 

But that's just me.

[Reply #7 on:]

draythomp, thanks for a very informative post. I've come across the XBee library on code.google before - I will try using this at first when I get my radios.

As for the retransmitting of traffic, I admit I am a bit confused as to why that causes a problem.

In broadcast mode, one device would ship packets out to any other device on the same network channel in range. The receiving devices would, from time to time, want to send data to the master device. I don't care if the other slaves see what the other slaves are seeing, as I would just discard data from the other slaves at the software level when receiving data. This isn't elegant, but in principle I'm confused as to why it wouldn't work.

In the scenario you mention with 7 nodes, what are your intermediate nodes and remote nodes? Is the reason this causes a problem because some of the nodes don't get other node's traffic on time to send an ACK message back to the sender to confirm they received the packets, causing the sender to think the recipient hasn't gotten anything and retransmit the same packet?

I will heed your recommendations and configure the slave's radios to send data to a particular address (the master). The master will still use broadcast, since that is the intended effect.

Thanks

[Reply #8 on:]

The problem with broadcast happens as soon as you have a node that can't talk to the coordinator or its intended destination.  Suppose you have an XBee about 4 walls away and it can't join the network because it can't talk to the coordinator (this is a remote node).  You simply put another XBee in the middle and this new one will store forward the data from the remote XBee to the coordinator and whatever other XBee it needs to talk to (this makes it an intermediate node).  In broadcast, this means the middle one will echo every packet that is broadcast so the remote one can get it.  Get enough remote ones (2 seems to be enough in my case) and the traffic jumps way up because the various XBees are echoing stuff for the remote ones.

You should have no problem at all with a couple of XBees broadcasting commands.  I have two of them, one transmits the time every few minutes to sync the various clocks and the other transmits commands in broadcast.  I use broadcast in commands because I want to be able to see them easily for tracking the performance of the network.

Also, it's actually a good idea to bring up a new node in broadcast to be sure that it is doing what you intend.  Once it's working to your satisfaction, change the setup to transmit to a single destination for continued operation.  It's tough to debug something you can't see.