LTE-Modem des Pycom FiPy komplett stilllegen

[Andreas]

Bei Strom sparen beim Einsatz der MicroPython-Firmware im Batteriebetrieb geht es um die Abschaltung möglichst vieler Peripheriekomponenten des Pycom FiPy.

Gerade mit dem LTE-Modem gab/gibt? es Probleme und widersprüchliche Aussagen im Pycom-Forum. Hier wollen wir dem auf die Spur kommen.

Bei der Bewertung der Dinge kann man denken was man will. Ich will jedoch darauf hinweisen, dass der Start der Reise noch gar nicht so lange her ist:

Development status update

Länger brauchts immer ;].

[Andreas]

Chronologie

2017

Testing deepsleep on FyPi

20. Dezember 2017

daniel
Dec 20, 2017, 3:52 PM

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

1. Februar 2018

daniel
Feb 1, 2018, 10:46 PM

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

16. April 2018

akshayjames
Apr 16, 2018, 9:01 AM

@incognico Hi
The high current during deepsleep is due to the LTE module. LTE is started automatically during boot. You need to deinit LTE separately before calling deepsleep as LTE is not stopped automatically during deepsleep.
I had the same issue. My FiPy module was drawing 49mA during deepsleep. After I called LTE deinit, the current draw reduced by a lot at that time itself. After that deepsleep worked as expected. :)

from network import LTE
lte = LTE()
LTE.deinit()

Hope this helps.

19. April 2018

https://forum.pycom.io/topic/3083/lte-deinit-not-working

20. April 2018

FiPy current consumption analysis

22. April 2018

Power Consumption Issue

30. April 2018

All radios on by default

2. Mai 2018

jmarcelino
May 2, 2018, 12:51 PM

@thomand1000
If you don’t actively use the LTE it’s actually better not to deinit() it, don’t call LTE module even. The modem should automatically go into deepsleep mode.

24. Mai 2018

adrianbro
May 24, 2018, 6:27 AM

@dylan

The LTE doco at

Introduction states the following:

"IMPORTANT: Once the LTE radio is initialized, it must be de-initialized before going to deepsleep in order to ensure minimum power consumption. This is required due to the LTE radio being powered independently and allowing use cases which require the system to be taken out from deepsleep by an event from the LTE network (data or SMS received for instance).+

When using the expansion board and the FiPy together, the RTS/CTS jumpers MUST be removed as those pins are being used by the LTE radio. Keeping those jumpers in place will lead to erratic operation and higher current consumption specially while in deepsleep."

https://docs.pycom.io/firmwareapi/pycom/network/lte.html states the following

"lte.deinit()

Disables LTE modem completely. This reduces the power consumption to the minimum. Call this before entering deepsleep."

2. Oktober 2018

High current consumption in deep sleep: 80 mA

[Andreas]

10. Dezember 2018 ff.

Diese Diskussion zwischen v.a. Daniel Campora und Robert ist hochinterssant, v.a. wird hier mal richtig gemessen.

G01 power consumption

12. Dezember 2018

iwahdan
Dec 12, 2018, 11:25 PM

Hello All ,

I’ve released a new version of Release candidate v1.20.0.rc1 having the following updates:

Improvements

• Exposed Keyboard Interrupts Control to Micropython

Bug Fixes

• Fixed DeepSleep high current Consumption when LTE is not Initialized
• Increased Delay before initialising RGB color to not Have RGB turn green at startup

Link to release on GitHub Release Firmware Release Candidate v1.20.0.rc1 · pycom/pycom-micropython-sigfox · GitHub

you can also download this Firmware via Firmware updater using development as firmware type.

---

Wahdan

18. Dezember 2018, 11:55

D

danielm
Dec 18, 2018, 11:55 AM

@xykon

Deep-sleep current on G01 with v1.20.0.rc3 built today from source:

import machine
machine.deepsleep()

Result: 7uA OK

import machine
import network
lte=network.LTE()
lte.deinit()
machine.deepsleep()

Result: 29mA Not OK!

Both tests are included in this graph:

Edit: Tested with FiPy on custom board (no FTDI or other peripherals) powered with 3.75V from Otii Arc.
Results are almost the same as for G01!

• 22uA for the first test code (includes quiescent current of voltage regulator)
• 27mA for the second test code.

Same results if LTE is attached between init and deinit.
The modem starts attach after first lte.isattached() is called!
It can be clearly verified when monitoring consumption with Otii Arc or similar tool.

18. Dezember 2018, 12:08

Xykon administrators
Dec 18, 2018, 12:08 AM

@danielm said in New Firmware Release Candidate v1.20.0.rc0:

@iwahdan @Paul-Thornton
In my opinion Pycom should provide statement regarding readiness of PSM/eDRX features implemented in the modem’s firmware because without these features it is not possible to develop battery-powered solutions with reasonable long battery life-time which is the main purpose of NB-IoT.
There should also be tutorial available in the documentation because of importance of these features.

I will try to post more details about PSM/eDRX as soon as possible. Generally the standard 3GPP AT commands should be used using lte.send_at_command() . However in order to tell the modem to go into PSM/eDRX mode, lte.deinit(dettach=False) should be called. The wrong spelling of dettach aside, the modem checks the state of the flow control pins to see if it is OK to go into low power mode. The deinit command releases the flow control pins thus allowing the modem to go into the configured sleep mode.

In regards to the release candidate, after uploading v1.20.0.rc2 earlier today, which includes the latest Sequans firmware updater and Pybytes scripts, I have realised an error was made in pycom_config.h that causes the fs_type flag to be stored at an incorrect position. This is also the reason why the setting from the firmware updater is ignored. I have already uploaded a correction to the release-candidate branch as I had issues updating the perviously used v1.20.0.rc0 branch. I will upload a new version shortly but wanted to give people a heads-up to check the file system type in the firmware updater when updating. This should only affect people who used the commands I posted above to manually switch the fs_type with the pycom_bootmgr command.

---

Christian Ehlers, Pycom VP Engineering

19. Dezember 2018

EinarJ
Dec 19, 2018, 8:11 AM

@danielm I’m using the GPy. The only way of achieving desired deep-sleep current levels is when i do a “lte.deinit(dettach=True)” and have the GPy alone without any expansion board or PySense/PyTrack

[Andreas]

16. Januar 2019

robert-hh
Jan 16, 2019, 2:55 PM

@einarj @danielm and me made similar tests a few weeks ago. (G01 power consumption | Pycom user forum) @danielm had seen 7µA on a G01, best case, but very often also 29 mA. I tested with a FiPy, SIM inserted.
After a lte init, attach, connect, disconnect, dettach, deinit, machine.deepsleep, I have seen aconsumption of 290µA 5 seconds after the deepsleep command, and then 40µA after about a minute past the deepsleep command. All that with SIM, but without an expansion board.

17. Januar 2019

EinarJ
Jan 17, 2019, 8:51 AM

@robert-hh Interesting results. I have also managed to get the FiPy and GPy down to uA current draw when the LTE modem is left alone. But having LTE was kind of the reason for using those boards :)
Until Pycom and Sequans have solved all the issues, I’m using a SARA N210 for my NB-IoT tests, together with a LoPy and a Pysense.

You can see the power results here:
New Firmware Release Candidate v1.20.0 | Pycom user forum

20. März 2019

bramelfvering
Mar 20, 2019, 12:05 PM

I’m using a fipy to send some sensor data with LoRa after which it goes into deepsleep for 15 minutes.
The first time the fipy boots up i deinit the LTE-m modem. Which takes about 4 seconds.
if my code detects a deepsleep reset, it skips this lte-m deinit.
Do i have to deinit the LTE-m modem after every deepsleep even though i don’t us it in my code.
I can’t find any documentation if the LTE-m modem inits after a reset like the WLAN does even though i don’t use it.

8. Mai 2019

FiPy, Nb-IoT and Deepsleep

Mai / Juni 2019

https://forum.pycom.io/topic/4877/deepsleep-on-batteries

[Andreas]

@Andreas

Investigate LTE airplane mode

Is explicit airplane mode better than just “off”?

Da jener Beitrag vom 3. Mai 2019 recht aktuell ist und am Ende eine konkrete Frage aufwirft…

@Andreas

AT+CFUN fun

John Baird
May 3, 2019, 9:04 AM

The latest manual I have is LR5.1.1.0 and I cannot seem to find LR6.0.0.0 anywhere.

