2
\$\begingroup\$

I am having some trouble dealing with xbee s2 sleep mode. Hope you all can give me some help.

The following is my setup: The network composes of one coordinator and several end devices, all in transparent mode The coordinator is connected to X-CTU and a computer and receives all the messages.

End devices are connected to another MCU(MSP430), MCU wakes up xbee periodically(8 seconds, 16 seconds, 48 seconds etc), writes a short message (11 bytes) to xbee through UART, then immediately asserts sleep_rq pin of xbee.

Here is the problem: if I set the wakeup interval at 8 seconds, then all messages from the same end device will come in two messages batch at roughly 16 seconds interval instead of one message every 8 seconds. If I set the wakeup interval at 48 seconds, then again, all message still tend come in two messages batch roughly every 96 seconds, plus the last two bytes of the second message constantly get lost.

The SN, SP on both coordinator and end devices are set properly. The RO is at default value 3.

If I don't assert sleep_rq pin of xbee and keep xbee awake all the time, then no matter what the interval between two messages is, all the messages come in one by one at defined interval.

I believe this has something to do with packetization but I could figure out the exact problem.

Edit: I believe at certain conditions, when sleep_rq is asserted, message up to certain length will be retained in the transmit buffer of xbee until xbee being waken up next time. I am wondering if there is any way to force xbee to send out everything before entering into sleep. One way of doing this is to write enough dummy byte to fill up the entire transmission buffer(84 byte in transparent mode without encryption). But this is really a waste of limited throughput of xbee network. So I hope someone can come up with something better.

This is driving me crazy. Some one please direct me to some relevant literature.

Thanks in advance, ZL

\$\endgroup\$
2
  • 2
    \$\begingroup\$ Could it be that the XBee doesn't have enough time to transmit the message - being forced to sleep too soon? \$\endgroup\$
    – Dzarda
    Commented Jan 12, 2014 at 16:29
  • \$\begingroup\$ According to the manual, when sleep_rq is asserted, xbee will automatically finish everything it is doing, be it sending a message, joining a network etc, then enters into sleep mode. This is particularly addressed by digi on page 85 of document 90000976_K: adafruit.com/datasheets/XBee%20ZB%20User%20Manual.pdf So I rullled out this by default. \$\endgroup\$
    – Zhiyong Li
    Commented Jan 13, 2014 at 2:40

1 Answer 1

Reset to default
4
\$\begingroup\$

I had the same problem, it was caused by not waiting long enough after sending the message before re-asserting the sleep_rq pin. (@Dzarda got it). Experiment with different delays until it works.

Edit: I know you have already set up SN and SP properly, but I'll leave this part of the answer in for others:

The other thing to know is that you have to set SN and SP in the always-on router so that it doesn't timeout and forget the end devices. If it does, the connection can take up to 6 seconds to renegotiate when the end device came out of sleep. See http://www.digi.com/wiki/developer/index.php/XBee_Sleeping_Problems

\$\endgroup\$
2
  • 1
    \$\begingroup\$ For a second I thought about putting a delay before reasserting sleep_rq but then didn't act on it. Digi definitely needs to improve documentation on xbee sleep mode. The other undocumented trick about sleep mode is, I have wait two bytes of time after waking up xbee before writing anything to it through UART. Otherwise everything be lost. \$\endgroup\$
    – Zhiyong Li
    Commented Jan 13, 2014 at 2:33
  • 2
    \$\begingroup\$ An update: a delay of 5 mini seconds before asserting sleep_rq did the trick. At 1 mini second, message will still arrive on receiving end in batches of two but without the loss of the last two bytes of the second message. The delay could possibly even shorter, like 2 or 3 miniSeconds, but for the sake of safety, I will settle with 5. I am not sure this is a zigbee protocol issue or a Digi implementation problem. But either way, Digi needs improve its documentation. I just cannot afford to deal with those hidden tricks. \$\endgroup\$
    – Zhiyong Li
    Commented Jan 13, 2014 at 3:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.