Calculation of the SOC based on coloumb-counting

[cflenker]

SOC is calculated by integrating the current that flows in and out the battery.
The advantage of doing this in the driver is the ability to define the reset-conditions (current, voltage, debouncing-time).
This solves especially the problem of the famous jkbms that only resets the soc when you reach OVP (and the BMS switches off the charging-fets).

[mr-manuel]

Please do not merge with the master branch. You have to merge with the dev branch.

[mr-manuel]

I changed it, please update your branch to be up do date with the dev branch.

[cflenker]

Dear @mr-manuel,
Thank you very much for your reply! I will update the branch to be up to date with the dev-Branch.

[gurkc006]

I just had the same idea today and glad to find the "solution" here in the pull requests. Perfect. I would like to test this new feature, if it is ready for testing. I have also a small request: My JKBMS seems to have a small offset in current measurement. Over time, my SOC gets lower and lower (by around 2-3% per day). In summer this is no problem, because it resets every day, but now my SOC drifts down over time. It would be nice, if in calculation of SOC it would be possible do correct for such an offset in the settings of the calculation (maybe offset and span). Thanks.

[gurkc006]

Maybe also a topic here: Wouldn't it be possible to calc a current-corrected cell voltage for supporting estimation of SOC? What I mean: Has someone tried to assume an internal resistance of cables/cells and correct cell voltage with actual current flowing. This should give a quite smooth cell voltage which is not (or much less) affected by current flowing. It also would be possible to "learn" the internal resistance of a system using the current flucuations at different SOC to get better information, what SOC is. Do you get the idea?

[cflenker]

Hello @gurkc006,
I had the same issue. The current measurement of the JKBMS was about 5-8% higher than the measurement of the victron smartshunt. I doublechecked it with a clamp meter and it seems that the current of the smartshunt was quite correct and the jkbms was too high.
But there is a possibility to calibrate the current-measurement of the BMS in the jkbms-app. I just tried this and now smartshunt and bms seem to be much closer together.
I posted a picture of a day of soc measurement of the smartshunt and the bms-driver in this thread:
#869
Accordingly to the higher current measurement of the bms the soc of the bms drops faster than the soc of the smartshunt.
Let's wait if the SOC stays closer together now after the calibration of the bms.
If this works, we can perhaps do without an additional correction in the driver.
I assume, that the correction in the bms is only a factor on the measurement as the calibration can be done at a single operation point.

[gurkc006]

Hi cflenker,
thanks for your input. I already did a calibration right at the beginning when top balancing my battery for the very first time, because I had steady charge current from lab power supply. Now on the Multiplus II it's rather difficult to perform good calibration because current from or to battery is very unstable. Also I suspect, that I don't need a span calibration rather then an offset calibration and this is not possible with JKBMS app as far as I know. I see it, if my Multiplus is in idle, JKBMS thinks to see a small current flowing out of battery (around maybe 1 A). But that's 50 W... So over time this adds up. So for me it would be nice to see, if a offset/span calibration in the driver would lead to a better SOC calculation. But of course, if it's not necessary for many people I can understand, that you won't implement it in the driver. Maybe I try to fork for myself and try. But I never used github, so I hoped I can "attach" to guys like you, who are already doing gihub stuff :-) Thanks a lot

[cflenker]

Hi @gurkc006,
I recorded the current values of the victron bms and the jkbms for about 24h. Each point is the average of 30s.
Here is the result:

Based on the regression-line the jkbms is about 3.7% too high.
The bigger problem is the big deviation at low discharging values (-6...0A). Here the jkbms shows much higher values.
That's typical the current that is consumed during the night (0...300W).
I trust the victron smartshunt much more than the jkbms.
But if you implement a correction curve: I wonder who does the effort to measure out the curve.

[mr-manuel]

And the question is, if the curve is the same for all... I have measured the base load on my system and then calibrated the JKBMS on the base load that matches 16 of 24 hours of the day

[gurkc006]

Hi cflenker!
That's a great plot. And I would definitly try to produce such a plut for my setup. Maybe then we learn something, if it looks the same or not. Problem is, I have no Smartshunt... At the moment I only have a Fluke clamp current meter without serial interface, so I have to take value manually. But the good thing: In the morning I can have only my 4 MPPTs loading the battery starting from 0A to around 20A when sun is shining - so not at the moment :-( - and I can then take very undisturbed calibration points. Maybe I also can use the wires from battery to first junction to measre voltage drop and calibrate this with the fluke. So then I can use a normal good multimeter to log much more points. This will take some days, but I will definitly do this to see, if I can correct for this offset problem. I think, it would be best, if I just can define a pair of values to produce a calibration curve, so the serialbattery-driver can just linear interpolate between these point-pairs to correct the JKBMS curent values.
Thanks a alot for your work! Great!

[gurkc006]

This morning I just had the chance to take some values manually. So here are my results from loading my battery with MPPT this morgning:

As you can see, all points are on a good line. I thought about your data cflenker, and the "problem" is not the slope of your fit, because this should neutralize over time. So if JKBMS sees too high currents for charging and discharging, if you sum up all your (a little bit to high) positive and negative numbers, should still give 0 over time. But the offset of -0.25A is there all the time, so you should have also a drift down to lower values, because JKBMS has this offset for ALL values. And this results to a virtual self discharge rate of around 0.25A*24h = 6Ah/d = 2.1% per day (for a 280Ah battery).
For me this offset is around 0.32A*24h = 2.7% per day (for a 280Ah battery). This fits quite well with the numbers I see, if I don't charge my battery full ervery day. So potentially adding this offset to ALL current values coming from JKBMS should compensate for this offest and the virtual self discharge should be gone.
Will try to make some more measurements on sunday also for discharging the battery. Have a nice weekend.

[cflenker]

Thank you very much for your measurements! Your measurements fit very good to a straight line. That's the right way to do it. My measurements have been taken normal operation and this is a very unsteady state. Your measurement quality seems to be much better.
Your conclusion, that the offset of the regression-curve (0.25A oder 0.32A) leads to soc-loss per day is only valid if all points fit to a straight line. In your measurement this seems to be the case.
In my measurement it seems that the low current points are relativly too high.
Anyway - for the first look it seems to be sensible to do a slope+offset-correction.
The only point is, that if I disconnect the battery the jkbms shows 0 Amps. WIth the correction it would show 0.25A.

[cflenker]

I just added the option to make a current correction with offset and factor.
@gurkc006: If you want to try it, you can install this pre-release from my fork of the repo:
https://github.com/cflenker/dbus-serialbattery/releases/tag/v1.0.20231117dev_chfl231124

[cflenker]

The more I think about it, it would perhaps be better to make a separate scaling factor for positiv (charging) and negativ (discharging) current.
That would ensure, that 0A will stay 0A.

[cflenker]

I installed the driver on a friend's system. Here are the results of the last week. I installed the driver with coloumb-counting at late evening of 11/22:

I had no correction of the current applied.
For investigation-reasons I had no [0...100]-limitation of the soc.

[gurkc006]

I will install your driver tomorrow, when I'm at home again. Personally I would prefer a table solution for the correction. Something like in the other tables in the driver:
I_JKBMS = -20, -10, -1, 0, 1, 5, 10, 25, 70
I_ref = -19.75, -9.75, -0.75, 0.25, 1.25, 5.25,10.25, 25.25, 70.25
Then just linear interpolate between the values and use the last slope for bigger values than in the table. That would be the most flexible solution and maye it's also the easiest, because you don't have to caluclato gain and offset. Just take measurements at different currents and put it into table. What do you think?

[cflenker]

I agree. That would be the most flexible solution. But I would never calibrate it with someting else than 0Amps at 0Amps. When the Battery is disconnected the JKBMS measures 0Amps. And I would not want the driver to calculate a rising SOC over time when the battery is disconnected.
I will have a look how the interpolation can be done.
@mr-manuel: What do you think about that? Would you agree to spend the computing-time for that?

[cflenker]

I think it is a known fact, that the capacity of a battery depends on the discharge rate. This effect is much smaller at lifepo4 than at lead-batteries, but it is also present. It is called the peukert-exponent.
The smartshunt takes this into account (I calibrated it to 1.01). Theoretical it would be able to calibrate this effect into the correction-curve, but you can't do this with plain current-measurement.
Maybe we should think about taking this into account in a future version. (I did not completely understand how to take Peukert into account during charging).

This would explain, why the driver-soc ends up to low at low discharging current (yesterday) and quite correct at high discharging current (today).

[mr-manuel]

The correction with a table should be the simplest one for the end users. So they can measure the current at different values and compare the value with the BMS provided.

Most of them does not have even a current measurement tool. We try to keep it as simple as possible for the user. The question is also, how does this work, if you have multiple batteries? Is this very CPU intensive? Will a weak GX device also be able to handle that?

