AHED_BMS: Nutzerfeedback & Musteranfragen

Wiedermal Danke für Dein ausführliches Feedback.

Ich stimme zu, dass für eine richtige Serie das idealerweise alles so vorbereitet/beigelegt sein sollte, dass man außer Wrkzeug kein weiteres Material mehr benötigt.

Mir fällt auf, dass die Zelltemperaturen insbesondere im ersten Screenshot mit 3.5 °C eine ziemlich große Spreizung haben. Ist das plausibel?
FYI: Offsets der Sensoren kannst Du unter Settings bei Bedarf auch korrigieren.

Bis auf das Erreichen der 5 mV zu warten, hätte vorwiegend den Grund, dass man dann einen sehr genauen Referenzpunkt hat, z.B um nach einiger Zeit möglichst präzise den Unterschied in Selbstentladung bzw. Coulomb-Effizienz der Zellen zu bestimmen.
Da Deine Zellen bei Lieferung aber gerade mal ~ 0.8 Ah Ladestandunterschied hatten spricht viel dafür, dass das für Dich auf absehbare Zeit keine Relevanz hat.

PS: die Uhrzeit des BMS kann Du mit dem PC synchronisieren, wenn Du unter Settings in das Feld mit der Uhrzeit klickst.

So, jetzt komme ich auch zu antworten - viel zu tun bei einer Haussanierung.

Prinzipiell nehme ich, was ich bekommen kann.
Wenn ich es oben weiter richtig gelesen habe, ist die neue version noch in Arbeit.
Welche grundlegenden Unterschiede wuerde es denn in der neue Version geben?
Wann wuerde diese zur Verfuegung stehen und ist diese dann mit der aktuellen kompatibel?

Da stellt sich mir gerade die Frage, wie ich mehrere BMS - respektive Akku-Packs - an ein System anschliesse? (Ich nehme an, dass ein BMS pro Akku-Pack benoetigt wird)

Ich kann es leider noch nicht genau sagen, aber in ca. 2 Monaten sollten die Akkus da sein.
Bzgl. der Montage der PV-Module bin ich noch auf Dienstleistersuche und bis ich die Elektroinstallation soweit habe, werden auch noch einige Wochen vergehen.
Ich sage mal: Es waere gut, wenn ich die BMS mitte Juni habe.

Das sollte reichen!

Korrekt! Ich plane ein Cerbo GX zu verbauen.

Das mache ich gerne!

Eine Sache noch, da ich es bisher nicht gelesen habe: Wie sieht die Preisgestaltung aus?

Danke für die Hinweise.

Ein Temperatursensor ist an einem 35 mm2 Kabel angebracht und die Anderen muss ich auch noch richtig im Zwischenraum zwischen den Zellreihen anbringen. Daher vermutlich die Unterschiede.

Die neuere Version ist schon seit mehr als 6 Monaten im Einsatz, Ich habe im Moment aber nur noch HW davon hier ( > 10 Stück ) die rechtlich schon meinem Kunden gehört und ich möchte davon ungern kurzfristig eine Kleinstmenge nachfertigen. Ich denke bis HW aus einem größeren Fertigungslos zur Verfügugn steht wird es bestimmt Q3 sein. Kostenlose Muster plane ich von dieser HW aber nicht mehr.

Die neue HW hat im wesentlichen folgende Neuerungen:

  • < 100uA Deep Sleep ( hat eigentlich nur eine Relevanz, wenn man kleine ( < 100 Ah ) Batteriepacks über Monate per Seefracht verschickt oder einlagert)

- Anschluss um einen fernauslösbaren Sicherungsautomaten anzusteuern.

- nicht mehr die ungeschützte Steuerplatine Huckepack, sondern mit unter dem Kühlblech

- der MCU hat 8 Mbyte statt 4 Mbyte Speicher ( im Moment hat das im wesentlichen nur Einfluß auf die maximale Größe der internen Log-Datei )

- Die Stecker für die Zellanschlüsse sind nicht mehr 2mm PH, sondern 2.54 mm Stiftleisten.

- Es werden 4 statt 3 externe Temperatursensoren unterstützt

Ich benutze selber für meine Packs noch etwas ältere HW als die, von der ich hier Muster verteile. Deswegen ist die SW-Kompatibilität älterer HW zu der aktuellen und damit auch ein Mischbetrieb für die nächsten Jahre in jedem Fall sichergestellt.

Habe zuletzt mal 8 BMS aus mehreren HW Generation zusammen an einem CAN-Bus gehabt. Solange die FW auf halbwegs ähnlichem Stand ist, funktioniert das völlig unauffällig

Genau, jeder Pack ein BMS. Auf 48 V Schiene typischerweise alle parallel geschaltet.

