# Analog input hiccup

**URL:** <https://forums.digi.com/t/analog-input-hiccup/11648>\
**Category:** ZNet 2.5\
**Tags:** analog-input, analog-read, xbee-api, xbee-api-java, xbee\
**Created:** [June 25, 2013, 11:23am UTC](https://forums.digi.com/t/analog-input-hiccup/11648 "2013-06-25T11:23:54Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![snouwakpo](https://avatars.discourse-cdn.com/v4/letter/s/c67d28/32.png) [@snouwakpo](https://forums.digi.com/u/snouwakpo)\
**Post date:** [June 25, 2013, 11:23am UTC](https://forums.digi.com/t/analog-input-hiccup/11648/1 "2013-06-25T11:23:54Z")

</div>

My network:  
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.

Problem:  
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.

Update:  
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?

---

<div class="post-metadata">

**Author:** ![plater](https://avatars.discourse-cdn.com/v4/letter/p/f05b48/32.png) [@plater](https://forums.digi.com/u/plater)\
**Post date:** [June 25, 2013, 1:22pm UTC](https://forums.digi.com/t/analog-input-hiccup/11648/2 "2013-06-25T13:22:22Z")

</div>

Are you following the correct amount of hold/wait times when changing the sleeping pin (when SM=1 or SM=2)?

---

<div class="post-metadata">

**Author:** ![snouwakpo](https://avatars.discourse-cdn.com/v4/letter/s/c67d28/32.png) [@snouwakpo](https://forums.digi.com/u/snouwakpo)\
**Post date:** [June 26, 2013, 9:41am UTC](https://forums.digi.com/t/analog-input-hiccup/11648/3 "2013-06-26T09:41:08Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![plater](https://avatars.discourse-cdn.com/v4/letter/p/f05b48/32.png) [@plater](https://forums.digi.com/u/plater)\
**Post date:** [June 26, 2013, 9:53am UTC](https://forums.digi.com/t/analog-input-hiccup/11648/4 "2013-06-26T09:53:32Z")

</div>

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.

Waking up:

> 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.

---

<div class="post-metadata">

**Author:** ![jhonharry](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jhonharry](https://forums.digi.com/u/jhonharry)\
**Post date:** [July 1, 2013, 8:14am UTC](https://forums.digi.com/t/analog-input-hiccup/11648/5 "2013-07-01T08:14:36Z")

</div>

I am not able to give the answer of your question. But i am try to get infomation about it.

…  
jhonharry