Solarbetrieb der BOB-Platine, verschiedene Möglichkeiten

Leider taugt das o.g. Waveshare Solar Power Management Module nicht für unsere Zwecke. Es liefert nicht die Spannung des LiPos aus, was für uns völlig reichend wäre, sondern wandelt die 3,x bis 4,2 V des LiPos in eine 5 V-Spannung.

2019-09-16%2009_53_34-Greenshot

Ein voll geladener 2000 mAh-LiPo liefert nur 4 (!) Stunden Energie, trotz Unterstützung der 5 W-Solarzelle! Danach schlägt die Schutzschaltung der Platine zu und trennt die Stromversorgung bei einer LiPo-Spannung von 3,0 V. Hier ein Graph der 5 V, die beim FiPy ankommen und dort wieder auf 3,3 V heruntergeregelt werden. Also auch energetisch Quatsch, da wir die 5 V ja gar nicht benötigen.

Nächster Versuch ebenfalls mit der Platine oben, als Spannungsquelle für die Platine aber nicht der 5 V-Ausgang, sondern der LiPo direkt.

Leider werden in den Datenblättern die theoretischen Spitzenwerte und nur selten die realen Dauerwerte angegeben. Eine 5 Wpeak-Solarzelle liefert bei uns vermutlich nie 5 W, wir leben ja nicht in der Sahara. Und ein 2000 mAh-LiPo enthält auch nur theoretisch 2000 mAh * 3,7 V = 7400 mWh. Mein FiPy verbraucht etwa 1 W. Theoretisch könnte er über 7 Stunden am Akku laufen, praktisch sind es aber nur 4.

2 Likes

Das hilft zwar nicht bei der Auswahl einer guten Versorgungseinheit für Solarstrom, ich wollte die aktuellen Zahlen aber nun doch einmal auch hier im Kontext nennen.

Nach langen zähen Optimierungsarbeiten konnten wir drüben bei Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb eine Laufzeit von ~40 Stunden mit einer Akkuladung erreichen, wenn ca. alle 90 Sekunden gemessen wurde.

Das kommt doch hin: alle 10 sec Messen -> 4 h und alle 90 sec Messen -> 40 h

1 Like

I see. Dann passt das ja zusammen. Danke!

Wie geschrieben habe ich nun, im nächsten Versuch, den LiPo und den Verbraucher / FiPy am gleichen Batterie-Anschluss der Ladeplatine hängen, wie es auch beim CN3065 Solar-Lader der Fall ist.

Das Szenario scheint nicht gut zu funktionieren: Auch hier lief der LiPo nur 4 Stunden, allerdings sagt die Telemetrie, dass er beim Ausstieg noch 3,8 V hatte. Dann ist das System nach 14 Stunden, mitten in der Nacht, wieder angesprungen und hat 4x Daten übertragen, allerdings mit einer Batteriespannung von 2,5 V, danach wieder Funkstille, Heute beim Austausch der Batterie (und ggf. etwas Solarladestrom heute Vormittag) hatte der LiPo 3,3 V, das System ist aber nicht angesprungen hat also keine Daten geliefert.

Next trial, so wie ursprünglich geplant, die Waveshare-Platine entfernt, statt dessen das CN3065-breakout auf die BOB-Platine gesetzt, an der große 5 W-Solarzelle den Hohlstecker abgeschnitten und statt dessen einen JST-Stecker gecrimt und angeschlossen.

Komisch, gleiches Verhalten wie mit der Waveshare-Platine. Die Spannung sinkt über 4 Stunden von 4,2 auf 3,9 V dann hört der FiPy auf Daten zu senden! Dann ist 15 Stunden Pause, nun werden nochmal drei Datensätze bei 2,5 V übertagen:

Mich würde jetzt brennend interessieren, warum der FiPy bei ca. 3,9 V aussteigt. Ist es tatsächlich die Spannung, oder eine Variable die überläuft? Es sind jeweils 4 Stunden 10 Minuten nachdem der FiPy “aufgibt”. Kann’s am watchdog liegen, der komisch konfiguriert ist / mit falschen Parametern? Ich habe die gleiche Software allerdings mit mehr Zeit zwischen den Messungen auf vier WiPys, allerdings mit USB-Stromversorgung, ohne Probleme laufen.

[edit] Nochmal die Software gecheckt und in der fraglichen settings.py ist der watchdog nicht aktivert und deep sleep ebenfalls nicht, vermutlich liegt es daran, gab doch schon mal Hinweise, dass es ohne deep sleep und watchdog irgendwann nicht mehr läuft.

Ist schon merkwürdig. Ist der Akku in Ordnung? Welche Firmware hast du drauf?
Wenn ich die maximale Deep Sleep Zeit richtig im Kopf habe waren das knapp 3 Std.
Passt also nicht zu den 10h.
Das einzige was mir dazu einfällt ist das sich der FiPy aufhängt und in einen Halbschlaf befindet. Also noch relativ viel Strom braucht. Die Spannung fällt dann ab bis der Lipo dicht macht. Bei den ersten Sonnenstrahlen steigt die Spannung Recht schnell an aber es reicht dann nur für ein paar Übertragungen. Bis der Lipo wieder dicht macht.

1 Like

Ich bin gerade dabei, eine Strommess-Platine zu entwerfen, um dann in einer USB-Stromversorgung ( 3.5 bis 5.5 V ) jede Sekunde Spannungen und Ströme zu messen. Gestern abend hat der MAX471 auf dem Prototypen schon funktioniert. Bis aber die Aufzeichnung läuft, dauert es noch ein paar Tage.

1 Like

Ja das ist sicher das, was @clemens brauchen könnte. Eine Überwachung, der Spannungsversorgung des FiPy außerhalb seiner eigenen Möglichkeiten.

Finde den Stromverbrauch des Fipy, sogar noch wichtiger zu testen, als die Solarmodule. Was bringt mir genau zu wissen, wie viel mAh ich mit Modul xy am Tag rein bekomme, wenn ich nicht genau weiß wie viel ich jetzt wirklich benötige.

Im Pycom Form steht auch irgendwo, das der FiPy Probleme mit dem Runterfahren in den Deep Sleep bei unter 4V haben kann. Soweit ich mich entsinne war das aber nur im Zusammenhang mit einem höheren Stromverbrauch im Deep sleep.
Ich hatte schon versucht, das zu simulieren, könnte, aber bei mir, keine Probleme bis runter auf 2,5V feststellen. Das war aber soweit ich mich entsinne noch mit V0.4.0

Es waren zwei verschiedene LiPos, daran sollte es nicht liegen, die Software ist die hiveeyes, release 0.6.0.

Versuche jetzt herauszufinden, ob es an dem FiPy (vs. WiPy) oder an der Solarzelle liegt und beides nacheinander tauschen.

[edit] Wie oben gerade nachgebessert war der watchdog nicht aktivert und deep sleep ebenfalls nicht, nun mit beidem aktiviert nochmal testen!

ehrlichgesagt finde ich 3.9 nicht verwunderlich.

das ‘datenblatt’ (der schmierzettel als pdf von pycom) schreibt 3.5-5.5V.

ehrlichgesagt glaube ich das nicht, da erfahrungsgemaess lineare spannungsregler sehr oft nicht ideale, theoretische werte sondern reale werte haben… also nicht 0.2V drop, sondern eher 0.7-1.1V
der esp32 will 3.3V haben, ich wuerde also mindestens 3.9V fuer stabilen betrieb vorhalten wollen.

wenn das aus einen lithium-chemie basierten akku mir nur einer zelle (3.x-4.xV) laufen soll kommt man m.e. ohne einen step-up wandler nirgendshin.

das ist der grund warum fast all diese solarsysteme mindestens 12V machen…
selbst schottky dioden haben nicht theoretische 0.1V sondern schnell mal 0.3-0.4V drop. diese spannungsoffsets sind begruendet in der physik von halbleitern und gehn soschnell nicht weg.
daher ist es deutlich einfacher mit hoeheren spannungen zu arbeiten und nur ganz am ende auf z.b. 3.3V zu regeln.

tldr: wie sie sehn sehn sie den unterschied zwischen datenblatt und realitaet ;)

ps: sicher das die 3.9V 3.9V sind? ich glaube nach all den adc-fnord auf der platform jedem china multimeter mehr als diesem adc… mal nachmessen schadet nicht.

1 Like

This. Thanks!

Nun, mit aktiviertem deep sleep und watchdog, schaut es besser aus und das System läuft seit mehr als 24 h! Durch den reboot nach dem deep sleep haben wir allerdings “nur” alle 60 Sekunden Messwerte, siehe auch Diskussion über designierte Messfrequenz :

Die Messelektronik steht auf der Südseite des Hauses und da kommt erst ab Mittag Sonne hin, d.h. mit einem 1-minütigen Intervall, der 5 W-Solarzelle und dem 2000 mAh LiPo werden wir einen konstanten Solarbetrieb nicht hinbekommen, sondern müssten mit der Messfrequenz noch weiter runter, zumindest mit der aktuellen Software, die keine Daten zwischenspeichert.

1 Like

Meine Strommess-Platine läuft jetzt mit einem ACS712, MAX471, INA219 und einem USB-Tester. Die Messwerte des INA219 mit I2C ausgelesen scheinen am genauesten zu sein. Ich habe mal den FiPy mit Hiverize/FiPy, OLED-Display, BME280, HX711 und 5 x DS18B20 gemessen:


nach ca. 1 min habe ich den FiPy eingesteckt, er hat gebootet und alle 10 sec gemessen und gesendet. Dann habe ich ca. 20 sec den Reset-Knopf gedrückt. Aufgezeichnet wurden Spannung, Strom und Leistung, die zwischen 0.9 und 1.0 Watt schwankt. Man beachte, dass auch die Spannungsversorgung eines guten USB-Netzteils mit 2.5 Ampere nicht sehr stabil ist

Heute habe ich den FiPy mit dem LiIon-Akku 2000 mAh von Eckstein betrieben. Er lief fast 10 Stunden bis der Akku schwach wurde. Hier die Entladekurve


Um 16 Uhr gab es einen Aussetzer, der mit einem Reset behoben wurde. Es wurden regelmässig Daten bis 21:56 übertragen, dann immer unregelmässiger. Bei 2,5 V um 22:23 habe ich abgebrochen.
Die verbrauchte Leistung ist stark von der Versorgungsspannung abhängig:
bei 5.2 V ca 0.9 bis 1.0 W
bei 3.8 V ca. 0.8 bis 0.9 W
bei 3.1 V ca. 0.7 W

Die Details:


Um 15:38 hing sich der FiPy auf: es wird nicht mehr gemessen, es werden keine Daten gesendet, der Stromverbrauch bleibt. Um 16:15 ein manueller Reset von einigen Sekunden.


Um 21:31 scheint der FiPy bei ca 3 Volt in einen leistungsärmeren Modus gegangen zu sein, er hat aber bis 21:56 gesendet. Unter 3 Volt läuft nicht mehr viel, bis ich bei 2.5V abgebrochen habe.
Danach hat sich die Spannung des Akkus rasch erholt, er ist aber trotzdem leer.
Man kann also nicht nur aus der Spannung den Status des Akkus ermitteln.

1 Like

Hi Didi,

vielen Dank für Deine Meßreihe. Mit entsprechenden Stromsparmechanismen, die wir uns bei Strom sparen beim Einsatz der MicroPython-Firmware im Batteriebetrieb erarbeitet hatten, sind wir auf ca. 40 Stunden Betriebszeit gekommen.

Vielleicht könntest Du mit den Optionen “Deep Sleep” und “Watchdog” auch noch einmal einen Versuch wagen, damit wir die Meßergebnisse besser vergleichen und ggf. überprüfen könnten.

Viele Grüße,
Andreas.

Das sind die nächsten Schritte

1 Like

Hi Didi,

Achso – erstmal im Trockendock – soweit klar.

Für den Echtbetrieb zusammen mit der Firmware hat @roh hier [1] vor kurzem schon den Treiber für die INA eingebunden. Da fehlt aber natürlich noch entsprechender Code zur Ansteuerung.

Ist das die Richtung, die Du anstrebst, den INA-Treiber in die Firmware zu integrieren, um damit Messungen veranstalten zu können? Sag gern Bescheid, falls Du dabei Unterstützung benötigst.

Viele Grüße,
Andreas.

[1] add ina219 driver from https://github.com/chrisb2/pyb_ina219 · rohlan/hiveeyes-micropython-firmware@71a5a1c · GitHub