Software based SOC

[Chris Hobson]

Ever since I discovered that the Axpert has worthless state of charge(SOC) readings I have felt that with a bit of lateral thinking one could develop a reasonably accurate SOC from the battery amp readings that are readily available from the inverter. After all it does have an internal shunt and so should be able to give us some sense of SOC. I have been playing with data from Emoncms and this is the result.

 

I include the feed from the BMV and the inverter's own SOC calculation for comparison. I am pleased with the result. The first thing I did was convert my battery bank Ah value into Ampseconds. I did this for two reasons:

1. The handling of the data after this conversion was relatively simple
2. Converting the Amp feed into Ah resulted in small numbers which of had a recurring decimal number which the computer would truncate and introduce errors. So I have upgraded (not really) and have a 936000As battery bank. It looks impressive but it is not really.

If anyone is prepared to send me the data from their inverter I would like to test my ideas on more data - preferably from one 100% SOC peak through one or two charge cycles until a 100% SOC is achieved again. I would need inverter battery amps and BMV SOC for this period.

[Mark]

As discussed with Chris... this could make the BMV redundant for some although I do use it for Mid Point readings...

Shot Chris!

[Chris Hobson]

14 hours ago, Mark said:

As discussed with Chris... this could make the BMV redundant for some although I do use it for Mid Point readings...

I think a BMV's midpoint capability is more important than its SOC capability and coupled with a relay a BMV is always going to be part of one's strategy to ensure optimal usage of batteries. A software SOC will help where a BMV is not available and the algorithm has been incorporated into 3rd party software. The software SOC's weakness is it loses accuracy if there is any loss of battery amp feed from the inverter and one then has to wait until the charge cycle has completed to reset 100% SOC. Here is the software SOC till this morning.

[___]

Fwiw, Victron now also has a software SoC calculation (since version 2.0 of Venus). I think how they do it is they use the SoC in the Multi, and feed it with data from the external solar chargers. Traditionally the SoC in the Multiplus only works properly if the Multi itself does the charging. By bridging the information gap, you get a better SoC determination. In other words: Software SoC is a real possibility. I think it can be made quite safe by underestimating the efficiency values.

In the end you're doing numerical integration of a current figure over time (ampere times hours). Visually, if you take an ampere figure I every Δt seconds, and you draw little trapesiums to calculate the area under the chart, and this area is then the amp-hours. The shorter the Δt, the closer the value will be to the actual value, and the larger the Δt, the greater the discrepancy. With highly variable loads, the accuracy will suffer, and with stable linear loads it should be very accurate.

If I recall there is a way to estimate the maximum error, but I cannot remember what it is. I'd think by simply adding a bit of experimental weighting to it so it sits on top of or slightly under the BMV figure, should be sufficient. From your chart it seems the calculated one sits a little higher than what the BMV says, so just multiply it by a 0.98 fudge factor or something and I expect you'd get a pretty useable SoC meter.

[Chris Hobson]

Discharge is fairly easy. I do have some heavy loads but not long enough to really see Peukert's Law having a marked influence on SOC. So discharge is just cumulative.

Charging should be nearly 1:1 up until 80% and then some other factor for charging above that, but I found that if I use a fudge factor of 0.85 for all charging I got a very workable SOC. I have just created a virtual EmonCMS feed to test my ideas.

[___]

25 minutes ago, Chris Hobson said:

not long enough to really see Peukert's Law having a marked influence on SOC

Peukert's law doesn't say that Amp-hours are going missing. What it says is the USABLE capacity of the battery goes down with high discharge rates (ie Watt-hours are going missing). The largest contributing factor to this is simply what can be called voltage efficiency.

For example, if you discharge a 100Ah battery at 20A (C5 rating) for one hour, it might pull the voltage down to an average of 12.5V, so you get 20*12.5 = 250Wh. If you discharge it at 5A instead for 4 hours (C20 rating) you will do the work at an average of maybe 13V, so you get 5*13*4 = 260Wh. You just magically got an extra 10Wh for the same Ah budget.

As you get to lower SoC levels, the internal resistance of the battery increases and you start to lose even more power to heat, but the Ah budget is still the same.

Similarly on recharge, some energy is lost due to coulomb inefficiency, heat, and gassing and of course this happens at the higher absorption voltage so in terms of watts the losses are greater, but similarly the losses will be mostly proportional to the charge current so that a simple linear fudge factor should be good enough. The biggest trouble with lead-acids is that they start accepting less charge current, forcing you to prolong the recharge process. This is where most power is lost: The batteries aren't full yet and there is plenty of sun, but I just can't fill them up faster than 2 coulombs per second (aka amps)!

[Chris Hobson]

After two days the relationship between the BMV SOC and software SOC had started to deteriorate. I did a sync on the software SOC. In the interim the BMV SOC had had 3 automatic synchronisations. The software SOC will need automatic synchronisation conditions much like the BMV.

 

[Dylanjiva]

Hi Chris, I have also been trying to get a software based SOC. Thought you might be interested in this post: