Waking up from sleep mode

[sidmalani]

How do we know that the device has woken up from sleep mode. Is there a hook for this?

I mean I can use the timer call to do that but that means a max error of X seconds where X is the timer before I know its woken up from sleep. This is not good as it means power wastage...

Also does the timer wake up the device when in sleep mode for a longer duration than the timer?

Thanks
Sid

[sidmalani]

Possible solution

This is how I attempted to solve it - but not sure if this is the correct way?

    
    #main code
    sleep(0, 0)
    
@setHook(HOOK_1S)
def timer1sEvent(currentMs):
    
    global timerCounter
    
    timerCounter += 1
    if timerCounter >= 10:
        timerCounter = 0
        mcastRpc(1, 1, "tagping", localAddr())
    else:
        print "sleeping"
        sleep(0, 0)
        
@setHook(HOOK_RPC_SENT)
def rpcSentEvent():    
    print "rpc sent sleeping"
    sleep(0, 0)

Any comments will be appreciated.

Thanks

[korymc]

@sidmalani are you trying to sleep for a certain amount of time or are you trying to wake up on an IO Pin Interrupt? Currently you are putting it into a deep sleep (first param of the sleep method is 0) and you are waiting for an IO pin interrupt to occur (second param of the sleep method is 0). From the manual:

A ticks parameter of 0 can be used to sleep until an IO pin interrupt occurs (see script pinWakeup.py), but SNAPpy is smart enough to know if you have not enabled a wakeup pin, and will ignore a sleep(mode, 0) if there is no wakeup possible.

I have personally not used the IO pin interrupt but have used the timed sleep (first param of the sleep method = 1). If you are trying to use the timed sleep, you can do something like:

def doSomethingThenSleep():
    # Do some stuff here.
    sleep(1, 10) # Timed sleep for 10 ticks (i.e. 10 seconds, depending upon the platform)
    # Print that we are awake
    print 'awake!'

Instead of a print statement, you can also RPC another node or SNAP connect instance to let them know the node is awake.

Also note that in your code:

print 'sleeping'
sleep(0, 0)

I believe (from reading other posts) that the print may not have enough time to actually clear the buffer before the sleep occurs, so you may not see it.

Hope that helps.

KM

[sidmalani]

Thank

@KM

Many thanks for your explanation. I am using the SM200P81. At the moment I simply want a timed call (not with IO).

Somewhere in the doc (as I understood it and I am probably mistaken) use sleep(1,1) if there is a RTC on target (which I don't have) else use set(0,1).

Does it mean that if you have a

@setHook(HOOK_1S)
def timer1sEvent(currentMs):

then this will be called even if you do (to sleep indefinitely until another timer interrupt) as in

sleep(1, 0)

?
Thanks
Sid

[Jheath]

How do we know that the device has woken up from sleep mode. Is there a hook for this?

No HOOK is required since execution resumes immediately after the call to sleep (ie the function will run to completion). You can stick a print statement (or blink an LED) after the sleep call in your "timer1sEvent".

Side Note: Your print issued before the sleep (print "spleeping") is probably not going to execute the actual print until the system awakes. Sleep happens immediately while a print must enqueue to a serial port or radio interface first. In other words, you are telling the system to sleep before it has a chance to finish the print process (blocking vs. non-blocking operations). Do a quick search on HOOK_RPC_SENT and HOOK_STDOUT for more.

[Jheath]

Somewhere in the doc (as I understood it and I am probably mistaken) use sleep(1,1) if there is a RTC on target (which I don't have) else use set(0,1).

The difference in sleep modes depends on the platform you are using, but in most cases one mode is a deeper sleep, but at a decreased time accuracy. Neither require an external RTC though.

Does it mean that if you have a

@setHook(HOOK_1S)
def timer1sEvent(currentMs):

then this will be called even if you do (to sleep indefinitely until another timer interrupt) as in

sleep(1, 0)

?

During sleep the system will no longer execute any hooks including the timers. Once you awake from sleep you will complete the function you were in, then begin running through the hooks again.

[sidmalani]

Another approach

Thanks for your responses. I guess I could do this... right??

 ....
    #main code

    #This triggers first rpc call
    mcastRpc(1, 1, "tagping", localAddr())


@setHook(HOOK_RPC_SENT)
def rpcSentEvent():    
    sleep(1, 2)
    mcastRpc(1, 1, "tagping", localAddr())

[korymc]

Thanks for your responses. I guess I could do this... right??

Yes, your code would sleep for 2 ticks so ~2s after the first mcastRpc and the hook is invoked and then when it wakes up it would fire the second. One thing to keep in mind, though, is that HOOK_RPC_SENT is fired after every single RPC, so if you have more RPCs happening throughout the other SNAPpy code, it will sleep after those as well. This may not be what you want or are expecting.

KM

[sidmalani]

Wake up power

Thanks KM

I have only one RPC so it should be ok. The only other question is how much current does it consume while waking up and calling the rpc. I have done rx(0) to avoid receiving overheads while waking up.

So basically I am expecting it to consume some current while waking up (duration of ~890us) and then transmission for which I am not sure what the overheads are?? I could not find clear values in doc for current when rx off, time for rpc calls or packet overheads so I can calculate how much it takes to make a RPC call happen etc. to calculate average duty cycle and battery requirements...

Sid

[gvoce]

Take a look at the attached spreadsheet for know current measurements.

[sidmalani]

TX overheads

@gvoce - thanks for the doc. That really helps a lot.

Is there any such doc for the tx overheads - i.e. if its rpc, what format does it use etc. i.e. XML or does it use something else, and whether it can be optimized at all?

Thanks
Sid

[korymc]

Take a look at the attached spreadsheet for know current measurements.

@gvoce That's a great document, I have never seen it before; thanks for posting it. Out of curiosity, does the "extended" just mean over an extended period of time?

Thanks,
KM

[gvoce]

Yes extended means longer than the other timed sleep mode. Basically until the current measurment stablized, then some. (1-2 minutes)

[gvoce]

Is there any such doc for the tx overheads - i.e. if its rpc, what format does it use etc. i.e. XML or does it use something else

no measurements for TX overheads that I am aware of. Your statement RPC format ------- RPCs or either multicast or unicast take a look at the SNAP reference manual.