• Have you tried out dark mode?! Scroll to the bottom of any page to find a sun or moon icon to turn dark mode on or off!

diy solar

diy solar

JKBMS Inverter Edition Problems/Issues | No Support / Help to fix major issues. - DO NOT BUY ! Warning (as of Oct.12.2024)

Imagine if JK (or any manufacturer) made a very precise shunt that communicated with the BMS for SOC... It could even be integrated into the BMS...
Seems like the ideal solution.
The current solutions seem like a joke, no jk'ing around...
There will still be a problem, I use a Lynx shunt, I set the Ah to 280 which is the advertised capacity of the cells, but in theory you only get 280Ah if you use the full voltage range, another problem is the cells often actually have less or even more capacity, and of course that changes through out the cells lifetime.

If the voltage method was usable then it would be more reliable and not be prone to the above issues once upper and lower voltages are set, but I do wonder why so many manufacturers, Victron included count the Ah in and out, if voltage was reliable surely they'd use it.

PS no issues with my Smart shunt, seems very reliable.
 
I have a thought.

Provide a switch that lets the user decide the method. One option would use voltage as described by @Steve_S and the other option would be the approach @Nami mentioned.
No
Logical error
Voltage and capacity are not completely proportional
We will provide solutions,
Open our soc-ocv curve
 
This formula does not seems to take into account of charging/discharging efficiency of the battery. In real-world battery systems, there are always energy losses during both charging and discharging due to internal resistance, heat generation, and other factors.


Just give us the option to reset SOC to 98% and maintain it 98%, when all cells voltage are above SOC100%Volt settings value, switches to 99% and maintain it 99% during "Controlled Float Charge" (RCV Time and this will give sufficient time for active balancing to take place), then change to 100% (after RCV Time completed) and the RFV Time begins.......
库仑计数法通过累计传入或传出电池的电荷来计算剩余容量。这种方法的精度主要取决于对电池电流的精密测量和对初始SOC的精确估计。利用一个预知容量(可以是存储器记忆的或通过工作条件初始估计的),电池的SOC可以通过充电和放电电流对运行时间的积分来计算。然而,可释放的电荷总是少于充放电周期中储存的电荷。换言之,充电和放电期间会有损耗。这些损耗加上自放电,会引起累计误差。若要更精确地估计SOC,就必须考虑这些因素。此外,应当定期重新校准SOC,并应考虑可释放容量的衰减以使估计更准确。
 
Last edited:
@Nami I believe I found a bug. I have 2 JK BMS one configured as a master and one as a slave it communicates with CAN to my Victron Cerbo which uses DVCC which controls the DCL CCL via the info it is getting from the JK BMS. When I use one phone to communicate via bluetooth no issues I see 250A DCL (125A per BMS) but when I use a second phone to pair with the other BMS the DCL toggles between 125A and 250A very few minutes. Maybe timing issues in the firmware my assumption would be RS485 had lower priority then bluetooth.

So as long as I communicate to only one of the BMS (does not matter which one) it works fine but when using both bluetooth there are issues. Both BMS use 15.30

EDIT: Correction If I communicate continously with only one it happens less frequent but still happens.

JK BMS Bluetooth issues.png
 
Last edited:
Running Nami's last response through a translator:

"The Coulomb counting method calculates the remaining capacity by accumulating the charge that passes in or out of the battery. The accuracy of this method depends primarily on the precise measurement of the battery current and the accurate estimation of the initial SOC. Using a predictable capacity (which can be memory memory or initially estimated by operating conditions), the SOC of a battery can be calculated by integrating the charge and discharge currents into the runtime. However, the dischargeable charge is always less than the charge stored during the charge-discharge cycle. In other words, there is a loss during charging and discharging. These losses, combined with self-discharge, cause cumulative errors. These factors must be taken into account for a more accurate estimate of the SOC. In addition, the SOC should be recalibrated periodically, and attenuation of the releasable capacity should be considered to make the estimation more accurate."
 
JK Precision is NOT that good.
I have never seen it register an Amperage less than 0.2A, In or Out.
Low Voltage In/Out is also not registered apparently.

The software can only register what the hardware used allows for. If the hardware is not density enough to be accurate down to Low Voltage/Amperage that will limit the accuracy.
 