In October '18 Pycom was expecting an updated manual and I notice in pycom-micropython-sigfox/lteppp.c at master · pycom/pycom-micropython-sigfox · GitHub the library uses the command

 lteppp_send_at_cmd("AT!=\"setlpm airplane=1 enable=1\"", LTE_RX_TIMEOUT_MAX_MS);

which does not appear in the LR5.1.1.0 manual. Could it be from the updated manual? I thought the AT! commands were manufacturer specific. If so, is there any Sequans documentations for this command?

How is "AT!=setlpm airplane=1 enable=1" different to "AT+CFUN=4" - or is it more like "AT+CFUN=2"?

… und uns auch @MKO bereits darauf hingewiesen hatte …

@Andreas

@MKO

Ich habe eben oben noch aufgeschnappt, das es nach aktivierung des “Fly-Mode” und evtl der Anrufsperre dennoch klappt. Der Flymode klingt auf alle fälle sehr logisch, das er das Problem umschiffen könnte, da ich weiß, das bei einem “normalem” Handy in diesem Modus die Sim abgeschaltet wird. Ein Handy ist ohne Sim oft kaum zu bedienen im Flymode aber nahezu problemlos. Einen versuch wär es sicher wert.

Hatte ich auch irgendwo gestreift, danke. Hast Du vielleicht noch den Direktlink im Tab?

… wollte ich das noch einmal aufgreifen, obwohl das Thema bereits ursprünglich Anfang 2018 erstmalig aufkam …

@Andreas

1. Februar 2018

daniel
Feb 1, 2018, 10:46 PM

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

… und daher vermutlich längst behoben / verbessert sein müsste.

Allerdings weiß man ja nie, schließlich gibt es gerade in diesem Bereich scheinbar weitere Verbesserungen, die es bis jetzt nicht in ein Release geschafft haben:

• Erschließung von LTE Cat M1 und NB1 mit dem Pycom FiPy - #87 by Andreas
• Fixed delays causing not to achieve low power after deepsleep by arapostol · Pull Request #255 · pycom/pycom-micropython-sigfox · GitHub

[Andreas]

Andere im Pycom Benutzerforum berichten zu diesem Thema:

@kjm

I’m struggling to understand the purpose of lte.init() and lte.deinit(). I get what attach/connect & disconnect/detach do but regardless of if I use init/deinit or not the software cycle & deepsleep power consumption are unchanged. Can someone please enlighten me?

– kjm Jul 26, 2019, 9:35 AM

[Andreas]

Recap lte.deinit()

Einleitung

Dank @pinguin kam drüben bei Improve watchdog behavior re. LTE modem deinit by pinguin999 · Pull Request #11 · hiveeyes/terkin-datalogger · GitHub das Thema “To lte.deinit() or not to lte.deinit()?” nochmal auf den Tisch. Das ist fein, weil ich es gedanklich auch noch nicht abgeschlossen hatte, siehe auch LTE-Modem ordentlich deaktiviert?.

Retrospektive

Deep Sleep with FiPy / ESP32 on MicroPython

lte.deinit() hatte ich schon mal irgendwo aufgeschnappt, aber hier stehts nun schwarz auf weiß von @adrianbro, was das mit der Stromaufnahme machen kann, wenn man es vergisst. Danke! – FiPy current consumption analysis | Pycom user forum

Status quo

Die Routine def power_off_lte_modem() wird aktuell bei jedem Systemstart aufgerufen.

Fragestellung

However, we are wondering whether this single line actually does something reasonable.

hiveeyes/terkin-datalogger/blob/0.5.1/terkin/device.py#L178-L178

These

Wenn das LTE-Modem gar nicht erst hochfährt, gilt dann o.g. Faustregel bzgl. lte.deinit() überhaupt?

Ausblick

Erstmal bleibt alles so wie es ist. Sehr schade ist allerdings, dass die o.g. Routine ungefähr 6 Sekunden bei jedem Systemstart in Anspruch nimmt.

Wenn also nochmal jemand Fleißarbeit in Richtung Stromverbrauchsmessungen mit/ohne unternehmen will… Top!

[Andreas]

