ich habe meinem Kumpel bei der Installation eines Victron ESS, bestehend aus Cerbo GX, 3x MultiPlus-II 48/5000/70-50 und 3x Pytes 48000R-C, unterstützt.
Seit dem Wochenende ist die Anlage in Betrieb. Am Wochenende haben wir wiederholt aus dem Netz gebalanced, leider nur bis knapp unter 40 mV Zelldifferenz.
Der Akku wurde heute Nacht auf “16 %” SOC entladen, obwohl nur 10 kWh entnommen wurden. Das sollte eigentlich einem SOC von etwa 30 % entsprechen. Heute Mittag überschreiten die Zellspannungen schon 3,45 V und der SOC zeigt zeitgleich 86 % an.
Hat jemand eine Erklärung warum das so ist? Ist das “normal”?
Im DVCC ist seit Beginn SCS aktiviert. Ist das ein Problem? In der Battery Compatibility List für Pytes ist dazu nichts zu lesen. Die allgemeine SCS-Dokumentation lässt vermuten, dass es in diesem System ausgeschaltet sein müsste.
Die Pytes Firmware habe ich noch nicht ausgelesen. Man kann aber erkennen, dass der Akku die CVL dynamisch anpasst und im oberen Bereich auch die CCL reduziert, obwohl die Zellen zu dem Zeitpunkt schon saturieren.
Mir kommt eine derart große Abweichung zwischen Zellspannung und SOC merkwürdig vor. Was meint ihr?
auch heute Morgen wieder ähnliches Verhalten: Die 18% SOC hält der Akku außergewöhnlich lange. Das DCL wird auch schon reduziert, obwohl erst 9,8 kWh aus dem 15 kWh großen Akku entladen wurden.
Die Batterie wurde vor Inbetriebnahme eine Woche lang auf CVL geladen. Allerdings betrug die Spannungsdifferenz am Ende dieser Periode immer noch über 30 mV.
Ich selbst habe ein Seplos BMS mit NEEY Balancer in Betrieb. <5 mV Zelldifferenz ist da der Standard.
Hello, Koni.
This SOC problem you are facing is generally due to older firmware of the battery. Updating the firmware to latest version and then charging all the batteries to 100% SOC would solve your battery SOC problem. Please let us know firmware versions of all the batteries. so we can assist you solving this problem.
you can use BMSQt software and use console cable to connect master battery with laptop. you can see battery firmware and other information. Or you can give us battery SN code(on the sticker on battery) we can find initial version of battery firmware.
we tried BMSQt software yesterday evening, but it crashed shortly after pressing Login. Sometimes it takes a little bit longer, sometimes immediately after pressing. I recorded several crash dumps.
I noticed that the SOC (on the left) of 2 instead of 3 installed batteries was shown.
how do we figure out what software is installed on the batteries? As for now, I assume that I cant support you any longer. Please advice how to proceed! I will do my very best to provide you with all the necessary informations you need.
The most reliable way is to use a serial terminal program like MOSerial on Linux or HyperTerminal on Windows.
There you can query all parameters from the batteries and also the firmware versions.
There is supposed to be a mechanism where firmware updates are deployed from master battery to all slaves, but I found it more reliable to update each battery individually (I only have 2 of them) while they are disconnected from each other (no link cable, no nor power cables connected) and also disconnected from GX.
And one important thing to mind with these (and most likely other) batteries is that the upper 10% of the SoC (90..100%) as well as the lower 20% (0..20%) are hard to calculate / estimate and even harder, the less the cells are balanced, so it’s very normal to see jumps there because the SoC levels are calculated from voltage levels and as soon as a single cell is reaching a certain max or min threshold, the SoC may e.g. jump from 15 to 10% or 90 to 100%.
Attention: The battery FW version shown on GX is awkward - Pytes does not transmit the full version number (like v1.5.28.C16) but some stripped down version (v28.3 in my case).
My link above is also showing cell voltages towards 100% SoC. You won’t see 100% with only 3.45V. Balancing (passive!) starts at 3.36V and 100% is reported by the BMS as soon as a single cell of a module has reached 3.55V.
Since I am an embedded software engineer, I am very familiar with serial communication. Is there a protocol or any description of how to communicate with the battery in order to read the firmware version, update the battery, and so on…?
I did not try to have the serial port open before the battery is turned on. Maybe the battery prints some informations at the very beginning that I am currently not aware of.
Don’t miss that: I just edited my post regarding 100% SoC / voltage levels.
Regarding the communication - it’s basic serial terminal communication. Plain text.
1.) connect the cable
2.) run the terminal app and connect with 115200 baud, data 8, stop 1, no parity, no handshake / flow control
3.) power on the battery => you will see a flow of boot messages
4.) Finally you get a prompt where you can enter commands, most importantly the “help” command
Firmware update goes like this:
1.) put battery in update mode (updata command)
2.) send firmware file with terminal program in XMODEM mode
The most important part here is to check the bootloader version before updating. Your manufacturing dates look safe, but on older batteries the bootloader needs to be updated prior to the firmware. And if you make a mistake here, you can soft-brick the BMS, requiring some extra efforts to bring it back to life.
And: there are different models / revisions of the battery (A, B, C8, C16, more to come - your’s have a TE+ suffix - maybe another new revision???). There are different firmwares for each revision!
