Root causes of high deep sleep current [LoPy1, WiPy2 and SiPy], all the new modules **do not have deepsleep issues**

[Fred]

IMPORTANT: All the information available here is only application to the LoPy1, the WiPy 2.0 and the SiPy. The rest of the modules (W01, L01, WiPy3, LoPy4, FiPy, GPy) have proper deesleep mode that can achieve between ~5 and ~15uA.

Dear All,

We have now completed a series of extensive tests around the deep sleep issues being experienced with the WiPy 2.0, LoPy 1.0 and SiPy 1.0. We appreciate your patience whilst we were able to review in detail the root cause of this issue with the Espressif teams. Our findings are as follow:

Root cause 1:
The DC-DC switching regulator always stays in high performance PWM mode. We are using a pin from the ESP32 to control the operating mode of the switching regulator. In high performance PWM mode it offers the lowest output ripple and noise, but the quiescent current is ~10mA. When the regulator is set into ECO mode, the quiescent current goes down to 10uA. We chose this type of design in order to have the best performance and lowest ripple during active operation while being able to switch to ECO mode while in deep sleep. Unfortunately, the pin used to control this mode is out of the RTC domain, and therefore not usable during deep sleep. This causes the regulator to always stay in PWM mode, keeping it’s quiescent current at 10mA.

Workaround:
Power the board via the VIN (not 3V3!) pin using a stable 3V3 supply that is able to deliver at least 400mA. This lowers the deep-sleep current to around 2.5mA.

Root Cause 2:
The flash chip doesn’t enter power down mode because the CS pin is floating during deep sleep. This causes the flash chip to consume around 2mA of current. The way our circuit is designed, the VDD_SDIO domain of the ESP32 (which also powers the external flash), is powered externally instead of using the internal regulator in the ESP32 itself. Because of this, the flash memory always remains powered and never goes to deep sleep. We opted for this design as it had the benefit of being able to control the VDD_SDIO without having to rely on the value of the MTDI pin during boot-up. With this approach we gain 1 extra GPIO pin.

Workaround:
We have designed a retrofit hardware solution for this, and will very soon be releasing a deep-sleep shield that can be fitted between our expansion board and the modules (but also can be used without the expansion board). This deep sleep board will take care of powering down the module completely when the deep sleep command is sent. It’ll be able to wake on timer and pin interrupts. With the Low power shield the current consumption during deep sleep is between 7uA and 10uA depending on the wake sources configured. This board will work in a transparent way in terms of software. Once it is connected to the module it will be detected during start-up. The deep-sleep shield will resolve root causes 1 and 2.

Conclusion:
The design problems that have been identified only affect WiPy 2.0, LoPy 1.0 and SiPy 1.0. These design problems do not exist in any of the other Pycom developer boards such as FiPy, GPy or any of the OEM modules. You can see some of the test results from Daniel here: https://www.pycom.io/news/l01-oem-module-deep-sleep-test/. We will redesign the WiPy 2.0, LoPy 1.0 and SiPy 1.0 over the next few months in order to remove this deep sleep issue whilst enhancing the product performance to include 4MBytes of RAM and 8 Mbytes of flash.

The FiPy, GPy and newer developer modules to be released (as well as the motherboard reference design for the OEM modules), have the switching regulator configured in automatic mode, therefore, when the module is active, the voltage regulation uses PWM mode for best performance and low ripple voltage, and when the current consumption drops to uA levels, it enters ECO mode consuming just 10uA. All the new designs with the 4MByte external RAM also use 1.8V for the VDD_SDIO supply, which comes from one of the ESP32 pins. With this approach, the flash and the external RAM are switched off during deep sleep, as well as any other additional circuits (LoRa, Sigfox, etc), ensuring the lowest possible current during deep sleep.

Resolution:
Pycom is committed to resolving this problem for our developer community and has been working in parallel on the development of the deep sleep shield in the shortest possible time.

Whilst we are satisfied that this problem is limited to the first generation of the modules, this is of no consolation to those of you facing deadlines and whom require testing of the Ultra Low Power modes prior to moving to OEM modules. We believe the deep sleep shield will provide the ‘best’ resolution for this issue and will be making it available Free Of Charge to all customers whom have purchased the affected developer boards. To receive your free shield please email https://www.surveymonkey.co.uk/r/PSTPWBB order number, the number of shields required (maximum 1 per developer board purchased) and the delivery address. We expect to have all shields available for shipping Mid May 2017 (4 weeks time).