Auch wenn wir das noch nicht(?) 100%ig überprüft haben, weisen Beiträge im Pycom Benutzerforum darauf hin, dass es nach der ersten deep sleep Phase mit der Reduktion des Stromverbrauchs gut klappt, aber nicht mehr bei allen Folgenden.

Ähnliche Beobachtungen wurden hier bei uns u.U. bereits von @clemens, @MKO und @didilamken gemacht.

Hier wollen wir noch einmal auf entsprechende Beiträge/Zitate hinweisen.

@thomand1000

I’ve tested this now (removed lte = LTE() and lte.deinit() ) and the peak is still there. The device goes into deep sleep, but like before the current rises quickly to about 200 mA for a couple of seconds before it goes into deep sleep. I also find it strange that it doesn’t happen the first time the device goes into deep sleep, but all consecutive runs. The first time now, since I don’t deinit() LTE the current is at about 200 mA and drops down to deep sleep. Then when waking up it is around 60-70 mA when measuring and then peaks to 200 right before deep sleep.

– thomand1000 May 2, 2018, 1:04 PM

@davidchallender

Have been looking at power consumption and have similar issues to what is reported here have 200mA in main program then 190 to 150 mA for 30 sec before dropping to deep sleep. In first cycle deep sleep current is 200 micro amps. In subsequent cycles the deep sleep current is 30 mA. Have tried turning everything off without change. Have same issue with LTE but don’t have a SIM. Agree that things should not be instantiated by default but as required.

– davidchallender Sep 6, 2018, 7:24 AM

[Andreas]

Auch dies passt zum Thema:

Fipy, is LTE.deinit needed after every deepsleep?

[Andreas]

Ein weiterer Beitrag von @robert-hh aus dem Pycom Benutzerforum:

Using your command sequence with a FiPy, firmware v1.20.0.rc1, the current drops after a few seconds to 290µA, and then to 20µA after about a minute.

With lte.send_at_command('AT!="CBE::powerOff"') between lte.dettach() and lte.deinit() the current drops to 20 µA after a while too, but faster than a minute.

Without LTE init, the current drops to 20µA too. The difference to your test may be caused by the LoRa chip on the FiPy.

For the test, the FiPy was just connected to GND, Vin at 3.8V and an antenna, every other pin was left open.

– robert-hh Dec 16, 2018, 4:49 PM

---

Wir sollten vielleicht einfach kurzerhand

lte.send_at_cmd('AT!="powerOff"')

senden und lte.deinit() komplett umgehen?

– Erschließung von LTE Cat M1 und NB1 mit dem Pycom FiPy - #41 by Andreas

[IngoP]

gibt es schon erkenntnisse, was das dann an Energieeinsparung bringt?

Wo stecke ich die Deaktivierung hin?

Ich habe ja nur die main und die settings bei der annapurna vorliegen.

[clemens]

Das ist noch “research” wir müssen erst mal messen ob und was das bringt und dann wird es sicher auch in die “frozen” firmware einfließen. Hättest du denn die Möglichkeit den Stromverbrauch mit und ohne zu messen? Dann müssten wir den FiPy am besten über die sandbox flashen?

[IngoP]

Also ich kann über mein Multimeter das hier messen… klar.
Ich habe nur keine Möglichkeit das auf eine Zeitachse zu setzen … also mit Messintervallen.

NOCH ist der Test Pi auf Grund von Zeitmangel wegen Kampf mit meiner Wärmepumpe und meinen Stockdämmkisten nicht am Stock verbaut

[clemens]

@IngoP

Also ich kann über mein Multimeter das hier messen… klar.
Ich habe nur keine Möglichkeit das auf eine Zeitachse zu setzen … also mit Messintervallen.

Das braucht es auch nicht! Ich habe hier das sleep-Intervall so lange eingestellt, dass man das per Multimeter eindeutig identifizieren kann. Im Optimalfall noch kurz die LED blinken lassen, damit man den Start der Messphase oder der sleep-Phase mitbekommt dann kann man den Verbrauch im sleep mode mit und ohne die Änderung oben messen. Ich denke Andreas würde sich sehr freuen, wenn wir hier Messwerte liefern können. Häufig sind das ja Vermutungen oder Messungen mit anderer / alter firmware, die bei den vielen Änderungen bei PyCom heute nicht mehr so sein müssen wie zum Zeitpunkt des Berichts.