Battery Gauge for small LiPo - Page 1
Forum section: electronics / projects

author: dingari
author_rank: Contributor
timestamp: August 25, 2017, 02:33:55 pm
content: Hi, I'm looking at ways to estimate the state-of-charge of a small LiPo battery (~25 mAh). I've looked at various ICs from TI and they all state a minimum battery capacity of 100 mAh on the site, while there is no mention of it in the datasheets.I've foundSTC3115to be the cheapest Coulomb Counting device. It doesn't state anything about the minimum battery capacity.What are my options? I can always read the voltage via ADC, which is what I'm doing as of now, but I want a more accurate battery level estimate.

author: HKJ
author_rank: Super Contributor
timestamp: August 25, 2017, 04:03:14 pm
content: Depending on how much precision you require, a simple voltage measurement may be enough.Changes in load current will affect voltage readouts.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 25, 2017, 04:16:28 pm
content: Coulomb counting is only more accurate than voltage sensing in specific applications, when done exactly right, and often cannot be offloaded to be handled by a separate IC in an easy attemp to let it do it and forget about it. This is because accurate coulomb counting interferes with the normal operation (necessitating both full charges and discharges to reset the integrator and update capacity count, and these need to be done fairly often).Voltage based follows the reduction of the battery capacity automatically through the lifetime of the product.In many cases, where simplicity is required, a simple voltage-based estimation gives worst-case accuracy of about 20-25%. Maybe the biggest issue is that, especially in cold environment, the battery gauge jumps depending on the current peaks, when the battery is near depletion. However, this is usually desirable, since it directly shows the user how close it goes to being shut down. This gives an intuitive "blinking" effect. An alternative is the coulomb counting gauge, which, in afairly good case, shows nice and steady 20% and then the device suddenly dies.While Coulomb counting may sound accurate on paper, it always bears the risk than unless designed in a complex, yet correct way, it is way more inaccurate than voltage-based estimation.Proper coulomb counting algorithms of course do the voltage-based estimation and use it as an override when coulomb counting is clearly wrong (for example: coulomb counter says 80%, voltage-based says 30%), but the problem is, you never know what the accuracy is, so you need to assume the accuracy of voltage-based only.Many off-the-shelf coulomb-counting li-ion battery gauge ICs are notorious of being far from robust.If you want to increase the accuracy of voltage-based, while keeping most of the simplicity and statelessness, you should implement current and temperature compensation. It's still orders of magnitude simpler and more robust than coulomb counting.OTOH, if you need to report the user the battery health in detail (percentage of original capacity), then coulomb counting is the only way to go.

author: colorado.rob
author_rank: Frequent Contributor
timestamp: August 25, 2017, 05:44:33 pm
content: The ADC method is perfectly fine. What you can do to improve accuracy is to characterize the load of the system while checking the battery level, and analyze a reasonable sample of cells to get their voltage discharge curves, measuring the voltage at the same load. You can then map the voltage to capacity fairly accurately.

author: krho
author_rank: Regular Contributor
timestamp: August 25, 2017, 08:35:21 pm
content: I've had numerous problems with STC. e.g. The thing won't start measuring no matter what you do if you push it through reset state. Even with the original driver provided by STM. The only thing it's good for is measuring battery voltage and the current running though the current resistor.

author: krho
author_rank: Regular Contributor
timestamp: August 25, 2017, 08:39:00 pm
content: The ones from TI are even worse. They want you to run a couple of batteries through high current charging/discharging so they can record the battery SOC curve. Then you save this into your MCU code and load it in production. The problem then becomes, if you have a long running product which you do in batches of 500. And every time you get the different battery. So now you have no way of knowing which profile to load.

author: stmdude
author_rank: Frequent Contributor
timestamp: August 25, 2017, 08:45:48 pm
content: Quote from: krho on August 25, 2017, 08:39:00 pmPfft.. They're a dream to use compared to Maxims MAX17040 chip.Me: "How does it measure SoC?"Them: "Magic.. Or, ModelGauge™.. One or the other"

