Stromversorgung der BOB-Platine

Da der FiPy auf der BOB-Platine mit allen Sensoren und häufigen Messungen mit ca. 1100 mW recht viel Strom verbraucht, ist die Laufzeit mit der Ladung eines 2000 mAh LiPo-Akkus nur gering ( ca. 7-8 Stunden) Wenn man auch noch Solarstrom benutzen möchte, braucht man ein sehr grosses Solarmodul.
Da die Stromspar-Massnahmen per Software (sleep, lightsleep und deepsleep )nicht viel bringen, habe ich als Hardware-Lösung die Platine BOB-Strom-V2 entworfen, auf der die RTC DS3231 per Alarm die Stromversorgung über einen MOSFET ein/ausschalten kann. 2 x Stromsensoren INA219 messen den Ladestrom des Solarladers CN3065 und den Entladestrom des Akkus.

Die Platine in Fritzing: BOB-Strom-V2.fzz (59,4 KB)
BOB-Strom-V2_Schaltplan.pdf (1014,3 KB)
BOB-Strom-V2_Leiterplatte.pdf (1,6 MB)


Die Platine kann in 2 Varianten betrieben werden:

  1. nur mit DS3231 und MOSFET bestückt, die INA219 überbrückt

BOB-HAT-V6 und BOB-Strom-V2 nur mit DS3231 sind so konstruiert, dass sie zusammen mit einem Akku in das BOB-Gehäuse passen.

Dann kann die BOB-Software mit dem DS3231 die Stromspar-Pausen selbst einstellen und man benötigt keinen DeepSleep .

  1. zusätzlich bestückt mit CN3065 und 2 mal INA219.

Dann kann der Akku mit einem 6V-Solarmodul oder über USB geladen werden. Der erste INA219 misst Spannung, Strom und Leistung des Ladens. Der DS3231 kann über I2C so programmiert werden, dass der Alarm 1 im Sekundentakt die Stromversorgung schaltet und der zweite INA219 misst. Beispiel aus der Praxis: 30 sec ein ( booten, messen und senden) und 30 sec aus ergibt einen Messwert pro Minute bei einerAkku- Laufzeit von 20 Stunden.
Verlängert man die Pausenzeiten, verlängert man die Laufzeit ebenfalls.
Sinnvollerweise steuert man die Platine mit einem 2. FiPy über I2C an, der jede Sekunde misst. der BOB-FiPy misst ja nur noch selten

Die folgende Software BOB-Strom-V2.zip (32,2 KB)
enthält Testprogramme für DS3231 und INA219 und Programme, um die Versorgungsspannung des BOB-FiPy alarmgesteuert ein- und auszuschalten. Gleichzeitig wird der Stromverbrauch pro Sekunde gemessen und auf SD-Karte aufgezeichnet ( Datei cur2020-09-21.csv und *.plt ) die mit gnuplot angezeigt werden können.
sensor.ds3231.py enthält einen getesteten Treiber und sensor.timing.py Methoden, um die Zeit der internen RTC und des DS3231 per NTP auch auf Sommerzeit zu stellen und Alarm1 zu schalten.

Das folgende Bild zeigt die Spannung des geladenen 2000mAh-Akkus beim Betreiben des BOB mit seinen Sensoren.


Schon nach 7 Stunden ist Schluss mit Messen bei 3.3V. Da der Akku keinen Entladeschutz hat, sinkt die Spannung auf 0 V. Das ist ungesund für den Akku und sollte nicht oft vorkommen. Zieht man die Last ab, steigt die Spannung unregelmässig.
In die Software muss unbedingt eine Abschaltung bei Unterspannung eingebaut werden.

Bei der Strommessung ( gelb ) erkennt man, dass man mit einem Multimeter keine Chance zu messen hat. Die Werte variieren zu stark.
Die abgegebene Leistung ( blau ) schwankt stark um 1100 mW und wird erst kleiner, wenn der FiPy wegen Unterspannung nicht mehr messen kann.

