Pylontech and adapted charge algorithm - how to detect faulty battery

Q&A and troubleshooting
, , ,
1

With VenusOS 3.50 a change in the charge algorithm for Pylontech 15S batteries was introduced, that lowers the DVCC voltage, when min and max cell voltages differ too much. Ideally this behavior would keep the cells below 3.60 V.

I am running a stack of multiple Pylontech US2000C. Prior to this change, one block was regularly throwing Cell Overvoltage Errors when charging over 89%. I contacted Pylontech and after reviewing the logs of the battery a cell fault was determined and I received a replacement battery.

After some time now I suspect that a cell defect has occurred in another battery. But instead of hitting the cell overvoltage limit the charging voltage is repeatedly lowered and raised over a period of two hours until the cells have finally equalized.

image
image537Ă—456 19.3 KB

image
image537Ă—456 26.2 KB

Because of this behavior, no error log entry is created that I could use to contact Pylontech warranty support.

So how does Victron propose to reliably detect and document a defective cell in order to be able to initiate a warranty replacement?

2

I hope it’s okay to mention @iburger who, as far as I know, developed this feature.

3

What I found with a properly bad cell is the algo only reduced the number of alarms, and didn’t stop them completely, and a similar pattern developed.
You might have a marginal cell, that the system can still correct, but you are right, it likely can mask some developing issues on older systems.

4

I’m amazed that no log entry was created with the above cell voltage chart. That normally happens at 3.55V.

I would suggest using the above cell voltage chart to show that you have a persistent repeated imbalance that does not go away over several days.

Remember also that repeated overvoltage alarms can also be used to deny a warranty claim.

1 Like
5

The “High voltage alarm” is generated at 3,65V.

1 Like
6

If I may ask Izak @iburger, maybe an ease up on the parameters of the single-pole recursive low-pass filter in order for the algorithm to behave more quickly and not let the cells to reach so high voltages during regulation… :innocent:
Maybe 0.6 and 0.4 ?..

That’s also because the DVCC voltage is published by the driver on the bus on a 5 second time basis, which is also toooo long, in my opinion.
Many can happen on 5 seconds and if the charger is missing that packet, then after another 5 seconds…

The dvcc process things at 3 seconds interval and the driver publishes the values on 5 seconds interval, which is way too long.

7

That’s over voltage alarm at 3.65V, with recovery at 3.5V…
The high voltage alarm is at 3.6V, with recovery at the same 3.5V.

But from the OP graph, the 3.6V was hit at least 4 times… So, indeed, very strange that no alarm was raised…

8

In the BMS log high voltage alarms are generated at 3.55 V, but they are not passed on to VenusOS. This happens regularly in my system.

Only overvoltage alarms in the BMS log triggered at 3.65 V are passed on to VenusOS and displayed there as high voltage alarm.

During my last warranty claim Pylontech support didn’t seem to care about the high voltage alarms at all. Only after providing proof of regular overvoltage alarms due to cell imbalance my claim was accpeted.

9

This is from one of our systems (w/o the new algorithm):

image
image942Ă—459 24.3 KB

The spikes are 3,65V and the exact moments with the corresponding alarm in the alarm log.
The entry in the alarm log is definitely generated at 3,65V not 3,60V or 3,55V.

image
image945Ă—324 10.4 KB

The new algorithm seem to try to keep the highest cell voltage below 3,55V.

10

@M_Lange

That because the log interval is 1 minute… Try to lower the log interval to 5 seconds or less and see that the hit moment is at 3.6V.
Also, you don’t have to believe me, believe what the parameters read command from the Pylontechs console tells you.

Mine are similar with these:

3
3423Ă—211 25.1 KB

11

Also the sawtooth evolution of the voltage(s) is because the target voltage and the regulation voltage are not harmonized.

The code reads: charge_voltage = 52.5 - 30 * max(0, bms.maxcellvoltage-3.485)

You can see that the target is 52.5V, which is 3.5V per cell.
But the voltage is dragged down from when the cells are 3.485V, which is 52.27V.
Hence the continuous regulation/race of ups and downs after different voltages.

Here is how it is now:

1
11070Ă—456 63.8 KB

Here is how it should look without any low-pass filter and the below formula.
Regulation at 15mV above the target voltage per cell.

battery_target_voltage = DESIRED_BATTERY_VOLTAGE - 15 * max(0, bms.maxcellvoltage - ((DESIRED_BATTERY_VOLTAGE/15)+0.015))

2
21069Ă—833 105 KB

And another one from today.
See how the algorithm proposed here on Aug 27, last year, “pamper” the charging voltage in order for the battery to smoothly reach the desire voltage.
And how in the process, it caps the high cell voltage and wait for the low cell to get fully charged.

4
41081Ă—921 111 KB

12

The log interval is not the problem.
It hits 3,61V at 12:01 (3,62V at 12:02; 3,64V at 12:03) and the alarm appears at 3,65V at 12:05.
It is over 3,60V for 4 minutes without the alarm.

13

Maybe you have a different configuration on the batteries.

Also remember that the alarms are a consequence of Venus OS logging.

I am talking the event logs read from the battery console port itself at the exact moment of alarm.
Something like this, where you can see when the cell 4 was having 3.602V and raised an high voltage alarm and a log entry was generated.

ID    Day       Time      Volt   Curr     Tempr    Tlow     Thigh    Vlowest  Vhighest Base.St   Volt.St   Curr.St   Temp.St   ErrCode      MosT.St     SOC TotalCoul  ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC
0     23-10-01  22:53:09  52514  2933     31100    26800    27200    3358     3602     Charge    Normal    Normal    Normal    0x0          Normal      98% 50000      1  3543   27100   Normal    Normal     100% 2  3518   27100   Normal    Normal     100% 3  3466   27100   Normal    Normal      98% 4  3602   27100   High      Normal     100% 5  3522   27100   Normal    Normal     100% 6  3454   27200   Normal    Normal      98% 7  3526   27200   Normal    Normal     100% 8  3458   27200   Normal    Normal      98% 9  3456   27200   Normal    Normal      98% 10 3358   27200   Normal    Normal      98% 11 3460   26800   Normal    Normal      98% 12 3599   26800   Normal    Normal     100% 13 3495   26800   Normal    Normal     100% 14 3533   26800   Normal    Normal     100% 15 3524   26800   Normal    Normal     100%
14

I never changed any settings inside the battery.
(why should one do that?)

The problem seem to be a “translation” mistake.
Pylontech says >3,60V = “high voltage” but this isn’t send to the Victron system.
Pylontech says >3,65V = “over voltage” this is transmitted to the Victron system but Victron calls that a “high voltage” alarm.

1 Like
15

You are correct about translation and handling of errors… :+1:
I missed that. :innocent:

Indeed, here’s a row with an overvoltage, at the same cell 4 (3.652V), which says now OV, not High
And at the same time, cell 12, High with 3.649V (so close) :smile:

ID    Day       Time      Volt   Curr     Tempr    Tlow     Thigh    Vlowest  Vhighest Base.St   Volt.St   Curr.St   Temp.St   ErrCode      MosT.St     SOC TotalCoul  ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC ID BVolt  BTempr  BVolt.St  BTemp.St    SOC
3     23-10-02  00:12:33  53040  2987     32800    26700    27200    3359     3652     Charge    Normal    Normal    Normal    0x0          Normal      97% 50000      1  3592   27200   Normal    Normal     100% 2  3564   27200   Normal    Normal     100% 3  3495   27200   Normal    Normal      99% 4  3652   27200   OV        Normal     100% 5  3564   27200   Normal    Normal     100% 6  3477   27100   Normal    Normal      98% 7  3573   27100   Normal    Normal     100% 8  3482   27100   Normal    Normal      99% 9  3479   27100   Normal    Normal      98% 10 3359   27100   Normal    Normal      97% 11 3481   26700   Normal    Normal      99% 12 3649   26700   High      Normal     100% 13 3528   26700   Normal    Normal     100% 14 3577   26700   Normal    Normal     100% 15 3568   26700   Normal    Normal     100%
16

Back on the initial question:

If the algorithm is properly designed, you wont see any high/over voltage errors…
Only that the battery will not charge to 100% or will take forever to get there.

So if you start to see that on plenty of sun or grid availability (depending on how you charge them) you wont get 100% regularly, then you will start to take a look at the Remote Console and you will see that the same cell is either shooting up or dragging down on a regular basis.

This will raise eyebrows as a cell that is shooting up will make the algo intervene and drop the voltage and therefore the whole pack will not charge to 100%, or if the cell is dragging down, also the BMS will consider that the pack has not reached yet 100%.

As a side note… what happens with the ones that on purpose are not letting the battery to get to 100%… well, this is another discussion… :smile: