Vorstellung Eigenentwicklung BMS für große 16s LFP Packs - Diskussion

Die Idee mit der JK Kompabilität halte ich nicht für besonders clever. Die Chinesen allgemein und JK im Speziellen ändern ihre Versionen nämlich im Mondphasenrythmus. So schnell kommt man mit kopieren gar nicht hinterher. Man sieht es ja auch bei den Auschnitten altes und neues Terminal. Also ist es grad egal wenn es noch eine weiteres AHED Terminal gibt. Selbst wenn sich das an der nächsten Version wieder ändert.

Ebenso ist es auch beim Schnittstellenprotokoll. Das ändert sich zwar nie weil jeder von jedem abschreibt, aber es hat eklatante Mängel in Zuverlässigkeit und Funktionsumfang welcher ständig verschlimmbessert wird. In Wirklichkeit wird der CAN Bus auf eine Punkt zu Punkt Verbindung reduziert. Das frühe “Konzept” kommt nicht von Pylontech sondern von den SMA Sunny Islands. Zu diesen gibt es sogar eine offizielle Doku weshalb sich das vermutlich als “kompatibel” durchgesetzt hat.

Es wäre wohl nicht besonders kompliziert hier etwas besseres zu machen weil die Konzepte dazu überall bekannt sind. Allerdings mangelt es dann an der Kompabilität weshalb es wieder niemand macht und dann Alle wegen ihren defekten weil aufgeblasenen Pylons rumheulen.

Summa Summarum: Möglichst wenig bei den Chinesen kopieren.

SMA CAN protocol (2)-1.pdf (491,8 KB)

1 „Gefällt mir“

Da graut es mir auch schon vor.

Das schreibe ich mir auf die TODO-Liste.

Wenn man sich nicht gerade als Folterknecht der Zellen berufen fühlt, sehe ich in einer typischen privaten ESS Anwendung überhaupt keinen Grund, dass die Zellen im regulären Betrieb 3.65 V sehen.

In diesem Beispiel sieht man die durch die BMS-gesteuerte Ladekurve eines 100Ah Packs.
Der maximale Strom ist ~ 40 A <=> 0.4 C ( von 0.5 C habe ich leider keinen schönen Screenshot )

Schon ab ~ 60 % SOC wird der Ladestrom ( Spannungsgesteuert) zurückgenommen. ( das ist sehr konservativ )
Trotzdem dauert das Laden von 55% SOC bis 100 % "nur" ~ 100 min.
Wenn man auf 0.5C hochgeht und das Absenken des Stroms etwas später starten läßt, schafft man damit von 0% -> 100 % in ~ 2.5 h.
Das dürfte praktisch für alle Anforderungen in einer typischen privaten ESS Anwendung ausreichen.
Die Zellen sehen dabei maximal nur gute 3.45 V und sind für weniger als 1h über 3.4 V.

Wenn man die volle Kapazität nicht wirklich benötigt, würde ich regulär sogar nur bis 95% laden.

3 „Gefällt mir“

Ob es 95% sein soll, weiß ich noch nicht. Information Fehlen über den SoC Unterschied zwischen "0.5C + CV Ladevorgang" gegenüber "0.5P".

Bei 0,5P Ladevorgang ist das Lade-endpunkt jedenfalls nicht biss 100% elektrochemisch voll, weil ins Datenblatt mit 0,5P ohne CV-Phase geladen wird. Mit 0,5P wird der Ladevorgang gestoppt, sobald der Ladestrom 0,43(8356)C erreicht.

Was das Hersteller Voll SoC vermutlich ist lässt sich nur empirisch bestimmen. Deshalb wünsche ich mir ein 3.65V/0.5P-Ladeprofil. Also nicht für den täglichen Gebrauch, sondern für dieses Testzweck.

Nach Beendigung des 3.65V/0.5P Ladevorgangs möchte ich:

a.) die Versorgungsspannung des BMS trennen und anschließend die Zellspannung (der höchsten Zelle) über einen bestimmten Zeitraum messen. Auf diese Weise kann anhand der Ruhespannung nach X Zeit eine Schätzung des SoC vorgenommen werden.
oder
b.) das BMS umstellen auf Ihre Ladevorgang und messen welche Menge an Ah nachgeladen worden können.
c.) den Wert für den elektrochemischen SoC auf noch andere Weise bestimmen... (Vorschläge sind willkommen)

Welchem “normalen” SOC-Wert der Vollladezyklus mit 0.5 P entspricht, wäre ich auch neugierig. ( Ich würde auf etwas in der Gegend von 98 % tippen )