Auf dem CAN Bus können bei meinem BMS theoretisch bis zu 16 zusammengeschaltet werden ( bis jetzt praktisch getestet bis 8 ). Ein BMS wird dabei zum Master ernannt und aggregiert dann die Daten aller Packs, so dass dem WR gegenüber eine große virtuelle Batterie präsentiert werden kann.

Ein Muster der etwas älteren Generation kannst Du kostenlos haben.

Planst Du beide Packs gleichzeitig in Betrieb zu nehmen?

Zukünftig ( bezogen auf die neuere HW ) wird ein Verkauf von Einzelstückzahlen an Privat wohl über einen Shop erfolgen. Der Preis hängt dann natürlich auch erheblich von deren Kondition ab, so dass ich da heute noch keine verbindliche Aussagen zu treffen kann.

In großen Stückzahlen ließe sich das BMS aber grundsätzlich zu Preisen vermarkten, die nicht dramatisch über einem JK oder Seplos liegen.

1 „Gefällt mir“

Danke für die Einordnung, das klingt plausibel.

@nimbus4

Mach doch für Angebote und Nachfragen (und Versionen) getrennte Fäden. Du hast doch eine eigene Kategorie bekommen.

Gute Idee. Muss ich mir demnächst mal etwas Zeit für nehmen, diesen Thread etwas zu sortieren.

Ah okay, dann ist das beim gestueckelten durchlesen der ganzen Beitraege hier unter gegangen.

Das sind im Grossen und Ganzen Neuerungen, welche fuer mich nicht von grosser Relevanz sind.
(Bis auf den zusaetzlichen Temperatursensor - je mehr Daten desto besser)

Das ist ein Design (vor allem der SW) welches sehr zu begruessen ist!

Wird der Master automatisch ausgehandelt oder per Hand festgelegt?
Die BMS und der WR haengen dann aber trotzdem alle am gleichen CAN Bus?

Wow, damit habe ich nicht gerechnet - vielen Dank schon mal im Voraus fuer das ‘Vertrauen’!

Ja, ich plane beide Packs gleichzeitig in Betrieb zu nehmen.
Ob ich die Packs nacheinander initial Top-balance oder ein anderes Vorgehen sinnvoller ist, kannst du mir gern mitteilen.

Das habe ich schon in Posts von dir mitgenommen.
Vollkommen verstaendlich, dass du dazu noch keine Aussagen treffen kannst!

Das ist schon mal eine gute Ankuendigung - auch wenn mir bewusst ist, dass ‘grosse Stueckzahlen’ da wahrscheinlich die Variable mit dem groessten Einfluss ist.

Mir stellt sich da noch eine Frage:
Wie handhabst du aktuelle und in Zukunft das Thema ‘quelloffene’ SW & HW?

Nein, der Master wird einmalig manuell gesetzt. Die Slaves werden dann aber auto-addressiert.

Genau, das ist ein Unterschied meines BMS und vieler anderer.

Das kann man meines Erachtens so machen, wie es am besten zu den sonstigen Umständen paßt. Wenn es meine erste Packs wären, würde ich es vermutlich eher step by step machen.

Da ich im Moment auch an zwei kommerziellen Projekten rund um das BMS arbeite, ist “open source” aktuell kein wirkliches Thema. Man könnte zwar theoretisch Lizenzbedingungen auch so formulieren, dass beides nebeneinander geht. Ich habe aber keine wirkliche Lust meine Kraft in den nächsten Jahren für juristische Auseinandersetzungen zu verschwenden, die meiner Einschätzung nach dann sicher kommen würden.

Ich denke aber auch, dass für die meisten potentiellen Nutzer eines solchen BMS die Frage “open source” eher nachrangig ist.

Für die meisten dürfte es mehr um solche Fragen gehen:

  • Bekomme ich in 2 Jahren noch FW-Updates
  • Kann ich in 5 Jahren für eine Erweiterung oder falls mal was kaputt geht noch kompatible HW bekommen

Dazu kann ich folgendes aus meiner Sicht sagen:

Meine eigenen Batterie-Packs ( mit meiner ersten BMS HW Generation ) sind jetzt etwa 5 Jahre in Betrieb. Im Moment spricht viel dafür, dass die Packs ziemlich sicher noch 10 - 15 Jahre nutzbar sein werden. Alle paar Jahre neue BMS HW zu installieren, schließe ich für mich kategorisch aus. Ich möchte aber ganz sicher in meinen Packs die aktuelle FW nutzen können. Damit ist dann zumindest grundsätzlich gesichert, dass es für alle HW, die ich im Moment verteile, für diesen Zeitraum auch FW Updates geben wird.

Solche Spielchen, wie HW durch FW zu kastrieren, um mit dem Verkauf von SW-Zusatzoptionen den Gewinn zu maximieren, wird es bei mir nicht geben. Alle BMS werden, wenn es die HW ermöglicht ( einen 4ten Temperatursensor-Eingang kann ich natürlich nicht herbeiprogrammieren ) auch alle zukünftig möglicherweise neuen Funktionen nutzen können.