Finally, moving forward, we will be bundling Free of Charge the deep sleep shield for customers whom purchase current stocks of the developer boards impacted thus removing any possible issue for our customers.

Please note: For customers using Pysense and Pytrack, these boards are designed to support deep sleep mode (out-of-the-box) in the same manner as the deep sleep shield. We will also be releasing during the next few months a new expansion board V3 which supports the deep sleep feature and therefore can be used with the current batch of Pycom developer boards (LoPy 1.0, SiPy 1.0 and WiPy 2.0).

On behalf of the entire team here at Pycom, thank you for your continued support!

Best wishes
Fred

[mattliddle]

@mattliddle @Fred I discovered an important insight! When powering it through USB (I'm using the expansion board 2.1) there is an LED light that turns on and stays on even in deep sleep. I was measuring current draw and it was always at least 14 mA. I tried powering the device outside of the expansion board by a 3.7V source, and in deep sleep, sure enough it dropped into the microamp range. Even when it is on expansion board 2.1 and powered through battery instead of usb, the LED stays turned off, and therefore power consumption will drop into the micro amp range.

[mattliddle]

@Fred What do you need to do to accomplish that low of power consumption on the GPy with deep sleep? I'm getting about 18 mA when it's going into deep sleep..

import machine

# and later on in the code once my sensor is done running, I call this
machine.deepsleep(30000)

What could be going on? does the GPy 1.0 need a power saving board as well? I've looked around on the forum only to find no real solution yet, but other users with the same issue.

[dmayorquin]

Hi @radec, thanks. According to documentation, machine.deepsleep() works well when you are not using a shield or expansion board, but in my case I'm using SiPy + Pysense, so I must use the deep sleep methods of Pysense library. I've found a solution which I posted here:

https://forum.pycom.io/topic/3594/how-to-deep-sleep-with-sipy-pysense-3-7v-lipo

By the way, I also tried machine.deepsleep() with my setup, but didn't work (the deep sleep current was ~60 mA).

[Radec]

@dmayorquin I think you forget lines codes :
Example with timer :

import machine
machine.deepsleep(3600000 )  # 1 hours

[dmayorquin]

Hi @Fred, I need some help with the Pysense deep sleep mode. I have a SiPy + Pysense + 3.7 V LiPo battery (Using JST connector on Pysense). I'm testing Deep sleep mode from last version of Pysense library but I'm measuring high deep sleep current consumption.

My program disabled WiFi in boot.py. In main.py It blinks an LED for 5 seconds and then sleeps 20 seconds. These are my results:

SiPy firmware: 1.18.0
Pysense firmware: 0.0.8
Blinking: ~50 mA
Deep sleep: ~2.2 mA

main.py code:

from pysense import Pysense
import pycom
import time

py = Pysense()

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

#Blink the LED
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()

boot.py code:

from network import WLAN

wlan = WLAN()
wlan.deinit()

I tried other SiPy firmware versions (1.13.0.b1, 1.15.0.b1, 1.17.3.b1, 1.19.0.b4) but results are the same. @daniel said a few months ago this Pysense issue was resolved, but can you confirm if there is still something wrong with Pysense? Or, am I missing some line of code to make deep sleep mode works as it should? Thanks in advance.

[akshayjames]

@incognico Hi
The high current during deepsleep is due to the LTE module. LTE is started automatically during boot. You need to deinit LTE separately before calling deepsleep as LTE is not stopped automatically during deepsleep.
I had the same issue. My FiPy module was drawing 49mA during deepsleep. After I called LTE deinit, the current draw reduced by a lot at that time itself. After that deepsleep worked as expected. :)

from network import LTE
lte = LTE()
LTE.deinit()

Hope this helps.

[seb]

@james_seth

Sent an email to salessupport@pycom.io if you need some deepsleep shields

[james_seth]

@Fred

I have two Lopy v1.0r boards. Due to the evolving ESP32 code set I benched the boards for a while and used an alternative product to accomplish the task due to time constraints and have now come back to redesign the product using the Lopy. As the product runs off a battery the low power capabilities is a must. I only saw this post now and the survey is closed.