Ich denke Du kannst an diesen Wert viel einfacher rankommen:

Wenn Du mit meinem BMS das initiale Top-Balancing durchgeführt hast, hat das BMS bereits eine ziemlich genaue SOC-Schätzung ( nach der “normalen Skalierung”)

Wenn dann, nachdem mindestens einige % aus dem Pack entladen wurden, noch einmal vollgeladen wurde, sollte eine sehr präzise SOC-Schätzung vorliegen. ( Das kannst Du auch ganz einfach experimentell nachprüfen, indem Du dann noch einige Teilentlade- und Vollladezyklen durchführst und überprüftst, dass bei der 100% SOC-Rekalibrierung nur ± wenige 100 mAh korrigiert werden. )

Um dann den Unterschied zum 0.5P Vollzustand zu bestimmen, würde ich einfach so vorgehen:

  • OV-Schwelle in den Bereich von ~ 3.75 V verschieben ( Dazu benötigst Du einen “Spezialbefehl” von mir, da ich so hohe Werte über die GUI im Moment nicht zulasse )
  • OC-Charge-Schwelle >> 140 A setzen
  • Balancing deaktivieren ( auch über “Spezialbefehl” )
  • ~ 10 % aus dem Akku entladen. ( Dadurch ist die folgende Ladephase so kurz, dass es sehr unwahrscheinlich ist, dass Du ein OT-Problem bekommst )
  • Akku mit 140 A Ladestrom ( extern vorgegeben ) laden bis die Zellen 3.65 V erreichen. Zu diesem Zeitpunkt den vom BMS angezeigten SOC-Wert notieren.

Bei den von meinem BMS angezeigten Zellspannungwerten bitte immer berücksichtigen, dass, sobald das BMS Schätzwerte für den “ohmchen“ Widerstand im Zellpfad hat, nicht die Terminal-Spannung, sondern die “elektrochemische Zellspannung” angezeigt wird. Wenn das BMS z.B. 0.3 mOhm für eine Zelle bestimmt hat, ist der angezeigte Spannungswert bei 140 A Ladestrom um ~ 42 mV geringer, als man mit einem Multimeter messen würde. Wenn Du dich also an den vom BMS angezeigten ( GUI oder Display ) Zellspannungen orientierst, wirst Du schon bei ~ 3.6 V den SOC-Wert ablesen müssen.

( Die UV/OV-Schwellen sind dahingegen echte Terminalspannungen! )

Ein Spezial-Modus für 0.5P habe ich schon auf meiner TODO-Liste stehen.

PS: Wenn Du mein BMS von den Zellen trennst, denk bitte daran, vorher in den “Update mode” zu wechseln, damit keine Einstellungen und Zustandsinformationen verloren gehen.

1 „Gefällt mir“

@nimbus4 Anderes Thema: SoH (State of Health). Dieser "SoH"-Prozentsatz sehe ich nicht im WebGUI. "Nominal Capacity" soll ich ausfüllen im WebGUI und "Actual Capacity" bestimmen lassen.

  1. Bei z.B. (actual) 335 Ah auf (nominal) 314 wird SoH denn 106.6%, oder nicht?

  2. Was macht AHED_BMS mit SoH?

  3. Wann werden die maximalen CCL/DCL im AHED_BMS an die tatsächliche Kapazität angepasst, also an SoH?

  • fortlaufend/kontinuierlich?
  • niemals?
  • wie in Eve Zyklentest (MB56 Datenblatt Version A, Seite 28, 1.15): bei 80% SoH und 70% SoH, also 100~80% SoH lauft auf 100% CCL/DCL, 80~70% SoH lauft auf 80% CCL/DCL, und 70~60% SoH lauft auf 70% CCL/DCL?
  • anders?
  1. Gibt es ein SoH ≤ 60% Alarm?

Wunsch: BMS das sich auch am nicht isolierten CAN-Ports anschließen lässt, z.B. selbst ein isolierter CAN interface auf die Platine hat, weil Victron MP-II built-in GX, enthält ein nicht isoliertes VE.CAN Interface.

Ich bin kein wirklicher Freund von solchen “pseudo-SOH” Werten.

Ich habe intern im BMS einen solchen SOH bis jetzt überhaupt nur deswegen vorgesehen, weil das SMA/Pylontech-Protokoll mehr oder weniger verbindlich die Übermittlung fordert.

Genau

Kann man so definieren. nach meinem Eindruck ist aber ein Clipping auf 100% typischer

