Sleep mode settings

XBee & XBee Gateway XBee - Zigbee
1

I wish to create a network with ~200 end-devices, ~25 routers, with bi-directional communications between the coordinator and end-devices.

One of the requirements is to minimise the latency between coordinator and each end-device, yet maintain low-power operation. So I hope to make the end-devices do this:

  1. Each time an end-device wakes up, it wakes up for just a short time and polls rapidly. If it gets one packet, it extends its wake-up time, so that it will eventually get all its packets from its parent.
  2. End-devices will wake up often (between 100ms to 1000ms) to keep the latency low.
  3. It is not necessary to guarantee that an end-device gets all its packets every time it wakes up. e.g. if the poll fails, just try again the next time.

From the manual, it seems that 10ms is just enough (assuming no packet losses) for an end-device to poll and receive a packet from its parent. So I’m planning to set the sleep settings like this:

SM (Sleep mode) = 5
ST (Time before sleep) = 20ms
SP (Cyclic sleep period) = between 100ms to 1000ms
SO (Sleep options) = 0
SN (Number of cyclic sleep periods) = 0xFFFF
PO (Poll rate) = 15ms

Do you think this’ll work? Has anyone had experience with such a setup, and would like to share your experience?

Also, anyone knows if each end-device poll will result in the end-device receiving all packets for itself from the parent, or only one packet per poll?

2

No, this won’t work. The parents (routers) will not buffer message for sleeping end-devices for very long. So normally when the end-device wakes, there will be no data for them.

Also, supporting more than 50 devcies requires detailed low-level understanding of the RF behavior. The Xbee do retry packets, but only so much. Therefore a user with 200 nodes could have serious problems of lost packets if too many talk at the same time. Some would retry and succeeed, while other would give up.

Perhaps having them send a dummy message to the gateway will allow the gateway to try and send down data, but this is a huge ‘race condition’. If the gateway doesn’t get the first message in fast enough, it literally blocks things for up to 28 seconds, so any end-devices waking within that 28-second window is guarenteed to fail.

Overall, this will be hard.

3

I see, thank you!