Please check attached file for configuration used and a capture of the transmit on the oscilloscope .
Question: Why is the device awake for ~150 ms and not specified 32 ms by ST= 20 ?
Known information (please correct me if it wrong): The second peak is the regular poll every 100ms.
Request: Please tell me a way to minimise the wake period to be less than 20ms.
FYI: The output is amplified by a gain of 20 just so the peaks are visible.
Admin note: I deleted the two other posts created by you since it appeared they were duplicates.
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)
SP = 0x1F4 (5 s sleep period)
SM = 0x04 (Cyclic sleep)
ST = 0x05 (Wake for 5 ms)
With ST for 5 ms, I was expecting to see about 15 ms since there are some MCU operational tasks. However, I observed a much longer time. 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 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.”
In the attached image file, Typical Timing w-Coordinator Node.png, you can see the operational states of the modules. Channel 1 is the end node On signal pin, channel 2 (green) is the end node current with the coordinator node on channel 3 (purple). The 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.)
The apparent transmission sequence is:
EN - Poll
CN - Acknowledge
EN - Analog D1 data
CN - Acknowledge
delay -
EN - Poll
CN - Data
EN - Acknowldege
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.
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 because of the potential for longer wake times, which will cause high current drain due to excessive polling.
A discussion with a Digi support tech offered a possible explanation of the second transmission sequence that over rides the ST (wake time). It was suggested that there are two Ack classifications, one from the parent node and one from the destination node. The parent Ack is sent when the data is transmitted. The end node then remains awake, regardless of ST, to send a poll and receive the destination node Ack.
In the simplistic case, the destination node and the coordinator node are the same, nevertheless both types of Ack messages are still sent.
Explicitly setting the destination address does not eliminate this second packet or reduce the poll interval (no adaptive polling).
After another read of the manual, no description of this was found. However, there a several descriptions that contradict the observed behavior. There is no mention of the module waiting (idle) for the polling period to receive an Ack from destination. From what I could find, only parent Acks are described.
Even with cyclic sleep enabled and a short ST interval (0x05), the module still over rides these settings when the coordinator node is lost. In this case, the module wakes and sends network requests at a high rate for about 22 s at two different power levels. (This behavior was observed to be different between PO=0x01 and the default 0x00.) Afterwards, the module seems to enter a new mode, waking about every 8.9 s for a 2 s interval, sending packets every 144 ms until returning to sleep. This second state operates outside of any AT command settings.
Eugene
(I love talking to myself.)
Hi, Eugene
Thanks a lot for investigation. It’s really valuable info for me. It’s a pity Digi does not place high emphasis on documentation. Yes, it becomes better with any new version but still has be more precise.
When API is used there is possibility to forbid ACK, but is not clear for me which one: MAC or APS.