Has anyone ever gotten Sleep Mode to REALLY work?

I am using XBee modules and adapters and I have experimented with ZB Sleep Mode on and off for several months now and it seems to me, at least for the XBee devices, it just does not work! I’d like to hear from users using Xbee devices, who have actually gotten it to working.

In my experience and what I mean by ‘work’ is;

  • it is possible to 'program the XBee ZB radio to sleep by setting SM = 4 or 5. But it’s impossible to program it back to no sleep. Once set SM can never be set back to 0, so sleep mode is always enabled. Why can’t SM be programmed back to 0 (Sleep Disabled)?

  • if an XBee sensor adapter is set to sleep trying to change sleep parameters (SM, ST, SN, SO) is hit or miss, mostly miss. This is true from either the gateway web interface, X-CTU app or programmatically (Python)

  • Unless threading or similar is used a program hangs on a sleeping module.

  • Battery life seems to be a guess. Yes I understand Amp-hours, but accurately determining power draw during ST (wake time) is impossible due to so many exceptions.

  • A forced wake up mode would be a great help. I realize this will mean a significant increase in ‘sleep’ mode power, but to me the way it is now is nearly useless.

This mode is called ‘Sleep’ it may be more appropriate to call it ‘Dead’. Once an XBee module is put into ‘Sleep’ mode its functionality drops to near zero. I have ‘destroyed’ several XBee ZB radios by putting them in ‘Sleep’.

Your questions below in quotes, my answers follow…

“- it is possible to 'program the XBee ZB radio to sleep by setting SM = 4 or 5. But it’s impossible to program it back to no sleep. Once set SM can never be set back to 0, so sleep mode is always enabled. Why can’t SM be programmed back to 0 (Sleep Disabled)?”

It depends on the firmware really. Which version do you have loaded on the module? Router firmware can have SM=0 or SM=4/5 set. End Device firmware can NOT set SM=0.

“- if an XBee sensor adapter is set to sleep trying to change sleep parameters (SM, ST, SN, SO) is hit or miss, mostly miss. This is true from either the gateway web interface, X-CTU app or programmatically (Python)”

Yes, its best to make ALL other parameter changes before setting SM=4/5, since this means the device will sleep, and it can’t be communicated with while asleep. Alternately, the Ident button on an XBee adapter can be pushed once to wake up a sleeping end device for 30 seconds. This is sometimes useful in the situation you mention.

“- Unless threading or similar is used a program hangs on a sleeping module.”

A sleeping module is asleep and can’t be spoken to when in that state. Program accordingly…

“- Battery life seems to be a guess. Yes I understand Amp-hours, but accurately determining power draw during ST (wake time) is impossible due to so many exceptions.”

Yes, battery life is a variable that depends on how you set it to sleep, as well as whether the device connected to the XBee adapter requires time to take a sample.

“- A forced wake up mode would be a great help. I realize this will mean a significant increase in ‘sleep’ mode power, but to me the way it is now is nearly useless.”

I’m not sure what you mean by forced wakeup mode. How would this differ from Cyclic Sleep or Cyclic Sleep w/Pin Wake?

“This mode is called ‘Sleep’ it may be more appropriate to call it ‘Dead’. Once an XBee module is put into ‘Sleep’ mode its functionality drops to near zero. I have ‘destroyed’ several XBee ZB radios by putting them in ‘Sleep’.”

If the module were any more “awake” when in sleep mode, it would be draining battery life, which would reduce the battery life significantly. Sleep mode operates as intended. As far as modules being destroyed, you may want to call Technical Support about that to either try and recover the module, or get them RMA’d if they’re truly defective.