Ich meine, ich habe den Wert bis jetzt einfach nur auf 100% initialisiert.

Meiner Meinung nach ist eine Definition in der Art Restkapazität / Nominalkapazität in mehrerer Hinsicht irreführend. Es suggeriert z.B., dass, wenn ein solcher SOH bei 80 % liegt, erst 20% der möglichen Nutzung erfolgt ist. Außerdem werden Alterungsaspekte wie Widerstandsveränderung, Selbstentladung, “Memory-Effekt” völlig außen vorgelassen.Ich finde es sinnvoller die verschiedenen Alterungsaspekte individual mit Warnung– und Fehlerschwellen zu versehen.

Schon weil es in vielen Zelldatenblättern inwischen gefordert wird, gehört die Restkapazität ( im Sinne eines EOL-Kriteriums ) natürlich dazu.

Im Moment passe ich da nichts an, bzw. alle was konzeptionell C-rate basierend ist, beziehe ich auf die Nominalkapazität ( wie es nach meinem Eindruck typisch ist oder zumindest war ).

Ich denke ein Derating wie bei der MB56 ist in jüngster Zeit dazugekommen, weil man sich nun offensichtlich traut, statt früher ein EOL bei 80% Restkapazität zu setzen, auf 70% oder sogar 60% runterzugehen. Da das bis jetzt noch keine praktische Relevanz hatte, habe ich das noch nicht berücksichtigt. Mindestens für kommerzielle Anwendung wird man das dann auch im BMS abbilden müssen.

Durch die Veränderung vom Over-Potential mit der Alterung würde es im Moment aber zumindest teilweise bereits über I(V_cell) derating abgefangen.

Noch nicht, aber ein vom Hersteller konfigurierbares EOL-Management werde ich für kommerzielle Anwendungen in Kürze sowieso ergänzen müssen.

Bei einem 48V System mit Schalter im Plus-Pfad gibt es keine strenge Notwendigkeit für eine galvanische Isolation.

Wenn man es nicht vorsätzlich herbeiführt, gibt es keinen signifikanten Potentialunterschied zwischen den Geräten. Zudem übersteht z.B. der CAN PHY auf dem BMS einen CM-Unterschied von ±42 V.

Bei der HV Variante des BMS ist das CAN Interface für > 1kV galvanisch getrennt. Für die 48 V habe ich diesbezüglich im Moment keine Pläne.

Wenn man bei 48V die galvanische Trennung für seinen “Seelenfrieden” benötigt, kann man sich in vielen Anwendungen auch mit einem galvanisch getrennten CAN-USB Adapter behelfen:

Praktisch alle EMS laufen heute ja sowieso auf einem SBC mit Linux ( typischerweise Rpi basierend )

2 „Gefällt mir“

Naja bei dem wenig elaborierten CAN-Protokoll (BYD und Konsorten) sind SOH und MaxChargeCurrent wohl die einzigen Mittel mit denen sich eine Batterie "wehren" kann. M.E. muß /müsste ein BMS rückwirkend auf den WR bessere Möglichkeiten haben. Mein BMS dreht ab, wenn es die Verbindung (Modbus nicht CAN) zum Wechselrichter verliert, schon alleine deswegen weil es ihm nicht mittteilen kann "bitte reduziere den Ladestrom" (edit: ja zumindest limitieren geht ja gerade noch),... BYD und andere "kommerzielle Hersteller" handhaben das freilich anders. Bin gespannt auf das SG <-> SBH1XX Protokoll.
Aber 16S ... :X)

und solange man nicht weiß, wie ein WR den SOH Wert interpretiert .. bei mir hardcoded 100% - ein 80 jähriger fühlt sich ja manchmal auch "pumperlgsund".

Du scheinst ja auch keine Erkenntis zu haben, dass irgendein WR überhaupt auf den SOH-Wert reagiert. Ich halte das für eher unwahrscheinlich.

Das möchte ich bei mir explizit nicht. Ich habe zum Teil auch Lasten auf der 48V Schiene, die gerade nicht ausfallen sollen, wenn der WR ausgeschaltet oder defekt ist.

Ich werde mich in einigen Wochen wohl auch mit der Kommunikation zu HV-WRn ( zunächst Deye ) beschäftigen. Die Platinen für die HV Variante meines BMS sind schon bestückt:

1 „Gefällt mir“

Wer ich mal bei meinem Sungrowe ausprobieren, ich denke/erwarte er wird das dann wie MaxAmpsCharge/Discharge = 0 interpretieren ?!

