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

[Electrozest]

@fred, I wondered if the deep sleep issues have been resolved in the new LoPy4 modules? Will the deep-sleep shield still be needed for LoPy4 to achieve low current deep-sleep? Thank you. Best Regards, Martin

[livius]

@electrozest
No, deepsleep shield is not needed for Lopy4. It work "natively" in deepsleep mode.

[Electrozest]

@livius , thank you. Are the quoted <5uA standby currents for LoPy4 with Wifi/LoRa/SigFox disabled using the 3.3V-5.5V power external input pin via the LoPy4 internal 3.3V voltage regulator? To achieve lowest standby deep sleep power consumption, will I be able to use the built in voltage regulator or will a lower loss external 3.3V regulator be required instead?

[robd]

Has the Lopy sleep power been resolved and how can the modules be identified from the ones which have the issue?

Thank you,

[jmarcelino]

@robd
This has been resolved in all new the new development boards WiPy 3, FiPy, GPy and LoPy 4 as well as all the OEM modules including the L01.

For the existing LoPy (not the LoPy 4) the solution is still the deepsleep shield (complementary) or using the Pytrack/Pysense

[rvandam]

I have two V1.0 Lopy's. I tried to reach the link from Surveymonkey from above, but the survey is currently closed. Is there a way to order these deepsleep shields?

[robert-hh]

@rvandam Down the road on this post you'll find the answer:

Please send email to sales@pycom.io with order number details / address for delivery of the shields. Also, confirm how many you need. Thanks Fred

[rvandam]

@robert-hh Thank you for the reply. Email send :-)

[kdehmelt]

@jmarcelino Hey, I was not successful with a SiPy to reach low deep sleep currents, so I ordered a FiPy and expansion board. But I'm still not getting the wanted currents in uA (with machine.deepsleep still in the range of mA).
Do I need the DeepSleep shield, even with a FiPy?

[daniel]

@kdehmelt that's because the LTE radio needs to be placed into "fly-mode". We have tested that and uA current ranges can be achieved without issues, so no need to worry. The FiPy doesn't need the deepsleep shield.

We will enable fly-mode within a few days in our next release.

[incognico]

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

We will enable fly-mode within a few days in our next release.

Anything further on this? New firmware, same old 150mA result when activating deepsleep().

(sysname='FiPy', nodename='FiPy', release='1.13.0.b1', version='v1.8.6-849-656704e on 2018-01-10', machine='FiPy with ESP32', lorawan='1.0.0', sigfox='1.0.1')

[derchris]

@incognico @daniel
+1
I see 40 mA in deepsleep with current firmware

[daniel]

@derchris can you remove the RTS and CTS jumpers from the expansion board? Power cycle the whole thing and try again? If that doesn't help, there's a glitch in the firmware. From a hardware point of view deepsleep works well as we have tested that in length with all the new devices (FiPy, GPy, WiPy3, LoPy4, etc).

[derchris]

@daniel
I‘m running the fiPy plain, with only 3V3 (to FiPy’s VIN) and GND connected to my otii current monitor.
No other pins of the FiPy are used

[daniel]

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

[derchris]

@daniel it shows 36mA @ 4V

[dbrgn]

@derchris are you sure the device is in deep sleep? can you post the full code you're using in boot.py?

[derchris]

@dbrgn

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

[jmarcelino]

@derchris
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.

[daniel]

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.

Cheers,
Daniel