1. Home
  2. Getting Started
  3. FiPy
  4. FiPy deepsleep methods

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

FiPy deepsleep methods

  • T

    Re: Deepsleep bug fipy

    It appears that there are a number posts in the forum about issues with trying to obtain the lowest possible deepsleep current.

    I have been steadily chipping away at issues with my systems that have been built around FiPy.

    With the assistance of a number of people on the forum, I am now comfortable that I have a platform that is stable using NB-IoT and deepsleep as well as using LFS instead of FAT for longevity of the flash storage system.

    I have now com back to the issue of trying to reduce the current draw in deepsleep.

    For some reason, I do not seem to be able to get the current that my system draws below 15mA when in deepsleep.

    It appears that I have at least some issue where the LTE modem does not always remain turned off after the system wakes from sleep.

    This is probably a prompt for @peterp & @Gijs to shed some wisdom on the correct sequence of events required to ensure the lowest possible deepsleep current.

    What steps should I take in my code to ensure that all unwanted devices are turned off and remain off until such time as they are required after a wake from deepsleep?

    I have observed that after using the lte modem and then closing it off with a deinit(reset=True) the deeplsleep current appears to be its lowest at 15mA. After wake up (even without using/initilising the lte modem) and then going back to sleep again, the deepsleep current then sits at 50mA. This indicates to me that the lte modem has powered back on again even though I am not using it.

    How do I ensure that all unwanted/unused peripherals are placed in their lowest current (off) state and what is the lowest current that we should expect from the FiPy whwen in deepsleep??????

    Peter.

    0
  • B

    Hey @frederik-Leys, the LoPy does not have an LTE Modem so lte = LTE() should be have no effect on LoPy but und FiPy it should start the modem.

    Change your code to:

    import pycom
import machine
import time
from network import LTE
from network import WLAN
wlan = WLAN()
lte = LTE()
time.sleep(5)
lte.init()
wlan.deinit()

pycom.heartbeat(False)

print(pycom.heartbeat_on_boot())
print(pycom.lte_modem_en_on_boot())
print(pycom.pybytes_on_boot())
print(pycom.smart_config_on_boot())
print(pycom.wdt_on_boot())
print(pycom.wifi_on_boot())

#colors in hexadecimal (0xRRGGBB)
pycom.rgbled(0x00FF00) # Red
time.sleep(1)
lte.deinit()
machine.deepsleep(40*1000)

    To get in uA range. Or let it run in powersave mode like:

    import pycom
import machine
import time
from network import LTE
from network import WLAN
wlan = WLAN()
lte = LTE(psm_period_value=1, psm_period_unit=LTE.PSM_PERIOD_1H,
          psm_active_value=5, psm_active_unit=LTE.PSM_ACTIVE_2S )
print(lte.psm())
time.sleep(5)
lte.init()
wlan.deinit()

pycom.heartbeat(False)

print(pycom.heartbeat_on_boot())
print(pycom.lte_modem_en_on_boot())
print(pycom.pybytes_on_boot())
print(pycom.smart_config_on_boot())
print(pycom.wdt_on_boot())
print(pycom.wifi_on_boot())

#colors in hexadecimal (0xRRGGBB)
pycom.rgbled(0x00FF00) # Red
time.sleep(1)
lte.deinit(detach=False, reset=False)
machine.deepsleep(40*1000)

    which brought me to 300uA.

    0
  • G

    I'll answer the questions I can answer now, for the other ones I'll have to get back to you

    Can you also clarify whether the time.sleep statements are required?

    This is for me to determine when something is happening in the code during my power measurement and should allow to CTRL+C out of the deepsleep loop. I dont think it provides any other 'functionality'

    Also, even though you instantiate LTE, you don't do much with it before going back to sleep. Did you try a full init-attach-connect-send-sleep cycle?

    I did not, mainly because I couldn't come by any simcard at the time of measuring. Though I believe it should make no difference in the end result per the workings of lte.deinit(reset=True)

    I'm pretty sure many will want to know if this works for both NB-IOT and Cat-M1.

    Yes, I understand. At the moment I cannot be conclusive about this, as there are some dissimilarities between the firmwares. We're working on gathering operational current measurements to publish in the docs that should be reproducable, but its taking some more time than expected.

    I think it would be great for someone at Pycom to take each and everyone of the tutorials and examples (IIRC there are examples here and there in the reference part of the documentation) and check that they indeed work as they should with the current versions (and ideally list for each "tested with version XXX", including both module and modem firmware versions where appropriate, and all relevant details to be able to reproduce the test). For all examples involving deep sleep, stating the resulting deep sleep current would be great.

    I totally agree. All examples should work with the latest (stable) firmware. At the moment we're thinking about syncing the examples in the docs to a github repository (just like how it used to be in the pycom-libraries repo), so that when the repo is updated, the examples automatically update in the docs. Though we were not able to find a system yet.

    66 OSError: the requested operation failed

    This is something I'll have to look into again, but things keep coming up :(

    0
  • K

    @jcaron Not to mention what to do when the deinit attempt causes an line "66 OSError: the requested operation failed"!

    0
  • J

    @Gijs You should probably also update the first example at https://docs.pycom.io/tutorials/networks/lte/power/ then.

    Can you also clarify whether the time.sleep statements are required?

    Also, even though you instantiate LTE, you don't do much with it before going back to sleep. Did you try a full init-attach-connect-send-sleep cycle?

    I'm pretty sure many will want to know if this works for both NB-IOT and Cat-M1.

    I think it would be great for someone at Pycom to take each and everyone of the tutorials and examples (IIRC there are examples here and there in the reference part of the documentation) and check that they indeed work as they should with the current versions (and ideally list for each "tested with version XXX", including both module and modem firmware versions where appropriate, and all relevant details to be able to reproduce the test). For all examples involving deep sleep, stating the resulting deep sleep current would be great.

    The next step would then be prior to any new release to check that all those still work. Many tutorials and examples have gone awry over time.

    That would probably one the biggest steps Pycom could take towards better QA. Quite some work and probably a full time job (or maybe several), but it would save soooo much time for all the people trying to reproduce examples that just don't work...

    1 K 1 Reply
  • livius

    @Gijs said in FiPy deepsleep methods:

    lte.deinit(reset=True)

    It is in doc but i suppose it should be more strictly commented to highlight the problem.
    https://docs.pycom.io/firmwareapi/pycom/network/lte/#ltedeinitdetachtrue-resetfalse

    3
  • G

    Sorry, it took me some time to look at this again, but updating my previous example to include LTE, this seems to be the proper way on NB-41019:

    import machine
import time
import pycom
from network import LTE
lte = LTE()
print("log {}".format(time.ticks_ms()))
print(pycom.heartbeat())
lte.deinit(reset=True)
time.sleep(1)
time.sleep(1)
time.sleep(1)
machine.deepsleep(10000)

    To clarify, by default lte.deinit() closes the UART connection to the modem, and the modem should put itself into sleep mode as its no longer needed. Except, the behaviour is somewhat unreliable, so forcing the flag reset=True, we can force the modem to go back to its initial powerup behaviour, which is to go to sleep when its no longer needed. For example calling the following:

    lte.deinit()
lte.reset()

    Does not quite work, as we close the UART before resetting. Moreover, switching the statements will wake the modem after the reset, which is also not desired.
    In my testing, I was able to get the device down to 35uA, with the LTE modem included

    5 livius J 2 Replies
  • K

    @jcaron Agree with your earlier comment that lte.init()/deinit() are vague & vary with the version. Also we've found that deepsleep current also depends on if the modem was reset at some point. We've found

    lte.deinit(); lte.init(); lte.deinit()

    is necessary to get uA deepsleep after an lte modem reset.

    1
  • G

    Ah sorry then I misunderstood the problem at hand. I thought it was impossible for them to get down to 35uA at all. I'll have a look at this again then.

    0
  • J

    @Gijs I think the big difference is that you never instantiate LTE, whereas they do (which is kind of useful on an LTE-capable board ;-> ), but then never manage to stop it from drawing milliamps.

    I would suppose the goal is to reproduce (at least) one of the scenarios listed here, i.e. either:

    • manage to switch off the modem (in theory with lte.deinit()) so that it completely stops drawing power
    • get the modem in power saving mode (in theory with lte.deinit(detach=False, reset=False) after setting the PSM parameters) so that it draws as little as possible.
    1 K 1 Reply
  • G

    Returning to this with the LTE firmware version you're using, LR6 41019 (NB-IoT) and the same boot flags, I again get results close to ~35uA with the same Fipy. Not sure what the difference is between our setups, except that Im using an expansionboard, but that should not make a (positive) difference here. Are you confident in your current measurement setup?
    Let me know!

    0 J 1 Reply
  • G

    I finally got around to testing this with our otii-arc, using the Fipy on 1.20.2.r4, with LTE modem firmware LR5.2.1.0-48829 (Cat-M1) and all boot flags set to False, in an expansionboard v3.1 (no jumpers), I was able to get down to ~30uA.
    I will let you know of the results for LR6 41019 (NB-IoT)

    You can find the example scripts I used below

    #setting boot flags