[cflenker]

Thank you @mr-manuel for your quick reply.
I will make a proposal for that. I would use the utils.calcLinearRelationship-Function.
And I would set the default of the look-up as short as possible:
SOC_CALC_CURRENT_MEASURED = -300, 300
SOC_CALC_CURRENT_REAL = -300, 300
It is calculated every second for the jkbms.
For my understanding it is calculated for every battery separately.

[gurkc006]

You can make it disabled as default so only users who want to use this feature can enable it in the ini- file?! Should be no problem as it's only maybe once per second to calculate the correction.

[cflenker]

I made a "prerelease" last night: https://github.com/cflenker/dbus-serialbattery/releases/tag/v1.0.20231117dev_chfl231125c
This is based on the official dev-branch from 17.11.2023.
It includes the latest "Calculation of the SOC based on coloumb-counting"-Feature and an alternative method for dynamic CVL I am just working on. Both are switched of by default.

I am just doing a few tests on my system with this v1.0.20231117dev_chfl231125c.

My configuration concerning soc_calc is the following:

SOC_CALCULATION = True
SOC_RESET_CURRENT = 7
SOC_RESET_TIME = 60
SOC_CALC_CURRENT_CORRECTION = True
SOC_CALC_CURRENT_MEASURED = -300.0, 300.0
SOC_CALC_CURRENT_REAL = -289.0, 289.0
SOC_CALC_INIT_VALUE = 25.0

[mr-manuel]

Until the merge you can use https://github.com/cflenker/dbus-serialbattery/tree/cflenker/soccalc

[gurkc006]

Installed this version two days ago, had a litle trouble with the installation because I didn't find a way to get the proper venus-data.tar.gz file. Had to build one on my own, but finally it seemed to work. Driver is running now, but nearly no sunlight at all in these days in germany... So only very little variation in SOC as my battery rests on 60% at the moment. Thanks for the great work!

[mr-manuel]

Did anyone track the CPU usage before and after this commit? That would be interesting.

[gurkc006]

How do I check? htop? Nothing to see. But haven't checked before.

[mr-manuel]

If you have an InfluxDB and Grafana you can run Telegraf with this version and the normal version.

[mr-manuel]

I added a check before this lines get executed:

                    # load SOC from dbus only if SOC_CALCULATION is enabled
                    if utils.SOC_CALCULATION:
                        if "SocCalc" in value:
                            self.battery.soc_calc = float(value["SocCalc"])
                            logger.info(
                                f"Soc_calc read from dbus: {int(self.battery.soc_calc)}"
                            )
                        else:
                            logger.info("Soc_calc not found in dbus")

[mr-manuel]

@cflenker relooking at the values after a bit of time the naming is a somehow not very clear.

SOC_CALC_CURRENT_MEASURED is this the value measured by the user or by the BMS?
SOC_CALC_CURRENT_REAL is this the real value from the BMS or the value measured by the user?

I will rename
SOC_CALC_CURRENT_MEASURED to SOC_CALC_CURRENT_REPORTED_BY_BMS
and
SOC_CALC_CURRENT_REAL to SOC_CALC_CURRENT_MEASURED_BY_USER
after you confirm me, that this is correct.

[cflenker]

Hello @mr-manuel , that is correct. Your proposal is perfect an very clear! Thank you!

[cflenker]

Thanks a lot for merging this PR!

[mr-manuel]

I tested the changes a bit further and made some little improvements. One thing is that you are currently saving the SocCalc as int to the dbus on change. Since you are calculating the SocCalc from self.soc_calc_capacity_remain would it maybe make more sense to save this value to the dbus instead? The bigger the battery is the more inaccurate the soc is.

Regardless of this, I changed the code in order that the soc has two decimals, so there is a smoother graph.

[cflenker]

Ohh, I did not know that you are reading the soc directly from the dbus. Then integer is surely not precise enough. I thought dbus is only to preserve the soc for a reset. Please feel free to change whatever you want. You are much experienced than I am with the driver. Thank you very much for your enhancements!

[mr-manuel]

I merged my changes. I would be glad, if you could also test the current nightly of the dev branch.

[cflenker]

I have some problems with the nightly. Please see #898

[mr-manuel]

@cflenker have you an idea how we could best add a method to reset also the SOC to 0%? Now one cell in my system reached 2.700 V, the SOC is 9 % and DCL is below 0.1 A.

[cflenker]