Um Strom zu sparen, kann man versuchen, in der Software Energiesparmodi einzustellen.
Ich habe es mit folgenden versucht:

  1. print(‘end of cycle: sleep 30 sec’)
    time.sleep(30) # OK, spart kein Strom
    nur alle 35 sec ein Messwert, spart aber kein Strom

  2. print(‘end of cycle: lightsleep 35 sec’)
    machine.sleep(35*1000 ) # Wlanprobleme
    das WLAN funktioniert nicht mehr und muss neu gestartet werden

  3. machine.sleep(35*1000, resume_wifi_ble=True) # Exception
    fuhrt zu Absturz

  4. machine.lightsleep(30) # Excption
    führt zu Absturz

  5. print(‘end of cycle: deepsleep 35 sec’)
    machine.deepsleep(35*1000) # OK, spart etwas Strom
    funktioniert, 1 Messwert pro Minute, spart etwas Strom, für jede Messung muss der FiPy booten


Die Laufzeit verlängert sich auf 12 Stunden
Der Akku wurde dann über den CN3065 an USB geladen. Der Akku war nach gut 3 Stunden voll.

Bei Strom und Leistung sieht man den Zyklus:
20 sec Booten, 5 sec Messen, 35 sec Deepsleep -> 1 Messung pro Minute
Die Leistung im Deepsleep beträgt immer noch 350 mW

Als weitere Stromsparmassnahme kann ich mit der Platine BOB-Strom-V2 die Versorgung des BOB-FiPy alarmgesteuert ein/ausschalten. Im folgenden Beispiel schalte ich den Strom für 30 sec ein und 30 sec aus:


Nun beträgt die Laufzeit schon 20 Stunden, danach wurde wieder mit USB geladen.

Ein Zyklus besteht aus 20 sec Booten, 5 sec Messen, 5 sec Deepsleep und 30 sec Strom aus
=> 1 Messwert pro Minute

Die Pausenzeiten können grösser eingestellt werden. Bei 30 sec ein und 150 sec aus erhält man nur alle 3 Minuten einen Messwert. Man könnte die Pausenzeiten auch abhängig von der Spannung machen:
USB-Betrieb mit 5 V => keine Pause und 1 Messung alle 5 sec,
Akku voll mit 4 V => 30 sec Pause 1 Messung jede Minute
Akku leer mt 3.2V => 570 sec Pause mit 1 Messung alle 10 Minuten

3 Likes

Welchen Akku hast du denn dran gehabt, den 2000 mAh von BOB? Da dachte ich auch zuerst er hätte keinen Schutz, hat er aber wie @weef herausgefunden hat: Solarbetrieb der BOB-Platine mit einem CN3065 Solar-Lader - #13 by weef

Ich teste 3 Akkus 2000 mAh von BOB ( Eckstein ). Wie man an den Kurven sieht, wird der Akku nicht bei 3.0V oder darunter abgeschaltet.

Ergänzung:
Ich möchte den Akku nicht zerlegen, betrachte aber das Verhalten beim Entladen noch näher.


Das Messen des FiPy funktionierte bis Uein=3.07 V um 12:05, danach entlud der FiPy aber weiter den Akku bis die Schutzschaltung ihn um 12:22 kurz und um 12:25 endgültig bei 2.5V abschaltete.

Ich halte es für sinnvoll, den Akku unter einer Spannung von 3.1V abzuschalten, damit der BOB-FiPy im regulären Messbetrieb bleibt oder ganz ausgeschaltet wird.

Bis 8:00 eine Messung pro 3 Minuten


ab 12:00 eine Messung pro 15 Minuten

Der Akku wird sehr langsam entladen. Dauer muss noch gemessen werden.

2 Likes

Prima, dann hat der LiPo also doch einen Schutz vor Tiefenentladung, wenn auch sehr “weit unten” eingestellt. Ich hatte ja auch eher etwas weiter oben erwartet, aber immerhin es ist einer da.

Ja, man sollte mit einem anderen, höheren threshold, z.B. 3,2 V, das Ganze per software schon vorher in den never ending deep sleep schicken.

machine.sleep(1000*35, True)

Da sollten die Wlan Probleme weg sein. Das True sagt das WLAN nach dem light sleep wiederhergestellt werden soll.

Edit:
OK hilft dir auch nicht wirklich weiter hast du ja in Punkt 3 schon versucht.
Punkt 4 ist ja eigendlich der Befehl der anstatt Punkt 2und 3 verwendet werden sollte. Denke Mal die Problematik dreht sich um die reconect Wlan geschichte.

Hast du beobachtet, ob er vor oder nach dem Schlafen abgestürzt ist?

Um den Stromverbrauch zu untersuchen habe ich mir einen neuen WiPy zum Vergleich mit dem FiPy gekauft:
WiPy Firmware 1.18.2.r1 [v1.8.6-849-e0fb68e] on 2018-12-08;
FiPy Firmware 1.20.1.r1-0.7.0-vanilla-dragonfly-onewire [13d82ea5-dirty] on 2019-11-17