author: Siwastaja
author_rank: Super Contributor
timestamp: August 25, 2017, 08:53:14 pm
content: Well, IMHO, if the manufacturer cannot even figure out the title of the product correctly, even remotely so, it has little chance of working. (gasgauge, what the f***?)Or maybe it was designed to measure amount of gas in the first place?Overcomplication, and some more overcomplication, and competiting on who's got the most complex and poorly specified black box, including nice algorithm names, has beenthe thingin li-ion-related IC industry fortwo decadesnow. I'm not sure, but it might be the legacy from Sony's "InfoLithium" brand.One would think that this is all mature technology, but no, we all know that there never is a reliable battery gauge available. We all know how mobile devices suddenly die unexpectedly, or show battery status that's totally nuts. Or just brick themselves and deny powering on ever again.Except those simple voltage-based ones, which jump over a little bit, but always give a good indication to the user (and work).I think no one wants false promises of 1 percentage point accuracy on their battery gauges. What everybody wants is that they freakin'just work.But yes, even though I say this, even I made a mistake of designing in ali-ion specificIC (from TI) in my latest design. I needed a synchronous buck controller to charge the battery, so why not use a specific "li-ion charger IC"? The funny thing is, it implements a complex algorithm, requires a bunch of passives to set up, but multiplexes two different values that have nothing to do with each other, and that, by definition, almostneverare the same, into the same selection resistor, and guess what, it does basically everything incorrectly, so that all those fancy "algorithm" things, like protection, need to bereplicatedin an external MCU, which would have been the right thing to do from the start, instead of believing in "easy" ICs. But at least I didn't fall into the trap of designing in a "gas gauge" let alone a BMS chip!Of course, for a non battery expert (afraid of rolling their own design from standard non-li-ion ICs and some code), such a chip would be an easy choice. The fact it fails, possibly catastrophically, may be revealed years later. But no one blames the designer, they used a TI or ST or whatever well-known product! The problem must be elsewhere. (Compare: "Nobody ever got fired for choosing IBM".)

author: amyk
author_rank: Super Contributor
timestamp: August 26, 2017, 04:15:42 am
content: Quote from: stmdude on August 25, 2017, 08:45:48 pmI think it's the same or similar, exclusively voltage-based algorithm that's explained here in more detail:http://www.richtek.com/en/Design%20Support/Technical%20Document/AN024http://www.batterypoweronline.com/conferences/wp-content/uploads/2013/06/TI_YandongZhang__dynamic_voltage_correlation.pdfVarious other companies make similar products:http://www.mitsumi.co.jp/latest/Catalog/pdf/battery_mm_3556_e.pdfPhones with removable batteries that don't have coloumb-counting ICs on them, yet provide reasonably accurate gauges, are probably using something similar.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 26, 2017, 07:21:52 am
content: The issue with coulomb counting is, how do you reset the integrator?The integrator can never be (at least in sub-$100 in parts) accurate enough so that it would work for the whole lifetime of the cell, track extremely small and large currents, and never drift.So, it needs to be reset, typically at least once per each 5 to 10 fullish cycles.How it is reset? Based on - tadah - voltage!But the coulomb countingexistsbecause the voltage based measurement is not accurate enough. So how can we reset it based on voltage?The answer is, we create a special condition where the voltage based measurement is more accurate. In practice, this means a full charge, so that the CV phase lasts long enough, so that the current tapers to small enough values, so that the DCR of the cell does not affect the SoC vs. V accuracy too much.But such a full charge is generally not recommended, since it's not oftenneeded, it reduces the battery lifetime a bit, and who wants to wait so long for a practically full battery to still charge a little bit? This full charge is used to top off the cell from, say, 95% to 100%, and it can last as long as hour or two extra, after the 95% point.So, in practice, people disconnect when the charge is almost finished. Which is agoodthing.But it prevents the coulomb counting (with the basic integrator reset algorithm) from working. Then the drift accumulates. Then, when you do this for weeks in daily usage, the SoC error can be anything, like 50%. And then the device suddenly dies while it lies to the user about "50% battery status".Better algorithms can compensate using several ways. The more you put complexity in, the better it gets, as long as you are doing the right things and testing them thoroughly. In practice, implementations are buggy, or doing wrong things. And even if they were perfect, theaccuracythat was our initial goal - and only reason - to use coulomb counting to begin with, is compromised when the "good" reset point is missing. And, it's very difficult to tell what the actual worst-case accuracy is, so there is always a lot of uncertainty, even if in optimum cases the accuracy can be very good (such as 1 percentage point of SoC)

