[Gta04-owner] bq27000-battery: battery is not calibrated! ignoring capacity values

Dr. H. Nikolaus Schaller hns at goldelico.com
Tue Feb 5 08:36:43 CET 2013


Am 05.02.2013 um 00:27 schrieb EdorFaus:

> On 02/04/2013 05:01 PM, Bob Ham wrote:
>> On Mon, 4 Feb 2013 16:11:48 +0100, Radek Polak <psonek2 at seznam.cz> wrote:
>>> On Monday, February 04, 2013 12:55:30 PM Bob Ham wrote:
>>> 
>>>> On Sun, 3 Feb 2013 20:20:47 +0100, Radek Polak <psonek2 at seznam.cz>
>> wrote:
>>>>> Until the problem is really understood it would be very easy to use
>>>>> "charge_full_design" if "charge_full" is not available
>>>> 
>>>> Actually, I don't think this will work.
> 
>>> Hi, i dont get this. Why it should not work?
>> 
>> Because the value will never change :-)
> 
> I think you're missing that this value is not *supposed* to change.
> 
> This is the value that marks the "full" endpoint on the charge scale, so that we can use the "charge_now" value to see how much charge we currently have relative to a fully charged battery.
> 
> The "charge_full_design" value doesn't have to be read more than once because it's burned into an EEPROM in the battery, and thus won't really ever change for that battery. It's the value the battery was designed for, unlike the "charge_full" value, which is the actual value as measured during calibration. (That *can* change, but rarely does, especially since calibration involves running the battery all the way to empty.)

I think the charge_full_design is just a value flashed to the EEPROM at production test. And since it is "by design", it is probably representing the 1200 mAh specification of the cell manufacturer.

So it may be quite different from the real operational capacity
* because production variance of the cell (it may be advertized as typically 1200 mAh but may not have it)
* because it is measured by a different definition of "capacity" (e.g. different voltages for "full" and "empty")
* because it is defined at a different temperature
* because capacity depends on how smoothly (constantly or intermittently) the battery is discharged.

> 
> Technically I suppose the "charge_full_design" value could change at runtime if the user swapped out the battery without rebooting, but I think all the currently available batteries were designed for the same charge, so probably have the same value anyway.

As far as I know the FIC battery type is "HF08" and the last digit/letter denotes a production batch. I have seen mainly HF083, HF084, HF086, HF08C.

All these report the same charge_full_design so it is indeed constant. Maybe someone of the guys working previously for Openmoko, Inc knows a little more background about this.

Now the interesting thing is how the real capacity is influenced by useage.

Some weeks ago I checked a handful of batteries. Some results:

* the best battery was not the one with the least number of cycles (it did have approx. 50 cycles)
* there was a battery with 300 cycles but a higher capacity than the worst one which did report ca. 40 cycles
* none was in "not good" condition, although they all are between 3 and 5 years old and have been used
* none of them did reach charge_full_design but only approx. 90%.

So this indicates that # of cycles does not correlate to charge_full which means:
* batteries are not getting much worse by long storage or useage
* charge_full_design is never reached and appears to be based on a different definition of "capacity"

A final factor influencing battery values may be the way the fuel gauge works. It is a milli-ohm resistor converting the current into a voltage and that is amplified and processed by an ADC. So there are three factors that can influence the precision:
* the shunt resistor has a tolerance and is temperature dependent
* the reference voltage within the ADC has a tolerance (but may be temperature compensated)
* the ADC may have some offset

Without having analysed that I would expect that the whole measurement process may have an error of up to 5%. Which is good enough FAPP [1].

So what do we do if the charge_full value is not available?

I can propose to use the battery voltage and simply estimate the filling level by

100 * (Vbatt - 3300 mV) / (4250 mV - 3300 mV) => charge level in %

This is a rough estimate (and may indeed become negative some minutes before the device shuts off - the GTA04 works down to ca. 3.2V).

And reading the real Vbatt goes through the hwmon (/sys/devices/platform/twl4030_madc_hwmon/in12_input). For sample code see here:

http://git.goldelico.com/?p=gta04-rootfs.git;a=blob;f=debian/config/root/charger

This also works with the GTA01 battery.

Nikolaus

[1]: http://en.wikipedia.org/wiki/For_All_Practical_Purposes


More information about the Gta04-owner mailing list