Deep Sleep Summary

[iotmaker]

@PeterBaugh From the battery positive lead in series to the VIn of the expansion board

[Colateral]

Hello,

I'm using LopY with Expansion board. SW upgraded to ver 1.7.8.b1

I tried deepsleep functionality simple as below.

import machine
machine.pin_deepsleep_wakeup(['P18', 'P15'],machine.WAKEUP_ALL_LOW, True)
machine.deepsleep(15*1000)
print("\n\n Wakeup",  machine.wake_reason())

The board is going to sleep and indeed is waking up on P18 dumping the following output .

rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff9010,len:12
ho 0 tail 12 room 4
load:0x3fff9020,len:388
load:0x40078000,len:11584
load:0x4009fc00,len:848
entry 0x4009fd9c

** I don't understand why the LoPy was reset after this wakeup **

In order to dump the reason, I also added in main.py the following

print("\n\n Wakeup main reason",  machine.wake_reason())

and has no output

Wakeup main reason (1, []) 

** I believe there is bug that no GPIO is mentioned in that list **

[jcaron]

@Colateral wake from deep sleep is actually similar to a reset: as the CPU and its RAM are not powered during deep sleep, you can't just resume at the next Python instruction, as it restarts from scratch.

Differentiating a wake up from deep sleep from other reasons (regular power on, reset...) is still a bit difficult, the subject has already been discussed in other threads.

[Colateral]

@jcaron Thank you.

Yes, in the meanwhile I read dozens of posts. The question is why after reset I don't get the GPIO pin that triggered the wakeup?

Do the deepsleep shield fixing this GPIO wake up cause bug?
Actually, If the Lopy is working fine with this reset what else is enhancing the deepsleep shield?

[rloro338]

@iotmaker I am measuring the same power comsumption ... 620 uA with expansion board and 520 uA without it.

[iotmaker]

@rloro338 said in Deep Sleep Summary:

@iotmaker I am measuring the same power comsumption ... 620 uA with expansion board and 520 uA without it.

I am glad i am not the only one.. I just took another sipy updated firmware and deepsleep library and same issue 520uA really far from 7 or 10 ua

[jcaron]

@iotmaker @rloro338 Updated the summary with the current draw reported with the Deep Sleep Shield.

Also added that powering via 3V3 may not be a solution, and that wake on pin with the Pysense is not trivial.

[dmayorquin]

Hi, I have a SiPy + Pysense + 3.7 V LiPo battery. I'm testing Deep sleep mode from Pysense library but the multimeter is not showing 12 µA current consumption.

SiPy firmware: 1.18.0
Pysense firmware: 0.0.8

My program disabled WiFi in boot.py. In main.py I blink an LED for 5 seconds and then go to sleep. These are my results:

Blinking: ~50 mA
Deep sleep: ~2.2 mA

main.py code:

from pysense import Pysense
import pycom
import time

py = Pysense()

#Turn-of heartbeat
if pycom.heartbeat() == True:
    pycom.heartbeat(False)

for i in range(5):
    pycom.rgbled(0x1F)
    time.sleep(0.05)
    pycom.rgbled(0x00)
    time.sleep(1)

#Sleep 20 seconds
py.setup_sleep(20)
py.go_to_sleep()

Is there any piece of code I'm missing? What are you doing to get 12 µA with the Pysense board?

[jcaron]

@dmayorquin never tried with a SiPy, only a LoPy, but the end result should be the same as the PySense will completely switch off the module.

The usual culprit is powering through USB, but if I understand correctly your setup, this is not the case. You are connecting the battery directly to the JST-PH connector on the Pysense, right?

Do you have anything else connected? Do you have an SD card in the slot? You haven’t setup any of the sensors to remain awake (like accelerometer wake up)?

[dmayorquin]

Hi @jcaron , thanks for your fast answer. Yes, I'm connecting the battery directly to the JST connector on the Pysense and I'm not using any sensor or SD card. In boot.py I disable WiFi:

