FiPy deepsleep methods

[Gijs]

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)

[frederik Leys]

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

[frederik Leys]

@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

[frederik Leys]

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

[jcaron]

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

[Gijs]

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)

[Gijs]

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!

[jcaron]

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

[Gijs]

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.

[kjm]

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

[Gijs]

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

[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

[jcaron]

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

[kjm]

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

[Gijs]

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 :(

[BlackDuck]

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.