Echt ? Welche Lasten denn ? Die einzige Last für meine Batterien sind die JKs und der Wechselrichter ?! Ich kappe dann auch nur das Main-Relais und die Batterie muß dann neu "gestartet" werden.

:flexed_biceps:

Du hattest Recht, SOH 0% voll ignoriert :slight_smile:

Ich habe für ~ zwei Jahre praktisch meinen kompletten PC Arbeitsplatz, also Workstation Labtop, großer Monitor, USB-Hub, Ethernet Switch, “direkt” (also ohne AC-Umweg ) aus der Batterie versorgt.

Nach einem Labtop Wechsel konnte ich das leider nicht so weiter laufen lassen, weil der neue Laptop wohl zu heftige Lastwechsel für die DCDC Netzteile erzeugt hat.

Das große LCD Dispaly bei dem ich vor ~ 10 Jahren das AC-Netzteil wegen Defekt einfach rausgeworfen und das Gerät dann auf 24 V Versorgung umgebaut hatte, ist inzwischen leider auch anderweitig defekt.

1 „Gefällt mir“

DC zu DC ist ja nicht die schlechteste Idee - bei meinen 320V allerdings ... Frage mich nur wie DC-DC Wandler für EVs in Zukunft (Mercedes-Posting) funktionieren sollen (PWM ?).

In künftigen Konzepten wird es in der Hausinstallation 3 Netze geben. AC 230/400V, DC 48V und ein High Voltage DC Netz. Unabhängig von der Spannung gibt es für DC Netze einen VDE Vorentwurf der aber seit Jahren ähnlich der Smartmeter Gateway Schnittstellen in VDE nicht wirklich vorankommt. Trotz Industrieallianzen mit namhaften Mitgliedern gibt es nur vereinzelte Produkte deren Anwendung bis auf Weiteres Fricklern vorbehalten bleibt. Die Allgemeinbeleuchtung mit LED und praktisch alle 24/7 EDV funktioniert bei mir auf 48V zwischenzeitlich aber ganz passabel. Hauptleitung 35mmq H01N2 auf 60m Distanz, Leistung trotzdem relativ begrenzt. Waschmaschine u.ä. werden vermutlich immer auf AC bleiben. Kühlkompressoren könnte von der Leistung her vielleicht mal jemand auf 48V entwickeln wenn die Stückzahlen passen. 24V gibts ja von Danfoss für Camper bereits was. Viele AC Geräte mit SNTs laufen mit einem HV-DC Netz absichtlich oder zufällig ohne Modifikation sobald der Zwischenkreis genug Spannung hat. Einige aber nicht alle 230V AC Schalter, Sicherungen, Stecker, Schütz können auch für 48V verwendet werden ohne daß sie explizit dafür spezifiziert sind. Kommt aber wegen den Server Farmen und Hybrid BEV immer mehr.

Für HV gibts dann auch das Problem mit kostspieligen Steckverbindern welche zur Verhinderung von Lichtbogen aktive Mosfets zum Abschalten bei der Trennung unter Last brauchen.

https://akkudoktor.net/uploads/default/original/3X/7/3/731b59516464f5341a7a9fcaecf329beeea13dcf.png

Du meinst dies?

Technisch ist das keine wirkliche Herausforderung. Bei einer galvanisch getrennten Netzteil-Topology ist es konzeptionell praktisch nur das Windungsverhältnis, das entscheidet ob ich ein 48 V → 24 V oder 320 V → 24 V Netzteil erhalte. Bei 320 V ist es aber deutlich schwieriger etwas dediziertes COTS zu finden als bei 48 V.

Bei 320 V könnte man aber auch Glück haben, dass man das einfach in ein Standard AC230 Netzteil gibt. Je dümmer das Netzteil, desto größer die Chance, dass das einfach so läuft.

An diesem Beispiel sieht man dann auch ganz gut, dass es auf Schaltungsebene keinen wirklich dramatischen Kosten- und Wirkungsgradunterschied zwischen einem AC230 und z.B. DC400 Netzteil gibt. Mit dem Aufkommen von bidirektionalen GAN-FETs und der Verwendung von Cycloconverter Topologien dürfte der Unterschied noch weiter schrumpfen.