No
Logical error
Voltage and capacity are not completely proportional
We will provide solutions,
Open our soc-ocv curve
From the voltage to soc table it very much appears that the voltages are only usable to determine SOC on the ends of the curve. Hence everyone counting AH's. There may need to be more logic to "reset" the current SOC/AH remaining when the battery is in the ends of the curve were the voltages are useful.
I have by resetting my BMS a couple of times got it to fully charge the battery, and once it was fully charged the SOC seems close to right (for the moment after 2-3 discharges to around 25%). I have noticed that when changing the AH in the bluetooth app the battery SOC seems to be hardwired to use 68% (or so) no matter what the current voltage of the battery is. This would appear to need better logic when the battery voltage is in the ends of the curve.
 
JK Precision is NOT that good.
I have never seen it register an Amperage less than 0.2A, In or Out.
Low Voltage In/Out is also not registered apparently.

The software can only register what the hardware used allows for. If the hardware is not density enough to be accurate down to Low Voltage/Amperage that will limit the accuracy.

The issue would be that if you have to register up to say 200A-300A(surge) then 200.x is already 4 significant figures and would require at least a 11-12 bit ADC converter that is accurate and reasonable fast. Going down to .01 would need a 16bit adc. I am betting they do not have a 16-bit adc.

Based on my messing with mine, the AH counter seems okish, so long as the battery accurate finds 100%. It would seem that on the 100% end that the bms must keep charging the battery until the voltages rise in such a way that you know you are at 100%. The same thing would need to be done on the lower end were the voltages also change quickly. Without resetting to a known point in the curve (say if you stay 30% - 80% for a bunch of cycles) then the SOC is going to drift. From my tests I was able to force a reset to a known point by changing the AH value and getting the battery to default to 68% (when it was say 75%) and then charge it from there such that it did hit the voltage rise/100%. With that mine seems okish on the low end, but based on voltages seems to not really be getting to 100%.

I have not upgraded my JK bms firmware yet, so have an older version (no real reason to upgrade since the only issue I have is the SOC bug and that bug is still supposed to be in the new firmware).
 
SOC based on Voltage provides a reasonably good approximation for a "generic" BMS. Meaning a BMS capable of multiple chemistries. If it was a dedicated LFP only BMS some additional things could be done to tighten up the slack that comes from Compromising.