@mr-manuel : calibrating the soc at 0% is not very common. Most of the bms and also the smartshunt does not do this (afaik). But I do not see a reason why not. The reset should only be done if the lowerst cell drops below a voltage limit at low current for a certain time. If you want me to make a proposal, just tell me. But I am on a business-trip till the end of next week.

[mr-manuel]

The new JKBMS do this and the smartshunt does not see the cell voltages.

The reset should only be done if the lowerst cell drops below a voltage limit at low current for a certain time.

What if my battery is nearly depleeted and then a bigger load turns on and the whole system crashes because the BMS disconnect the battery? In this case I don't think that it has to be at this voltage for a certain amount of time. Once reached lowest disconnect voltage then it should be se to 0 %. Another thing would be, if you are using a voltage above the BMS under voltage protection. What would be the better value to use in your opinion?
On electric cars the 0% SOC is always above the BMS disconnect voltage from what I know.

[Vitalic66]

Hi, thanks for your work, just installed dev driver, because I also have big differences between Victron shunt SOC an JK SOC. Thinking about this solution, might give it a try. But why do you use -300,0,0,300? My JK can only handle up to 200A.

Another idea, isn‘t it possible to use the SOC meassured and calculated from the Smartshunt instead? So if it is allready installed why not using this SOC directly?

So using the charge and discharge logic from the driver with the SOC reported from the Victron smartshunt.

[Honusnap]

The new JKBMS do this and the smartshunt does not see the cell voltages.

The reset should only be done if the lowerst cell drops below a voltage limit at low current for a certain time.

What if my battery is nearly depleeted and then a bigger load turns on and the whole system crashes because the BMS disconnect the battery? In this case I don't think that it has to be at this voltage for a certain amount of time. Once reached lowest disconnect voltage then it should be se to 0 %. Another thing would be, if you are using a voltage above the BMS under voltage protection. What would be the better value to use in your opinion? On electric cars the 0% SOC is always above the BMS disconnect voltage from what I know.

You can't really set the "0% SOC" on a cell reaching a minimum voltage setting, as you said a high load at 5% SOC could maybe let the weakest cell drop under this voltage and set the SOC to 0%. Maybe a combination of total battery voltage and current, like 45V and under one Amp. => We are at 0% SOC usable.
Like you said, we... at least most people, will use their battery in a safe zone, i'm using mine between 10% and 95% REAL SOC. Now, to reset the coulomb counting we need to reach those limits( 10% and 95% REAL SOC), a 10kWh battery would then only have 85% usefull capacity (in my case) and those 85% are now the 0%-100% displayed SOC.

[Honusnap]

@mr-manuel : calibrating the soc at 0% is not very common. Most of the bms and also the smartshunt does not do this (afaik). But I do not see a reason why not. The reset should only be done if the lowerst cell drops below a voltage limit at low current for a certain time. If you want me to make a proposal, just tell me. But I am on a business-trip till the end of next week.

In your config.ini there are 2 values... is this config valid : (stock unmeasured device)

SOC_CALC_CURRENT_MEASURED = -200, -100, -50, -25, -10, -5, 0, 5, 10, 25, 50, 100, 200
SOC_CALC_CURRENT_REAL = -200, -100, -50, -25, -10, -5, 0, 5, 10, 25, 50, 100, 200

Can we use decimal numbers : 0.5 ?

[mr-manuel]

Your config is valid for an example, but would make no sense for a real config.

Yes you can use decimal numbers, as you see in the config.default.ini:

dbus-serialbattery/etc/dbus-serialbattery/config.default.ini

Lines 170 to 172 in ce2df1a

	; Example to set small currents to zero
	; SOC_CALC_CURRENT_REPORTED_BY_BMS = -300, -0.5, 0.5, 300
	; SOC_CALC_CURRENT_MEASURED_BY_USER = -300, 0, 0, 300

[Vitalic66]

So to have valid values we'd need a USB DC Amp data logger to have some values we can feed to the config.ini? Any good recommendations?

[Honusnap]

So to have valid values we'd need a USB DC Amp data logger to have some values we can feed to the config.ini? Any good recommendations?

I use values seen on the shunt, you can also use an hall effect current meter.

[Honusnap]

Here is what i got after some experiments :

Also trying with that :

[Huuh-17]

Hello, i need some help to create a code for a circuit with current sensor arduino lithium ion battery usb charger and lcd monitor i need to display the SOC using the coloumb counting method