Was kleine Privathäuser betrifft, bin ich da in der Breite eher skeptisch. Weil die technischen Vorteile da einfach zu gering sind. Meine Lösung war zwar eine technisch nette Spielerei, aber teuer und was Wirkungsgrad betrifft eher ein Nullsummenspiel, weil es mir zu heiß war meinen PC Arbeitsplatz (mit teilweise sehr teuerem Messequipment über USB ) ohne galvanische Trennung an den Akku zu hängen. Wenn in einem einfachen Buck der FET druchbrennt, würde die Akkuspannung mit vielen 100A oder je nach Kabel sogar bis in den Bereich 1000A praktisch direkt durch alle Geräte durchschießen. Ein kleines COTS isoliertes 300 W 48 V → 24 V Netzteil hat aber gerne 5 W Leerlaufverlust. Da kann man inzwischen viele AC-Adapter für eingesteckt lassen und durch USB-PD reduziert sich die Anzahl der benötigten AC-Adapter ja sowieso tendenziell immer weiter.

Bei AI-Servern ist allerdings der nächste große Trend, dass man mit 800 V ( z.B. ± 400 V ) direkt auf das Mainboard geht und man dann erst direkt neben den GPUs auf 12V runtergeht.

Da ist die treibende Kraft, dass man sonst die vielen 100 kW einfach nicht mit Anstand ins Rack bekommen würde, was mit einer privaten Energieversorgung aber überhaupt nicht vergleichbar ist.

Ich möchte hier mal ein Beispiel zeigen, wie gut die Kompensation von Spannungsabfällen über ohmsche Widerstände ( und damit implizit auch die Schätzung der Widerstände ) im Zellpfad funktioniert.

Zum Kontext: Ich nehme gerade einen neuen 100 Ah Pack in Betrieb.
Dabei habe ich es erstmalig mit (wahrscheinlich vernickelten) Aluverbindern zu tun.
Bei der großen Schwankung der Widerstände im Zellpfad zwischen ~ 0.6 und 1.7 mOhm ist da offensichtlich etwas ziemlich schief gelaufen.

Ein positiver Beifang ist aber erfreulicherweise ein Screenshot, der sehr anschaulich zeigt, wie gut die Kompensation funktioniert.

Wesentlich ist der mittlere Graph.
Vor ~ 18:24 war die Kompensation deaktiviert und der Pack auf ~ 98 % SOC geladen ( eine 100% SOC Kalibration fand noch nicht statt, weswegen das BMS ~168 % annimmt)
In drei Schritten habe ich die AC-Last am WR von 0 auf knapp 2 kW erhöht.
Der 100 Hz Ripple des WR erzeugt dabei in der Batterie Ströme zwischen ~ 25 A und 45 A, die bei der Zellspannungsmessung durch die Spannungsabfälle über den ohmschen Widerstand im Zellpfad ein großes Störsignal erzeugen.
Von ~ 18:26 bis 18:40 verfeinert das BMS kontinuierlich seinen Schätzwert der Widerstände und das Ergebnis konvergiert dabei zu den unten angebildeten Werten.
Visuell erkennt man das Konvergieren sehr anschaulich im Zusammenlaufen der Spannungskurven.

Es ist offensichtlich, dass das BMS auf Basis der unkompensierten Spannungsmessungen keine konsistenten Entscheidungen treffen kann.
Nach der Kompensation sieht es so aus, als gäbe es gar kein Problem mit den Übergangswiderständen ( Mit dem "R"-Fehler signalisiert das BMS aber, dass es mit der Situation nicht glücklich ist )

2 „Gefällt mir“

Ackmaniac hat für den Deye LV eine sehr schöne Kommunikation/Steuerung zwischen JK-BMS mit HA über esp32 entwickelt. Ich hab die im Einsatz und bin sehr zufrieden. Vielleicht hilft es ja.

Wenn ist das richtig überblicke, ist das aber nur für LV WR ( also SMA/Pylontech ), was ich ja auch schon lange bei meinem BMS unterstütze.

Die HV WR nutzen ein völlig anderes Protokoll.

Das wusste ich nicht, sorry.

Für die Erweiterung einer 304 Ah EVE Zellen Batterie wollte ich eigentlich 314 Ah Zellen parallel zu den vorhandenen einbauen. Nun zeigt sich, dass eine der vorhanden Zellen einen Memory-Effekt aufweist. Deswegen denke ich nun, es wäre besser für die Zellübewachung eine getrennte Batterie parallel anzuschließen. Hierfür benötige ich dann ein neues BMS das mit dem vorhandenen JK-BMS zusammen funktioniert. Wichtig wäre, dass ich die zuvor o.g. genannte Steuerung von Ackmainiac über Home Assistant weiter verwenden kann. Wenn das möglich ist, würde ich gerne zunächst ein BMS von dir erwerben. Sollen wir Weiteres über PN erörtern oder hier.

Ich würde 300er eh nicht mehr parallel schalten.