How to Predict Battery Status?

[marloh]

I am working on an IOT project and our device is run on on a Renogy RBT100LFP12S Battery. I would like to give our users a rough prediction of the battery status, a simple percentage of "battery life" remaining.

My initial plan was to sample the voltage of the battery at the terminals and to determine the battery depletion that way. So I decided to plot the discharge curve of my battery. So I hooked my battery up to a 15ohm power resistor and depleted a fully charged battery as I sampled voltage. This worked nicely and I got a nice discharge curve. Then I calculated a polynomial using python that would predict battery percentage as a function of voltage. That equation came out to be:

B_s(v) = -1.189 v⁵ + 100.9 v⁴ - 3105 v³ + 4.511*10⁴ v² - 3.158*10⁵ v + 8.614*10⁵

I though that this equation would do a decent job at predicting the battery percentage. The problem is that when I hooked my battery up to my actual device the discharge graph was much different. Firstly it was quite noisy, but that was an easy to fix with a simple rolling average. But once the graph was smoothed out it didn't match the discharge curve with the power resistor as well as I'd hoped. I'm now questioning my entire approach to this problem!

My questions for the community are:

• Is using a polynomial equation to predict battery life reasonable?
• Is there a way to predict battery life without a specialized IC?

Note:Pay no attention to the fact the resistor discharge curve and the device discharge curve shut off at different voltages. I accidentally used a different protection board during testing.

[nctnico]

Unfortunately this is extremely hard to do. Some battery packs use Coulomb counting but this needs to be reset at full charge to give a relevant SOC as Coulomb counting suffers from accumulating errors due to integration. When I need to implement a battery empty status, I look at both voltage and SOC. If the voltage is not low enough for the battery to be empty, the assumption is the SOC of way off and I use a voltage based estimation of remaining battery time. IOW: you can use the voltage level for the situation where the battery is nearly full or nearly empty. Bonus points for taking temperature in account. Anywhere in between depends on Coulomb counting but if the battery hasn't been fully charged this won't get reset.

[Siwastaja]

Terminal voltage is theoretical open-circuit voltage minus current * ESR. But ESR is very much temperature dependent and also not a constant but varies over SoC. Therefore, first step to better result is to test using similar current than the actual load. I guess your actual load was much smaller (higher resistance) than your test load. You can also run discharge at two significantly different currents and inter/extrapolate more discharge curves for different currents.

There are massive differences in curve flatness between li-ion chemistries and even products with the "same" chemistry. Most LFP cells are quite flat, meaning it is hard to see SoC from the voltage because the contribution of internal resistance and whatever noise is significant. On the other hand, classic LCO and modern NCA cells optimized for high energy density (as used in phones, laptops, EVs etc.) are often much less flat and it's fairly easy to see the SoC form the curve, like, it's nearly linear from 100% @ 4.15V to 15% @ 3.50V or so. But LFP is more difficult.

There is silver lining though: when discharge currents are very low, then the ESR drop becomes meaningless. So maybe the only thing you are missing is, you have to characterize the discharge curve at much lower current. Try that first.

Coulomb counting is sometimes the only key to accurate SoC numbers but it's a huge can of worms. You need reset points and those are voltage based because there is nothing else available in physical reality.

[jbb]

You can buy “fuel gauge” chips for this job. I think some likely suppliers are Texas Instruments, Analog Devices, Renesas, maybe NXP and likely several others.

The good ones will combine voltage sensing and Coulomb counting.

[jbb]

Maybe something like the BQ34Z100-R2?

https://www.ti.com/product/BQ34Z100-R2

[djacobow]

I built an SoC model for my old employer and a specific battery using a programmable power supply and programmable load, along with a fair bit of python to control them, plus a hot plate and pot of water.

What I did was charge the battery fully at room temperature. Then, I discharged the battery at 0.1C. every few minutes I would stop discharging and then load/charge the battery at several levels, including 0, measuring the voltage at each load/charge rate and pausing several seconds between each measurement, then resume discharging, repeat.

