The Xbee product manual states that when an end device loses contact with it’s parent, the end device will poll for the parent, and if no reply is received in three polls the unit will go into a search for network mode.
I find that with Xbee S2 modems (that came in several L/H/T sensors I purchased), when the coordinator inadvertently loses power the end device modem instead starts a rapid fire output of data requests (assumed to be polls) at approximately 5ms intervals for indeterminate amounts of time, a minimum of 30+ seconds. In some instances the polling appears to never stop. In some instances the polling finally stops and a beacon request is sent as a start to a network search.
I have tried several variants of parameter settings including various sleep modes and times, polling rates, etc, these have minimal effect.
The XBee PRO S2B modems with the same parameter settings appear to stop polling fairly rapidly (a few seconds or less) and send a beacon request.
I’ve been monitoring traffic with a TI sniffer. When I have several (30+) end devices in a network with sleep cycles, sampling, and everything working fine then the coordinator power is lost, the traffic is so dense that I can’t even run my office WiFi (running at 2.4MHz) until I get the modems to be quiet.
Any info on this, suggestions, clues?
My last resort is to replace all the S2 units with PRO S2B units, but this adds significant cost to each Digi sensor unit, which comes with what I am starting to suspect is a buggy S2 modem design.
If anyone is experiencing a large power drain whenever their end device loses contact with its parent (out of range or power down), this could be related.
Looks like it is an issue with the firmware version loaded thru XCTU. I don’t know if I had a wrong version or an old version spelled out in XCTU prior to programming the modem, but when I changed it to what appears to be the most recent for that modem, the end devices act appropriately.
Anyone know where a proper history of modem drivers can be found?
Final note - I encountered the problem using Digi sensor modules, when they were configured for sleep. Turns out the units I received had older firmware in them. When I upgraded the firmware using XCTU and an eval board with the ‘offending modem’ plugged in, the problem went away. At least this is my conclusion, haven’t heard from tech support yet. Heads up if you are using the sensor modules…
I just have a problem with end devices staying awake forever when a router or coordinator was turned off. I just discovered it was a bug that has been fixed by a FW upgrade. I will give it a try.
This is the description on the FW update note:
A sleeping End Device with no network available was staying awake forever after the first sleep cycle.
If AI =0 then, zigbee need not to find the nodes, but if AI is non zero, at the first steps, end node will try to join the network. This is only because, as per ZigBee protocol, network need to be formed first.