is short period Deep Sleep possible to save power?

[chrisi]

I am using a sipy and pytrack to take an accelerometer measurement every second or so. I need to drastically reduce power and was wondering what would be the shortest period i could go into deep sleep for to save power. I do not need wifi or Bluetooth enabled but would like to send a sigfox message once a day. Normal sleep mode still uses 50mA of power which is barley less than not sleeping at all.

I guess what i am asking is

• what power is consumed to wake up / go into deep sleep?
• how long does it take to wake up / go into deep sleep?
• Other then disabling Wifi, Bluetooth and other sensors I am not using how else can I save power (maybe by clock speed)?

[bucknall]

Hi @chrisi,

Please read this post (https://forum.pycom.io/topic/1022/root-causes-of-high-deep-sleep-current/54) for more information regarding the Deep Sleep.

In short, you will need to use a Deep Sleep shield to achieve the current draw that you are expecting. We're shipping these out now so please drop an email to support if you need to get one for your board.

Let me know if that helps,

Thanks!

[this.wiederkehr]

@chrisi said in is short period Deep Sleep possible to save power?:

sipy and pytrack

@bucknall there should be no need for the deep sleep shield if he is using the pytrack

@chrisi: If you are using the pytrack the procedure to go to sleep is different:

see here for reference on the current draw:
https://forum.pycom.io/topic/1460/power-consumption-deep-sleep-pysense-pytrack

Basically do:

from pytrack import Pytrack
time.sleep(10)
py = Pytrack()
py.setup_sleep(30)
py.go_to_sleep()

I'm also interested in the answers to your questions as I have the need for short sleep periods (<1 sec) as well.

[bucknall]

@this.wiederkehr @chrisi

This is correct; I missed the fact that you said you have a Pytrack. You can use the Pytrack Libraries to achieve deep sleep.

[Eric24]

@this.wiederkehr I'm not sure this is the right approach for very short sleep periods (especially < 1 second), since there is latency in entering and waking up from deep-sleep (mostly when waking). I believe there is planned future support for a sleep mode that essentially just "pauses" the device, but I haven't seen anything about this recently, and in fact, it may not work with the current generation of pycom modules (those that require the support of a shield for deep-sleep). For short sleep periods, something like that is probably a better solution, since it should enter/leave sleep mode almost instantaneously.

I'd be interested to hear from others that have experimented with deep-sleep, and what kind of latency you're seeing on wake-up.

[BetterAuto]

On the ESP8266 there were "light sleep" and "modem sleep" modes that were actually more efficient than deep sleep for cycles under 2 seconds, per Espressif, due to as Eric said the long wake latency. Waking from deep sleep is the same as a reset. I can't speak to Sigfox latency but Wi-Fi latency is several seconds. Maybe these two modes are available on Pycom modules? I haven't looked. Also look at machine.idle().

[Eric24]

@BetterAuto It's my understanding that "modem sleep" is achieved by simply turning off the WiFi and Bluetooth radios. "Light sleep" is the mode that I think is not yet supported by pycom (which I believe is the machine.sleep() function, per the micropython docs). As for "machine.idle()", it only gates the CPU clock until the next interrupt, but (at least) the system timer interrupt is running at a fairly short interval, it won't have much of an effect (frankly, I haven't seen any difference in power consumption between this and the utime.sleep*() functions; I haven't dug into the source code, so that may be because the utime functions are actually using machine.idle() under the covers, or because machine.idle() doesn't actually get the CPU clock, or possibly because the reduction in power is too small for me to measure).

[jmarcelino]

The SiPy takes about 1.9 seconds from the Pytrack deep-sleep wakeup (effectively power on) until it's running the first command (in boot.py) so this style of sleep isn't suitable for very frequent actions. Also the power-on current is particularly high - I haven't done the math yet but my feeling is if you're deepsleeping for less than 30s it's not worth doing it.

Until all the ESP32 functionality is available (sleep modes, true deep-sleep, ULP) a good strategy is to do what Pycom did on the Pytrack and Pysense: use a separate low power microcontroller for small repetitive tasks and only wake up the main processor when necessary.

[chrisi]

@jmarcelino Thanks, a separate low power microcontroller is exactly what I am now planning to do now until they bring out the ability to use the UPL for small tasks.

[chrisi]

This post is deleted!

[chrisi]

@jmarcelino I have done what you have suggested and used a separate low power microcontroller for small repetitive tasks (MSP430). I was wondering if you have any I2C example code to which can communicate between the 2 devices? Or do you think SPI or another was to comunicate would be better?

[BetterAuto]

@chrisi Or what about good old UART?