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

[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

[derchris]

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

[incognico]

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

[incognico]

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.

This test was with empty main.py; boot.py as follows:

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.