import pycom
print('Current boot flags')
print('Heartbeat on boot: \t', pycom.heartbeat_on_boot())
print('WiFi on boot: \t\t', pycom.wifi_on_boot())
print('LTE modem on boot: \t', pycom.lte_modem_en_on_boot())
print('Pybytes on boot: \t', pycom.pybytes_on_boot())
print('Smart config on boot: \t', pycom.smart_config_on_boot())
print('Watchdog on boot: \t', pycom.wdt_on_boot())
print('setting ALL boot flags to False')
pycom.heartbeat_on_boot(False)
pycom.wifi_on_boot(False)
pycom.lte_modem_en_on_boot(False)
pycom.pybytes_on_boot(False)
pycom.smart_config_on_boot(False)
pycom.wdt_on_boot(False)
print('Heartbeat on boot: \t', pycom.heartbeat_on_boot())
print('WiFi on boot: \t\t', pycom.wifi_on_boot())
print('LTE modem on boot: \t', pycom.lte_modem_en_on_boot())
print('Pybytes on boot: \t', pycom.pybytes_on_boot())
print('Smart config on boot: \t', pycom.smart_config_on_boot())
print('Watchdog on boot: \t', pycom.wdt_on_boot())

    Deepsleep:

    import machine
import time
import pycom
print("log {}".format(time.ticks_ms()))
print(pycom.heartbeat())
time.sleep(1)
time.sleep(1)
time.sleep(1)
machine.deepsleep(10000)
    0
  • J

    @frederik-Leys @tuftec

    Related: https://forum.pycom.io/topic/5547/power-saving-mode-psm-in-nb-iot-problems-with-reconnecting-after-deepsleep/4

    The actual effect of the various lte methods (init, deinit, attach, detach, connect, disconnect) is quite fuzzy and I believe has changed over time, and of course depends on the exact sequence and the parameters in use.

    The best option for deep sleep seems to be to keep the modem attached but in power-saving mode using lte.deinit(detach=False, reset=False) after having set the PSM settings with AT+CPSMS (or via the optional parameters of lte.init).

    I don't have a FiPy or GPy so I never tried this.

    1
  • F

    @Gijs

    So both @tuftec and me measure exactly 15mA in 'deepsleep' when using Fipy, I find it hard to believe that this is coincidence. I use the latest firmware (1.20.2.r4.) and modem version (LR6.0.0.0-41019). I don't even use any peripherals nor are there any sensors or anything else attached to the pins. I power the Fipy with a lipo on the Vin pin and the NB-IoT antenna is attached). Can we conclude then that in reality the Fipy, can't go lower in current consumption in deepsleep?

    By the way, the same code on a LoPy4 results in a current consumption of 20uA as expected and desired. (So the measurement system is reliable)

    this is my code:

    import pycom
    import machine
    import time
    from network import LTE
    from network import WLAN
    wlan = WLAN()
    lte = LTE()
    time.sleep(5)
    lte.init() => (this line of code doesn't have an effect!)
    wlan.deinit()
    pycom.heartbeat(False)
    pycom.rgbled(0x00FF00) # Red
    time.sleep(1)
    machine.deepsleep(40*1000)

    0 J 1 Reply
  • F

    @frederik-Leys

    So, latest firmware version (1.20.2.r4.), latest Nb-IoT modem software version (LR6.0.0.0-41019), only battery (4.1 V) and antenna attached and bare minimum code:

    import pycom
    import machine
    import time
    from network import LTE
    lte = LTE()

    lte.deinit()
    print("ik ga slapen")
    machine.deepsleep(40*1000)

    and still 15mA power current consumption during deep sleep on a FiPy. Using LTE-deinit() or not also doesn't make a difference. I thought it should

    0 F 1 Reply
  • F

    @Gijs I don't use any peripherals, the only connection to the FiPy is the battery (Vin & GND), and the NBIoT antenna, and indeed I am using firmware version 1.20.2.r4.

    Could it be that i use the NB-IoT modem software and not the LTE-M software? I don't see any other possible issues

    kind regards,

    Fré

    0 F 1 Reply
  • G

    It should be possible to reach close to 20uA in deepsleep, though Im not sure what is drawing the current at this moment. Im guessing you're not using any peripherals or the like, and also running the latest pycom firmware (1.20.2.r4)

    0 F 1 Reply
  • F

    @Gijs I updated the firmware and the modem firmware to get this result:

    FiPy with firmware version 1.20.2.r4
    Your modem is in application mode. Here is the current version:
    UE6.0.0.0
    LR6.0.0.0-41019

    Now, the current consumption dropped from 16mA too 15.6mA. The main question I have is: will it be possible with my FiPy to go to a deepsleep power consumption around +/- 20uA or is 15mA the lowest I will get?

    kind regards

    0
  • G

    Both the Fipy and GPy support NB-IoT, so that should not be the issue. From the variables still remaining, It does help to update the LTE modem and pycom firmware to the latest version, and there's some additional things mentioned in the original topic you can find in the first post.

    0 F 1 Reply
  • F

    @Gijs I power my board though Vin and i am not using an expansionboard. (i only use an expansionboard for programming)
    Will it be possible to get to +/- 20uA with the Fipy or will i need to buy a Gipy to be able to use NB-IoT and let the device go to a +/- 20uA deepsleep?

    0
Log in to reply
 

Pycom on Twitter