For example for our battery, the battery overall discharge was at 100mA, but when taking measurements, I used -200, -100, -50, 0, 50, 100, 200mA.

After discharging the battery completely, I charged the battery again and discharged it again at a different temperature; 0C, room temp 23C, 40C, 60C, and 80C (we were using a battery that claimed it should handle that ). Temperature was controlled by immersion in Ziploc baggy in heated water or ice water with thermocouple to monitor)

Then this was repeated with several copies of the same battery model.

After I collected all this data, more python scripts converted this data in an SoC as a function of measured voltage, load, and temperature. You can use a fitted polynomial or just a 3D lookup table and interpolation.

Collecting the data took several weeks of careful administration of the setup.

The final outcome was a pretty decent, not perfect model of battery soc that was reliable across a wide temp range and loading, which was important to use since we could not in our application just totally unload the battery to get a Voc measurement.

It was a lot of effort, though.

[Siwastaja]

The final outcome was a pretty decent

Yeah. What it misses is aging model. Reduced capacity due to aging is not a big problem; voltage scales "automagically" so that if 3.6V was 50% initially, 3.6V is still 50% even if capacity is reduced. (So pure voltage-based without coulomb counting gets the capacity drop right easier than a coulomb counting solution, that is, if your output is % and not Ah!). But increase in DC ESR is trickier, rendering those initially collected discharge curves wrong. In this regard, coulomb counter would win.

To compensate, you would need to monitor application current and voltage and detect current peak patterns (dI during operation) and then calculate dV during those events and track how it changes and adjust the curves. Again more work.

A very good "fuel gauge" IC should be able to do this, but the usual problem here is companies like Benchmarq (acquired by TI) flooding the market with gazillion of poorly (too quickly) engineered parts. Too many parts in too little time. After getting burned (quite literally) once or twice, I stopped designing in BQ anything. Doing battery management or power conversion "from scratch" is indeed a lot of work, but so is committing half a year to a design cycle, then recalling sold units and starting over. That costs even more. Developing decent li-ion management might be half a year of software work but at least you can fix it with a firmware update instead of recall and redesign.

You should be able to cope with battery management ICs by looking at which parts are extremely popular and copying the whole designs (assuming yours is similar enough), but be careful choosing parts from the catalog ("oh, this part looks nice, it does exactly what I need!") and especially be careful with appnote reference designs, they are often completely wrong.

[Gribo]

The current crop of TI's BQ are quite decent. But even with an IC, its software, driver and dev kit, all of which have already implemented many different chemistries, battery characterization takes quite a lot of time, and sometimes your cell source changes in the middle of the process.

[djacobow]

Yeah. What it misses is aging model.

True.

I think what kills me about this is that the battery manufacturers don't do this detailed characterization, or, if they do, they do not provide the data you need to build a great model. If you are lucky, the datasheets have a couple of tiny graphs. This seems to be the norm from fly-by-night Chinese companies to highly respected big-name brands.

When I'm designing a product, I really detest getting stuck in ratholes that take me away from the core goal of the product, especially ones that are generic enough that they should have been taken care of by "the industry" already. Knowing the state of a battery cell is one of those. I think for most products, it doesn't matter because the battery life is just a "best effort" sort of thing and most customers are conditioned to expect charge levels to be inaccurate. However, I just came off a design cycle where we were designing a completely wireless solar powered product that needed to work indefinitely in a wide variety of circumstances and exposed to massive temperature swings, and it was just a complete slog.

[Siwastaja]

If you are lucky, the datasheets have a couple of tiny graphs. This seems to be the norm from fly-by-night Chinese companies to highly respected big-name brands.

I'm certain respected big-name brands have true characterizations of their products, they must have, massive R&D has gone into these high-tech products. It's just that you need to be a big name yourself (and commit to buy a million cells) to get into the real documentation. This is more about hearsay from the industry; I have never been in a position to see such "real documentation" myself, but it must exist.

