I have a small testbed set up with a coordinator one router at two end devices. the end devices sleep for 20 seconds and then send sensor data. the router sends periodic sensor data (0x92).
I was expecting the NODE_IDENTIFICATION_INDICATOR (0x95) packets to only be sent when the devices join the network, but I am seeing few intermixed with the expected 0x92 traffic.
one side question is: Is there anyway to have a sleeping device wake up send a single 0x92 and then go back to sleep.
I guess I need to state the question a little different. What conditions cause 0x95 packets to be sent? My assumption was they were sent when a XBee first joins a network.
If the SN/SP within the ‘parent’ (aka: your coordinator) are left at default of about 320msec, and if the child sleeps longer than 1 second (3 x 320msec), then the child may be forced to ‘re-join’ frequently.
In effect the parent has flushed the absent child inorder to free up the memory resources.
I tend to set SP to be 0x07D0, which is 20 seconds, then use SN as the multipler. So SP=0x07DO and SN=0x0003 means abotu 1 minute, and the parent should keep the child in the table 3 times longer, so about 3 minutes.
Ok, that makes sense, my values were sp=12c and sn=2 which gives me 6 seconds. I guess I confused all my little children.
thanks
should the routers be set similar?
Anything which can be a ‘parent’ needs to have the correct SN/SP. You could use a periodic broadcast from the coordinator to force all joined routers to adjust their settings to match.
I see this as a weakness ZigBee, although 'legal ZigBee doesn’t acknowledge end-devices sleeping longer than 28 seconds. My own systems (tank gauging) tend to see sleep time of 1 to 12 hours, so SN/SP is critical.
Under DigiMesh, such parameters are shared globally based on the sleep coordinator, which dynamically over-rides the settings within any XBee.
28 seconds, that must be where the SP max comes from. Is Digi with the XBee product deviating from the ZigBee standard by allowing the SP multiplyer?
Yes and No.
The Zigbee Alliance never says a device cannot sleep longer than 28 seconds, only that their standard profiles and compliant tools do not need to handle nodes sleeping longer than 28 seconds. So how one deals with it is undefined and at your own risk. For example, how do you ‘configure’ a device which only wakes once per 24 hours? Imagine trying to maintain it - your changes might not be visible for days.
In our case, we use Digi’s own profile (0xC105) so we legally can do anything we wish.
But bottom line in tank systems, the customer rarely wants to see more than a few readings per day and waking every 28 seconds is a waste of battery life. It is also a partial reason why WirelessHART and other don’t use ZB, claiming the 28-second wake suggestion is unrealistic.
thanks, great information. I guess I should do a little battery life calculations, It would be nice to get a couple of years out of a pair of AA’s. I’ll see what the load is with a 28 second sleep and waking to send a 0x92 and a short delay waiting for an incoming message before going back to sleep. If it misses a packet it is not a problem, it would just get it the next 28 second wake.
Adding some stateful logic to the data upload would also help. For example, users often are happy with the logic “send a new sample at least every x minutes, or if it changes by Y%, but never more often than once per X seconds.” For example a room temperature might be updated every 15 minutes, or if it changes by 1 degree, but never more often than once per minute (or 2 x 28 seconds).
That is kind of the theory of ZB - the end-device wakes, send data if it’s meaningful, sends a beacon to check if the parent holds a message, if not go instantly back to sleep.