The following started under the Znet Mesh, where a similar problem was described. Problem with wake period more than set ST
–
I have been testing the XBee ZigBee SMT modules (S2C) and have found that the shortest wake time (ST) is 128 ms. I’ve programmed the device with the following settings:
D1 = 0x02 (Analog input read)
IR = 0x600 (Only want one read. Value just needs to be > ST)
SP = 0x1F4 (5 s sleep period)
SM = 0x04 (Cyclic sleep)
ST = 0x05 (Wake for 5 ms)
These settings will wake the module every 5 s and send the analog value from ADC1.
With ST for 5 ms, I was expecting to see about 15-25 ms total wake time, since there are some MCU operational tasks. However, I observed a much longer time, 128 ms. The following was a summary e-mail sent to Digi support.
–
I have been testing the XBee ZigBee SMT modules (S2C) with firmware 4016. The observed behavior differs from the device manual significantly. A case was submitted and updated as more information was discovered.
A response was received from Eric this morning, but does not explain the observed behavior nor provide a viable work around. Therefore, I would like to summarize my findings.
ST does not represent the wake time when set below 100 ms.
According to the manual, a poll transmission occurs when the unit first wakes. The manual states: “If the end device wakes and finds that its parent has no data for it, the end device can return to sleep immediately.” However, the PO (polling) setting is driving the wake time (ST). The Digi firmware is forcing a second poll transmission regardless of sleep settings.
According to the manual, if a parent has data, the end node “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.” This is referred to as Adaptive Polling in the manual.
In the attached image file, Typical Timing w-Coordinator Node.png, you can see the operational states of the modules. The scope traces were made using a 10 ohm shunt resistor on the module supply.
- Channel 1 (yellow) is the end node On signal pin
- Channel 2 (green) is the end node current
- Channel 3 (purple) is the coordinator node.
The high-current spikes represent radio transmissions.
You can see that the end node stays on for 125 ms even though ST is set to 0x05. (PO is at the default 0x00, 100 ms.)
The apparent transmission sequence is:
End Node - Poll
Coordinator - Acknowledge
End Node - Analog D1 data
Coordinator - Acknowledge
-
delay - Why??
End Node - Poll
Coordinator - Data
End Node - Acknowledge -
Why is there a delay?
-
Why is there a second poll when ST has expired?
-
What data is being sent to the end node?
-
If there is data from the coordinator to the end node, why isn’t adaptive polling working?
Also:
-
PO is given in the Sleep AT command summary (pg 135), however, the units are missing. Based on my testing, it should show 10 ms.
-
The PO parameter is not present in the Modem Parameter interface. It has to be set through the terminal interface.
Changing PO to 1 through the terminal interface did shorten the wake time to 37-45 ms. However, the second exchange with the coordinator node is still present.
While this shortens the wake time for this particular instance, it is not an acceptable fix for field use. When the end node loses the coordinator, it no longer abides by the SP and ST values, but enters a new mode.
When a coordinator is first lost, it will send network requests at the PO rate for about 22 s, then will send wakes every 8.9 s for a 2.2 s period, sending network requests at a period of 144 ms.
So, the moral of the story…
The module does not operate per the protocol in the manual, or the manual is not correctly describing the protocol.
The polling behavior of the module does not allow wake times (ST) shorter than one polling period (PO), at least for cyclic sleep operation.
Digi support cannot explain the reason for the second polling request, nor is Digi engineering willing to explore the problem.
Leaving the PO set to the default (0x00, 100 ms) may cause more than a 2x power drain for cyclic sleepy node operation.
Eugene