"Fly-by-night" company would more easily give you exactly the documentation you want, with the specifications you want

When I'm designing a product, I really detest getting stuck in ratholes that take me away from the core goal of the product, especially ones that are generic enough that they should have been taken care of by "the industry" already.

We all do, yet way too often it's the best to bite the bullet early on and try to build as wide experience as possible and solve as many problems from scratch as possible. I think I'm fairly successful doing that, with of course some failures. But really the other option incurs massive delays and puts a lot of trust into others, who are equally prone to failure.

This is the same story when it comes to a chip design or use of software library. If it's easily available and testable within hours, then do it. But if dead end follows after dead end, it's usually a good idea to get one's own hands dirty. At the same time you are building value in the company by adding own IPR.

But if the problem is large and team is small, risk for failure is high anyway. You can offload only so much. Attempts to make complex products out of "already solved" modules very often fail due to lack of customization of those modules, or outright failure of the modules to provide what they promise at all (very typical). So regardless of the strategy (heavy use of existing work vs. do from scratch), resources must scale with the complexity of the deliverables, and unfortunately the relationship is not linear, 30 people cannot do 10x the complexity of a team of three.

[nctnico]

If you are lucky, the datasheets have a couple of tiny graphs. This seems to be the norm from fly-by-night Chinese companies to highly respected big-name brands.

I'm certain respected big-name brands have true characterizations of their products, they must have, massive R&D has gone into these high-tech products. It's just that you need to be a big name yourself (and commit to buy a million cells) to get into the real documentation. This is more about hearsay from the industry; I have never been in a position to see such "real documentation" myself, but it must exist.

I'm not sure. Back when I was doing work for a battery manufacturer who is buying cells in large volumes, they didn't seem to have access to detailed data for the cells at all. I think the problem is that cells are primarily developed by chemists, metallurgists  and mechanical engineers who have very little understanding of what information is required to integrate their product into a system. So this information doesn't make it to the outside -if it even exists-. It is kind of like the mechanical drawings of many connectors. These are drawn to produce a connector, but not to integrate them into a PCB; essential information like board edge, rotation and positioning of a mating connector is missing.

[mtwieg]

Maybe something like the BQ34Z100-R2?

https://www.ti.com/product/BQ34Z100-R2

I had tried this one out (or rather the BQ34Z100-G1, an earlier revision I guess) a couple years ago for use with a SLA battery (it still seems to be the only fuel gauge chip which supports PbA chemistries, for some reason). Bought the dev hardware along with a specific battery model which I knew matched one of their existing chemids. Long story short, it was a huge waste of time because their development software BQstudio is a raging dumpster fire. The process for customizing the chip for your application is thirty steps long, and I couldn't get more then five steps in before some show-stopping bugs manifested. I'm convinced that the only chance of successfully using these chips is with direct support (as in from the factory via an FAE, likely under NDA. Support on their public E2E forums was unhelpful).

Perhaps most of the other "BQ" chips which are just AFEs and not gas gauges are a different story.

Maxim also makes a family of gas gauging ICs, look up "modelgauge". I had played with the dev tools for one of them, and while complicated it at least seemed to function. Unfortunately it didn't support my SLA chemistry.

[jbb]

Ah. That sounds extremely annoying.

[tomasA]

I am working on an IOT project and our device is run on on a Renogy RBT100LFP12S Battery. I would like to give our users a rough prediction of the battery status, a simple percentage of "battery life" remaining.

...
My questions for the community are:

• Is using a polynomial equation to predict battery life reasonable?
• Is there a way to predict battery life without a specialized IC?

• If you had a fixed load yes, but it's an IOT device so the power consumption severely depends on how often you have the device "awake" for.
  

[li] Maybe, If the device is awake for a fixed amount of time, e.g 70% asleep, 30% awake. You could record a few runs and then recalculate your polynomial. Which would work until you change the awake/asleep ratios. [/li][/list]