XBEE buffer / reception from many nodes


I am using XBEE S2 with ZB firmware. I have 1 coordinator and a number of end devices (no routers). All the modules are configured in API escaping enabled. Also, NH is set to 1.

This is the objective: the coordinator must read the signal strength from all the end devices (all of them are in the range)

The way I am doing it right now:
I send request from coordinator to first node and wait until the complete response is received. Then do the same for the second , third, …
The time required to complete a single reading is given by :
((50 * NH) + 100) = 150ms in the best cases.

The way I want to do it:
In order to reduce the time, I want to send all the requests to all the nodes, and then receive all the responses. The time period that I will wait for the responses to arrive is the same as the time period needed for a single response to arrive.
This obviously also depends on the buffer size of the coordinator. What is the size of the buffer ? .

I have actually implemented this setup using only 4 nodes + coordinator (so that I am sure that the buffer wont be completely filled).
The results were so unreliable. most of the times a packet or two wont be received( although sometimes all of them are received). I increased the waiting period for the reposes to arrive to more than 2sec which is much more than enough, but the results did not improve a lot.
Why is that ? could it be that many nodes are sending to the coordinator at the same time and the coordinator cannot handle all of them at once ? (this is my best guest because there no routers, but I am not sure)

Any suggestions are welcomed.


The world is more complicated than this :slight_smile:

So you are trying to issue a Remote AT command for the DB value? You didn’t mention if the end-devcies are sleeping or not.

First complexity, routers (the coordinator is a router) don’t send message to end-devices - they send them to the parent, which in this case is your coordinator. The parent buffers the message until the end-device polls for it. So it should not be involving any broadcasts so NH should have no impact. Even if you broadcast, the parent just queues a copy of the broadcast for the end-device - end-devcies don’t see broadcasts directly.

Second complexity is that Remote AT messages are synchronous, meaning a second message can’t be sent out by the XBee until the first one either is answered or times out, which could be 28 seconds later.

Third complexity is that the DB response is NOT necessarily related to the coordinator/end-device link. It is the last packet received by the radio, which might be a message from another end-device. Trying to talk to multiple nodes by queuing/pipelining requests increases the probability that the Db response isn’t what you expect.

Plus you do understand that 1 coordinator can only support at most 10 end-devices (but 8 is a safer max)?

Given what I know about ZigBee, I would just send you messages 1 by 1, delaying until the TX Status response from the previous request before queueing a 2nd message.

Playing with the PO setting will allow you to shorten response time, but it also adds radio-packet congestion.

You may want to look at using the Series1/802.15.4 Xbee instead of ZigBee if you don’t need routers or mesh.