Im Moment erfolgt Bestückung, Zusammenbau und Inbetriebnahme der BMS noch durch mich, so dass wenn ich “vom Schlag getroffen würde“ es keine weiteren BMS mehr geben würde. Für die kommerziellen Projekte ist so etwas natürlich ein absolutes No-Go, so dass in der nächsten Zeit sowieso eine Fertigung die von meiner Person losgelöst ist, geben wird.
Damit ist dann zumindest gesichert dass es grundsätzlich die Möglichkeit gibt zukünftig weitere BMS HW zu erhalten.

Davon abgesehen habe ich keinerei Pläne, mich aus der Weiterentwicklung des BMS auf absehbare Zeit zu verabschieden und eine der wesentlichen Motivationen hier HW an verschiede Nutzer zu verteilen ist es, Feedback zu dem BMS aus anderen Perspektiven zu erhalten und es darauf basierend weiter zu verbessern. Wenn also jemand mir plausibel darlegt, dass Funktionalität ergänzt werden sollte, werde ich das gerne umsetzen und dann allen per FW Update zugänglich machen.

1 „Gefällt mir“

In der Weiterentwicklung sehe ich einen großen Schritt in die professionelle und optisch richtige Richtung. Obgleich es mir persönlich lieber wäre, Kabel irgendwo hinten rauszuführen und zu verbinden.

Gestern habe ich mein drittes AHED-BMS in Betrieb genommen.

Eigentlich wollte ich gestern weniger zittrig die Steuerungsplatine mit den PH-Kontakten aufzustecken. Ich hab zwei Versuche benötigt und dabei haben sich wieder versehentlich die MOSFETs geschlossen. Ein Anschluss zum Inverter bestand dabei noch nicht.
Ich hatte beim zweiten BMS gelernt mit Manual FET control (Load +) zu trennen und nach Anschluss eines Inverters wieder zu verbinden.

Beim anschließenden Verstauen der Balancerkabel in den Zwischenraum zwischen den Zellreihen hat sich, zunächst unbemerkt, eine Verkrimpung an Zelle 11 gelöst. Soweit ich mich erinnere wurde dadurch an Zelle 11 Null Volt und an Zelle 12 ungefähr 6 Volt detektiert.
In der Folge gab es eine “Overvolt Protection” und die MOSFETs wurden geöffnet.

Es hat einige Minuten gedauert bis ich den Fehler erkannte. Nach der Reparatur hat das BMS selbstständig die FETs wieder geschlossen.
Währenddessen scheint aus heutiger Sicht das BMS gebalanced zu haben.

Heute konnte die Batterie weiter geladen werden.

Streng genommen sind das keine PH-Kontakte sondern “normale” 2mm Buchsen- bzw Stiftleisten. Die PH-Kontakte sind nur an den Kabeln.

Ich kann mich nicht erinnern das schon mal so erlebt zu haben. Ich muss bei Gelegenheit mal probieren, das hier nachzustellen. Kannst du mal beschreiben, wie genau Du aufsteckst? Einen Stecker/eine Seite zuerst? Wenn ja, welche? Waren die Balancer-Kabel beim Aufstecken der Steuerplatine schon gesteckt? Das sollte keinesfalls so sein.

Eine von meinen PH-Crimpungen?

Ja, das bewirkt die Broken-Wire-Detection. Das ist eine wichtige Fail-Safe Funktion und muss genauso.

Und zwar die ganze gestrige Nacht durch. Das war das “Night Balancing“. Für das BMS wirkte das so, als wäre die Zelle 12 viel voller als die anderen. Da sollte ich eine Zusatzvalidierung einbauen, dass bei einer Spannung z.B > 4.0 V das “Night-Balancing” gecancelt wird. Die 1.8 Ah werden Dir beim ersten Vollladen nun erst einmal ein massives Vorrauseilen von Zelle 11 bringen, was dann vom Balancer erst wieder eingefangen werden muss. Da sollte das “Night Balancing“ dann diesmal aber wirklich helfen.

Da sind wir wieder bei @carolus :slight_smile: Man kann testen und testen und immer wieder ergeben sich Zustände mit denen man bei der SW-Entwicklung nicht gerechnet hatte. Aber genau das braucht es ja um ein Produkt stetig zu verbessern und solange gewisse Grundregeln immer eingehalten werden (im Sinne von protection) ist das ja auch kein Problem.

Ich versuchte das wie in der Beschreibung mit dem kleineren Stecker beginnend aufzustecken. Balancerkabel waren noch nicht aufgesteckt.

Es war meine Verkrimpung an einem Ringkabelschuh. Zum Einen war vermutlich nicht fest genug verkrimpt und zum Zweiten habe ich vermutlich zu sehr daran gezerrt.

