diy solar

diy solar

JK-BMS-CAN with new Cut-Off Charging Logic (open-source)

@MrPablo: Unfortunately the new automatic Charge Voltage doesn't work correctly for me.

It's actually extremely aggressive - jumping from 54.9V to 56.0V to 55.1V to 56V

Do you want me to create a separate GitHub issue for this as well ?
 
MrPablo said:
Yes please.
Click to expand...
I'll actually wait a bit now just to not create another issue on GitHub for nothing .... If I set the charge_v_factor_setting to 3.0 it seems somewhat more stable.

I hit OVP 3 times in the last 10 minutes on Battery 02 ...

And of course current control is DISABLED as I don't want to debug interactions between the 2 (it was happening).
 
If you are charging at a higher C rate (which a max of 180A would suggest) then yes, charge_v_factor_setting can be set to be more aggressive.

At the same time, current control is recommended (with default float voltage and a sensible OVPR setting, but we've already gone through that in some detail.
 
MrPablo said:
If you are charging at a higher C rate (which a max of 180A would suggest) then yes, charge_v_factor_setting can be set to be more aggressive.
Click to expand...
Keep in mind 180A (well 200A) is for both batteries: the smart one running the communication with the inverter, and the "dumb" one (only reporting to MQTT/HA).

So it's actually Around 90-100A each.
 
@MrPablo: Actually I take it back. The default value of 2.0 didn't work at all for me (it actually went "full" power and caused cell 11 to hit OVP as usual).

When charge_v_factor = 3.0 instead it seems to work WONDERS.

So ... conclusions ... if there is no BMS communication or the current doesn't taper off when one cell is near OVP, then that will overcharge and recharging the other ones via the active balancer will take forever. Not sure why the overcharged cell comes back A LOT, then needs to rise again though.

Now all of them are above 3.42VDC so it should not take much. So in terms of Ah, it was NOT a huge unbalance:
1711549268542.png


Yesterday I think I brought up the lowest ones from 3.36VDC to 3.39VDC.

I think once the pack will be (re)balanced, it will be much more "normal" (provided that the voltage control works).

I'm still thinking there is something quite off with the active current control, but that's probably because I am forcing a top balance WELL ABOVE float of 53.6 V. Hence I decided to disable it, at least for now.
 
silverstone said:
@MrPablo: Actually I take it back. The default value of 2.0 didn't work at all for me (it actually went "full" power and caused cell 11 to hit OVP as usual).

When charge_v_factor = 3.0 instead it seems to work WONDERS.

So ... conclusions ... if there is no BMS communication or the current doesn't taper off when one cell is near OVP, then that will overcharge and recharging the other ones via the active balancer will take forever. Not sure why the overcharged cell comes back A LOT, then needs to rise again though.

Now all of them are above 3.42VDC so it should not take much. So in terms of Ah, it was NOT a huge unbalance:
View attachment 205074


Yesterday I think I brought up the lowest ones from 3.36VDC to 3.39VDC.

I think once the pack will be (re)balanced, it will be much more "normal" (provided that the voltage control works).

I'm still thinking there is something quite off with the active current control, but that's probably because I am forcing a top balance WELL ABOVE float of 53.6 V. Hence I decided to disable it, at least for now.
Click to expand...
I think I'll open an issue after all. It's "ringing" (oscillating) quite a lot near the top of the charge ... Both the requested charge voltage, the requested battery voltage and the actual charge current :cry:

EDIT 1: Link to Issue https://github.com/Sleeper85/esphome-jk-bms-can/issues/41
 
Last edited:
paulsteigel said:
Hi @silverstone and Mr. Pablo, why dont you try map(maxcellvoltage, UVP-50, UVP + 10, Max_charge_current, 0) I tested with this and it working sound okay! Will test tomorrrow a bit more on this!
Click to expand...
Hi @paulsteigel, the existing auto charge current control does similar to this already.
At the moment, we're working on controlling charge current through dynamically adjusting the requested CVL. That's the more effective way to do it, assuming your inverter regulates CVL properly...
 
MrPablo said:
Hi @paulsteigel, the existing auto charge current control does similar to this already.
At the moment, we're working on controlling charge current through dynamically adjusting the requested CVL. That's the more effective way to do it, assuming your inverter regulates CVL properly...
Click to expand...
My Inverter prefer fix charge voltage. I observed some dedicated BMS shipped with whole pack of high quality battery over months connected to the inverter via Rs485 and it only applies a single voltage 56V during the charging and sometime does resetting SOC by trying to lengthen the charging process to make cell be as close to 3.45 as better. Over a year, I could hardly see the min cell voltage drop below 3.1V and few time discovered the max voltage reach 3.46.
The only things I found was changing of charging current limit.
The reason I moved to map function was the "High voltage warning" by the inverter. For the case of 280Ah battery pack, charging current reached 70-80A and make the cells become so unbalanced and current dropped a bit too quickly and make cells became less unbalanced. As the result the current get back high again.
I tested today with map(), current changed a bit slower comparing to yours great function (both in increasing and decreasing as well). My trick was defining a buffer such as 50mV toward the OVP (defined by user, not by the BMS and often 3450mV) and 10mV above the OVP. So when max_cell_volt increased as closer to the OVP the current will be mapped down from the initial charging current defined by user often 0.25 - 0.3C.
I used old code of Sleeper85 and revised quite remarkably to meet with Luxpower SNA5000. If tomorrow test is successful I will share back!
I learned from you alot by using the platform: copy. Before I have to rely on script.
In general, my approach is to help Inverter treating battery pack as lead acid.
I have small problem occurred today that Inverter complained "Battery High voltage" with one of my friend (SNA5000 but it does not happen with a SNA6000 of the same yaml code) when he charge with 50A current so he turn back to Lead acid and charge went well again using 57.5V without problem. So I doubt there would be problem relating to the reporting of charging voltage from BMS (CAN_ID 0x356) or (CAN_ID 0x351). I discussed with Luxpower Dealer on this point but he failed to explain (he might not know about this).

This is today record of the premium BMS with SVE5000WM battery
1711984676338.png

And this is today charging using map() for 50Ah battery
1711984774887.png
And this is today charge using your power() option with manual control of charging current
1711984870928.png
 
Last edited:
paulsteigel said:
So I doubt there would be problem relating to the reporting of charging voltage from BMS (CAN_ID 0x356) or (CAN_ID 0x351). I discussed with Luxpower Dealer on this point but he failed to explain (he might not know about this).
Click to expand...
Now that you have mentioned, I too have a Luxpower SNA 5000 and everything is working for me at my end for months. Let me know what settings are you using and what version specifically.
 
Also, if it bears mentioning again and again. When there is current going in/out of the battery, its balance can't be determined due to internal resistance.
Very Ideally, determining battery balance involves removing all external potentials across the battery (such as can be achieved by turning BMS Charge MOS off) and letting the cells rest for like half an hour or so.
Then the voltage measured of the cells will correspond to the true balance voltages. Theoretically, this is also the ideal time for a balancer to do its job. after a full charge with no current going in/out, and no external potential to affect voltage readings.

Everything else is a compromise, loosely speaking.
 
shvm said:
Now that you have mentioned, I too have a Luxpower SNA 5000 and everything is working for me at my end for months. Let me know what settings are you using and what version specifically.
Click to expand...
Yap, it was very strange as the code worked (the Mr.Pablo one) on the SNA6K version, but the same code failed on the SNA5000. I tried a few options but it was too late, no more solar today. Will try tomorrow on 0x356 and 0x351 to report lower voltage for checking what has happened!
 
shvm said:
Also, if it bears mentioning again and again. When there is current going in/out of the battery, its balance can't be determined due to internal resistance.
Very Ideally, determining battery balance involves removing all external potentials across the battery (such as can be achieved by turning BMS Charge MOS off) and letting the cells rest for like half an hour or so.
Then the voltage measured of the cells will correspond to the true balance voltages. Theoretically, this is also the ideal time for a balancer to do its job. after a full charge with no current going in/out, and no external potential to affect voltage readings.

Everything else is a compromise, loosely speaking.
Click to expand...
You are totally right! That is why we are here with Pablo and other working hard to find a solution for this! What we are doing is making the JK work better as we can expect it to function perfectly! I myself believe current limit and voltage limit are two feasible options then!
 
paulsteigel said:
Yap, it was very strange as the code worked (the Mr.Pablo one) on the SNA6K version, but the same code failed on the SNA5000. I tried a few options but it was too late, no more solar today. Will try tomorrow on 0x356 and 0x351 to report lower voltage for checking what has happened!
Click to expand...
your battery brand setting?

setting PYLON + and Battery brand 2 is recommended for LXP SNA.5k
Additionally try cleaning up the project files and doing a fresh recompile.
 
shvm said:
your battery brand setting?
Click to expand...
on JK OVP is 3.55V, current limit for charge 100A, discharge 100A but I have addition layer of limits on esphome with max_cell_protection of 3450mV and Charge current limit of 70A. On SNA, Charge limit is 100A but it listened to the BMS via CAN, Voltage was 57.4 (default set for lead acid and still kept as it is). Lux stop charging at some period and reported W025 - Battery High voltage). He changed to lead acid and charge went well without problem. Haiza - this is headache. This did not happen with another guy usign SNA6K. He even push the current to almost 80A
1711985658371.png
 
