Hi developers,
Maybe I am wrong but in the experimental charge voltage algorithm for Pylontech batteries, a small omission could be present.
I’ve tried to show it in the picture attached.
If that line is missing, the sawtooth behavior will come back, together with error #29.
If I am wrong, sorry…
By the way, ingenious thing!
Although, the way I know Pylontechs, slowly, the CVL will go down to that imposed 51.75V limit.
Hi Alex, that omission is deliberate.
In a previous candidate I removed the charge current limit, as requested by one of our beta testers (maybe you?), but I later decided to revert that. Pylontech batteries tend to go overvoltage quite easily, and since this has been working well a long time and we had few complaints, I decided to revert to the old way and rather hold to the CCL. Instead, I am hoping that lowering the charge voltage when CCL is below 0.2C will be a more stable solution.
Please test this new voltage control mechanism. The theory is that we want 3.45V per cell, or 51.8V, which is essentially full, but we have to go higher to properly reset the SOC estimate and for balancing to happen (which to my knowledge happens above 3.485V per cell).
Again the theory of this calculation, is that when the battery is close to full, most of your cells will be at the same voltage, and one will jump out, and the same with the reverse. So this assumes that all the cells are at a similar voltage, except one, in both cases.
In testing this has behaved very well so far. It doesn’t look as if it needs a low pass filter on the calculation, but we will see. If you want to tweak and play with it a bit, please do.
Hi Izak @iburger
Thank you very much for taking the time to give us the feedback.
Indeed, I was the one who suggested to keep a small current flowing.
But in the cases where you have many parallel modules, their BMS consumption adds-up (about 50mA per BMS) and together with the inverter small consumption will drag the voltage down and down.
That’s because the current is set to 0, no one will charge and finish up the charging.
And when the SOC will drop to 99%, the BMS charging current will increase and the charging resumes and so on, sawtooth…
By introducing this algo (which for overvoltages is quite OK) and nullifying the current, you’ve just increased the frequency of the sawtooth period and bring its max amplitude down to 51.75V
From my experience, when the CCL = 0, if you leave a small current to flow, say 0.5 Amps to cover the “parasitic” consumption, all is OK. No more sawtooth and no more error #29.
This added with your method / algorithm of avoiding overvoltages is perfect.
Thanks again!
Alex
LE:
I realize now that in my particular configuration it may never reach balancing stage.
I have a Multi RS for which I’ve set a charging limit of 60A.
This because I have 6 x US2000C which I don’t want to charge with more than 10A per battery.
So, according with your algo, I will always be on the flow of if charge_current < capacity/5.0
Therefore my top voltage will hardly hit more than 51.75V.
I did consider that. But then I also realised that if the cells are so neatly balanced that the calculation yields a voltage that low (ie all of them reach 3.45V simultaneously) the battery isn’t exactly unbalanced. Nevertheless, I am open to suggestions. One that I am already considering, is to perhaps make the >0.2C case use 15 times the highest cell, just to add a bit more delta at the top.
The user current limit is applied AFTER the quirks, so the decision is made based on what the BMS sends, not on the user setting. The 0.2C figure was determined through observation. This seems to be the first step for a Pylontech battery. I’ve seen this even on the 16-cell variants.
Today, because of some very rapidly changing solar conditions the final charging stage was very aggressive.
For the first time I had a cell difference of about 100mV. See below, it maxed out at 90mV.
The maximum cell was about 3.54V.
I have the float voltage set at 52.5V, the minimum charging voltage recommended by Pylontech. It’s a nice round figure of 3.5V per cell.
Still, seen on the graph, the battery recovered quite nicely, because of the decreasing charge current when the battery voltage was closing to 52.5V.
The problem is when one or more cells overshot. And in that moment is good practice to ease back the charging.
So one must keep an eye on cell voltage, not on BMS charging current.
I would do the following:
Of course, I would keep a charging current of at least 1A permanently, to compensate that parasitic draw I’ve talked about before. max(charge_current, 1)
So no sawtooth behavior and no #29 error.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
