Root causes of high deep sleep current


  • administrators

    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 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



  • Thank you for the fix.

    So, does one use the lopy deepsleep, the pysense go-to-sleep, or both (somehow)?

    Is there an example of using the nvram save and load?



  • @daniel said in Root causes of high deep sleep current:

    Coming soon (also for Pytrack)

    Great to hear. Do you already have information on which pins we'll be able to use for wakeup? I'm currently designing some hardware, and with that information I'd be able to order prototypes sooner.


  • administrators

    While you have your hands in there, any chance for wake on pin on the Pysense?

    Coming soon (also for Pytrack)



  • @daniel Woohoo! Too bad I don't have my LoPys at hand to test right now, but I will do so as soon as I can.

    While you have your hands in there, any chance for wake on pin on the Pysense?

    Thanks!



  • @daniel said in Root causes of high deep sleep current:

    @jcaron and everyone. We have fixed the deepsleep current issue of the Pysense. As explained before, it was just a software thing (the pressure sensor needed to be powered down). Just use the new library: https://github.com/pycom/pycom-libraries/blob/master/pysense/lib/pysense.py

    Great, thanks! :) Will test it tonight or tomorrow.


  • administrators

    @jcaron and everyone. We have fixed the deepsleep current issue of the Pysense. As explained before, it was just a software thing (the pressure sensor needed to be powered down). Just use the new library: https://github.com/pycom/pycom-libraries/blob/master/pysense/lib/pysense.py

    And you'll enjoy a current of only 10uA during deepsleep :-)



  • Just arrived today! Thanks



  • @bucknall
    For the record: my deepsleep shields came in yesterday



  • @bucknall I've sent an email to you with our order numbers.


  • administrators

    Hi @tlntu,

    I'm asking our sales team where the deep sleep shields are - could you please send me an email (alex@pycom.io) with your order number?

    Thanks!

    Alex



  • @bucknall My colleague and I have made total of 3 orders ( 7 LoPy development boards in total), but the deep sleep shield didn't come with our orders. May I know where can I order the deep sleep shield? I've contacted the support team, but haven't got any reply from them.



  • @daniel said in Root causes of high deep sleep current:

    @jcaron the reason for the higher current on the Pysense is because the sensors need to be disabled as part of the process of going to deepsleep. We will add that to the official library within the next few days.

    Hi @daniel,

    • is this actually confirmed to be a purely software issue?
    • has there been any progress with the libraries? I've seen a few updates pushed on Monday, but I don't think they're relevant to this issue?

    The other thing I really would like to see is the ability to wake on pins (and the related control of the pins connected to the PIC on the Pysense, which from what I understand will be the only pins which can used for wake up?)

    Thanks,

    Jacques.


  • administrators

    @jcaron That is correct, my wording was slightly confusing! If you order any of our devices (WiPy 2.0, LoPy or SiPy) you will automatically be sent a deep sleep shield.



  • @bucknall From what I understood, you will automatically receive a Deep Sleep Shield with any new orders. I know I received shields with the boards I ordered week before last.


  • administrators

    @chrisi you will need to order a shield - the SiPy can also use the Pytrack/Pysense to sleep as well.



  • If I order another Sipy now will the deep sleep feature be fixed or will I still need a shield?



  • Thanks jmarcelino.

    Does the below earlier comment of yours still apply?

    By the way I found that if I do:

    from network import WLAN
    wlan = WLAN(mode=WLAN.STA)
    power saving is enabled, but if I use this instead it doesn't:

    from network import WLAN
    wlan = WLAN()
    wlan.mode(WLAN.STA)



  • @jalperin
    This works to turn off WiFi

    import network
    n = network.WLAN()
    n.deinit()
    

    Turning off Bluetooth would be similar but for network.Bluetooth() instead.
    However removing Bluetooth doesn't change anything in power consumption at the moment - but also it won't be on or consuming anything unless you had previously initialised Bluetooth() in your code. So it's actually better to do nothing at all for the Bluetooth side.



  • Thank you, @jcaron. Very helpful.

    I have been executing that code, but followed by machine.deepsleep(). I gather that is not necessary. Correct?

    So, lastly, exactly how does one turn off wifi and bluetooth (I've read different methods in this forum)?


Log in to reply
 

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.