sounds very interesting.
Maybe I finally can decommission my NR-flow, which I implemented as single cells tended to create high voltage alarms, when the module-stack wasn’t balanced enough and one had a good day with lots of PV incoming.
My flow kills charging entirely when a singe cell reaches above 3.498V and limits charging Amps in steps according to SoC and max. Cell voltage
Edit: took the plunge and updated to 3.50~20, while my stack of 10xUS3000C was already at 80%SoC, deactivated my own flow and disabled a charge limit.
After restart, the charge current was starting way above what I normally use at this SoC-Level but the new algorithm kept Vmax below 3.5V … nice work…I will further evaluate but this will come very handy during winter season.
Absolutely can agree with that. Running 8 packs is a total of 120 cells, during (dis-)charge the cell voltage difference is 1 mV at max, and when SoC reaches 100%, they normalize at 10 mV maximum difference.
Not running the beta, but not seeing any issues with balancing / cell overvoltage until now. (Using 52.4V CVL)
So, thumbs up for keeping up the work and even improving stuff that works. This is seeking for perfection, rarely to be seen these days.
I’ve just read your message. I also have a running node red flow to avoid overvoltage of single cells after long time without charging to 100%. I cutted the charging limit hard to 7 A when first max charge go over 3,43 V (5*US3000C) and limited charging voltage generally to 52,00V. With this sometimes single cells go to 3,5 V or only a ltlle bit over.
I also updated now to 3.50.20 and deactivated my flow and the charging voltage. There should be still enough sun today to reach 100% wthin this day. I keep you and the others here updated.
I’m very interested about the result.
now it charged to 100%. The algorythm seems to work. It try to not get too much over 3,5 V. Peak was at 3,531 in my case and it tried to reach 52,4V (3,49V per cell in average). I was able to see how it tried to control the charging voltage.
Peak:
Personally the very short peak of 3,531V and total voltage messured by BMS of 52,45 is for my case a little bit too high. I still try to get max 3,50 V per cell and in total a max of 52,1V. But it is my personal quirk.
Note: The stop of charging before 4 p.m. seems to have something to do with DESS. I often observed this today 1,2,3 minutes before full hour. Perhaps it is charging faster than I configured the charge power in the DESS option in VRM.
…sorry if this is a dump question, but how/where did you apply that algo?
Also, i’ve seen single cells just jump tooo fast and would like to stay below 3.5V (at 3.498V), hence.
Pylon is probably one of the most popular brands around, having pioneered the lithium battery market. Personally, apart from a new install, I haven’t seen these issues on systems adequately sized, not heavily discharged and allowed to regularly balance. I suspect the cost effectiveness, and a common community theme of buying the bare minimum, if that, of battery, contributes to issues on 15 cell batteries.
One of my own systems runs on older 3000C’s for over 4 years now. No issues and 98% SOH. Flawless.
That said, the equivalent BYD’s were probably harder to get to settle than the pylons.
As Izak pointed out in the message #26, it’s a part of the dvcc.py script, from the dbus-systemcalc-py Venus OS driver.
The part responsible for the 48V-15S Pylontech battery “quirk”.
In that case, for sure, the solution proposed by Victron (Izak) and released in 3.50~20 is more than OK. And this solution you already have.
Izak generously shared his ideas and experiences and I just felt that it’s common sense to give something back and post my experiences in order for all others, maybe, to benefit. It’s just a different approach to the same issue.
It’s not necessarily the cell count. In our test fleet we have another 15-cell battery that uses a lower charge voltage, and behaves quite differently. What makes these more tricky, is that the charge voltage is quite high for the cell count: At 53.2V it evaluates to 3.55V per cell, which is very highly charged, and leaves just 0.05V room at the top before a high voltage alarm is raised. With margins that tight, even small amounts of imbalance can be an issue, and plans have to be made.
Their newer batteries (of the Premium family) have dynamic voltage control which works quite well. Also, they want 55.2V over 16 cells, which is a more comfortable 3.45V per cell.
Their BMS CVL limit of 53.2V is just a tad below 3.55V.
52.5V is 3.50V per cell. 100mV until a HV alarm.
What I’ve seen during my experiences:
If you charge daily and keep at 52.5V (3.50V per cell) the pack will be more uniform and balanced during time and the overshot in cell voltages (voltage drift between the cells) when charging will be lower. In other words the charging will be more “all in the same time”.
If you charge daily at a lower voltages, say 52.2V (3.48V per cell) or less, the pack will tend to develop some undercharged cells, the overshots (cells drift) when charging will be more frequent and you periodically need to do some “equalizing”.
But this is just me with my packs.
Still, I believe that Pylontech went from the assumption that the battery will be well balanced and therefore they imposed that 53.2V CVL, that tend to support the observation above.
And another real life observation:
New battery from the factory with SOC about 50%.
Stand alone charger set to 53.2V and 20A limits.
Start charging and monitoring with BatteryView.
Of course, some cells got to 3.6V and HV alarm.
Battery BMS disconnected the charger and waited for the culprit cell to drop below HV recovery voltage of 3.5V.
Then the BMS reconnected the battery and of course the charging resumes.
The steps 4 - 6 repeated, with progressively less and less frequency, until those slower cells caught up and finally got a well balanced battery with about all cells to about 3.53V - 3.55V.
In that moment that battery was put on a system that take for granted the parameters the BMS is communicating, so charges up to 53.2V and keeps there as idle voltage, and never had an HV alarm.
And during charging almost all cells reach the full voltage almost in the same time, the final balancing being no more than 5 minutes per cycle.
Just a note that this appears to apply to SOK battery banks as well, since they apparently use Pylontech protocols, if not their BMS itself.
I have (5) SOK 48v100 pros and high voltage alarms from the BMS were a regular occurrence during the first few weeks until I started to put a real load on them, then they decreased in occurrence. However, I routinely see on my MPIIs (split-phase setup) reporting via LED a low battery condition, although its partner does not, especially at night when the SOC drops to 65% or so.
Running V3.50~20 on the Cerbo and 552 on the MPIIs.
Feels like the BMS and the Victron gear are simply out of sync regarding what they want. Likely my fault… I’m forcing the MPIIs to use the SOK manufactured recommended settings of 57.6V Absorption, 55.2V float. The batteries are currently at 53.6V @ 74% SOC and being charged. This is typically what I see.
Point releases are to address specific known issues found after the GA release. They rarely include enhanced functionality which will be pushed out when the beta is finalised.
Now I missed that little piece of NB info. Thanks for the clarification.
I’ll leave 3.50~20 in as I think the Pylontech’s like it a bit better. I don’t get to 100% as early or as long as before but the benefits are longer battery life - I guess.
@alexpescaru and @dognose
Do you reach the smallest max-min cell delta when charging, discharging, or it doesn’t matter?
Using another brand of batteries, I notice that at a given SOC, the delta is consistently smallest when discharging.
Right now, I have a delta of 57mv at 100% SOC while discharging. Not as great as 1mv but acceptable, I think.
