Ich konnte den Fehler selbst nicht mehr reproduzieren. Auch bei 3V läuft gerade noch alles. Ich habe versucht mit einem externen USB-UART Adapter im Akkubetrieb zu debuggen, der auf dem Devboard zieht aber alles auf GND, daher klappt das nicht. Wenn irgendjemand mal eine 3V Versorgung und ESP32 ohne UART hat kann man das vielleicht genauer untersuchen, aber ich lass es jetzt mal auf sich beruhen.
Dass der PN5180 sporadisch aufwacht ist ja normal, passiert bei mir zumindest auch unter Normalbedingungen. Jedenfalls läuft im Moment auch bei 2.97V noch alles.
Ich versuche gerade verzweifelt, den MAX17055 mit meinem ESP32-S3 zum Laufen zu bekommen.
Solange ich das ganze via USB verkabelt habe, erhalte ich relativ vernünftige Werte in der Konsole.
Aber sobald ich das Kabel entferne - spätestens wenn ich den ESP vom Strom trenne und nur mit Batterie starte - erhalte ich nur Unsinn in der Webgui, etwa in der Art:
I [130067] Aktuelle Batteriespannung: 5.12 V
I [130074] Aktuelle Batterieladung: 256.00 %
I [130081] Stromverbrauch (Batterie): -0.16 mA
I [130088] Temperatur der Batterie: 256.00°C
I [130095] Gesehene Batteriezyklen: 655.35
D [130101] Battery percentage reading invalid, try again.
Drücke ich Button 3 für CMD_MEASUREBATTERY stürzt die Kiste ab und bootet neu.
Hat da jemand eine Idee?
Die Werte sehen mir sehr nach einer falschen Verdrahtung aus. Wenn nichts angeschlossen ist, wie verändern sich diese Werte? Sind I2C Pullups verbaut?
Ich muss aber auch dazu sagen, dass ich vom MAX17055 ziemlich enttäuscht bin. Das Messen des Stroms über Zeit funktioniert zwar ganz gut, aber für den Ladestand ist die Messung nicht so perfekt.
So was wie ein Lerneffekt scheint sich auch nicht einzustellen, obwohl alles wie in der Dokumentation implementiert sein sollte.
Ich hatte ursprünglich gehofft, dass entweder günstige LFP fuel gauges von Adafruit o.ä. erscheinen und verwendet werden können oder der MAX17055 sich gut etabliert und Unterstützung findet. Leider ist beides nicht passiert, ich nehme an LFP Batterien sind im Maker-Bereich einfach eine zu kleine Nische…
Ich selbst werde keinen Max17055 mehr verwenden - zu viel Ärger. Ich bin weiterhin davon überzeugt, den Code modular und für andere Messmethoden offen zu halten, aber dass der Max17055 die Zukunft ist, glaube ich nicht.
Trotzdem, so lange der code in ESPuino ist, bin ich bereit Fehler zu beheben und Verbesserungen anzusehen, aber der Chip ist eben auch eine „Black Box“.
Danke für die Antwort, scheinbar war tatsächlich meine Kelvin-Verbindung irgendwie gebrückt, nachdem ich da einen falschen Widerstand per Hand geändert hatte… Ich hab ein neues Board bestückt und damit funktioniert es jetzt auch.
Evtl. werde ich aber für die nächste Revision auch wieder die traditionelle Spannungsmessung als Alternative implementieren, falls mir der MAX im Langzeittest nicht gefallen sollte.
Tatsächlich habe ich mich demletzt schon gefragt, ob den MAX17055 überhaupt jmd. benutzt. Weil wenn nein, und wenn er offenbar eh eher Probleme macht, sollte man drüber nachdenken, den Support zu entfernen.