I need to collect analog readings at about 5Hz on remote end devices for maybe 10 min and then put them into energy saving mode. Essentially, I am trying to have the end devices go into sleep mode when I am not collecting data and keep them constantly active (no down time) when I am collecting data. I am thinking of achieving this by sending remote AT command ‘SM1′ (pin sleep mode) to end devices when I am collecting data with pin 9 to GND then switch them back to ‘SM4′ when not collecting data.
When I run the end device in cyclic sleep mode (‘SM4′), the data I receive is fine (fairly steady). But in ‘SM1′ mode, there is an occasional hiccup in the data stream (often a drop of 20 to 40 ADC units). What could it be? I am using a modified version of Faludi’s Simple_actuator_network processing code combined with the SensorData class from his Simple_sensor_network code .
Thanks in advance for your help.
One thing I just found out though was that when I drop the IR rate from 200 microsec (5Hz) to 250 microsec (4Hz), the hiccup seems to go away. Could this be a hardware limitation?
I am not sure what you mean by hold/wait times. I have confirmation that the sleep mode was switched properly from sm1 to sm4 and vice versa. I even have an led on pin 13 that tells me what the xbee is doing. One thing I found out though was that when I drop the IR rate from 200 microsec (5Hz) to 250 microsec (4Hz), the hiccup seems to go away. Could this be a hardware limitation?
When you tell the XBEE to go to sleep (via changing the sleep pin when SM=1 or 2) I believe it performs any waiting samples and uart/RF data, then moves a pin to indicate it has gone to sleep.
Then when you change the wakeup pin to wake the xbee up, you have to wait for the xbee to move a pin declaring it is awake and functioning, and then you are supposed to wait X amount of time.
It moves the CTS pin to indicate sleeping/wakening
Going to sleep:
When Sleep_RQ (pin 9) is asserted, the module will finish any transmit, receive or association activities, enter Idle Mode, and then enter a state of sleep. The module will not respond to either serial or RF activity while in pin sleep.
The module will wake when Sleep_RQ is de-asserted and is ready to transmit or receive when the CTS line is low. When waking the module, the pin must be de-asserted at least two ‘byte times’ after CTS goes low.
Those are from the manual for the 802.15.4 modules, so they might not be valid.