Deep sleep / standby power consumption

[pierrepoulpe]

Hello,

I'm currently developping a custom board for my device, based on ESP8266 and sigfox modem from Wisol WSSFM10R4.
I target to supply it with simple 3xAA batteries, and last years. 5 years would be great. Knowing that for this application, one measure per day is fine.
I quickly saw that standby consumption would be the biggest share if we don't take care about it.
This is why I didn't use ESP8266 internal deep sleep (plus internal RTC is very unprecise), nor I used any board on the market.

When I saw SiPy.... the price... and the standby current, I thought "stop! forget your custom card, use a brick from the shelf".

Well, problem is I'm a bit confused, on sipy spec sheet I saw 0.5uA (meaning 500nA right?)
https://www.pycom.io/wp-content/uploads/2017/06/sipySpecsheetJune.pdf
Not as good as my design (150nA), but fine enough.
But when I don't find more details, about the design of the power layer. And what are the wakeup possibilities.
I saw this but I don't really understand it.
And the I saw this and it's not exactly the same figure!!
15µA and 0.5µA is not exactly the same.

Well, could you give more details of how the deep sleep is managed, what takes care of waking up the board, what is supplied in deep sleep etc...

Thanks!
Hope I can forget all my custom board to use an existing brick.

[dmayorquin]

Hi @bucknall, I need some help with the Pysense deep sleep mode. I have a SiPy + Pysense + 3.7 V LiPo battery. I'm testing Deep sleep mode from last version of Pysense library but the multimeter is showing high deep sleep current consumption.

SiPy firmware: 1.18.0
Pysense firmware: 0.0.8

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:

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? If pysense_0.0.4 dfu firmware resolves the deep sleep issue It's supposed to be ok with 0.0.8 too.

[Pwntus]

@bucknall thanks for the quick reply! Yes, this clears things up, I wasn't aware of the new firmware release. We'll make some tests shortly and hope for the best :)

[bucknall]

Hi @Pwntus - apologies for the confusion! My response wasn't intended to contradict itself; there are two conversations here.

1. The Development SiPy module has an issue where it cannot perform deepsleep. This is a hardware issue and can be fixed using a Deep Sleep Shield or a Pytrack/Pysense.

2. The issue being discussed here is that the Pysense is not putting the SiPy (with the deepsleep issue) into a deepsleep state. This has now been resolved in the pysense_0.0.4.dfu firmware (https://docs.pycom.io/chapter/pytrackpysense/installation/firmware.html), I believe. This was a software issue that should now have been resolved.

Does that clear up the confusion?

Thanks!

Alex

[Pwntus]

Hi @bucknall,
as you mentioned earlier in https://forum.pycom.io/post/9178 the response you give here seems to contradict each other. I was just wondering what the progress on the Pysense investigation is and if it's just a software/library fix we should expect.

[bucknall]

@pierrepoulpe The external voltage regulator was the component that was causing the issues, which is why the problem is apparent in the Dev Modules but not the OEM

[pierrepoulpe]

Thanks Alex,

So what's the scope of these 0,5µA? OEM module excluding voltage regulator?

[bucknall]

Hi @pierrepoulpe,

We discovered a hardware issue with the SiPy earlier this year that was preventing it from reaching the desired power consumption. Please have a read here for more information about this issue (https://forum.pycom.io/topic/1022/root-causes-of-high-deep-sleep-current/52).

Note - this issue only affects the Development Modules, the OEM solutions are NOT affected and can still perform at the required deep sleep currents!

We're releasing a solution, aka. the Deep Sleep Shield later this month that proposes a fix for that issue. Please stay tuned for more updates about when that is releasing and how to get hold of one!

If you're looking for an immediate solution, the Pytrack and Pysense devices both support the hardware fix that is coming with the Deep Sleep Shield and can immediately be used for long term IoT deployments.

Thanks!

Alex