Home/Support/Support Forum/Sleep behaviour when migrating from S2B to S2C

Sleep behaviour when migrating from S2B to S2C

0 votes
We have to migrate from an S2B module to the newer S2C module.

The configuration is practically the same, especially the sleep mode parameters.
SM=5, SO=2, SP=0x7D0 (=20secs), ST=2000, SN=0xffff

When examining the S2B module, we see a higher current consumption every 20secs (the SP time) for about 10ms. (No RF frames are being sent to the module). It seems, the RF CPU wakes every 20secs to check for new RF frames. When no frame is available, it goes to sleep after several ms.

The S2C module also sleeps for 20secs, but stays awake for the full 2 secs, even if NO RF frame is pending (ST time ?).

(When reducing the ST parameter to 10ms, the regular wakeup is reduced to 10ms, but we are not able to communicate from our host software.)


The configuration of SO is a bit confusing, because CodeWarrior GUI shows for SO="short sleep". Which results in SO=2.
The documentation (for S2B and S2C) says SO=2 -> "Always wake for ST time".

Is the S2B interpreting this parameter different as the S2C ?

What is the correct configuration - for both modules ?

kind regards, Bernd.
asked Jan 10, 2017 in XBee Programmable Development by kohlmaier New to the Community (3 points)

Please log in or register to answer this question.

2 Answers

0 votes
No, the SO command should be the same. Setting it to a 02 would cause the module to remain awake for the entire ST time frame.
answered Jan 10, 2017 by mvut Veteran of the Digi Community (12,829 points)
0 votes
But why is the S2B module NOT awake for the full time ?
answered Jan 10, 2017 by kohlmaier New to the Community (3 points)
What firmware version are you working with on the S2B?
28A7 reads as follows for the SO command:

Set/read sleep options. Bitfield options include: 0x02 - Wake for ST time on each cyclic wake (after sleeping for SN sleep periods), 0x04 - Enable extended cyclic sleep (sleep for entire SN*SP time - possible data loss). All other option bits should be set to 0.
Firmware version 29A7 (S2B Module)
SO on your S2B is most likely set to 0 instead of 0x02.
...