Damit die Nodes auch mit einer Batterie gut laufen brauchen wir eine deep sleep-Phase zwischen den Messungen, erster Versuch:
committed 08:34AM - 15 Apr 19 UTC
* sleep hangs
* set sleeping_time to "0" produces "undefied variable"
Ist es nur beim Setzen auf “0”, sprich ist der Vairablenwert “0” das Problem – was macht z.B. “5”? – oder ist es der deep sleep an sich?
Bezüglich der Sorge von @Andreas , ob dann alles auch wieder anständig hochkommt, gäbe es auch noch die brachiale Methode deep_sleep.hw_reset()
.
Wenn es irgend geht bitte nicht, wir versperren uns damit den Weg Dinge dynamisch über ein reset hinweg lokal zu speichern, z.B. das letzte Gewicht, um bei einer sehr hohen Differenz bei der nächsten Messung einen Schwarm- oder Diebstahlsalarm auch lokal auszulösen.
Für die Micro-Python-Firmware von BOB wollen wir zwischen den Messungen eine deep sleep-Phase, siehe https://github.com/Hiverize/FiPy/issues/2 haben, um den Stromverbrauch zu reduzieren.
@einsiedlerkrebs , du hattest doch schon mal erste Versuche gestartet, sagte mir @Andreas . Hast du Tipps für @vinz wie das am besten zu realisieren ist?
Ich hatte es so probiert:
Aber keinen Erfolg gehabt. I commented in Github:
Nachdem @clemens bei Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb nochmal zu Recht gedrängt hatte - danke! - sind wir hier nun einen Schritt weitergekommen.
opened 08:15AM - 07 Jun 19 UTC
closed 07:53PM - 16 Jun 19 UTC
People have been asking [1,2] for Deep Sleep on FiPy. While @einsiedlerkrebs and… others [3] tried already,
> I have tried deep sleep, but without success. Tried 1s sleep but device didn't wake up.
>
> I have to admit that I did not do any debugging on this yet.
> see: [hiveeyes/hiveeyes-micropython-firmware@191a46b](https://github.com/hiveeyes/hiveeyes-micropython-firmware/commit/191a46b9a6063ce2d05997e655a3f9e5164bd683)
it looks like it would be harder than expected. As usual, the devil might just be in the details.
We will try to dedicate some time to that exceptionally important detail.
[1] https://community.hiveeyes.org/t/bob-platine-im-lipo-betrieb-ohne-deep-sleep/2055
[2] https://github.com/Hiverize/FiPy/issues/2
[3] https://github.com/pycom/pycom-libraries/issues/26
Einleitung
@clemens meint, wir wären hier noch nicht fertig.
Mit dem Hiveeyes-code messe ich 30 mA mit expansion board und 10 mA ohne in der 30 sekündigen Schlafphase, hmmm viieeeel zu viel verglichen mit den postulierten 0.02 mA beim WiPy, gut, es ist ein FiPy, aber 10 mA vs. 0,02 mA, da muss noch was nicht passen!
Ohne angeschlossene Sensoren sind es 4 mA, deutlich weniger aber immer noch nicht im Bereich von 0,02 mA!
Gut, lass uns weitermachen.
Sammlung
Hier nochmals eine wertvolle Sammelei von @clemens , die schon '17 begann.
The ESP8266 had some limitations regarding deep sleep to appoint at least two:
the deep sleep period with a maximum time of a bit more then one hour
deep sleep wake up was implemented as a reset, so all variables lost their values and got back to default, due to the reset all initialization code in setup() must be executed after a wake up
Seems that the successor, the ESP32 has not this limitation any more:
[#149 ESP32 Deep Sleep, RTC Memory, "Secret" LoLin Pins]
Andreas
Split this topic
June 8, 2019, 12:26am
9
A post was merged into an existing topic: Low power ESP32: Hardware and Software
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!
adrianbro
May 24, 2018, 6:11 AM
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.
states the following:
lte.deinit(detach=True, reset=False)
Disables LTE modem completely. This reduces the power consumption to the minimum. Call this before entering deepsleep.
detach
: detach from network.
reset
: reset LTE modem.
– FiPy current consumption analysis | Pycom user forum
2 Likes
Hier auch noch mehr dazu:
davidchallender
Sep 6, 2018, 7:24 AM
@thomand1000
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.
See also.
Hi, after making some tests mettering the current consumption of a FIPY in deep sleep mode, there is an issue that I couln't solve yet. Basically the code makes a Lora publication and then goes to sleep 1 minute and repeats the same routine. In the...
This is the code used to sleep:
import machine
machine.pin_deepsleep_wakeup(pins=['P8'], mode=machine.WAKEUP_ALL_LOW, enable_pull=True)
machine.deepsleep(60000)
Ok, für LoRa, LTE sind wir dann erst mal auf der sicheren Seite, da es in unserer Firmware nicht enabled wird, oder?
Wird WLAN / Bluetooth bei uns schon ausgeschaltet vor den schlafen?
Hallo in die Runde,
ein kleiner Zwischenbericht zum Thema. Ich muss sagen: Zu fast jedem Aspekt im Bereich des Deep Sleep gibt es widersprüchliche Meinungen (im Pycom Forum) – wie überall anders auch auf der Welt. Der Irrsinn!
Gerade das LTE-Modem soll angeblich ein Biest sein, was die korrekte und deterministische Abschaltung betrifft. Es gibt aber noch eine ganze Reihe anderer Dinge, die unter bestimmten Umständen bei manchen Leuten noch nicht ordentlich zu funktionieren scheinen – und dann wieder doch ;].
Ich vermute eine eindeutige Korrelation mit Mondphasen. Wer andere Begründungen finden will, wird unter Umständen auch bei [1] fündig. Im Zweifelsfall immer geeignet: cosmic rays – not actually kidding at all [2] ;].
Viele Grüße,
Andreas.
[1] Spurious Correlations
[2] Re: Memory errors / ECC memory vs. cosmic rays
Moar News
Während jenes ganz frische bei
Hi everybody I'm a little bit lost, as deepsleep doesn't look to be working correctly with my setup, as I always get around 5 mA while in deepsleep. The setup is: FiPy (tried versions 1.80 -> 1.20) PySense 0.0.8 (did at least 5 times the update,...
vielleicht wirklich nur PySense-spezifisch sein mag, erzeugt der ebenso recht aktuelle Beitrag (gegründet vor zwei Wochen) bei
definitiv wieder weitere Perspektiven auf. Gut, dass wir Hardware-Leute an Bord haben. Tobt Euch aus. ;]
Viele Grüße,
Andreas.
Andreas
Split this topic
November 3, 2019, 10:03pm
18
3 posts were merged into an existing topic: LTE-Modem des Pycom FiPy komplett stilllegen
Hi. Hier gibt es ein paar Neuigkeiten aus der Community.
frederik Leys , 2 days ago
@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)
– FiPy deepsleep methods | Pycom user forum
Gijs , 2 days ago
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.
– FiPy deepsleep methods | Pycom user forum