author: Rerouter
author_rank: Super Contributor
timestamp: August 26, 2017, 08:33:09 am
content: I've done it with voltage in the past, but not as a % point, just 8 lines, 8 being full, flashing 1 being almost flat.I cant find the image right now, but a few of the hobby tesla style powerwall groups have done capacity vs voltage discharge graphs which show that you will never have a clean and linear relation between voltage and capacity. e.g. 4.0 to 3.9 might by 25% of the cells capacity, but 3.9 to 3.8 might be 2%. varying in weird ways each voltage step.So based on this info, My approach was to discharge the battery, install it in to my device and as it charged up, record the time it took to gain between steps, and then save those in a tiny section of eeprom as how many % each step represented. (I treated above 4.05V as full in my system, and 3.5V as flat, only wanted a rough representation)

author: Siwastaja
author_rank: Super Contributor
timestamp: August 26, 2017, 08:41:53 am
content: You are right, of course the SoC vs. V curve isn't linear.But it's trivial to store the expected curve in a LUT.As someone earlier stated, changing the battery types mid-production is an issue when the battery curve is stored. Still, if it is a similar type, similar chemistry, just from a different manufacturer, the chances are that it's close enough.

author: dingari
author_rank: Contributor
timestamp: August 28, 2017, 09:42:17 am
content: Quote from: Rerouter on August 26, 2017, 08:33:09 amYep, I always would have ended up doing something like that in the UI for the voltage based measurement.Thanks everyone for the input. It's clearly true that simple is better in this case (as it is most often).I'll probably try to map the votlage more accurately to the discharge curve in the end, but simple voltage based measurement is fine in the meantime.

author: marshallh
author_rank: Unknown
timestamp: August 28, 2017, 02:10:40 pm
content: I've been using the TI bq28z610 which has a custom 16-bit CPU core and upgradeable firmware. It is extremely flexible and has quite a high learning curve to get going. It is giving me very good results though.Probalby won't work for OP's situation though, for his maybe just use an ADC with voltage lookup table - discharge at the typical current, then map your percentages linearly onto the voltage range. For very low current loads, the voltage sag and rebound in relaxation are going to be very subtle compared to a large battery sourcing 3-4A intermittent loads.

author: stmdude
author_rank: Frequent Contributor
timestamp: August 30, 2017, 10:59:53 am
content: Just thought of something. When you're mapping voltage->SoC, even under constant load, temperature throws you a curveball.The discharge-curve gets offset by quite a bit if it's hot vs. cold. This might be an issue if you're designing something like a wearable (user moves from a varm room into sub-zero temps outside). I've ended up having three to five "mappings" of voltage->SoC depending on temperature (-5, 0, 15, 30, 45C for example), and interpolating between them depending on what the measured temp is.

author: plazma
author_rank: Frequent Contributor
timestamp: August 30, 2017, 11:29:59 am
content: A battery characteristics table works quite well for a software battery gauge. Battery voltage is measured by the MCU during a low current quiet moment. You also need battery temperature. The characteristics table is made by discharging the battery with a low current in different temperatures. Percentage is integrated so you have equal amount on energy between each percentage step. 10C steps are enough but around 0C in 5C steps. Percentage in 10% steps down to 20%. 5% steps down to 10%. 1% steps down to 0%.