BMS respond differently. In the ideal world cvl is variable to improve balancing. Many have a fixed cvl and block charge.
This might be a rudimentary way of trying to protect against cells hitting limits. You would expect voltage control to be more granular. A large voltage drop will shut down the mppts and force a battery discharge.
Actually now all is clear and you are a âvictimâ of circumstancesâŠ
The B009 corresponds to Pylontech⊠So the saga beginsâŠ
At the moment the BMS is requesting 58.4V, the algorithm for Pylontech is considering the battery to be 16S.
So it doesnât interfere with the voltages set by the BMS - the CVL of 58.4V
BUT
When the BMS requests to lower the voltage to 54.4V, the algorithm implemented for Pylontech will falsely believe that the battery is 15S, because of this line inside the code.
if charge_voltage > 55:
# 48V battery (16 cells.) Assume BMS knows what it's doing.
You see, the requested CVL of 54.4V, even if it is for a 16S battery, will trigger the 15S path in the logic, because it compares with 55V which is bigger than 54.4V.
From this moment, as long as the BMS is sending 54.4V, the DVCC algorithm will try to keep the voltage to 52.5V and below!!!
So you see, with 52.5V, the battery will never reach 100% as long as the real voltage will never be 54.4V, but a much lower value.
Please @iburger , can you take a look at this case?
Because, as long as max CVL requested by Pylontech isnât greater than 53.2V (on later firmwares even 52.8V), can you consider on the comparison above, for 15S batteries, 53.5V or even 54V, instead of 55V, in order to avoid such cases as the one discussed on this thread?
1 Like
Would it make sense to deactivate DVCC and just use a shunt to monitor SOC until there is an official correction to whichever bits need to be corrected?
No, because the fact that the battery is lowering the CVL is a very good one for the sake of the batteryâs health.
Disabling the DVCC, makes the inverter to charge with the fixed voltage set in VEConfigure on the Charger section.
And therefore ignoring the batteryâs âcryâ for lowering the voltage when itâs needed.
Leave it this way, the fact that the battery will not go higher than 95% is not such a bad thing for a periodâŠ
Or instead of buying a shunt, modify just a single character in the DVCC scripts and fix it yourself.
It will be much cheaper and youâll learn something new along the way, if you donât already know⊠
Leave dvcc on, it has a role. But a shunt and manual voltage control will help.
I wouldnât expect the algo for pylon to change in a hurry to accommodate unsupported batteries that pretend to be pylon.
Your bms should reset to a higher cvl the moment cell voltages drop which would get out of this cycle.
Honestly, this is lousy bms firmware. I would contact the manufacturer and check for updates and if none are available then they should adjust this behaviour. That is the best solution.
Well, the fact that the battery pretends to be Pylontech is lousy, indeed.
But the fact that the battery tries to protect itself by lowering the CVL is exactly the thing that even Victron calls for it, so I would not call this lousy. And 54.4V, which means 3.4V per cell is quite a good voltage up until a possible high cell voltage situation is solved.
The shunt will only mask this problem, reporting a different SOC, but for sure will not help protect the battery when the battery will ask for a lower voltage, so in the long run it could be worse for the batteryâs health.
In the same way, the battery manufacturer could say:
Hey, why donât you follow the voltages I am sending and try to guess a 15S and 16S situation in your code?
Ignore the fact that I am pretending to be Pylon, this is my problem, and just follow the voltages, because this is your problem.
What if the Pylon itself will send those voltages in the UF5000 battery? DVCC will malfunction and it will lead to nasty stuffâŠ
1 Like
Forgive my ignorance, but which character would I be changing?
I can research how to access and modify DVCC scripts but learning a new programming language is a bit beyond my time availability for the foreseeable future.
There is no need to drop cvl by 4v on a lithium battery to deal with a cell that has crept a bit high.
That is lousy coding.
Pylon wouldnât use such a blunt approach to control their batteries.
Unsupported batteries come with problems. Ones that pretend to be another historically have bigger issues.
It is unrealistic to expect changes to a supported battery profile to protect against a cheaper bms that is spoofing another to get compatibility.
As per support guidelines the battery manufacturer is responsible for support. Not victron.
Modifying code that is lost after any update is not a solution. It renders the entire system unsupported.
As a victron forum we do not encourage this and those topics belong in the modifications category.
I will be talking more with the battery folks about this issue. Their initial response was to have me change the charging values.
You can hurt some coders feelings saying thisâŠ
In the Victronâs code there is a line that says:
charge_voltage = 52.5 - 30 * max(0, bms.maxcellvoltage-3.485)
If a cell reaches 3.6V - which is not unheard of - , the result will be 49.05V.
Which versus 53.2V requested by Pylon will be over 4VâŠ
Indeed, from 52.5V will be only 3.45V, but still 52.5V is also a deviated from request value.
There is nothing wrong to take extreme measures to protect thingsâŠ
They donât understand the victron charger mods for pylon. On a managed battery you can only override cvl and ccl, cvl being more important. This shouldnât be necessary on a pack that isnât new and has been given sufficient time to charge.
In my case, the batteries have only been in service for a couple of days now.
This topic is not about a pylon battery. It is about a 16 cell battery with a much higher cvl as standard.
When one cell hits a threshold you can lower that easily with a modest adjustment.
The pylon bms does not behave in any form like this model.
In that case, leaving them on charge for an extended period should resolve the issue eventually. Even with the pylontechism.
BYD was the same. Time on charge can compensate for most bms flaws.
Your battery seems to behave more like BYD than pylontech.
If you compare different battery BMS approaches to balancing at top of charge.
Blue line is CVL, orange is CCL.
BYD (high initial CVL that drops for an extended time with CCL=0)
Orion BMS (Variable CVL and CCL)
Pylon US3000C (15 cell) (fixed cvl and lowering of ccl and ccl=0 to block charge)
The behaviour observed so far is basically this:
Below 95% SOC, 58.4V charging
Above 95%, no charging only discharging, 54.4V setting in CVL
Once discharged below 94% (sometimes down to 93%), charging resumes @ 58.4 until it hits 95% (sometimes it shows 98% for a few moments)
It is a bit disconcerting to see the discharging and next to zero input in full sun when above 95%
Even without the pylontech charge behaviour that kicks in briefly when it drops to the low cvl, the chargers will stop while the bus voltage is above the requested cvl. That is normal until it reaches or drops below the cvl.
If the battery keeps doing that at 95% it is going to struggle to sync, I would seriously consider using a bmv instead.
Some batteries just have issues with reported SOC and charging and the best way around it is old-school charging.
You can leave the bms connected for reporting purposes but not use it to control charging.
Does this mean just turning off DCVV? And adding in a shunt ?
We normally do not have the Bluetooth enabled on the Cerbo and have until now just used the screen to see how things are doing. From what I saw when looking at Victron shunts they all seemed to want Bluetooth enabled.
No. They are vedirect. You would still use dvcc with the shunt as a reference.
You would disable bms control in dvcc and config the shunt as the monitor in gx system settings.
Usually requires a full power off and on to affect the change from managed to unmanaged.
Thanks for the clarification.
Iâll need to do some more reading and see about ordering a shunt.