Das Testprogram macht Folgendes:
30 sec RGB-Led an, 30 sec time.sleep(30), 30 sec machine.deepsleep(30*1000)


Die ersten 3 Zyklen WiPy auf ExpansionBoard, dann 3 Zyklen auf BOB-HAT mit allen Sensoren,
Danach 3 Zyklen FiPy auf ExpansionBoard, dann 3 Zyklen auf BOB-HAT mit allen Sensoren,

Der WiPy verbraucht wesentlich weniger Strom als der FiPy, vermutlich weil er nur WLAN und BLE, aber kein Sigfox, Lora und LTE an Board hat.
Der BOB-HAT verbraucht im Leerlauf ca. 25 bis 29 mW für BME280, 5 x DS18B20 und HX711, obwohl sie nicht angesteuert werden, also auch bei deepsleep.
Die RGB-Led verbraucht bei voller Ansteuerung über 100 mW.
Besonders groß ist der Unterschied beim deepsleep: WiPy 42 mW, FiPy 328 mW , also das 7 fache.
Bei vollem Akku mit 4.1V fliessen gut 10 mA beim WiPy, weshalb in den Datenblättern von uA geschrieben wird, kann ich nicht nachvollziehen.

Kannst du deinen Testcode mit uns Teilen. Ist zwar schon eine ganze Weile her, aber ich habe schon mehrfach den Deepsleep iim uA Bereich gemessen.
Zuletzt Hier
Selbst im light waren es nur 1,8mA mit angeschlossenen Sensoren und SD Karte.
Wenn ich raten müßte würde ich sagen, das das WLAN Modul oder BT Modul nicht sauber runter gefahren wird.

Ich hatte damals auch 10 mA (WiPy) und 75 mA (FiPy) mit der hiveeyes-Software ohne Optimierung gemessen, s. Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb - #15 by clemens

War mit dem BOB-Hat auch das expansion board angeschlossen? Das expansion board braucht ja auch noch Strom. Daher war mir am Anfang auch so wichtig, dass unser komplettes System auch ohne expansion board läuft! Hier gibt es z.B. einen thread zum expansion board: Fipy & Expansion board 3.1 - deepsleep power consumption | Pycom user forum Angeblich sind das aber alle Verbrauche im Bereich von unter 1 mA.

Auch das kann mit expansion board und FiPy helfen:

Bei uns sind vermutlich aber Abschaltung des Funk-Moduls und die Sensoren, besonders der HX711 das Problem. Normalerweise versorgt der HX711 die Wägezelle mit einer Spannung und die macht den hohen Verbrauch im deep sleep aus. Wir müssen also dafür sorgen, dass der Treiber des HX711 die Spannung abschaltet. Weiter muss der pin state gehalten werden. Für die Terkin-Software hatten wir das hier damals lange erforscht, Ergebnis war dann:

Mit diversen Verbesserungen sind wir mit der Terkin-Software und einem FiPy damals auf 70 uA gekommen, s. Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb - #173 by clemens

Nur leider hat sich in der Zwischenzeit wieder ein bug eingeschlichen. :-/

Ich messe den neuen WiPy Firmware 1.18.2.r1 [v1.8.6-849-e0fb68e] on 2018-12-08; auf einem ExpansionBoard 3.1 ohne SD-Karte mit folgendem Code:

import pycom
import time
import machine

pycom.heartbeat(False)

for cycles in range(10):     # stop after x cycles
    print('loop', cycles)
    print('RGB-LED   30 sec')
    pycom.rgbled(0xffffff) # weiss
    time.sleep(30)
    pycom.rgbled(0x000000) # aus

    print('    sleep 30 sec')
    time.sleep(30)

    print('deepsleep 30 sec')
    machine.deepsleep(30*1000)

und messe Spannung Strom und Leistung mit einem USB-Meter von Elektor an einem USB-Netzteil:

  1. LED an: 5.25V 116 mA 613 mW
  2. sleep: 5.25V 97mA 515 mW
  3. deepsleep: 5.28V 15 mA 80 mW

Das sind sehr ähnliche Werte, wie ich sie auch mit dem INA219 auf dem Board BOB-Strom ( siehe oben ) messe.

Leider muss ich mit USB versorgen. Die Akkuspannung reicht nicht für das USB-Meter.

Das ist ja auch sehr alt, bringt ein update ggf. schon was?

Ich wollte zuerst den fabrikneuen WiPy testen. Jetzt kommen die Firmwareupdates.

1 Like

@didilamken, habe mal deine Zeilen code auf einen WiPy geladen, den dann auf die nackte BOB-Platine gesetzt und damit 16 uA im deep sleep gemessen:

Nun den WiPy umgesetzt auf eine Platine bei der alle BOB-Sensoren angeschlossen waren und damit verbraucht er dann schon 8 m(!)A im deep sleep:

Wenn du jetzt am Ausgang der HX711-Platine E+ und E- misst wirst du ca. 2,4 V angezeigt bekommen, das ist u.a. der Grund warum der noch so viel Strom verbraucht, der HX711 und damit die excitation voltage der Wägezelle wird nicht korrekt abgeschaltet.

Firmware war die 1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig [v1.20.1.r2-122-gd82a6f43e-dirty] on 2020-03-06 von Andreas.

Vielleicht ist das auch ein weiteres Probelm, die sind ggf. nicht für so kleine Ströme geeignet wie andere Messgeräte.

Ich werde heute abend weiter testen mit div. USB-Testern und Multimetern.
Ich habe aber keinen CurrentRanger.

Der deepsleep-Strom des WiPy auf einer nackten BOB-Platine ist so klein, dass ich ihn mit meinen Mitteln nicht mehr gut messen kann: 20 uA
Ich habe also bislang immer den Standbystrom des ExpansionBoards gemessen.

1 Like

Während der WiPy auf der nackten BOB-Platine einen sehr kleinen deepsleep-Strom hat, ist das beim FiPy leider nicht der Fall. Den Strom habe ich mit einem Multimeter und dem INA219 auf BOB-Strom-V2 gemessen. Die Unterschiede in der Anzeige sind gering, so dass ich im folgenden die Werte des INA219 benutze, da sie sekündlich ausgelesen und aufgezeichnet werden. Ebenfalls benutze ich zum Vergleich nicht die Stromstärke in mA, sondern die Leistung in mW, da es schon ein Unterschied ist, ob ich die Schaltung mit USB ( 5.2V ), vollem Akku ( 4.1V ) oder leerem Akku ( 3.2V ) betreibe.

Das Testprogramm ist wieder RGB-Led an ( 30 sec ), time.sleep(30), machine.deepsleep(30*1000):


Die ersten drei Zyklen ist der FiPy auf der leeren BOB-Platine, gespeist über die 2-pol. Steckklemme Spannung, LED 890 mW sleep 780 mW deepsleep 290 mW

dann habe ich das ExpansionBoard angesteckt: LED 1280 mW sleep 1150 mW deepsleep 290 mW

Zum Schluss habe ich das ExpansionBoard über den USB-Anschluss eingespeist:
LED 1040 mW sleep 910 mW deepsleep 370 mW

Warum der FiPy bei Einspeisung über USB so viel weniger Leistung verbraucht, ist mir ein Rätsel.

Ergänzung 30.9.20
Der gleiche Messzyklus mit einem WiPy zeigt einen deutlich sparsameren Microcontroller:


Bei Einspeisung über Pin 5V ( 2pol. Steckklemme) ist der deepsleep-Strom sehr gering ( ca. 20 uA ), nur bei Einspeisung über USB am Expansionboard verbraucht er ca. 75 mW.

Das ist sehr viel weniger als beim FiPy. Wenn also LoRa oder LTE nicht gebraucht werden, könnte der billigere WiPy besser sein als die eierlegende Wollmilchsau FiPy. Um beim FiPy Strom zu sparen, braucht man also die Strom-Abschaltung mit dem DS3231. Per Software wird man nicht viel erreichen.

Die einfachste Stromspar-Maßnahme: FiPy gegen WiPy tauschen:


links der WiPy mit WiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire-i2s
rechts der FiPy mit FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire-i2s
Hardware identisch BOB-HAT mit BME280, HX711 und 5 x DS18B20
Software identisch Hiverize/FiPy vom 29.8.20 mit 35 sec deepsleep am Ende der Mess-Schleife.

Der Stromverbrauch ist praktisch halbiert. Man kann auch noch in der Software optimieren, wird aber nicht so viel erreichen

Ich habe die Software zum Board BOB-Strom-V2 so erweitert, daß ich das Entladen und Laden des 2000 mAh Akkus mit Spannung, Strom und Leistung messen kann. Die Leistung wird so aufsummiert, daß ich die Energie in mWh erhalte.
Zuerst wurde der Akku mit einem FiPy und Sensoren mit 5 sec Messintervall ohne Deepsleep entladen, dann wurde er an USB wieder aufgeladen.


blau: Spannung des Akkus 4.2V bis 2.4V beim Entladen und 2.3V bis 4.2V beim Laden
grün: Leistung des FiPy ca. 1100 mW bis 0mW bei Akku leer
rot: Leistung beim Laden aus USB-Netzteil 4500 mW bei Start

die aufsummierte Energie:


grün: Der FiPy verbrauchte beim kompletten Entladen fast 8000 mWh
rot: der Akku benötigte zum kompletten Aufladen fast 10200 mWh
Fazit: im Akku wurden über 2200 mWh Verluste ( 22% ) verpulvert

interessant ist auch das Verhalten am Ende des Entladens:


Unter 3.0V scheint der FiPy in einen sparsameren Modus zu wechseln, misst und sendet aber weiter bis 2.52V, danach gibt es keinen geregelten Betrieb bis der Akku bei 2.45V abschaltet.

Inzwischen habe ich 3 Solarlader für 6 V Solarmodule und 3 MPP-Solarlader für 12 V Solarmodule im Test, und versuche auch mit der mageren Solarausbeute an einem trüben Novembertag noch messen zu können. Dazu steuert der Alarm der RTC DS3231 die Versorgung des Mess-FiPy oder -WiPy. Er schaltet den Strom für 30 sec ein, damit der FiPy booten, messen und senden kann. Dann schaltet er abhängig von der Akku-Spannung für viele sec aus.

if Uaus0 < 4.0: IntervalAlarmAus =   30   #  1 min
if Uaus0 < 3.8: IntervalAlarmAus =   90   #  2 min
if Uaus0 < 3.6: IntervalAlarmAus =  270   #  5 min
if Uaus0 < 3.4: IntervalAlarmAus =  570   # 10 min
if Uaus0 < 3.2: IntervalAlarmAus = 1170   # 20 min
if Uaus0 < 3.0: IntervalAlarmAus = 1770   # 30 min

So erhält man 60 bis 2 Messungen pro Stunde.
Mein erster Test sieht so aus:


Rot zeigt die Ladeleistung eines 50 Wp-Solarmoduls im Novembernebel : bis zu 700 mW ( milliWatt ! ) Um 8 Uhr ging die Sonne auf, um 11:30 lichtete sich der Nebel etwas, um 16 Uhr war es wieder dunkel.

Blau zeigt die Spannung eines kleinen LiPo-Akkus ( 3.7V 300 mAh ). Er war um 8 Uhr praktisch leer, mittags auf 3.7 V aufgeladen, nachmittags wieder leer.

Grün zeigt die Leistung einer angeschlossenen elektronischen Last. Sie wurde für 30 sec angeschaltet. Von 11:00 bis 13:30 30 mal und später nur 2 mal pro Stunde.

1 Like

Bei dem trüben Wetter ist es schwierig, auch durch ein 50 W Solarmodul genügend Energie für häufige Messungen zu erhalten.


Blau: Die Spannung des LiPo-Akkus ( 3,7V 2000mAh ) sank in der Nacht auf 3.0 V, stieg dann aber durch die Solaraufladung auf fast 3.5 V.

Rot: Die Solarlade-Leistung war max. 350 mW ( von einem 50 W Modul ! ) und ergab eine Energie von 1400 mWh ( schwarz ).

Grün: die elektr. Last wurde unterschiedlich oft für 30 sec eingeschaltet, die Leistung ist stark abhängig von der Akku-Spannung. Die aufsummierte Energie betrug 600 mWh ( grüne Treppe ) .

Die Firmware des WiPy läuft leider nicht stabil. Er bootet häufig neu - trotz GarbageCollector und Watchdog. Das führt zu dem nicht ganz gleichmässigen Einschalten. Gestern gab es Hänger, wo nur noch Strom aus/ein weiterhalf.
Da ich jede Sekunde 8 Werte messe und aufzeichne, ergeben sich 60 x 60 x 24 x 8 = 692200 Messwerte pro Tag und ca. 11 MByte auf der SD-Karte.
Kann diese Datenmenge sinnvoll über Internet übertragen und mit Grafana angezeigt werden ?

2 Likes