Hi,
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)
OK
atsp1f4 (sleep for 5000ms)
OK
atst14 (wake up for 20ms)
OK
atsm
4
atwr
OK
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.
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.