IMO: for this use case & device.
Reset to 100% State should only be set once AVG Cell Voltage reaches that target 100% setting in BMS config. That is also the point where the Change to Float signal needs to be sent to charge course (AIO/SCC's etc) if networked. When AVG cell Voltage hits target, the majority of cells will be in-line and should be a minimal deviation and by then Active Balancing should already be leveling up the lower cells. Inverter Model of BMS is Better at it.

The gotcha is the Depth of Charge which is not similar to FLA DOD in the case of Li tech. (that causes much grumble)
A more appropriate way to consider Li-DOD is "Saturation" and that's where EndAmps/TailCurrent comes into play. As the IR of the cells increases the amps taken drops as it is in essence "push filling the tank" or putting it under pressure (play on words). If you have a 280AH pack the EndAmps is 14A. Start charging at 140A and the cells will reach target voltage of 3.450ea and immediately the Amps Taken starts to drop (back pressure if you will) and that will continue to fall till EndAmps which is the point where the cells are at 100% Saturation and no further charge is needed OR desired. It's the chemistry that guides this, as it does with others as well relative to their specs. Upon reaching endamps, transition to Float for finishing & topping. Still on coffee #1 maybe not best explanation, long night. This is simple if you have 1 pack but with a Bank it's not so simple and THAT's where a lot of folks fall over into the tip.

PS: I should add, that no generic BMS that I have seen has ANY settings / values for Pack EndAmps/TailCurrent. Left to the domain of the external charging devices. Now in EV-Land it is factored and used for controlling & throttling of fast charging as it relates to the specific pack, but then again due to EV Architecture which controls all charging at the Vehicle which in turn "tells" the charger what to throttle and by how much. (simplest explanation).
 
Last edited:
I know it doesn't solve all the things that people want from the closed-loop communications, but I am wondering if something like the logic the Victron Smart Shunt uses to SoC reset to full would be close. It uses three settings that the user provides: Full voltage, tail current, and charge detection time. Here's the logic: If the battery voltage reaches the "charged voltage" and then the current drops to or below the "tail current" for at least the "charge detection time" the SoC is set to 100%. This has worked fine for any of us using the Victron Smart Shunt, and it keeps the SoC from drifting constantly (as the JK BMS seems to).

As current is drawn out of the battery the shunt is doing Coulomb counting to keep track of the SoC ups and downs. The above logic is just used (in the case of solar) for getting the SoC set back to 100% based on the observed behavior of the charging.

Things don't quite work as planned in the event of somewhat large loads hitting the system while the battery is not quite done charging, but it works most of the time.
 
Last edited:
I know it doesn't solve all the things that people want from the closed-loop communications, but I am wondering if something like the logic the Victron Smart Shunt uses to SoC reset to full would be close. It uses three settings that the user provides: Full voltage, tail current, and charge detection time. Here's the logic: If the battery voltage reaches the "charged voltage" and then the current drops to or below the "tail current" for at least the "charge detection time" the SoC is set to 100%. This has worked fine for any of us using the Victron Smart Shunt, and it keeps the SoC from drifting constantly (as the JK BMS seems to).

As current is drawn out of the battery the shunt is doing Coulomb counting to keep track of the SoC ups and downs. The above logic is just used (in the case of solar) for getting the SoC set back to 100% based on the observed behavior of the charging.

Things don't quite work as planned in the event of somewhat large loads hitting the system while the battery is not quite done charging, but it works most of the time.
Most good Smartshunts like the Victron, Wizbang and similar do it just that way, although the software is different but pretty much the same.
Reach present 100% Voltage, wait for TailCurrent/EndAmps to indicate full saturation & reset to 100% on transition while holding state @ 98/99% till TailCurrent reached to ensure full capacity charging as determined by the pack resistance..

Devils Cap in the ring...
This is an External Shunt and has no idea if its 1 Pack or 10 pack in parallel. It only sees the "whole" of whatever is on the other end of the cable. This ultimately requires "Compromises" and crap load of tweaking to get it right, especially if you have finicky battery packs. TailCurrent is relevant to the AH of the pack but not a bank as such.

The "Ideal" would be to have the BMS look at, the Pack Resistance for the TailCurrent value for that pack (it could easily calculate the TailCurrent value as it knows the AH rating) and take action based on that, as described above. That allows each pack the "independence" of handling its charge process. Then if you have 10 Packs in a Bank and each pack can switch to float upon reaching Tailcurrent you could not end up overcharging any pack in a bank. It would actually be a wise & prudent extra "Safety Feature". This would also enable better charging within a closed loop system because the packs that are NOT at TailCurrent can take whatever the cells permit while those that are are reduced to floating. YES coding would be required for the management aspect of that.

EndAmps & TailCurrent are the same thing, just different terms used by manufacturers. Not like it isn't complicated enough eh...
 
Last edited:
Interesting......but there is one issue with the RFV Timer reset 100% proposal. What if during that duration, there is a huge load on the battery pack? Assuming if I used the capacity down from 99% to 80%, it will be a bad idea to auto reset it to 100% after the timer ran its course.

One of the youtube video post an interesting proposal to automate the process.
1726399749557.png

JK will need to add another option which commonly known as "Tail Current" in Victron System, instead of that 10% of capacity, it will be more flexible if user can set the tail current him/herself.
 
Interesting......but there is one issue with the RFV Timer reset 100% proposal. What if during that duration, there is a huge load on the battery pack? Assuming if I used the capacity down from 99% to 80%, it will be a bad idea to auto reset it to 100% after the timer ran its course.

One of the youtube video post an interesting proposal to automate the process.
View attachment 244176

JK will need to add another option which commonly known as "Tail Current" in Victron System, instead of that 10% of capacity, it will be more flexible if user can set the tail current him/herself.
I hear Andy saying at the end, that the timer once started, will proceed. It will not be interrupted if the voltage drops again. So that sounds good to me.
 
They will never get this right. There are far too many edge cases where the actual solution may not work and people will just keep complaining and demanding. JK cannot keep up with demand (of new firmware and fixing 'bugs') and they have hardware limitations in terms of not enough memory in the inverter BMS. The limit of exposed parameters which can be changed by the user, has already been reached (due to bad design?), so demanding more and more will just not work with this BMS. Hence, they are trying to re-use existing parameters for certain functions (Continued Charge Current -5% = CCL, instead of providing a separate parameter for that setting, for example).
I'm receiving ~20 emails a week where people have great ideas how the JK should work and how I should convince the engineers and 'force' JK to implement all that. Most of these ideas will only fix the author's own edge case but will not help the majority of users. So, it is good you are discussing it here on 20+ pages to find solutions which will hopefully work for everyone...

Especially the SOC drift over time is something they cannot figure out. I wonder how other BMS manufacturer are doing this. I have a 100A JBD/Overkill in my battery shelf and this is mostly in line with the Victron Smart Shunt and even after months of no full charge it is not off by more than 5-8% of what the smart shunt claims. The other two JK BMS in that shelf are showing SOC beyond believe (up to 400% difference to the shunt).
A few weeks back, I discharged the batteries until all BMS turned off and showed 0%. You would think this is like a reset and while the BMS all started from 0% again, the 2 JKs sprinted far ahead and are showing unbelievable numbers for SOC after just a few days.

Yes, a tail current can be great but even this will cause issues under certain circumstances and will not correctly reset the battery to 100% in all cases (cloudy weather and loads just below solar production, both cause low charge currents and will cause premature resets). We have seen this in the PACE BMS which has a FullChargeVoltage and a FullChargeCurrent. Good but not ideal.

The Victron Smart Shunt adds another timer to that mix, so voltage, tail current plus timer before it resets to 100%. But where do you stop with all this? It takes weeks to fine tune this thing and even then, 5% of the full-charges are not recognised correctly and the shunt will not reset, because the circumstances are just not right to trigger it.

If you are a 'lucky' Victron user, you can probably just add a shunt and set this as the battery monitor and point of truth in your system. Let the JKs (or even other BMS) show whatever they want and just use them to monitor and protect your batteries on a cell level + enjoy the active balancer of the JK. Additionally, if communication is setup, you will get at least warnings from the JKs now if something goes out of specs, but accurate SOC comes solely from the shunt. Not a great solution but it works pretty well.

There is no winner here, neither us as users nor JK as the manufacturer. 🤷‍♂️
 
Hi Andy, nice to have you here too.
I for one welcome the current proposal of setting SOC to 100% after RCV Time expired.

At least there will be a positive drift rather than a negative drift for Growatt/Voltronic/Luxpower with SOC 99% before the RCV timer expired.
After all, these inverters will only recharge/rebulk again once the SOC is less than 95%.
Between 95% to 100%, these off-grid inverters performs zero-export between the solar production and battery with the solar being the priority where the battery will not be recharged at this 95%-100% range.

In Growatt/Voltronic inverter case, it ignores the float voltage command sent by the BMS.

Therefore, current proposal of setting SOC to 100% after RCV Time expired will work perfectly. I can just set the RCV Timer to 30 minutes for instance, drain the battery to 94% and the inverter will re-rebulk charging again while the JKBMS will hold 99% until RCV Timer expired, 100%. This is exactly the "positive" SOC drift that we need to ensure the battery is fully charged.
 
Especially the SOC drift over time is something they cannot figure out. I wonder how other BMS manufacturer are doing this. I have a 100A JBD/Overkill in my battery shelf and this is mostly in line with the Victron Smart Shunt and even after months of no full charge it is not off by more than 5-8% of what the smart shunt claims.

I'm pretty sure it's in part a hardware issue. The current measurement accuracy isn't what it should be over the entire range from 200A down to 0A to do state of charge calculations.
 
'm pretty sure it's in part a hardware issue. The current measurement accuracy isn't what it should be over the entire range from 200A down to 0A to do state of charge calculations.
You can see that in Andy's own amps calibration video, as soon as he calibrates at a set amp rate and then see what the accuracy is at different amps the JK starts to converge away from the meter readings the further the amps are from the calibration amps. So calibrate all you like, unless you then fix the charge rate to that rate the JK will start to diverge from reality as the amp flow varies.


The only fix is to use a more accurate shunt and overwrite the SOC using an intermediary such as that from Sleeper85 or JK fit a better current measurement component on their board.
 
They will never get this right. There are far too many edge cases where the actual solution may not work and people will just keep complaining and demanding. JK cannot keep up with demand (of new firmware and fixing 'bugs') and they have hardware limitations in terms of not enough memory in the inverter BMS.
Perhaps simplifying the number of protocols supported? Other vendors such as Midnite support PYLON period. While not ideal in potentially a number of cases, it might free up some memory requirements by reducing the amount of code needed. Just a thought. Maybe I am misunderstanding what is actually provided?
 
Perhaps simplifying the number of protocols supported? Other vendors such as Midnite support PYLON period. While not ideal in potentially a number of cases, it might free up some memory requirements by reducing the amount of code needed. Just a thought. Maybe I am misunderstanding what is actually provided?
Think limiting protocols would piss off another population of people. Using a 6000xp, Pylontech doesn’t provide full battery information like LuxPower protocol provides to the inverter which, I want. Everyone will have their own use case.
 
Everyone will have their own use case.

Good point. Wasn’t trying to upset anyone. Just wondering if simplifying the available options might be helpful. Is it possible that some units might be able to handle more than one protocol? I don’t know the answer to this.
 

diy solar

diy solar
Back
Top