FiPy deepsleep methods

[tuftec]

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.

[livius]

do you use some of this?

wifi_on_boot
lte_modem_on_boot

when you set it with false then you can bring it up when you really need it.

[tuftec]

@livius yes, wifi & lte components are turned off on boot and only enabled when needed. but I am still stick at 11mA. I am thinking that there are other bits of my circuit that are consuming current (level shifting components, i/o, etc). I did find that my rs232 monitoring port is responsible for a little. After disconnecting the monitoring, I can get down to 7.5mA. Still a long way to go to get down to 10's of uA as I would expect in deepsleep.

[frederik Leys]

@tuftec I have the same issue. I can't get the 'deepsleep' current under 16mA. Even if i exclude everything in my code and just keep this, it doesn't go under 16mA. The same code on a LoPy does bring the current consumption down to 20uA, so it has something todo with the hardware I guess? Anybody here that knows the answer to this issue?

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)
machine.deepsleep(40*1000)

[Gijs]

If you're using an expansionboard 3.1, it helps to remove the jumpers and connect the power through the battery terminal. That can save some additional current

[frederik Leys]

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

[Gijs]

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.

[frederik Leys]

@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

[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