I’m trying to minimize the time it takes to wake an end node XBee Pro S2B, associate with the network and send a packet. I am using sleep mode 1 (pin hibernate) to sleep/wake the XBee and sleeping for 2 minutes then waking to send a value from the microcontroller.
So far I have limited the coordinator and end node to a single channel which has helped but it is still taking the end node between 5.5 and 6 seconds.
Is there anything else I can do to further decrease the time or is 5.5 seconds the typical time it takes a node to join after waking?
What is the root of the delay? Is the End-Device waiting for a remote response?
You could try putting a smaller value into PO.
What happens now is the Coordinator (really the parent) NEVER sends/pushes to the end-device. the End-Device must PULL the data from the parent. The default PO=0 means the End-Device can only talk/pull once per 100msec. With PO=5, it would talk/pull every 50msec. Still at 6 seconds, that is 60 such cycles. That is a lot of wasted effort.
If you are trying to have the host app "acknowledge’ the end-device … I am not a fan of that. What is the End-Device going to do if there is no Ack? Better to have it wake, send data … if you care, send it a 2nd time in 200-300msec, then go back to sleep. The waitign for the Ack will eat up far more power than just send the data twice.
What is the root of the delay? Is the End-Device waiting for a remote response?
Good question. When the end device wakes it starts scanning for the PAN. Issuing an ATAI command returns 0xFF (scanning for network) and it takes the 5.5 or so seconds before ATAI returns 0x00 (joined network).
If an attempt to send a packet is made during this time it fails with a status of 0x22 (not joined to a network).
The application is not waiting for an ACK from the parent once the data is sent, it just needs to send the data and go back to sleep. The data can’t be sent though until the end device joins the network which is where the bulk of the time is spent waiting for that to happen.
Oh, I see. You probably don’t have the SN/SP set correctly in the parent. Yah … lots of details to learn.
The End-Device should not scan for a PAN. it should wake up, beacon its parent assuming life is good and get on with business.
The default SN/SP in an Xbee means that the parent dis-owns the child in less than a second (strange default if you ask me). So when your device wakes and tries to act friendly, the parent rejects it since the child has been flushed from memory.
These are set in the parent - not the child. I tend to set SP to 2000 (so 2 seconds), then set SN as a multiplier. In your case, 60 would cause the parent to hold the child’s record/slot active for 3x2000x60msec, or 3 x 2 minutes (6 minutes).
>> set SP to 2000 (so 2 seconds), then set SP as a multiplier
Oops, I mean “SN as the multiplier”. You probably got that from the PDF file.
The values don’t need to be exact & will be 3 times the SN*SP calculation. If you expect some device to sleep for an hour, setting SN/SP now to 22 minutes (so 66 minute timeout) doesn’t hurt.
The only down side to a long SN/SP is that the parent does not abandon end-devices long gone. For example, you may want to test/ship 30 units, with SN/SP set to 1 hour, after the first 10 are tested you’d NOT be able to test more as the coordinator would still be remembering the 10 you already packed.
You will also need SN/Sp sync’d in all system routers (wall routers, etc). They affect any node acting as parent.