PDA

View Full Version : wakeup occational problems


korda
04-16-2009, 11:12 AM
We are getting statistical data for the 100 remotes.
Observing that 1 out of 100 once a week does not wake up correctly.
The radio has uninterrupted power during all this time.
On wakeup script calls startup() function.

Appears that the script is not running. The radio responds to ping only and none of the script. Any suggestions?

mgenti
04-16-2009, 11:47 AM
Does rebooting the node start making the script respond or do you have to reupload the script?

korda
04-21-2009, 10:31 PM
reboot fixes the problem.

kbanks
04-22-2009, 01:46 PM
That rules out configuration issues (since the unit comes out of reset with the saved config, and talks).

The next thing to check is your script.
1) Are you putting the node into an infinite loop in your SNAPpy script?
2) Are you putting the node into a sleep from which it cannot wake up?
For example, did you enable "wakeup" on a pin that is not really externally connected, and do a sleep() with a timeout of 0 ("forever").
3) Are you turning off your radio in your script? (rx(False))
4) Are you reducing your TX Power too low to be heard?

WilliamM
04-22-2009, 07:44 PM
1) Are you putting the node into an infinite loop in your SNAPpy script?All 100 nodes have the same script loaded onto them, and the failure is very rare, so that seems unlikely. Also, we never use while loop.


2) Are you putting the node into a sleep from which it cannot wake up?
For example, did you enable "wakeup" on a pin that is not really externally connected, and do a sleep() with a timeout of 0 ("forever").The sleep is always finite. All nodes sleep for the same amount. Wakeup time varies by up to 6 minutes, because of randomized check-ins for a sleep interrupt.


3) Are you turning off your radio in your script? (rx(False))No.


4) Are you reducing your TX Power too low to be heard? As far as I know, we are doing no such thing.

kbanks
04-23-2009, 08:46 AM
Wakeup time varies by up to 6 minutes, because of randomized check-ins for a sleep interrupt.

Is it possible for your randomization algorithm to (very rarely) come up with the number 0, resulting in a "sleep forever"?

WilliamM
04-23-2009, 02:24 PM
Is it possible for your randomization algorithm to (very rarely) come up with the number 0, resulting in a "sleep forever"?

No, like I said, they all sleep for the same amount -- a finite number of hours.

mgenti
04-24-2009, 01:47 PM
Appears that the script is not running. The radio responds to ping only and none of the script.

In Portal if you enable printing function return values, is anything displayed in the event log when you click on one of the nodes functions.

kbanks
04-24-2009, 03:01 PM
I was re-reading this thread, and I realize I missed a key point.

In your initial post you said

Observing that 1 out of 100 once a week does not wake up correctly.

This had me thinking that the nodes were not responding at all, and is why I asked questions about sleeping forever, turning off the radio, etc.

However, in the same post you also said

The radio responds to ping only and none of the script.

If a node responds to ping, it is awake and communicating.

Since you said that a reboot is sufficient to get out of the failure mode, we know the SNAPpy image is not being corrupted.

When the unit is in this mode, what other functions can you get to work over the air (besides ping)? Can you successfully invoke any of the other built-ins? (Can you blink an LED?)

If the built-ins still work, can you invoke any of the user defined functions in your script?

Can you invoke the startup() function in your script manually, and what does it do?

korda
04-24-2009, 07:40 PM
We had only reboot option available at the time, so cannot answer your questions. Next time we see this happen, we will try to extend our test.