Logisch. Und gefährlich.
Was ist wenn das falsch eingestellt oder aus Versehen verstellt wird?
Lötbrücken statt dipswitch?
Lötbrücken sind unpraktisch. Das Übertragungsprotokoll, dass mir vorschwebt würde es erkennen, wenn es zwei identische IDs gibt und dann keinen Lade- und Entladestrom zulassen (über CAN). Außerdem kann man im Pylontech-Protokoll, welches ich nutzen möchte, verschiedene Warnungen und Fehler ausgeben. Da muss ich mich aber noch reinlesen.
Der DIP-Schalter wird auch nur einmal beim Reset eingelesen.
PCBs sind bestellt.
So, mal ein Update:
Die PCBs sind da und 11 davon bereits bestückt:
Damit ich nur ein Netzteil brauche, sind die für die Entwicklung alle parallel geschaltet.
Die Infrarot-Übertragung läuft, ist CRC gesichert und erlaubt ein Update pro Sekunde.
Die Gegenseite ist ein ESP32-C6 mit CAN und INA238 für Strom- und Gesamtspannungsmessung. Das ist noch frei verdrahtet, da gibt es noch kein PCB dazu.
Auf dem ESP32 habe ich inzwischen CAN und Infrarot am laufen und kann über den Webserver konfigurieren und auch den aktuellen BMS-Status anschauen:
Nicht von der großen Zahl der RX-Errors stören lassen, passiert entwicklungsbegleitend, wenn man die Zellmodule zeitweise nicht mit Strom versorgt hat
Was deutlich schlechter ist, als erwartet: Die Genauigkeit der Zellspannungsmessung. Ich habe zwar eine Referenz verwendet, die nur ±2,5mV Fehler verursacht, dabei aber übersehen, dass der 12-Bit-ADC des ATTiny typisch 10 LSB Fehler hat (Im Wesentlichen Offset). Ein Max-Wert ist nichtmal angegeben.
Also muss ich jedes Modul abgleichen. Eventuell ist bei LFP auch ein automatischer Abgleich möglich, denn im Bereich zwischen 70% und 90% SOC ist die Kennlinie so flach, dass die Zellspannungen im Prinzip identisch sind, solange kaum Strom fließt.
Außerdem habe ich die falschen Poly-Fuses bestellt. Mouser ist echt fies, deren Suchmaschine zeigt teils ähnliche Teile an, wenn das gesuchte Teil nicht im Katalog ist. Wenn man dem Suchergebnis glaubt und das Suchergebnis direkt in den Warenkorb kippt, dann kommt halt nichs, was man eigentlich haben wollte. Aktuell kann ich deshalb nur mit 500mA balancen, sonst lösen die aus. Deshalb ist auf dem Bild die Fuse auch noch nicht bestückt.
Der Elko da hinten hängt dran, weil die ATTinys sonst einen Brownout-Reset machen, wenn der Balancer angeht. Hab relativ wenig Kapazität auf den Modulen, weil die Akku-Zelle ja direkt drunter ist. Mit in Summe 2m Anschlusskabel zum Netzteil funktioniert das dann auch nicht mehr.
Nächste Schritte:
- Die eigentlich BMS-Funktionalität implementieren, also Vorgabe von Ladespannung, Ladestrom, Fehlerhandling, ...
- PCB-Design für das Haupt-Modul machen
2 „Gefällt mir“
Frohe Weihnachten!
Wie ich sehe, hast Du ein nettes Weihnachtsgeschenk bekommen
Wie immer bei der Schaltungsentwicklung. Kaum liegt das erst physische Sample auf dem Tisch und wird getestet, tauchen die ganzen Überraschungen auf, die im Datenblatt gut versteckt waren.
Also falls dieser ADC-Offsetfehler immer für einen Chip fix ist, d.h.
- nicht von der Versorgungsspannung abhängt
- nicht von der Temperatur abhängt
- und auch nicht anderweitig über Monate oder Jahre herumdriftet,
dann sollte man das durch einmalige, individuelle Kalibration eines Boards erschlagen können. Wenn das Board durch die am Mäuseklavier eingestellte Adresse weiß, welches es ist, dann kann man ja alle 16 Korrekturparameter in die selbe Firmware packen und das jeweilige Board pickt sich dann die Passende heraus.
Bin gespannt, wie es weitergeht!
Wenn Du in meinem letzten Post in das Bild mit den Settings reinschaust, siehst Du, dass ich schon eine Kalibriermöglichkeit für jede Zelle vorgesehen habe. Ich mache das nicht auf dem Zellmodul sondern im Hauptmodul. Im Zellmodul möchte ich die Software einfach und vor allem für jedes Modul identisch halten.
Das ermöglicht auch, jederzeit ein defektes Modul austauschen und den Offset-Abgleich sehr leicht nachziehen zu können.
Der Fehler ist ganz leicht von der Versorgungsspannung abhängig, zwischen 2,8 und 3,6V driften die Module so ±3mV gegeneinander hin- und her. Das ist völlig akzeptabel.
Ein Modul habe ich gerade mal mit Eisspray behandelt, das macht bei -20°C vs. +22°C ca. 3mV Fehler. Auch akzeptabel.
Langzeitdrift ist die große Unbekannte.
Ich hatte das Konzept zwischendurch auch für ein berufliches Projekt erwogen, weil Kabelbaum ein echter Kostenfaktor wegen ist. Zumindest mit der nicht wirklich spezifizierten Genauigkeit des ATTinys ist das aber ein Showstopper für ein Serienprodukt. STM32 gehen nur bis 3,6V. Nach anderen Alternativen habe ich noch nicht geschaut.
Michael
Die RL78 Serie von Renesas kann 1,6 - 5,5 V Supply Voltage und ist wirklich billig, würde also in dem Sinne passen. Ich habe von denen mal ein RL78 G22 Eval Board gratis bekommen.
Beim Anblick von deren Entwicklungsumgebung (e² Studio) wäre mir dann aber beinahe das Ko***n gekommen. Erst 1 GB Linux-Version heruntergeladen und installiert, um dann vom Support gesagt zu bekommen, dass da die Toolchain nicht implementiert ist, dann 1 GB für die Windows-Version heruntergeladen. Die war lauffähig, aber naja, wirklich anfreunden konnte ich mich damit nicht. Seither liegt das Board im Keller.
Falls Du mit dem Eval Board mal spielen magst, kann ich es Dir gerne ausleihen.
Ein anderer Rechner kommt hier für mein Privatprojekt nicht mehr in Frage. Es geht ja auch mit dem ATTiny.
Trotzdem habe ich mal bei den RL78 geschaut. Die ganz günstigen 8-Bitter haben nur 10 Bit ADCs.
Die nächsten mit 12-Bit ADCs gehen wieder nur bis 3,6V Vcc.
Bin grad am Überlegen, ob der ADC-Fehler-Abgleich nicht sogar automatisch mit der aktuellen Hardware geht.
Der ATTiny hat einen integrierten 8-Bit-DAC, leider mit nicht spezifizierter Genauigkeit.
Den könnte ich auf z.B. auf 2 LSB setzen. Der ADC müssten dann 32 LSB messen. Die Abweichung davon wäre im Wesentlichen der Offset-Fehler.
Alternativ:
Ich gebe auf PA7 als PushPull-Ausgang einmal Low und einmal High aus und messe mit dem ADC beide Pegel. Auch daraus kann ich einen Offset-Fehler ermitteln.
Da das aber alles sehr schlecht spezifiziert ist, bleibt nur ausprobieren, ob die Abweichung zwischen den 16 Zell-Module damit besser wird oder ob die Offset-Fehler des DACs oder der IOs größer sind als die des ADCs.
DAC ist eher ungenau bei paar bits nahe Null oder VCC. Kannst du einen Abgleich versuchen bei DAC etwa 1/4 und 3/4 VCC?
Falls du die Hardware noch mal anfasst: Bei vielen Geräten insbesondere batteriebetriebenen finde ich eine Tasten- und Schalterauswertung etwa in dieser Art:
/EN ist uC-Ausgang und wird nur zum einlesen auf low gezogen. Bei manchen uC geht das sogar ohne R5 (aber gegen GND), indem der Eingang den low current pullup für Digitaleingang aktiviert
Da ich die Bauteilanzahl minimal halten wollte (ich muss das 16mal von Hand löten), habe ich das so nicht gemacht, weil die IOs ja da waren und ich mit der aktuellen Lösung auch keine Nachteile gesehen habe.
Aber ja, so kann man das natürlich auch machen, um IOs zu sparen.
Im Übrigen: So ein Zell-Modul benötigt im Real-Betrieb im Mittel ca. 1,5-1,8mA, wenn es 1 Mal pro Sekunde sendet.
Das dürfte niedriger sein, als die Selbstentladung der Zellen, also völlig irrelevant.
Den µC betreibe ich dabei mit 2,5MHz.
1 „Gefällt mir“
Die Software des Haupt-Moduls nähert sich dem Ende. Es wird also Zeit, einen Schaltplan und ein PCB zu machen. Erster Entwurf:
Der Servo-Ausgang steuert ein Modellbauservo, welches mechanisch den Sicherungsautomaten auslösen soll, wenn einstellbare Grenzen von Zellspannung, Strom oder Temperatur gerissen werden.
Display ist aktuell nicht vorgesehen.
Das ESP32-Modul hat noch einen USB-C-Port, der zum Flashen dient.
Ich könnte die freien Ports des ESP32 mit LEDs bestücken. Oder habt Ihr noch Ideen, was man damit machen könnte?
Über konstruktive Kritik würde ich mich freuen.
So,
Schaltplan und Layout sind fertig, PCB wird demnächst bestellt:
Und hier noch die Settings, die geplant und zum größten Teil auch schon umgesetzt sind:
2 „Gefällt mir“
Mal wieder ein Update.
Das Hauptmodul ist inzwischen fertig und läuft.
Bin gerade dabei, das BMS an die Batterie anzubauen.
Aktuell habe ich schon 2 Zellmodule dran und will das mal ein paar Tage beobachten, ob das passt, weil ich nicht nachher an der Batterie 16 FW-Updates machen möchte.
So sahs Montag aus:
Inzwischen ist auch der Shunt (rechts) angeschlossen und das BMS zählt fleißig Ladung. Versorgung aktuell noch über USB, später dann über 48V. CAN funktioniert zwar, ist aber noch nicht an den Multiplus angebunden.
Wer das BMS live in Aktion sehen möchte: Ich habe den BMS-Webserver gespiegelt im Netz:
Das sieht zwar so aus, als könntet Ihr was verstellen, ist aber nicht so, es gibt keinen Weg aus dem Netz zurück zum BMS. Die Settings, die Ihr seht, sind nicht, die die tatsächlich konfiguriert sind, die Settings spiegle ich nichts ins Netz.