ESPuino schaltet vor Erreichen der Critical Voltage aus

Bugreports / Fehlersuche
1

Die Euphorie über den ersten Build hält noch an, der ESPuino läuft seit einer Weile. Heute Abend habe ich erstmals spontanes Ausschalten gehabt, sowohl im BT- als auch im WLAN-Modus. Aber nur im reinen Akku-Betrieb. Spannung war mindestens bei 3.07V, (wobei die Akkuspannung eine Differenz von 0,11V zur Spannung auf der Platine hat, welche ich nach dem Vorgehen in dem Thread gemessen habe).

Ich habe dann #define SHUTDOWN_ON_BAT_CRITICAL wieder aus der settings.h auskommentiert und seitdem läuft es. Scheint also etwas damit zu tun zu haben. Die Critical Voltage liegt bei 3.00V, wurde also eigentlich noch nicht erreicht.

Jetzt möchte ich gern auf Fehlersuche gehen, weiß aber nicht, wie. Serial Monitor läuft nur mit USB-Verbindung und der Log auf der Website ist Session-spezifisch. Habt ihr eine Idee, wie ich an eine Fehlermeldung ran komme (oder vielleicht sogar, woran das Verhalten liegt)?

2

Schau mal ob der richtige Wert gesetzt ist. Es kann sein, dass ein alter Wert in die Preferences geschrieben wurde und Änderungen in der settings.h gar nichts bewirken. Das ist leider noch nicht im Web-frontend einstellbar.

3

Der Analogeingang ESP32 ist halt einfach kein Präzisionsinstrument. So 100 % genau ist das nie.
Die Frage ist aus meiner Sicht, was man sich von SHUTDOWN_ON_BAT_CRITICAL erwartet. So lange man keinen Schaltregler verwendet, wird die Spannung irgendwann unter einen Punkt fallen, wo der ESP32 nicht mehr „anständig“ arbeitet. Hier kann es passieren, dass manche Dinge nicht wie vorgesehen funktionieren. Wenn man jetzt sagt, dass man solch mehr oder weniger undefinierte Zustände vermeiden möchte, dann kann man das benutzen.
Davon ab ist es jedoch so, dass sich das Gesamtsystem selbst limitiert: D.h. die Spannung ist irgendwann zu niedrig und denn läuft der ESP32 eh nicht mehr. Sicherlich wird aber auch noch dann ein kleiner Ruhestrom fließen. Ein Hardware-Schutz für den Akku kann SHUTDOWN_ON_BAT_CRITICAL also nicht sein. Hierfür braucht es das BMS des Akkus, der das Ganze vor weiterer Tiefentladung schützt.

Anders sieht es bei einem Schaltregler aus: Da kann die Spannung extrem niedrig absinken und man kriegt es gar nicht mit, weil der ESP32 noch normal arbeitet. Hier braucht’s aus meiner Sicht einen Hardware-Schutz. Für die Complete, welche leider (weiterhin) noch nicht fertig ist, habe ich das verwendet. Das Problem ist jedoch, dass kurze Spannungseinbrüche das Monitoring sofort dazu veranlassen, hinten ein LOW auszugeben. Also da reicht’s schon, wenn USB + Akku angeschlossen sind und der Akku aber nur so halb voll. Dann ziehst du USB ab und dann schaltet’s den ganzen ESPuino aus. Also grundsätzlich funktioniert die Platine, aber mit solchen Sachen habe ich noch Probleme. Da bin ich immer mal wieder am Rumexperimentieren.

2 „Gefällt mir“
4

Danke für die schnellen Rückmeldungen.

Wenn irgendwo ein Wert von 3.1V hinterlegt ist, würde das die Ausfälle beschreiben. Ich kann aber leider die richtige Stelle außerhalb der settings.h nicht finden, in denen ich die Preferences nachschauen kann. Kannst du mir das noch etwas genauer erklären bitte?

Das ist eine sicher berechtigte Frage. Dass das ganze nicht zuverlässig genau funktioniert war vorher schon gut beschrieben und mir auch klar. In der Anwendung habe ich dann erst gesehen, was das genau bedeutet: Unsicherheiten von bis zu 0,05V je Messung (kurzer empirischer Test). Das erläutert dann auch, warum der ESPuino ausging, sofern irgendwo noch die 3.1V hinterlegt sind.

Da es das erste Mikrocontroller-Projekt für mich ist bin ich gedanklich wohl noch dabei, dass ein harter Shutdown zu Datenverlust führen bzw. auf Dauer die SD-Karte schädigen kann. Wenn das hier aber hardwarebedingt nicht relevant ist werde ich auch ohne das Feature gut klarkommen.

5

Sollte beim Start eigentlich geloggt werden:

Zu dem Feature im Allgemeinen:
Ein Hardware-Schutz ist es natürlich nicht. Eher eine Art vorbeugende Akkupflege. Denn immer erst am absoluten Limit des Akkus auszuschalten ist bestimmt auch nicht ideal.
So kann man ein paar Tage gewinnen, in denen der ESPuino „leer“ aber nicht tiefentladen ist. Das ist in der Regel ausreichend.

Ich finde es aber primär sinnvoll, um undefinierte Zustände jeder Art zu vermeiden. Das kann ja von korrupten SD-Karten über Audio-Fehler bis zu geänderten Konfigurationen durch Brownout gehen.
Man muss auch bedenken, dass ja einige Komponenten schon mit 3.3V außerhalb der vorgesehenen 5V laufen. Dann gibt es Streuung, das heißt nicht jedes BMS oder sonstige Elektronik verhält sich exakt gleich.

Klar, wenn man das am laufen hat und auf Dauer keine Probleme dieser Art feststellt, kann man es theoretisch auch weglassen.

ZL;NG: Ich finde es sinnvoll für ein ruhiges Gewissen, kann i.d.R. aber auch weggelassen werden.

2 „Gefällt mir“
6

Tatsächlich habe ich im (Websrver)Log folgende Einträge:

I [158] Unterer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 3.00V
I [159] Oberer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 3.30V
I [172] Spannungslevel (Batterie) fuer Niedrig-Warnung via Neopixel aus NVS geladen: 3.10V
I [184] Spannungslevel (Batterie) fuer Kritisch-Warnung via Neopixel aus NVS geladen: 3.10V

In den settings.h sieht das aber so aus:

constexpr float s_warningLowVoltage = 3.1;                      
constexpr float s_warningCriticalVoltage = 3.0;                 
constexpr float s_voltageIndicatorLow = 3.0;
constexpr float s_voltageIndicatorHigh = 3.3;

Deine Vermutung trifft also zu. Hilft hier dann evt. ein Erase Flash und ein neuer Versuch? Oder gibt es da andere Wege?

7

Am einfachsten wäre es für’s erste,

gPrefsSettings.getFloat("wCritVoltage", 999.99);

durch 999.99 zu ersetzen. Damit wird der NVS Wert immer ignoriert.

1 „Gefällt mir“
8

Habe gerade einen Erase Flash gemacht und mit den neuen Werten für CriticalVoltae gesetzt und jetzt passt es :+1:
Vielen Dank für die schnelle Hilfe und ein paar schöne Feiertage an alle!

9

Das Thema ist schon länger offen, vielleicht hat jemand Lust & Zeit etwas dazu beizutragen: