I would very much like to be able to derive some dependable battery life projections before committing to an approach. For this I need certain specific information on XBee ZB timing and power supply current. Please let me know if Digi Internatinal can supply answers to these questions and where they might have already been published.
As I understand it, for an XBee ZB end device to respond to a developer-defined command from another node, it must perform the following RF operations upon waking:
- Transmit a Zigbee Poll Request to parent node
- Receive a Zigbee Ack from parent node
- Receive a developer-defined command from the coordinator node, buffered by parent node
- Transmit a Zigbee Ack via parent node
- Transmit a developer-defined response to the coordinator node, via parent node
- Receive a Zigbee Ack via parent node
How long will the XBee ZB be drawing Transmit-mode supply current during 1, 4, and 5
How long will the XBee ZB be drawing Receive-mode supply current during 2, 3 and 6
How will the durations of 3 and 5 be affected by packet payload size?
How will the time the receiver must stay on in 6 waiting for an Ack vary with the number of hops?
How long will the XBee ZB be in idle mode during each specific interval between the above steps?
How much delay will there be from the end of step 6 to the outputting of a Transmit Status API frame by the end device?
If a packet payload is between 85 and 255 bytes, will both steps 5 and 6 be executed multiple times before a Transmit Status API frame is output by the end device?
The XBee/XBee-PRO ZB Product Manual (90000976_F) p 90 says “if an end device receives RF data from its parent, it sends another poll after a very short delay to check for more data. The end device continues to poll at a faster rate as long as it receives data from its parent.”
How long is “a very short delay?”
How fast is “a faster rate?” Is it at the same interval as “a very short delay?”
How quickly after receiving a user command does the processor connected to the end device have to begin sending the end device user data to preempt it from performing another Poll Request?
If the processor connected to the end device is programmed to issue a SI command as soon as it receives a Transmit Status API frame, is there any way to preempt the end device from performing another Poll Request in the meantime?
The specifications section of the Product Manual specifies a “Power-down Current” of “< 1 uA @ 25oC”
Does this apply to pin sleep mode or cyclic sleep mode?
If not both, what is the current draw for the other mode?
How does this current vary with temperature? (This is critical for my application.)