Kind regards,
James

[robert-hh]

@lj I would not expect that. Any new devices use ESP32 Rev 1, and the code as it is assumes PSRAM for a Rev1 device. Obviously, that could be changed, but not easily.

[lj]

@Pycom

Will LoPy1 be redesigned to allow newer production bacthes to have a proper deesleep mode( ~5 and ~15uA) by its own ( at least this is what I undertood) , or will it need the deepsleep shield for ever?
migrating to Lopy4 is not an option because it is not priced the same.
Thanks for your reply.

[Thosch42]

@dbrgn
Nope! A little bit harder ;-)
I stripped down my complete design, module per module, to find out who draws the 6.5mA. The last step was, to pull the cable from the output terminal of my Arc. And, oh wonder, I had still a current of 6.5mA ;-)

I contacted the support from Qoitech, and a replacement arrived next day!!!

Cheers,
Thomas

[dbrgn]

@thosch42 said in Root causes of high deep sleep current [LoPy1, WiPy2 and SiPy], all the new modules **do not have deepsleep issues**:

My Otii Arc was defective.

Oh, how did you find out? With the resistor test?

[Thosch42]

@seb
Hi!
I found the problem. My Otii Arc was defective. So, everything is fine.

Thanks!

Cheers,
Thomas

[seb]

Hi,
Deep sleep using a LoPy an Deepsleep shield should result in a current draw of 530uA, could you please detail your setup for your current measurement and we can try replicate it? What voltage are you setting the Otii? Are you applying the voltage to Vin or 3.3V? Have you tried with the UART disconnected?

[Thosch42]

Hi all!
Since a few days I'm working on a deepsleep issue. I have a Lopy with Deepsleep-Shield, powered from my Otii Arc. Just connected the UART RX, to see what's going on. No Expansionboard. Latest Firmware, and a pretty simple script:

from deepsleep import DeepSleep
import deepsleep
from network import Bluetooth, WLAN

bluetooth = Bluetooth()
bluetooth.deinit()
wlan = WLAN(mode=WLAN.STA)
wlan.deinit()

ds = DeepSleep()

# get the wake reason and the value of the pins during wake up
wake_s = ds.get_wake_status()
print(wake_s)

if wake_s['wake'] == deepsleep.PIN_WAKE:
    print("Pin wake up")
elif wake_s['wake'] == deepsleep.TIMER_WAKE:
    print("Timer wake up")
else:  # deepsleep.POWER_ON_WAKE:
    print("Power ON reset")

ds.enable_pullups('P17')  # can also do ds.enable_pullups(['P17', 'P18'])
ds.enable_wake_on_fall('P17') # can also do ds.enable_wake_on_fall(['P17', 'P18'])

print("Go to sleep")
ds.go_to_sleep(20)

And my deepsleep power consumtion is 6.5mA.

Am I doing something wrong?

Cheers,
Thomas

[derchris]

@daniel sounds good!
Any news regarding the BLE sleep modes? AFAIK it‘s not possible to sleep and wait for BLE interrupts (because of the ESP32)

[daniel]

Hello everyone,

We have been doing lots of deepsleep tests again on FiPy and GPy. Deepsleep works well and we measure values between 35uA and 45 uA which will be improved to ~20uA after firmware updates to the LTE radio. User experiencing high deepsleep currents are due to timing issues in the firmware when sending the LTE radio to airplane mode. We will be working on fixing that ASAP during the next few days.

Cheers,
Daniel

[derchris]

@incognico
Well, I think it‘s time to find a pro-grade moldule :(

[incognico]

Same module powered via digital bench supply @5.0V shows the same current draw as the previous test (less the 16mA of the bare expansion board). Power is to VIN & GND pins. No other pins connected.

Same direct supply @ 3.6V shows slightly increased draw, ~39mA in sleep.

This test was with empty main.py; boot.py as follows:

import machine
import time

print('-START-')
time.sleep(10)
print('-SLEEP-')
machine.deepsleep(20000)
print('-AWAKE-')

I have not found any sleep current changes from [de]initializing WLAN or LoRa so have not done any of that in an attempt to keep the test as simple as possible.