Xbee point-to-multipoint setup

Hi,

Although this is not directly an Arduino question I know many of you use the Xbee's so I hope that you can help.
I'm setting up multiple (At this stage 3) Arduino's with Xbee's in them. 1 of them will be the master and the others slaves.
The data will be bidirectional from the master to the slaves. I plan on having the addressing side of things (So the master knows which slave it's talking to) handled by the Arduino by assigning them numbers to place in the serial stream, however I'm not too sure how to setup the Xbee to allow point-to-multipoint communication as all the videos and how-to's I've read only mention how to setup between 2 devices and entering the Serial Number High/Low of 1 Xbee into the Destination Address High/Low of the other.
How do I setup a multipoint network with the Xbee?
Not sure if it matters but I'm using the Xbee Pro 900 (XBP09)

The MY value defines an address for an XBee. The DL value defines the address of the XBee that it will be talking to. An XBee can have only one DL address, so it can only talk to one other XBee.

Seems like a real problem, right? Well, there is one special DL value, 0, that means broadcast mode. Broadcast sends the data to all other XBees on the PAN.

A perfect solution, right? Just make every XBee transmit everything, and let the Arduinos sort it out. Well, no. There is a drawback to broadcast mode, and that it that broadcast messages are low priority. It can take a while to get a broadcast message sent.

The way to handle the paradox is to have the master use broadcast mode to request data from a specific Arduino. The master XBee broadcasts a request for data ("Hey, Joe, talk to me"). All the XBees get the request, and pass it on to the Arduinos. Only one Arduino knows that it is "Joe", so only it prepares a reply, and passes it to its XBee to send, directed to the Master's DL. The other Arduinos know that they are not "Joe", so they do nothing about the incoming request.

Good overview here from PaulS, but wanted to offer a few corrections on a couple details:

PaulS:
The MY value defines an address for an XBee. The DL value defines the address of the XBee that it will be talking to. An XBee can have only one DL address, so it can only talk to one other XBee.

This is correct,however worth adding that the DL address can be changed interactively, or by using API mode, you would send each transmission along with an address (try the XBee Arduino library GitHub - andrewrapp/xbee-arduino: Arduino library for communicating with XBee radios in API mode with API mode).

PaulS:
Seems like a real problem, right? Well, there is one special DL value, 0, that means broadcast mode. Broadcast sends the data to all other XBees on the PAN.

Broadcast mode is ATDL FFFF and that would indeed send data to every other XBee on the same PAN (and channel of course).

PaulS:
A perfect solution, right? Just make every XBee transmit everything, and let the Arduinos sort it out. Well, no. There is a drawback to broadcast mode, and that it that broadcast messages are low priority. It can take a while to get a broadcast message sent.

The drawback isn't exactly priority. It's that broadcast messages are not confirmed by the recipient with an 'ack' since a single message in that case would have to generate thousands of 'asks' in some cases. So the effect isn't so much a delay as it is a potential for broadcast messages to be lost if there is noise or interference during their transmission are they not transmitted multiple times. Unicast addressing does create messages that get an 'ack' and will be retransmitted with collision avoidance backoffs up to three times by default. So your message is much more likely to get through, even in noisy environments.

PaulS:
The way to handle the paradox is to have the master use broadcast mode to request data from a specific Arduino. The master XBee broadcasts a request for data ("Hey, Joe, talk to me"). All the XBees get the request, and pass it on to the Arduinos. Only one Arduino knows that it is "Joe", so only it prepares a reply, and passes it to its XBee to send, directed to the Master's DL. The other Arduinos know that they are not "Joe", so they do nothing about the incoming request.

This will work, and you should also have an error correction routine. In case you don't hear back from the Arduino that you're talking to, the transmitter should create the request again because in broadcast mode you need to expect more transmission failures and handle them using your own communication routines.

Good luck with the project!!

hello there,

iam pretty new here. first thanks for the good explanations...
i ve just one additional question:
can every xbee handle this? or just series 1 or 2?

can every xbee handle this? or just series 1 or 2?

There are only series 1 and series 2 models.

oh sorry. i meant will it work with series 1 or with series 2 or both?

It will definitely work with series two; can't speak for series 1 (don't use them). I do something similar, I broadcast commands and then have the responding XBee reply to a specific address. If I don't get the response, I broadcast the command again. This way I only have one XBee doing broadcasts which keeps the traffic down. See, the series 2 XBees do store forward and handle remote XBees automatically. In my network I have several XBees that are way out there and can't transmit directly to all the others, so the commands get relayed to the far away XBees as does their response back to the originator.

I originally started with all the XBees doing broadcasts; this worked until I had around 6 of them talking. At that point I noticed there would be times that the messages wouldn't get through. When I expanded the network up to 10, a lot of messages wouldn't get through. Seems the various XBees repeating the messages all over the network was causing too many collisions. This was hard to figure out and I had to construct a little sniffer to watch the various XBees to see what was going on. So, I switched to the command broadcast - specific address response technique and everything started working again. From watching my network over various periods of time, it looks like I can add a lot of XBees to the network without having a collision problem again.

Moral, I'm not sure there is one, but it's certainly a technique that works fine around my house. It's also nice that I can see the commands going out by simply plugging an XBee into my laptop and watching. I can't see the responses, but at least I know the command went out. If you want to expand on it, say you want a time standard transmitted so all the devices have the same time for coordinating actions, you can broadcast a time signal that the various nodes receive and set their clocks with. You can also transmit sundown, sunrise, etc. as long as they are low volume.