CCL = Charge Current Limit. If the BMS issue that, then the Victron will listen. It might also be that Victron writes that value as part of the algorithm to prevent that the already high cell goes any higher. . @plonkster do you write/substitute this value as part of control?
My CCL comes from my Pylontech BMS BUT the Victron Algorithm stops the charging before CCL goes to zero (so makes decisions outside the BMS management process). The recommended charged voltage is 53.2v from PT but the new Victron Algorithm stops charging at around 52.4v.
Yes. But sometimes it is not sufficient. Charge Voltage is a more effective way of doing this.
1 Like
To confirm, I have US3000 pylons, bought in 2020. I assume those are âoldâ model, and thus need this cable:
Correct?
Yes, thatâs correct. The one with the RJ11 plug
1 Like
I oversee about two dozen Pylontech batteries and Iâve seen this happen on 4 so far, and the 5th is about to start doing the same. Hereâs todayâs graphs:
Even the new charge voltage adjustments in Venus OS 3.50 isnât fast enough to prevent it from exceeding 3.6V momentarily. It is already logging cell overvoltage warnings internally. The alarms will start happening once it starts hitting 3.65V, which is just a matter of time.
It seems there are good batches and there are bad batches: 3 out of 4 batteries in one batch I bought in 2020 have been replaced so far, and the battery bought together with the one in the above graph also had to be replaced recently.
Reviews of the Pylontech batteries have always been good, and a couple of years ago they were significantly cheaper than the competition (not so much anymore), which is why I went with them.
However, now I am starting to wonder whether I should not perhaps start looking elsewhere. So far I have not had any issues getting batteries replaced under warranty, but for how long will this continue to be the case?
Is a 20% failure rate over 4 years par for the course for LFP batteries? If not, which batteries are the most reliable in your experience?
Thanks!
Well if it makes you feel better, my ETowers which were the most expensive (and now one of the cheapest) is hitting 3.7-3.8v peak cell voltage. No noticeable damage though.
1 Like
This all requires the battery to send the cell voltage data which is a pretty new addition to the firmware. What firmware sends this data as my US3000C batteries on 2.8 donât send it? On the Victron site it gives a list but doesnât mention the old chip firmware.
Driving, short answer. There is no one in my opinion of the affordable batteries more reliable than the other. All have issues.I base my choice on local support.
If you have the money for BYD, they have the least complaints.
Freedom Won upped their game so much that I tend to use them a lot despite their issues.
Bsl giving little enough issues and if you know where to ask for support is also an option.
Hubble and Lithium battery SA came a long way with R&D and improved a lot on support. We use them more and more.
Greenridge impressed me a lot and we are currently quoting on 2 huge installation with them included.
The rest of the cheaper Pace BMS based batteries are still under R&D and I wonât wast my money on them.
Blue nova also came a long way, but I am not comfortable paying their prices per kw yet.
I will not use Pylons again. This issue will not stop and support might dry up soon. Failure rates are increasing as time goes by.
1 Like
Thatâs very odd. I have a mixture of US2000B, US2000C and US3000C batteries (old and new chip). All of them send the cell voltages. My old chip US2000C batteries are all on firmware 2.8 as well.
Is that because you are using a new chip as the master? Over the CAN bus?
Yes. Exactly that.
So, to confirm, only the new chip send it over the CAN bus.
Firmware 2.9 doesnât enable it?
2.9 should actually. Anything above 2.6 if remember correctly. Quickest way to check. Move can cable to one of the older units and see.
I only have the old chip. Iâm âsniffingâ the CAN connection between the battery and the inverter and canât see the battery transmitting them. Their is no 0x70 or 0x371
I have a stack of 6 x US2000B batteries that report the cell voltages over the CAN bus. They are currently on firmware 3.4, but they already reported the voltages on 2.9, perhaps earlier.
I also have several stacks of C-series batteries. The master batteries are all currently new chip, but I am quite sure that when the master batteries were still old chip that it already reported cell voltages.
Hereâs the latest firmware for both the old and new chip that I got off another forum. I have not yet upgraded to it myself:
US_C_stV2.9_NTV2.2Crc.zip (235.3 KB)
Thank you, I do have a copy of that but, same as you, havenât tried it yet.
This is really strange, I have just connected a Pi running Venus to the pack and it is indeed showing the cell voltages, but when I sniff the CAN lines I still canât see 0x70 and 0x371 which are the cell temps, voltages, and IDâs.
I donât run Victron stuff but am interested in doing a similar algorithm in my setup.
You could try changing the alpha value of the filter, presently set at 0.05. That will allow it to move faster. But there is the risk that it will not be completely stable. Try 0.1 for a start.
Another way would be to use the square of the value exceeding 3.485V and base the alpha proportionally on that. That means a little bit over causes a low alpha (it moves slowly) but a lot over (because of the square) reduces the alpha and makes it move faster. Lots of things one can do. I far prefer the simple approach.
There is no reason an LFP cell cannot handle 3.8V. Of course it is not good for them in the long term, but it is not necessary to be concerned. I am unsure what kind of chemistry Pylontech uses though. Maybe they have a reason to freak out at 3.6V.
1 Like
This picture is however a beautiful example of precisely what this algorithm is supposed to do.
The algorithm as it currently stands works well in most scenarios, but I have noticed that there is a specific sequence of events where its behaviour could be improved:
- The battery is charging and a single cell exceeds 3.485V
- The algorithm reduces the charge voltage and effectively prevents the cell from going into over-voltage
- Before the balancer can rebalance the cells, a cloud moves in front of the sun for a moment and the battery starts discharging
- LFP voltage drops rapidly under discharge, so the cell voltage drops below 3.485V within seconds and the algorithm adjusts the charge voltage back up to 52.5V
- The cloud moves away from the sun, and the cell voltages rise again - this time too rapidly for the algorithm and the cell voltage shoots up beyond 3.6V.
The voltage rise in (1) is slow enough for the current algorithm to deal with effectively, but the rise in (5) happens in seconds, and is too fast.
I think perhaps what will work well here is an asymmetric alpha: fast movement downward, but much slower charge voltage recovery.
To be fair though, I think the battery I am dealing with is probably a candidate for a warranty claim. I have sent the logs to Pylontech support in order to get their opinion.
1 Like