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

[livius]

@Fred
Sad that fix is not possible by firmware upgrade.
but good that you find the exact problems and future shopping will be with fixed module.

I'm not a mediator, but I understand that it was difficult to avoid this if it was not possible to test a previously running deepsleep mode because it was not implemented in the ESP-IDF.

[robert-hh]

@Fred In another post on this blog I came along the voltage divider, which provides the battery voltage to P16 on the expansion board. At value sof 56k and 115k, this divider alone consumes about 20µA. Since most of the people aiming for deep sleep want to run the deive from battery, this is large compared to you aim at getting into the range of < 10 µA.

[daniel]

@robert-hh that's true. The redesigned expansion board (v3) will also include circuitry to shutoff that divider circuitry during deep sleep mode.

[RobTuDelft]

Glad the problem has been identified and that the Pycom team is dedicated to solving the issue.

A 20 mA deepsleep current was just under the limit to power our sensor stations for around a week on battery, but still very high of course. We are now looking for a solar panel solution in the mean while.

[PiAir]

Quick question: for Kickstarter backers, with "order number" you mean "backer number" ?

[Fred]

@PiAir Absolutely! Well noted. Thanks Fred

[exquisitus]

how would that work for customers who bought from a distriutor, in my case elmwood in toronto, canada? please advise. thanx.

[Fred]

@exquisitus Hi,

We want to keep it simple so just register your details on the Link I quoted and we will send out the deep sleep shield. If you can simply include the invoice/order number relating to your purchase from Elmwood then we can take care of the rest. Thanks Fred

[jasonriedy]

For those of us who were hoping to just plug in a LiPo, what is needed to power via the 3V3 pin?

And the total deep sleep draw of the current expansion boards is a tad over 2.5 mA when powered via that pin?

(As a software person looking for a quick & easy gizmo for relaying sensor data, I really was hoping just to plug a big-ish LiPo into the expansion board.)

[ssmith]

@Fred
I'm in the process of designing an adapter board to use a LoPy module in a sensor application. Can you make the details of the shield board available to possibly be implemented in my adapter board?

[constantinos]

@Fred Very Nice! Can you provide us also a schematic of the solution in order to fix our custom boards?

Thanks in advance
Constantinos

[daniel]

@jasonriedy what you need to do is to plugin the LiPo and attach the deep sleep shield that we just announced. The LiPo battery on the expansion board powers the module via the VIN (3.6-5.5V) pin, not via the 3V3 pin. Deep sleep with the shield will work on a transparent way when you issue the machine.deep_sleep() instruction.

[daniel]

@ssmith @constantinos we will make the schematics available later today.

[Fred]

@constantinos Hi, I can confirm that we will be releasing the schematic later today. Thanks Fred

[daniel]

Hello,

The schematics for the deep sleep shield are now available here: https://docs.pycom.io/pycom_esp32/_downloads/Deep-Sleep-Shield_Schematic.pdf

Cheers,
Daniel

[robert-hh]

@daniel Thank you very much. Will you also publish the code for the PIC controller?

[daniel]

@robert-hh yes, it will be open source too.

[frankb]

What are the dimensions of the 'deep sleep shield'? Will it still fit in a standard housing together with the v1.0 expansion board?

[daniel]

@frankb it's going to be around 12mm tall. It's not going to fit inside the Pycase, but it most likely will fit inside the IP67 case. We will confirm this shortly.