text: Root causes of high deep sleep current [LoPy1, WiPy2 and SiPy], all the new modules **do not have deepsleep issues**
  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() ') >>> 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
  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
  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
  - jmarcelino last edited by
  @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.
  # 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)
  @derchris are you sure the device is in deep sleep? can you post the full code you're using in boot.py?
  @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.
  @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
  @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).
  @incognico @daniel
  +1
  I see 40 mA in deepsleep with current firmware
  @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')
  @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.
  @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?
  @robert-hh Thank you for the reply. Email send :-)
  @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
  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?
  - jmarcelino last edited by 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
  Has the Lopy sleep power been resolved and how can the modules be identified from the ones which have the issue?
  Thank you,
  - Electrozest last edited by
  @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?