Problems with getting response data after broadcast?

XBee & XBee Gateway XBee - 802.15.4
1

Hi all,

I’m wondering if any of you have experience using data broadcasting and the reliability of the response messages coming back. I’d like to be able to broadcast transmit data to a population of perhaps 5 or 10 XBee end devices and use the data responses to determine who is out there.

Is there a problem with responses from multiple end devices clobbering each other in your experience?

Best regards

Mike Cookson

2

The ND command will already send out a broadcast transmission and will request each radio in range to report certain identification parameters back to the unit that issued the ND command. The time the remote devices have to respond is given by the NT command, and they will already delay each response before they report. You can insert your own delay before a retransmission by setting the RN parameter.

Refer to the manual for the format of the ND response.

3

Thanks for your responses.

I don’t know which end units will be in range, so I can’t really iterate through them unless I do a Node Discover first.

I’m thinking of relying on the built-in retry features to get a response, or perhaps I will have the remote devices periodically send out a message and maintain a list of ID’s that I’ve heard from.

Best regards

Mike Cookson

4

Right, I am aware of the ND command. I was thinking of using a data broadcast instead since I need to communicate with each end device, anyway.

Does anyone have experience with getting responses from multiple end devices after broadcast, and whether that would be a problem due to the messages in response stepping on each other?

  • Mike
5

You do have a couple of option here. One is to send your broadcast and allow some of the XBee’s built in features to allow your messages to make it back. The RN command for instance (as mentioned earlier) can be used to set up a random delay before transmission. The modules also perform a Clear Channel Assesment, CCA, before transmission, and will perform up to 3 MAC level retransmissions if the messages collide, or are lost for some reason. Then, the RR parameter is available which allow for more than the original 3 retransmissions.

Since you need to communicate with each node anyway, a second method is to simply send a poll request to each unit instead of a broadcast. This way, you will receive the response back from each unit before moving on to the next one. This is the only way to determine for certain that you will not have any data collisions. If you were to use the radio’s API, you could send packets to different end devices very quickly, say once every 10ms. With the small number of units you have, you could do a poll request to each device and receive a response several times a second if necessary.