I’m having issues using the sleep mode on the XBee’s. I’m using a coordinator API (21A0) and one end node (28A0). I simply want to make the end node sleep for 5 seconds, then wake up, send a sample and go back to sleep. On the end node, I’m using the following:
atir0 (should send sample when it wakes up)
atsp1f4 (sleep for 5000ms)
atst14 (wake up for 20ms)
When the end node is up by itself (no coordinator), LEDs 13 and 15 are ON for about 5 seconds and OFF for about 1 second. This doesn’t make sense to me, but the coordinator is off so whatever.
When I turn on the coordinator, the LEDs are ON constantly, but flickr about every 5 seconds. I would expect the opposite behavior – asleep almost all the time with a blip when it sends the data. Also, I’m not seeing any data (I should get a sample each time the node wakes up).
Any thoughts what I’m doing wrong? I’ve already spent many hours on this and exchanged quite a few emails with the Digi support. Without the sleep, everything works fine. The DL=0, DH=0 on end node. On coordinator DL=0, DH=FFFF, SP=2F4.
Any advice is appreciated.
Unfortunately you are a victim of old status-quo defaults.
You need to change the SN/SP of the NON-SLEEPING unit, because right now the ‘parent’ (router/coordinator) is flushing the ‘child’ (your sleeping end-device), freeing up its buffer resources about 960 msec after it sleeps. Thus when the end-device wakes, it is rejected by the router/parent. It does rejoin, but any data you wished to send will have been lost unless you use API mode and see the error message upon waking and do a manual retry within the 960msec time window.
Look into the ZB manual for topics like ‘End Device Poll Timeouts’ and ‘Child Poll Timeout’, but I’d suggest setting (In the NON-SLEEPING XBEE!) SP=100, which means 1 second, and SN=5 which means the parent should not flush/orphan/forget the child for 3 times 5 seconds, so 15 seconds.
It’s a pity Digi doesn’t default the XBee to have more reasonable values in SN/SP, because I am sure 99% of new users suffer this problem!
I would add that having DH/DL set to broadcast is ‘bad’, as it can take up to 5 seconds for every broadcast to happen. It is okay for testing, but any real application you wish to create will require you to set the correct 8-byte MAC and do unicast. Or switch to use 802.15.4, which loves broadcast but does no meshing.
I made a Wiki page for you which describes the Sn/Sp settings more clearly: