Ich hab noch eine Frage zur Anzeige des Akku-Status mit dem LED-Ring.
Hier wird batteryLow und batteryCritical zwar abgefragt, aber nicht zur Farbauswahl verwendet. Dort wird dann „fest“ auf <0.3 / < 0.6 reagiert. Sollten wir da nicht batteryLow und batteryCritical verwenden? Dann kann das jeweilige Modul entscheiden was Critical und Low ist.
Hatte ich auch in meiner ersten Version, aber damit sind die Grenzen ziemlich weit unten definiert. Wenn man z.B. bei kritischem Ladezustand herunterfahren würde gäbe es nie eine rote Anzeige.
Die PCBs sind angekommen. Ich teste gerade mit einem separatem Aufbau (ohne ESPuino).
@SZenglein wie hast Du denn „kalibriert“? Oder getestet?
Ich hatte leider einen Fehler im Test-Code, so dass die Parameter nicht gespeichert wurden.
Gestern war war der Akku lt max17055 bei 100%, das Ladeboard hat aber noch nicht abgeschaltet. Heute morgen nun 0% (Parameter nicht gespeichert / Akku abgezogen / obwohl der Akku vermutlich 80-90% hat). Fängt sich der wieder? Oder muss ich jetzt einmal komplett leer / voll abwarten?
Verwendest du den Code vom ESPuino oder hast du dir ein eigenes Testprojekt geschrieben?
Die Fuelgauge lernt über dir Zeit und wird dadurch genauer. Bei mir kommt es leider auch vor dass der Ladestand nach Stromverlust extrem falsch ist.
Daher sollen die gelernten Werte regelmäßig gespeichert werden und wenn ein Stromverlust festgestellt wurde werden diese wiederhergestellt.
Wichtig ist natürlich auch dass du die Ladespannung, Batteriechemie, etc. richtig angibst.
Zusätzlich hat der Chip eigentlich das Feature so lange auf 99% zu verbleiben bis er die Ladeendbedingung erkennt (Stromfluss in Batterie, Spannung). Analog für die untere Spannungsgrenze.
Ich verwende Deinen Code. Hab die BatteryMax17055 übernommen.
Deshalb hatte ich auch die Hoffnung, dass ich weniger anpassen muss. Ich hab auch alle Defaults von Dir übernommen (6 Ah LiFePo4).
Das Abspeichern der gelernten Parameter, die Abfrage nach Stromverlust usw. habe ich ebenfalls alles übernommen.
Der Test-Code fragt die Parameter jede Sekunde ab und zeigt sie auf einem Display an.
Irgendetwas passt dann nicht. Muss mir das noch einmal in Ruhe ansehen.
Danke erst einmal!
Ja, das hört sich stark so an als wäre noch irgendwo ein Fehler. 0% sollte er wirklich nur anzeigen wenn die Spannung unter den Grenzwert fällt. Was gibt denn die Konsole als Spannung aus?
Generell wird beim initialisieren auch ein Teil der Konfiguration ausgegeben, vielleicht überprüfen ob das richtig geschrieben wird.
Hast du entsprechende Pullup-Widerstände für I2C bzw. werden alle Werte korrekt gelesen und geschrieben?
Hatte ich nicht in dem Test-Aufbau - Danke für den Hinweis.
Ich habe noch zwei weitere Fehler korrigiert und nun sieht es deutlich besser aus.
Was mir bei den Tests jetzt sehr stark auffällt:
Ich versuche natürlich den Akku möglichst schnell zu laden / entladen.
Auf welche Werte kommt ihr dabei?
Laden: Mit dem TP5000 / CN3058 lande ich sehr schnell bei <=300 mA. Beide ICs sollten (entsprechende Widerstände auf dem Board) mit max 1A laden. Bei einem 6Ah Akku dauert das Laden somit ewig…
Entladen: Sobald ich > 500mA Last erzeuge, geht die Spannung deutlich runter. So stark, dass der ESP32 sich rebootet.
Ist das bei Euch auch so?
Setzt ihr noch zusätzliche Buck / Boost Komponenten ein?
Ich habe hier ja einen (nicht von mir entwickelten) Complete-Prototyp da, der zwar keinen MAX17055 hat, jedoch einen TP5000 samt STBB1-APUR als BBC. Ich weiß es nicht mehr ganz exakt, aber ich meine da ist der Ladestrom auf 1,2 A eingestellt und die Versorgung des Restes kommt on top. Also irgendwie sowas wie 1,3x A insgesamt (via USB-C). Das funktioniert auf jeden Fall ordentlich.
Ist halt nice, dass da hinten immer 3.3 V rauskommen, egal ob du vorne mit nem LiPo oder mit nem FePo reingehst.
Wobei ich sagen muss, dass ich 1,2 A nicht unbedingt haben müsste. Also der D32 pro lädt ja über den TP4054 mit 500 mA und das reicht für meine Zwecke auf jeden Fall aus. Die ESPuinos meiner Kinder haben LiPos mit 2500 mAh. Ich habe da kein Problem mit, wenn das mehrere Stunden dauert, bis das Teil voll ist.
Aber gut: Haben ist besser als brauchen 
.
Bei mir lädt der TP5000 mit ziemlich exakt den eingestellten 1000mA. Könnte schneller sein, bei 6Ah dauert das 6h, aber ich denke damit kann man leben.
Ja, da ist man dann irgendwie wieder bei einem „Power-Board“.
Irgendwo ist aber bei mir immer noch der Wurm drin. Ich muss mal den Ladestrom in den Griff bekommen - Hab ein neues TP5000 Modul bestellt.
Ich könnte das , ja 
@Christian, @SZenglein ihr habt ja schon ein bisschen mit FePo gearbeitet. Seht ihr eigentlich einen großen Vorteil, einen STBB1-APUR zu haben? Also eigentlich hat das ja nur Benefit, wenn nach Abzug der Drop-Voltage vom LDO (z.B. ME6211) weniger als 3.3 V hinten rauskommen.
Also im Endeffekt gewinnt man damit sicherlich „unten raus“ Kapazität, die Frage ist nur, wieviel das ist.
Habt ihr da ne Vorstellung/Meinung zu?
Ja das ist schon sinnvoll denke ich. Der ESP läuft bis weit unter 3V weiter und kann auch die maximalen 3.6V ab, man kommt also komplett ohne LDO aus. Auch Neopixel/Verstärker/SD haben bei mir keine Probleme gemacht.
Aber trotzdem ist es besser eine konstante Spannung zu haben. Ich nehme an die Lautstärke variiert bei schwankender Spannung, keine Ahnung wie die Leistung vom RFID abnimmt, und generell ist es konsistenter.
Es lag am Ende an billigen Steckverbindungen. Ausgetauscht gegen vernünftige Kabel und Stecker ist der Ladestrom nun wie erwartet.
Die PCBs sehen nun so aus.
Klappt das bei Dir gut? Ich teste gerade noch recht viel und lade / entlade den Akku.
Ich habe festgestellt, dass eine Wiederherstellung der Parameter die Ergebnisse verschlechtert. Es werden ja auch „nur“ die Akku-Parameter zurückgesichert.
Beispiel:
Da könnte man auf die Wiederherstellung verzichten.
Ist das bei Dir auch so, oder hab’ ich noch irgendwo einen Fehler?
Weißt Du, ob man nicht auch den soc und „Verbrauch“ wiederherstellen könnte?
Es könnte tatsächlich sein dass die Werte falsch gespeichert werden, muss ich nochmal schauen ob die vorher und nachher das gleiche in den Registern steht.
Ich hab da um ehrlich zu sein nicht so genau verglichen, aber am Anfang liegt er tatsächlich oft etwas daneben, ich dachte aber das ist normal.
Ich hatte demletzt auch den Fehler dass der chip sich nicht auf 0 kalibriert hat, da ich schon bei 5% ausschalte. Laut Marketing braucht die Fuel Gauge keine 0% um zu kalibrieren, vor allem mit gespeicherten Werten erwarte ich das nicht.
Das hängt bestimmt damit zusammen; Ich kann mir vorstellen dass das Speichern der gelernten Werte falsch implementiert ist. Das musste ich selbst implementieren.
Vielleicht ist die Speicher-Sache Mist und man sollte das rauswerfen egal was der Hersteller sagt.
PS: die Platine gefällt mir!
Habe hier gerade ein kleines Problem mit dem PN5180 festgestellt. Und zwar wacht der ESP32 im LPCD-Modus immer direkt auf, wenn die Spannung zu niedrig ist (z.B. 3.1V). Führt dazu, dass die Batterie auch im ausgeschalteten Zustand recht schnell leer ist, da die Aufwachschleife nie aufhört.
Hast du ausmachen können, woran das liegt?
Feuert der PN5180 bei diesem Spannungslevel dann immer wieder IRQs?
Leider nicht. Aber den IRQ Pin habe ich mal gezogen und der ESP32 ist trotzdem aufgewacht. Ich habe die Funktion dass bei fake wakeups ausgeschaltet wird deaktiviert.
Ist leider schwierig zu debuggen, da ich nicht gleichzeitig USB anschließen kann. Wobei, gerade fällt mir ein dass ich ja direkt an RX-TX gehen kann ohne das Devboard. Muss ich eventuell noch probieren.
Falls du den D32 pro verwenden solltest: Der hat ja auf IO5 eine Led. Wenn man vom IO, der die Interrupts vom PN5180 empfängt, dahin eine Brücke lötet, dann kann man die IRQs gut sehen, die der PN5180 feuert. Das wäre so die einfachste Variante.
Ich könnte mir gut vorstellen das der PN5180 instabil wird unterhalb der 3,3V Spannung und sporadisch Aufwach-IRQ’s schickt. Wie wäre es vor dem Schlafenlegen die Batteriespannung abzufragen und LPCD nur aktivieren wenn die noch im Normbereich liegt?