Ich fürchte, daß dies vorwiegend ein HW Problem ist. Ein uC läuft normalerweise mit 3,3V und einer Refenzspannung für den 12 bit AD Wandler in dieser Größe. Damit lassen sich die Zellspannungen relativ genau messen. Für die Strommessung braucht man einen Shunt Widerstand. Vorzugsweise in 4-Leiter Technik von der Isabellenhütte weil die im thermischen Drift und bei Messfehler besonders genau sind. Leider kosten die gleich 1-2 Euro weshalb man zum Laden und Entladen nur einen Widerstand haben möchte. Üblich sind chinesische Nachbauten der beonsonders günstigen SMD Bauform BVS. Für 200 Amp nimmt man den kleinsten Wert 0,1mOhm. Für ein BMS mit 200 Amp fallen darüber 20mV ab, was eine bereits kritische Abwärme von 4 Watt macht. Beim Laden und Entladen beträgt die zu messende Spannung nun aber plus oder minus 20mV welche zunächst mit einem Offset versehen und dann auf etwa 2,5 Volt AD Referenz mit einem Faktor von etwa 50 verstärkt werden müssen. Ohne Batteriestrom stehen am 12 bit AD also 1,250 Volt an wozu die Firmware einen Wert von 2048 sehen muß. Vermutlich werden für den Offset aber aus Kostengründen nur 1% genaue Widerstände verwendet, was bereit einen Fehler von 20 Werten ausmachen kann. Darüber hinaus braucht man eine sehr genaue Referenzspannung für den Offset welche es vermutlich nicht gibt. Selbst wenn an der Hardware und am Platinenlayout alles stimmt, kann der Hub von 1250mV/2048 nur 0,5 Amp genau aufgelöst werden. Rein subjektiv wäre aber eine bessere Genauigkeit von 0,1Amp gewünscht was bereits einen 14 oder 16 bit Wandler erfordert. Es ist etwa so, wie wenn die Tankanzeige am Auto die restliche Reichweite nur auf 200km genau messen könnte.
Zum oben beschriebenen Offsetfehler kommt jetzt noch der Verstärkungsfehler des Operationsverstärkers welcher etwa die Verstärkung 50 haben sollte. Auch hier nehme ich an, daß nur 1% Widerstände verbaut werden und sich damit ein weiterer Fehler in der Strommessung der Größenordnung 1% verstärkt um Faktor 50 aufsummiert. Betrachtet man jetzt die bipolare Kurve mit Nullpunkt in der Mitte, so ergibt sich für das Laden und Entladen jeweils ein anderer Messfehler. Würde beim Laden und Entladen der gleiche Fehler gemacht werden, wäre nur die absolute Anzeige falsch. Der SOC würde aber nicht wegdriften. Hier werden aber aufgrund der falschen Verstärkung und fehlerhaftem Offset verschiedene Fehler gemacht. Diese summieren sich in der Bilanzierung des SOC auf welcher dann verständlcherweise immer falscher wird. Ein weiterer Fehler entsteht am Ende der Ausgangsspannung von Operationsverstärkern. Um diesen zu minimieren gibt es Rail 2 Rail Typen. Diese arbeiten bis ziemlich an die Grenzen ihrer Betriebsspannung genau. Besonders lästig ist das bei Werten von Null. Der AD Wandler zeigt noch immer einen Wert von 20-30 Zählern an, weil der davorliegende Verstärker keine kleinere Spannung ausgeben kann bzw. dessen Kennlinie gegen Null einfach abknickt. Das kann man allerdings vermeiden, indem der Operationsverstärker mit einer negativen Betriebsspannung versorgt wird. Er arbeitet damit auch um den Bereich von Null exakt genau. Ob JK eine negative Betriebsspannung bereitstellt, darf wegen dem Aufwand angezweifelt werden.
Was Andy jetzt gezeigt hat, ist der Korrekturversuch an einem Ende des Messbereichs per Software. Das funktioniert für diesen Punkt halbwegs, aber man hat gut gesehen, daß es um den Nullpunkt herum nie passt. Die Korrektur wirkt sich zwangsweise immer sowohl auf den Offsetfehler wie auch auf den Verstärkungsfehler aus. Eine Korrektur ist mit Ausnahme des Temperaturdrifts natürlich per Firmware möglich. Sie muß dann aber immer zwei Abgleichpunkte haben. Einer für den Offset bei kleinem Strom und einer für die Verstärkung bei großem Strom. Im bipolaren Fall wäre sogar ein dritter Kontrollpunkt sinnvoll. Diese Punkte müssen dann mit geeignet genauem Equipment wechselweise angefahren und korrigiert werden. Ein solcher Schaukelabgleich ist ein erheblicher Aufwand wenn dies nicht sinnvoll automatisiert in einem Prüfmittel in der Fertigung beim Hersteller gemacht wird.
Victron macht einen solchen Abgleich bei seinen Smartshunts sicherlich in der Fertigung. Aber im Vergleich kostet ein Smartshunt etwa genau soviel wie JK das gesamt BMS verkauft. Im Resultat ist das wie bei der Tankanzeige im Auto. Vertraut man darauf anstelle zusätzlich mit seinem letzten Tankbeleg nachzurechen, bleibt man einfach unerwartet irgendwo auf der Straße stehen. Bei sicherheitsrelevanten Batterien kann das eben besonders fatal sein.
Blöde Frage, da mit Victron Shunt noch nie beschäftigt: kann man einen solchen zusätzlich zum JK BMS installoeren, um den SOC-Drift annähernd zu eliminieren (auch wenn das kostet...). Oder bringt das dbgl. auch nichts?
Ich habe gerade mal etwas an meinem MPPT gastet, die 60 V Werte werden sauber übernommen. Ich kann es nicht aktiv testen, da ich noch eine 16S System betriebe.
Die Frage ist, was du mit dem Wert machen willst. Nur angucken? Dann kannst du das natürlich auch in der BT App machen. Im Venus/GX hast du immer Zugriff auf beide Werte(sätze). Ich hab eine SoC-basierte Laderegelung eingebaut, da hilft ein 'genauerer' SoC Wert natürlich...
@philippoo die Frage ist auch ob man diesen Drift nicht einfach mit 1x / Woche auf 100% laden möglichst eliminiert, dabei praktisch kostenlos...
Ja, im Winter wird es schwieriger, da kann man einfach ein paar Tage lang auf den Ertrag bzw. Akkuentladung zu verzichten damit der Akku 100% erreicht, statt gleich zu verbrauchen. Immer noch günstiger als den Shunt zu kaufen.
@eugenius bei mir geht der SoC schon am Ende eines Tages bis zu 10% auseinander. Dabei kann man nicht vorhersagen, ob das JK mehr oder weniger anzeigt.
Ich wollte auch erst auf einen SmartShunt verzichten, aber wenn man nicht täglich auf 100% hochladen will oder kann, fällt man ohne eine etwas bessere SoC Zählung (als per JK) ziemlich schnell auf die Nase glaub ich....
man kann da den Ladewirkungsgrad und den Peukert-Exponent einstellen, das ist wahr. Beides ist bei LiFePO4 relativ 'standard'. Aber ich werde trotzdem mal den Versuch machen. Guter Hinweis.
@philippoo ich habe die Strommessungen eingestellt (so weit es ging mit meiner Stromzange), Spannungen ausgeglichen (im vollgeladenem Zustand)
und behaupte mal, dass meine beide JKs mit den gleichen Zellen (16x davon sind 2 Monate länger im Gebrauch) sehr nah bei einander liegen, so 1-2% Abweichung OK allein durch die Verluste in den Kabeln (bei mir sind es leider je 1,4m von der Busbar zu den Akkus).
Ich habe die Akkus auch schon auf 0% Anzeige entladen, ohne dass ist irgendein Problem festgestellt habe.
Aber OK. SmartShunt kostet mittlerweile nur noch ~80 Euro, wenn er hilft, why not?
Diese SoC Zählerei ist ja immer nur ein Aufintegrieren von Plus und Minus über die Zeit. Irgendwann ist das auch bei dem besten Batteriecomputer weggedriftet. Auch einen SmartShunt muss man ab und zu kalibrieren. Aber wenn man die Strommessung beim JK anschaut wird eigentlich schon klar, dass das eher über kurz als über lang zu erheblichen 'Ungenauigkeiten im Integral' führt...
oben Shunt, unten JK (die rechte Skala sind Ampere). Um Null ist es ganz fürchterlich, aber auch bei etwas größeren Strömen liegen die Werte oft meilenweit auseinander
die Frage ist natürlich, wozu man einen SoC Wert wirklich braucht. Wenn der Akku leer ist, merkt man (bzw. das BMS) das auch so. Und machen kann man da dann auch nix gegen, 'besserer' Wert hin oder her.
Ich brauchte den Wert für 'Diskussionen' mit u-f-o, weil, wie er richtig sagte, meine diebezüglichen auf den Angaben des JK basierende Aussagen für die Tonne waren
ausserdem habe ich inzwischen (wo ich den SmartShunt schon habe...) eine SoC-basierte Laderegelung eingebaut, wo ich einstellen kann, bei welchem SoC die Ladesollspannung wie hoch ist (2-Punkt). Damit kann ich im Sommer z.B. den Akku schonend bei 80% halten, und im Winter läd er, wenn's mal grad geht, voll...
Dann frage ich wie soll man ohne den ach nicht so wichtigen soc dann eine Automatisierung erstellen etwas über die spannung der batterie, ich hab zwar keine ahnung aber es läuft hier und ob der soc nun stimmt oder nicht kann ich ohnedies nicht überprüfen ausser das system mit last runterzuquälen
@grua ich habe 'nur' Home Assistant, aber meine ganzen Regelungen laufen in Python Skripts. aber da kommt es nicht drauf an.
Was ich mache ist:
Ein Python Skript beobachtet (30s Takt oder so) den SoC.
Fällt dieser unter einen eingestellten unteren Wert, wird die Ladespannungsbegrenzung im Venus (-> bei den SmartSolar Chargern) aufgehoben und sie laufen gemäss (bei mir im BMS) eingestelltem Ladealgorithmus (also gewöhnlich erstmal auf Bulk).
Steigt der SoC Wert über den eingestellten oberen Wert, begrenze ich die Ladespannung auf etwas unter Float.
Sehr simpel und funktioniert wunnderbar. Die Werte (Soc hi/lo und zugeh. Ladespannung/sbegrenzung) kann ich per MQTT Publish ändern, die SoC Regelung greift auf die Spannungsbegrenzung auch per MQTT zu. Mit einem NodeRed direkt im Cerbo ist es natürlich noch einfacher.
@concierge bis zu der erst letztens eingeführten SoC basierten Regelung um den Akku nicht dauernd voll zu laden gab es die Größe SoC in meiner Regelung nicht. Obwohl diese mit 'kombinierter Nulleinspeisung und Überschusseinspeisung' sowie die Beheizung meines Warmwassers (also erst Akku voll, dann Warmwasser, dann Überschuss einspeisen, und wenn kein Überschuss da, dann Nullregelung) schon durchaus komplex ist.
Die Akkuspannung benutze ich trotzdem noch, um nahe dem 'unteren Knie' der Kennlinie die WR Leistung zu reduzieren. Algorithmen wie z.B. serialbattery oder einige Wechselrichter machen auch sowas.
