Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

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

    Scheduled Pinned Locked Moved Announcements & News
    deepsleep
    127 Posts 48 Posters 110.1k Views 57 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D Offline
      derchris @daniel
      last edited by

      @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

      1 Reply Last reply Reply Quote 0
      • D Offline
        daniel
        last edited by

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

        D 1 Reply Last reply Reply Quote 0
        • D Offline
          derchris @daniel
          last edited by

          @daniel it shows 36mA @ 4V

          D 1 Reply Last reply Reply Quote 0
          • D Offline
            dbrgn @derchris
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • D Offline
              derchris
              last edited by

              @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)
                  
              
              J 1 Reply Last reply Reply Quote 0
              • J Offline
                jmarcelino @derchris
                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.

                1 Reply Last reply Reply Quote 0
                • D Offline
                  daniel
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • D Offline
                    derchris
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • I Offline
                      incognico
                      last edited by

                      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

                      A 1 Reply Last reply Reply Quote 0
                      • I Offline
                        incognico
                        last edited by

                        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.

                        D 1 Reply Last reply Reply Quote 0
                        • D Offline
                          derchris @incognico
                          last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • D Offline
                            daniel
                            last edited by 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

                            D 1 Reply Last reply Reply Quote 1
                            • D Offline
                              derchris @daniel
                              last edited by

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

                              1 Reply Last reply Reply Quote 0
                              • T Offline
                                Thosch42
                                last edited by

                                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

                                1 Reply Last reply Reply Quote 0
                                • sebS Offline
                                  seb
                                  last edited by

                                  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?

                                  T 1 Reply Last reply Reply Quote 0
                                  • T Offline
                                    Thosch42 @seb
                                    last edited by

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

                                    Thanks!

                                    Cheers,
                                    Thomas

                                    D 1 Reply Last reply Reply Quote 0
                                    • D Offline
                                      dbrgn @Thosch42
                                      last edited by

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

                                      T 1 Reply Last reply Reply Quote 0
                                      • T Offline
                                        Thosch42 @dbrgn
                                        last edited by

                                        @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

                                        1 Reply Last reply Reply Quote 1
                                        • L Offline
                                          lj Pybytes Beta
                                          last edited by

                                          @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-hhR 1 Reply Last reply Reply Quote 0
                                          • robert-hhR Offline
                                            robert-hh @lj
                                            last edited by

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

                                            1 Reply Last reply Reply Quote 1

                                            Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                                            Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                                            With your input, this post could be even better 💗

                                            Register Login
                                            • 1
                                            • 2
                                            • 3
                                            • 4
                                            • 5
                                            • 6
                                            • 7
                                            • 5 / 7
                                            • First post
                                              Last post

                                            Pycom on Twitter

                                            Pycom