Not on JK, I'm asking specifically what CAN protocol you are using in YAML script dashboard
AND
What battery brand under lithium battery you are using in your LXP SNA 5k?
inverter set .png
 
paulsteigel said:
on JK OVP is 3.55V, current limit for charge 100A, discharge 100A but I have addition layer of limits on esphome with max_cell_protection of 3450mV and Charge current limit of 70A. On SNA, Charge limit is 100A but it listened to the BMS via CAN, Voltage was 57.4 (default set for lead acid and still kept as it is). Lux stop charging at some period and reported W025 - Battery High voltage). He changed to lead acid and charge went well without problem. Haiza - this is headache. This did not happen with another guy usign SNA6K. He even push the current to almost 80A
View attachment 206255
Click to expand...
57.4v is a high charge voltage assuming a 16s battery. General guidance is to bulk charge at 3.45v per cell, so 55.2v.
This will give sufficient headroom for balancing without triggering OVP, etc, but also fully charge the battery.
 
You must log in or register to reply here.

Similar threads

B
JK BMS CAN info
Replies
4
Views
456
LEumel
L
meetyg
JK BMS cell UVP ‐ Prevents charging via AIO inverter
Replies
5
Views
432
Skypower
S
K
Cell Over Charging in JK BMS
2
Replies
26
Views
865
ScrotusGobbleBottom
ScrotusGobbleBottom
H
Failed JK BMS
7 8 9
Replies
161
Views
14K
Capt Bill
Capt Bill
djnitehawk
Yet another erratic SOC readout case of JK BMS :-(
Replies
6
Views
1K
Ucatchmydrift
Ucatchmydrift
Back
Top