I always understood that was the algorithm of Pylontech BMS who was managing the solar charger and inverter and it is the BMS, not the Cerbo, who is telling to them the current and charge voltage requiered. Isn’t it?
That is very interesting to me as I have 3x UP5000s and have always had a voltage of 52.8v.
The CerboGX is using the Pylontech BMS and the default charge settings given by the VenusGX firmware. Interesting to see 2 very different charged voltages for 100% SOC values between the US vs the UP.
I setup my system 2 years ago based in this VE document. No changes been done since then. My cerbo is running firmware version 3.32.
https://www.victronenergy.com/live/battery_compatibility:pylontech_phantom
It is true that sometimes the battery bank does not reach 100% SOC for some days and it is not due to a lack of solar power.
For some reason, i want to understand that there is a high unballanced voltage cells, BMS does not admit more charges. Sometimes stays at 95% some others at 98%.
When I setup the system, this effect took a couple of months and my battery bank stayed at 95% during the first 2 moths aprox. Now happens only time to time and pnly for few days.
Another effect that i have is that the bartery bank stays during the day around 98% and at the end of the afternoon when solar power declines jump suddenly to 100%.
Hi everyone,
Please note that the algorithm in Venus 3.50~15 has some shortcomings. Another improvement is on the way. That’s why I have not really responded yet. At this point in time spending lots of time on a discussion is not really productive.
I agree with @nickdb that some kind of voltage control really is indispensable. As mentioned earlier, it is way too common for a battery to have the majority of its cells slightly above 3.45V, and to then develop a high cell condition because another cell is above 3.55V (the BMS raises a high voltage warning at this point). It is perfectly possible for such a thing to happen while you are still under 52V, and that really makes it impossible to have just one static charge voltage.
Please be patient for a little longer. It is coming.
1 Like
Hi Izak @iburger
Thank you for your efforts.
This is the algo I am using for some days and below the cell evolution.
Instead of capping the voltage from up downwards, I am imposing a lower limit and then I am going up slowly, following the lowest voltage cell.
I am also controlling the current for avoiding sawtooth voltage and error #29
DESIRED_BATTERY_VOLTAGE = 52.50 # 3.50V per cell
MINIMUM_BATTERY_VOLTAGE = 52.05 # 3.47V per cell
battery_target_voltage = DESIRED_BATTERY_VOLTAGE
if charge_current > 0.1:
# still charging (CCL != 0) so keep an eye for over voltages
battery_target_voltage = (bms.mincellvoltage + 0.035) * 15 # wait for slower cells, max 35mV deltaV between cells
battery_target_voltage = min(battery_target_voltage, DESIRED_BATTERY_VOLTAGE) # just to be sure it's between the limits - max one
battery_target_voltage = max(battery_target_voltage, MINIMUM_BATTERY_VOLTAGE) # just to be sure it's between the limits - min one
difference = max(0, battery_target_voltage - 0.02 - bms.voltage) # starts after 0.02V below target voltage
system_idle_current = difference * 20 + 0.3 # a 0.3A minimum idle current to avoid error 29
system_idle_current = round(system_idle_current, 1) # round the current nicely to 1 decimal
system_target_voltage = battery_target_voltage + 0.05 # an addition of 0.05V for compensate cable loss
system_target_voltage = round(system_target_voltage, 2) # round the voltage nicely to 2 decimals
return (min(charge_voltage, system_target_voltage), max(charge_current, min(system_idle_current, 30)), feedback_allowed, False) # idle current of no more than 30A
@alexpescaru , If you want, you can look at the latest plan here.
Basically, we aim for 52.5V until the highest cell exceeds 3.485V. From that point on, the charge voltage is penalised by the amount by which the highest cell exceeds that threshold, multiplied by 30 (twice the cell count). In testing it results in the high cell leveling off at 3.5V. It uses a low pass filter to keep the calculated voltage setpoint stable.
1 Like
Where batteries are on older firmware that doesn’t send cell voltages, will it default to legacy behaviour?
Yes.
@nickdb
Yes, it has a try … except… implementation.
Hi Izak @iburger
I’ve saw your pushed modification. Much nicer than previous.
But the final voltage will be 3.485*15 = 52.275, not the target 52.5… As seen from your graph…
For sure it will work OK, I’ve just wanted to show my implementation, from a different point of view.
I even wanted at some point to take into consideration neither the mincellvoltage, nor the maxcellvoltage, but the difference between them.
In the end I’ve settled for this, because, as seen from the graph, there is a slow and progressive recovery without the need of low pass filter, because I follow the low cell voltage, not the max cell voltage.
Thanks!
Thanks Izak.
I have left ~15 on my system so you can monitor if needed.
Still 52.8V and then the “wild” fluctuations after 13:00 that are of interest to me… even on the beta version. My geyser comes on @ 13:30 but the batteries are at 100% from 10:30.
Good luck and thanks for the work!
Mark
Indeed, I’m actually quite happy with that number. In a battery that is perfectly balanced, it stops at 52.3V. In any other battery, it keeps the highest cell below 3.5V. We can of course tweak it upwards a little bit if necessary.
I don’t think that will work very well. Simply because I imagine that whether my lowest cell is at 3.3V or at 3.4V reflects an extra 100mV in the delta, but it makes no difference to the actions that is needed to keep the highest cell in check.
I was talking the difference between maxcell and mincell. Whenever their difference is bigger than, let say 40mV, start to throttle back the charge voltage. Anyway, didn’t liked it so I’ve dropped the difference implementation.
And another thing…
The quirks are called at the timer rate of 1 second. This is quite some time for a quick evolving cell voltage.
In some cases maybe the filter needs to be more relaxed, so instead (0.95/0.05), maybe (0.8/0.2) it will be much prompt.
Anyway these are details…
Nice work! Thank you!
I see that peoole commenting this topic in the chain are very expert and masters.
I do not want to disturb too much but not being as experts as you, i have a basic doubt that I would need to understand to improve my knowledge.
I understood that BMS and its algorithm is who controls charge and discharge parameters and tells to mppt and inverter how to proceed. This is communicated to cerbo and cerbo links with mppt and inverter.
If I am not wrong, why do you need a charge/discharge algorithm in Venus OS if the master is the battery BMS and its algorithm?
Thabks
Because the BMS imposes just (some) limits.
Along the way, up until those limits are hit, many things can happen.
And if the things get out of control during the ride, it’s better to hit the wall at slower speed than on full throttle, metaphorically speaking. 
3 Likes
Hi Izak @iburger
I’m not a Python guy, more of a C(&co), but for the unknown 12V battery, the last parameter returned is automatically assumed to be False, or should be specified?
Thanks!
# Not known, probably a 12V battery.
return (charge_voltage, charge_current, feedback_allowed, False)
or
return (charge_voltage, charge_current, feedback_allowed, False, False)
Hi!
Will the changes to the charge algorithm for 48 volt batteries also be implemented for 24 volt (UP2500) systems? In the github code that was linked earlier it didn’t seems to be any change for 24 volt systems?
/Kaj
Thanks @alexpescaru , spot on, that is an omission! Probably need a unit test for that…
3.50~18 installed yesterday in prep for the sun today.
Charged voltage sits nicely around 52.4 (SOC is now 98% hope it moves up to 100%
)
CCL still @ 60A which I thought should now be @ 0v but this may still be in dev.
The CCL is not modified. The ideal is to keep that as a way for the battery to prevent charge as a second resort. Reaching a good charge voltage without the CCL going to zero is actually ideal.
Thanks Izak. Hope the testing above is helping - I would like to see 100% SOC though 
Edit: 100% after 3 hours … Very nice!
1 Like