Wenn ich es “einfangen” kann werde ich berichten.

Man kann die Fehlerfreiheit nicht hineintesten. Man kann sie nur hineinkonstruieren.

Was übrigens auch dafür sorgt, das Software pünktlich und planbar fertig wird.

Deswegen werden bei diesem BMS alle kritischen Sicherheitsfunktionen auch in HW durch das BMS-IC erledigt.

Das größte Restrisiko ist eigentlich, dass der Benutzer aus Versehen oder Unwissenheit Einstellungen (wie Schutzschwellen) so setzt, dass Sie nicht mehr zu den Zellen passen. Wenn man für LFP OVP z.B. auf 4.4 V stellen würde, könnte die HW perfekt arbeiten und der Pack würde einem trotzdem wahrscheinlich früher oder später um die Ohren fliegen.

Wenn ein BMS generisch für verschiedene Chemien nutzbar sein soll, wird man das vermutlich nie ganz ausräumen können. Ich habe es aber bereits so umgesetzt, dass die Batterie-Chemie sowie die erlaubten CHG/DSG-C-Raten die grundlegenden Parameter sind und bei der Bereichsprüfung vieler anderer Parameter dann daraus abgeleitete Grenzwerte genutzt werden.

Das Fehlbalancing was oben in der Folge eines Leitungsbruchs an den Zellmessleitungen entstanden ist, ist nicht schön und ich werde das mit einem der nächsten FW-Updates zukünftig auch abstellen.

Wichtig ist, dass die in HW implementierte Open-Wire-Detection funktioniert hat. Wenn sich in einem solchen Fall am BMS Messeingang eine “Phantomspannung” ausbilden würde, die im gültigen Bereich liegt, während die echte Zellspannung aber deutlich davon abweichen könnte, wäre das potentiell wirklich gefährlich.

Dieses night-balancing scheint heute Nacht wieder aktiv gewesen zu sein. Kann das sonst irgendwie abgestellt werden? Während gestern die Zelle 16 noch die höchste Zellspannung hatte, hat heute Zelle 11 die höchste Spannung.

Wenn Balancing ab über 3400 mV einsetzt wechselt die Balancinganzeige auf dieses Bild.

Grundsätzlich könnte man das auch ganz abstellen. Du wirst bei der Korrektur dieses Fehlbalancings aber froh sein, dass es dann dabei hilft. Andernfalls müßtest Du den Pack wahrscheinlich 10 - 20 h über 3.4 V halten.

Du solltest heute den Pack möglichst lange so halten, dass die Zelle 11 über 3.4 V bleibt. Nach ~ 30 min sollte ein neuer korregierter Zielwert fürs Nightbalancing abgeleitet worden sein, der dann in der nächsten Nacht die Zelle 11 zur Korrektur deutlich entläd.

Dass das funktioniert hat, kannst du heute Abend ( bzw. sobald alle Zellen unter 3.4 V sind ) ganz einfach kontrollieren, weil dann nur noch Zelle 11 gebalanced werden sollte.

Mit weiterer Hilfe von Nimbus4 hier ein kurzer Zwischenstatus.
Das Night-Balancing hat sich heute, nachdem die Balancingschwelle von 3,4 Volt für mehr als 30 Minuten (ca. 4 Std.) überschritten wurde, neu an den aktuellen Zellstatus angepasst. Zelle 11 wird nun gebalanced. Morgen oder übermorgen könnte sich mein Malhuer aufgelöst haben.

Hinreichend Geduld, für das BMS-eigene Balancing hatte ich leider nicht. Den notwendigen Spannungsausgleich habe ich mit der “Glühlampen-Methode” bis auf 4 mV Delta unterstützt und danach die Spannung eine Stunde über 3,41 Volt gehalten, damit sich der errechnete Balancingbedarf des BMS erneuert.

Nun stimmt die Balacingstatistik nicht mehr. Aber da diese auf einen Kabelbruch mit anschließendem Fehlbalancing beruhte, war mir dies nicht wichtig. Eigentlich würde ich die bestehende Statistik für BMS 1507 gerne löschen, um von nun an eine neue Basis zu haben.

Mangels PV-Leistung der vergangenen Tage wurden die parallel geschalteten Batterien weitgehend entladen. Dies habe ich genutzt um durch weiteres Entladen eine SoC Kalibrierung auf 2 % bei 3,00 Volt auszulösen.

Für die Batterie mit dem AHED-BMS 1505 wurde dabei eine Kapazität von 323 Ah ermittelt - und der SoC wurde um 1 % korrigiert. Für die Batterie mit dem AHED-BMS 1507 wurden mit der erstmaligen “3,0 Volt” 327 Ah Kapazität ermittelt, der SoC wurde um ca. 4 % korrigiert.