Home/Support/Support Forum/Analog input hiccup

Analog input hiccup

0 votes
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?
asked Jun 25, 2013 in ZNet 2.5 by snouwakpo New to the Community (0 points)
edited Jun 26, 2013 by snouwakpo

Please log in or register to answer this question.

3 Answers

0 votes
Are you following the correct amount of hold/wait times when changing the sleeping pin (when SM=1 or SM=2)?
answered Jun 25, 2013 by plater New to the Community (22 points)
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?
0 votes
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:
Quote:
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:
Quote:
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.
answered Jun 26, 2013 by plater New to the Community (22 points)
0 votes
I am not able to give the answer of your question. But i am try to get infomation about it.


..............................................................
jhonharry
answered Jul 1, 2013 by jhonharry New to the Community (0 points)
...