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

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

[derchris]

@incognico
Well, I think it‘s time to find a pro-grade moldule :(

[daniel]

Hello everyone,

We have been doing lots of deepsleep tests again on FiPy and GPy. Deepsleep works well and we measure values between 35uA and 45 uA which will be improved to ~20uA after firmware updates to the LTE radio. User experiencing high deepsleep currents are due to timing issues in the firmware when sending the LTE radio to airplane mode. We will be working on fixing that ASAP during the next few days.

Cheers,
Daniel

[derchris]

@daniel sounds good!
Any news regarding the BLE sleep modes? AFAIK it‘s not possible to sleep and wait for BLE interrupts (because of the ESP32)

[Thosch42]

Hi all!
Since a few days I'm working on a deepsleep issue. I have a Lopy with Deepsleep-Shield, powered from my Otii Arc. Just connected the UART RX, to see what's going on. No Expansionboard. Latest Firmware, and a pretty simple script:

from deepsleep import DeepSleep
import deepsleep
from network import Bluetooth, WLAN

bluetooth = Bluetooth()
bluetooth.deinit()
wlan = WLAN(mode=WLAN.STA)
wlan.deinit()

ds = DeepSleep()

# get the wake reason and the value of the pins during wake up
wake_s = ds.get_wake_status()
print(wake_s)

if wake_s['wake'] == deepsleep.PIN_WAKE:
    print("Pin wake up")
elif wake_s['wake'] == deepsleep.TIMER_WAKE:
    print("Timer wake up")
else:  # deepsleep.POWER_ON_WAKE:
    print("Power ON reset")

ds.enable_pullups('P17')  # can also do ds.enable_pullups(['P17', 'P18'])
ds.enable_wake_on_fall('P17') # can also do ds.enable_wake_on_fall(['P17', 'P18'])

print("Go to sleep")
ds.go_to_sleep(20)

And my deepsleep power consumtion is 6.5mA.

Am I doing something wrong?

Cheers,
Thomas

[seb]

Hi,
Deep sleep using a LoPy an Deepsleep shield should result in a current draw of 530uA, could you please detail your setup for your current measurement and we can try replicate it? What voltage are you setting the Otii? Are you applying the voltage to Vin or 3.3V? Have you tried with the UART disconnected?

[Thosch42]

@seb
Hi!
I found the problem. My Otii Arc was defective. So, everything is fine.

Thanks!

Cheers,
Thomas

[dbrgn]

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

My Otii Arc was defective.

Oh, how did you find out? With the resistor test?

[Thosch42]

@dbrgn
Nope! A little bit harder ;-)
I stripped down my complete design, module per module, to find out who draws the 6.5mA. The last step was, to pull the cable from the output terminal of my Arc. And, oh wonder, I had still a current of 6.5mA ;-)

I contacted the support from Qoitech, and a replacement arrived next day!!!

Cheers,
Thomas

[lj]

@Pycom

Will LoPy1 be redesigned to allow newer production bacthes to have a proper deesleep mode( ~5 and ~15uA) by its own ( at least this is what I undertood) , or will it need the deepsleep shield for ever?
migrating to Lopy4 is not an option because it is not priced the same.
Thanks for your reply.

[robert-hh]

@lj I would not expect that. Any new devices use ESP32 Rev 1, and the code as it is assumes PSRAM for a Rev1 device. Obviously, that could be changed, but not easily.

[james_seth]

@Fred

I have two Lopy v1.0r boards. Due to the evolving ESP32 code set I benched the boards for a while and used an alternative product to accomplish the task due to time constraints and have now come back to redesign the product using the Lopy. As the product runs off a battery the low power capabilities is a must. I only saw this post now and the survey is closed.

Kind regards,
James

[seb]

@james_seth

Sent an email to salessupport@pycom.io if you need some deepsleep shields