from network import WLAN

wlan = WLAN()
wlan.deinit()

And main.py code is exactly as It's shown in my previous reply. I'm going to try with other releases of SiPy firmware. If you have any suggestion please let me know.

[sslupsky]

@dmayorquin Did you resolve this issue? Looking at your code, one question comes to mind that I have been looking to find an answer to.

You use py.go_to_sleep() to enter sleep mode which is part of the Pysense class.

Is that that call functionally equivalent to machine.deepsleep() ?

[jcaron]

@sslupsky if you have one of the older modules (LoPy 1, SiPy, WiPy 2), then there is an issue with the “native” deep sleep (machine.deepsleep) which results in a higher than expected power draw during deep sleep (>10 mA instead of 10-20 uA).

For those modules, the workaround to achieve low current deep sleep is to use an external board: Deep Sleep Shield, PySense or PyTrack, and the relevant library. This will cut all power to the module during deep sleep.

If you use one of the more recent modules, you should in most cases use the native deep sleep.

[dmayorquin]

Hi @sslupsky, I solved the issue and the complete code is here: https://forum.pycom.io/topic/3594/how-to-deep-sleep-with-sipy-pysense-3-7v-lipo/3

As @jcaron says, machine.deepsleep() works well with the new hardware, but I'm not sure it works too when your setup has a shield like Pysense. In that case I've read that you should use the deep sleep method from Pysense library (or Pytrack or whatever shield you're using).

[sslupsky]

Hi @dmayorquin ,

Your post was extremely helpful, thank you for pointing that out. It is encouraging that you achieved < 20uA sleep current.

Thank you @jcaron for the clarifications. I should have mentioned that I am using a Pysense and LoPY4.

I think I understand now that when you use a Pysense, use the Pysense API to put the system to sleep (ie: py.go_to_sleep()). If you have just a LoPY4 and are not using the Pysense, then use the machine.deepsleep() to put it to sleep.

[sslupsky]

Hi @jcaron I have another question regarding the Pysense. Is it possible to "sleep" the SD Card? Typically that would require that power to the card is turned off since most SD card sleep current specs are 100's of uA.

@administrators May I make a suggestion regarding a future update to the Pysense? Instead of an SD card, could you embed an eMMC chip instead? Or have both? eMMC chips typically have lower sleep current ratings and wider temperature ratings than SD cards.

[jcaron]

@sslupsky even if you are using a Pysense, it probably makes sense to use the native machine.deepsleep if you are using a LoPy 4. This keeps the RTC running, for instance.

[sslupsky]

@jcaron Thank you for the suggestion. I did not realize the Pysense API killed the RTC. That is good to know since I want to keep track of time. I have a code module working with the Pysense API now. I will try the native machine API.

[jcaron]

@sslupsky When you use deep sleep controlled by a PySense, PyTrack or the Deep Sleep Shield, deep sleep just completely powers off the xxPy module (ESP32, LoRa/Sigfox and/or LTE modem). No RTC, no ULP, no pin wake-up (on the ESP32), nothing...

If you use modules that support the native machine.deepsleep without the higher power consumption, it's probably always better to use that. The PySense/PyTrack/Deep Sleep Shield deep sleep was just a workaround.

[sslupsky]

@jcaron Ahh, that explains it. Now I understand better. Thank you.

[philwilkinson]

@sslupsky I just wanted to add a little to this discussion for new boards e.g. LoPy4 on an expansion board (not Pysense/Pytrack).
-The machine.pin_deepsleep_wakeup() function works fine.
-Using machine.deepsleep(time_in_ms) works fine once only. When the time_in_ms is complete, the unit wakes up OK and runs main.py. machine.wake_reason() correctly identifies a RTC WAKEUP.

However, it is not possible to then run machine.deepsleep(time_in_ms) again. The unit thinks the time has already elapsed and immediately exits deepsleep.