Root causes of high deep sleep current [LoPy1, WiPy2 and SiPy], all the new modules **do not have deepsleep issues**
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.
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.
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.
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.
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.
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!
@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.
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.
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!!!
My Otii Arc was defective.
Oh, how did you find out? With the resistor test?
I found the problem. My Otii Arc was defective. So, everything is fine.
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?
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?
@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)
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.
Well, I think it‘s time to find a pro-grade moldule :(
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.
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.
All tests in this post are on an expansion board v2.1A, only TX/RX jumpers in place, with a USB inline power monitor. FyPi module is freshly formatted (mkfs'd) with 1.15.0.b1 firmware.
No module installed: 16mA (power LED etc)
Insert FyPi module. Result: 264mA; settles down to 137mA after several seconds
>>> import os >>> os.uname() (sysname='FiPy', nodename='FiPy', release='1.15.0.b1', version='v1.8.6-849-baa8c33 on 2018-01-29', machine='FiPy with ESP32', lorawan='1.0.0', sigfox='1.0.1') >>> import machine >>> machine.deepsleep(10000)
Result from above: 46.9mA during deep sleep
>>> import network >>> from network import WLAN >>> wlan=WLAN() >>> wlan.deinit()
Result from above: Drops from 137mA to 75mA
>>> import machine >>> machine.deepsleep()
Result from above: 46.9mA
I‘ll try it tomorrow when I‘m back in office.
But I already tried with 8 secs and that did change nothing.
Well, is there any option to completely disable the modem? For the current project I don‘t need it
The ~5 seconds are required because we do some initialisation on the LTE modem than can be improved to speed up the process. This is something that we will work on for the next release.
I think what’s happening is we need a few seconds (5 - 10) to turn on the modem and ask it to go into “airplane mode”. However if you go into deepsleep before this process is concluded the LTE modem will not do it.
We’ll probably have to make deepsleep call blocking on this process being complete, but for now could you try increasing the time before going to deepsleep to 10 seconds? Adding time.sleep(10) should do it.
# boot.py import os import machine import pycom
(yes, that'is it :) )
from network import WLAN from network import LoRa import socket import binascii import struct import time import pycom pycom.heartbeat(False) wlan = WLAN() wlan.deinit() lora = LoRa(mode=LoRa.LORA, frequency=867100000, rx_iq=True, public=True, tx_power=14, bandwidth=LoRa.BW_125KHZ, sf=7, coding_rate=LoRa.CODING_4_5) s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) while True: try: s.settimeout(2) pycom.rgbled(0x222222) rx = s.recv(64) pycom.rgbled(0x000000) except TimeoutError: rx = None if rx: print(rx) machine.deepsleep(8000)
@daniel it shows 36mA @ 4V
@derchris OK we will check this. In the meantime, can you use a voltage a little bit higher than 3V3? That's a bit on the limit of what the DC-DC regulator inside the FiPy should see on the input. Ideally it should be between 3.5 and 5.5V.