[POWER] battery calibration parameters from sysfs

[POWER] battery calibration parameters from sysfs

[Pavel Machek]

Hi!

> > If you browse down to line 275 you can see it parse the sysfs
> > attribute "capacity", then this propagates up to the battery
> > status indicator on *all* Android phones out there. So if
> > you want to run Android unmodified, this is what you need to
> > provide. They are effectively using the power sysfs as
> > their hardware abstraction layer in this case.
> 
> Oh dear.  Using the power sysfs as the hardware abstraction seems
> perfectly reasonable but assuming that a given battery driver is going
> to have this level of information doesn't match up with an awful lot of
> actual charger hardware.  My main concern here is that battery
> performance monitoring has no pressing need to be in kernel and that
> pushing it into the kernel creates a barrier to implementing more
> advanced schemes in userspace, which is especially serious given how
> involved this needs to be in order to be accurate.  

Well, kernel provides /proc/apm emulation and many systems still rely
on it. So it would be nice to provide something halfway-decent there.

Plus you need to shutdown/suspend machine on battery critical. That
has to be in kernel and already needs those tricky parts.

(Sharp got it wrong in collie kernel, and you get 5hours instead of 10
with old battery :-(().

> I'm not sure how familiar you are with the issues surrounding trying to
> do a voltage to charge mapping for a battery but it's much more complex
> than a simple table if you want to get it accurate.  There's a lot
> of

Well... current zaurus kernels use _huge_ table that maps voltage to
battery %... and that table is linear function :-(.

Do you have some papers on that?

> dependence on particular operating conditions and things do change as
> the batteries age.  There are systems out there that do the work
> required to gather the information in hardware and it's definitely good
> to report the information from them but that doesn't mean it's a good
> idea to try to synthesise the information for other systems.

So... on zaurus I plan to:

1) provide better voltage -- %age map

2) estimate current

3) estimate internal battery resistance as constant

4) estimate internal battery volltage using ohm's law and base %age
 estmate on that.

Now... I realize that internal resistance depends on charge left. Nasty
but probably can be ignored. Then it depends on temperature. Does
anyone have better idea how?

Then... I need a way to measure internal resistance. I know it is in
200mOhm to 400mOhm range, on my device. Is there easy way to measure
it more accurately?

									Pavel
#!/bin/bash
#
# Copyright 2009 Pavel Machek <pavel@ucw.cz>, GPLv2
#

getval() {
    SETTLETIME=5
    echo Run this on idle, unplugged system, with expansion cards
    echo removed and backlight enabled
    echo
    echo 1 > /sys/class/backlight/corgi?bl/brightness
    echo Backlight 1, waiting for power to settle
    sleep $SETTLETIME
    VBMIN=`cat /sys/class/power*/*battery/voltage_now`
    VBMIN=$[$VBMIN/1000]
    echo Voltage = $VBMIN mV

    echo
    echo 47 > /sys/class/backlight/corgi?bl/brightness
    echo Backlight 47, waiting for power to settle
    sleep $SETTLETIME
    VBMAX=`cat /sys/class/power*/*battery/voltage_now`
    VBMAX=$[$VBMAX/1000]
    echo Voltage = $VBMAX mV

    echo 1 > /sys/class/backlight/corgi?bl/brightness
}

fake1() {
    # Very old 1000mAh battery from collie: 703 mOhm
    VBMIN=3638
    VBMAX=3543
}


fake2() {
    # Old 2000mAh battery, nearly charged, 4C: 274 mOhm
    VBMIN=3732
    VBMAX=3695
}


fake3() {
    # Same old 2000mAh battery, nearly charged, 4C: 140 mOhm
    # temp: 155.
    VBMIN=3714
    VBMAX=3695
    # Next try: temp 151 -- little warmer: 422 mOhm.
    # Next try: temp 151 -- little warmer: 1266 mOhm.
    # Next try: temp 148 -- getting warmer: 281 mOhm.
    # Next try: temp 148 -- getting warmer, full load: 422 mOhm.
    # Next try: temp 148 -- getting warmer, full load: 140 mOhm.
    # Next try: temp 148 -- getting warmer, full load: 422 mOhm.
    # Next try: temp 138 -- getting warmer, full load: 422 mOhm.
    # Next try: temp 139 -- getting warmer, full load: 422 mOhm.
    # Next try: temp 136 -- getting warmer, full load: 562 mOhm.
    # Next try: temp 132 -- getting warmer, full load: 703 mOhm.
    # Next try: temp 132 -- getting warmer, full load: 281 mOhm.
    # Next try: temp 134 -- getting warmer, full load: 281 mOhm.
    # Next try: temp 134 -- getting warmer, full load: 562 mOhm.
    # Next try: temp 129 -- getting warmer, full load: 562 mOhm.
    # hugh, I''m getting n*140, wtf?
    # ...voltmeters have sensitivity limits...
    # temp 118 -- metro, venku zima -- full load: 281 mOhm.
    # temp 118 -- metro, venku zima, baterie poloprazdna -- full load: 281 mOhm.
    # temp 120 -- metro, venku zima, baterie poloprazdna -- full load: 281 mOhm.
    # temp 120 -- metro, venku zima, baterie poloprazdna -- full load: 281 mOhm.
    # temp 120 -- metro, venku zima, baterie poloprazdna -- full load: 414 mOhm.
    # temp 120 -- metro, venku zima, baterie poloprazdna -- full load: 555 mOhm.
    # temp 120 -- metro, venku zima, baterie poloprazdna -- full load: 422 mOhm.
    # temp 124 -- metro, venku zima, baterie poloprazdna -- full load: 422 mOhm.
    # temp 127 -- metro, venku zima, baterie poloprazdna -- full load: 422 mOhm.
    
}



getval
#fake1

BLDIFF=135
echo Assuming $BLDIFF mA difference

echo $VBMIN $VBMAX $BLDIFF

# With RESIST in mOhm
#	VINSIDE = VBMIN + RESIST * BASECURRENT / 1000
#	VINSIDE = VBMAX + RESIST * (BASECURRENT + BLDIFF) / 1000
# Therefore
#	RESIST = 1000*(VBMIN-VBMAX)/BLDIFF

RESIST=$[(1000*($VBMIN-$VBMAX))/$BLDIFF]
echo Resistance is $RESIST mOhm

BASECURRENT=280
echo This should be equal:
echo During  low backlight $[$VBMIN + ($RESIST * $BASECURRENT) / 1000] mV
echo During high backlight $[$VBMAX + ($RESIST * ($BASECURRENT + $BLDIFF)) / 1000] mV

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[POWER] battery calibration parameters from sysfs

[Mark Brown]

On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote:

> > actual charger hardware.  My main concern here is that battery
> > performance monitoring has no pressing need to be in kernel and that
> > pushing it into the kernel creates a barrier to implementing more
> > advanced schemes in userspace, which is especially serious given how
> > involved this needs to be in order to be accurate.  

> Well, kernel provides /proc/apm emulation and many systems still rely
> on it. So it would be nice to provide something halfway-decent there.

Unfortunately that's really painful in kernel since you really need to
do state tracking over reboots, and even if you do that it's really
not trivial.

> Plus you need to shutdown/suspend machine on battery critical. That
> has to be in kernel and already needs those tricky parts.

Power failure detection based on voltage drop is much more reasonable
but it's a very different thing to general battery capacity estimation.

Normally you'd want to do the power failure detection separately anyway,
monitoring the system supply voltage rather than the battery voltage.
Supply failure is not only an issue in battery operation, it's also an
issue for example in systems systems powered over USB which may be
drawing more than the 500mA that USB delivers and need to supplement the
USB supply with the battery.

> > I'm not sure how familiar you are with the issues surrounding trying to
> > do a voltage to charge mapping for a battery but it's much more complex
> > than a simple table if you want to get it accurate.  There's a lot
> > of

> Well... current zaurus kernels use _huge_ table that maps voltage to
> battery %... and that table is linear function :-(.

> Do you have some papers on that?

Something like "Measure Battery Capacity Precisely in Medical Design"
by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be
useful here.

[POWER] battery calibration parameters from sysfs

[Pavel Machek]

Hi!

> > > I'm not sure how familiar you are with the issues surrounding trying to
> > > do a voltage to charge mapping for a battery but it's much more complex
> > > than a simple table if you want to get it accurate.  There's a lot
> > > of
> 
> > Well... current zaurus kernels use _huge_ table that maps voltage to
> > battery %... and that table is linear function :-(.
> 
> > Do you have some papers on that?
> 
> Something like "Measure Battery Capacity Precisely in Medical Design"
> by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be
> useful here.

Well, that would really require extensive hardware modifications: it
needs _way_ more accurate ADCs on battery for a start, and a way to
generate huge load.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[POWER] battery calibration parameters from sysfs

[Aras Vaichas]

2009/12/15 Pavel Machek <pavel@ucw.cz>:
> Hi!
>
>> > > I'm not sure how familiar you are with the issues surrounding trying to
>> > > do a voltage to charge mapping for a battery but it's much more complex
>> > > than a simple table if you want to get it accurate. ?There's a lot
>> > > of
>>
>> > Well... current zaurus kernels use _huge_ table that maps voltage to
>> > battery %... and that table is linear function :-(.
>>
>> > Do you have some papers on that?
>>
>> Something like "Measure Battery Capacity Precisely in Medical Design"
>> by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be
>> useful here.
>
> Well, that would really require extensive hardware modifications: it
> needs _way_ more accurate ADCs on battery for a start, and a way to
> generate huge load.

I've worked on several battery powered devices and battery monitoring
is very hard to achieve without a deep understanding of the chemistry,
circuitry and the algorithms. Large current loads can cause the
battery voltage to drop and therefore there can be a significant
voltage drop between measuring the quiescent and the loaded battery
voltages.  I once did try to implement an algorithm which took into
account the different battery voltage during heavy current drain but
it's hard to know how to interpret that data.  One of the RFID systems
I worked on could run the user interface for days on a low battery but
a single RFID read would cause the system to die due to the internal
resistance current drop ...

One of the easiest ways to monitor the battery is with a coulomb
counting method (accumulate current going into and out of the battery)
e.g. "LTC4150 - Coulomb Counter/Battery Gas Gauge"
http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1003,C1037,C1134,P2354

As long as you aren't draining very large amounts of current from the
battery, the accumulated current measurement should be almost equal to
the amp-hour rating of the battery.

Unfortunately the simple coulomb counting chips have the disadvantage
that the CPU has to be running to accumulate the pulses. Of course,
the pulses could wake the CPU from a suspend mode, but I'd rather not
do that just to add "one" to a counter ...

Finally we decided on a fully integrated "smart" battery monitor
device like the DS2782
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4779. This chip has
Linux device driver support, I got the driver from Ryan Mallon at
Bluewater Systems. It was fairly complex to set up and calibrate but
we now use it in a commercial product.

I recommend having a look at the datasheet for the DS2782 to see what
methods they use for determining the remaining charge in a battery and
to get an idea of the complexity of the problem.

Good luck!

Aras Vaichas

[POWER] battery calibration parameters from sysfs

[Bill Gatliff]

Aras Vaichas wrote:
> Unfortunately the simple coulomb counting chips have the disadvantage
> that the CPU has to be running to accumulate the pulses. Of course,
> the pulses could wake the CPU from a suspend mode, but I'd rather not
> do that just to add "one" to a counter ...
>   

Could you have the coulomb-counting chip connected to a tiny
microcontroller, or even a dedicated hardware counter?  Then the main
CPU wouldn't need to wake as often, it could just ask the
microcontroller over I2C, or read/reset the hardware counter.


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

[POWER] battery calibration parameters from sysfs

[Aras Vaichas]

2009/12/15 Bill Gatliff <bgat@billgatliff.com>:
> Aras Vaichas wrote:
>> Unfortunately the simple coulomb counting chips have the disadvantage
>> that the CPU has to be running to accumulate the pulses. Of course,
>> the pulses could wake the CPU from a suspend mode, but I'd rather not
>> do that just to add "one" to a counter ...
>>
>
> Could you have the coulomb-counting chip connected to a tiny
> microcontroller, or even a dedicated hardware counter? ?Then the main
> CPU wouldn't need to wake as often, it could just ask the
> microcontroller over I2C, or read/reset the hardware counter.
>
> b.g.

Yes, but in that case you might as well just purchase a coulomb
counter with a built-in accumulator and an I2C/SPI/microwire interface
save yourself some PCB space and cost (maybe)

Google for, say,  "coulomb counter i2c" and you'll get something like
this: http://eu.st.com/stonline/products/literature/ds/15269.pdf as an
example

The only time we used a pulse-and-polarity-output coulomb counter was
with an ATmega128. The CPU had to run all the time in order to
maintain its RTC so we could use it to accumulate pulses as well. It
wasn't a Linux project though.

Aras

[POWER] battery calibration parameters from sysfs

[Stanislav Brabec]

Aras Vaichas wrote:

> Yes, but in that case you might as well just purchase a coulomb
> counter with a built-in accumulator and an I2C/SPI/microwire interface
> save yourself some PCB space and cost (maybe)

Well, Pavel attempts to implement a "poor man's Coulomb counter" or at
least "poor man's Ampere meter" for devices that are not equipped with
any of it.

- We know the time.
- We know the backlight power consumption, it's dependent only on
  brightness.
- We know how much eats the HDD and how long it is on.
- We know how much eats the CPU and companion chips (it is not as
  stable, but it eats less).
- We don't know, how much USB host eats, but we know how much USB
  clients claim to eat.
- Well, and we don't know how much eats CF and SD.

=> We can guess how many Coulombs the device already consumed. If the
Coulomb counting would be inaccurate, we can at least correct voltage ->
remaining energy table using current power consumption guess.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

[POWER] battery calibration parameters from sysfs

[Andy Green]

On 12/15/09 23:32, Somebody in the thread at some point said:

Hi -

>> Yes, but in that case you might as well just purchase a coulomb
>> counter with a built-in accumulator and an I2C/SPI/microwire interface
>> save yourself some PCB space and cost (maybe)
>
> Well, Pavel attempts to implement a "poor man's Coulomb counter" or at
> least "poor man's Ampere meter" for devices that are not equipped with
> any of it.

I think the "poor man's Coulomb counter" is a loser, the errors will 
overwhelm you too rapidly.  The estimated rate of discharge could work, 
based on what clocks, regulators and so on are running, but I am not 
sure how useful that number is really given you can't realistically 
integrate it due to the big error it is bound to have.

I didn't see it mentioned yet but the biggest problem I saw with battery 
state monitoring by voltage alone is what happens during charging: the 
charger is artificially raising the voltage by an amount depending on 
current limit in the charger and battery capacity level.  That's what 
you see when you go and look at battery voltage during charging.

Otherwise for L-ion batteries, looking at the voltage level alone, 
filtered to remove GSM transmit slots etc, is really quite workable for 
estimating charge status.

-Andy

[POWER] battery calibration parameters from sysfs

[Pavel Machek]

Hi!1


>>> Yes, but in that case you might as well just purchase a coulomb
>>> counter with a built-in accumulator and an I2C/SPI/microwire interface
>>> save yourself some PCB space and cost (maybe)

Hardware is already given.

>> Well, Pavel attempts to implement a "poor man's Coulomb counter" or at
>> least "poor man's Ampere meter" for devices that are not equipped with
>> any of it.
>
> I think the "poor man's Coulomb counter" is a loser, the errors will  
> overwhelm you too rapidly.  The estimated rate of discharge could
>> work,  

Actually android phones do "poor man's Coulomb counter", and it seems
to mostly work.

> based on what clocks, regulators and so on are running, but I am not  
> sure how useful that number is really given you can't realistically  
> integrate it due to the big error it is bound to have.
...
> Otherwise for L-ion batteries, looking at the voltage level alone,  
> filtered to remove GSM transmit slots etc, is really quite workable for  
> estimating charge status.

Well, you have to compensate for backlight power; and yes, that's what
I'm trying to do.
								Pavel 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[POWER] battery calibration parameters from sysfs

[Pavel Machek]

On Mon 2009-12-14 12:12:47, Mark Brown wrote:
> On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote:
> 
> > > actual charger hardware.  My main concern here is that battery
> > > performance monitoring has no pressing need to be in kernel and that
> > > pushing it into the kernel creates a barrier to implementing more
> > > advanced schemes in userspace, which is especially serious given how
> > > involved this needs to be in order to be accurate.  
> 
> > Well, kernel provides /proc/apm emulation and many systems still rely
> > on it. So it would be nice to provide something halfway-decent there.
> 
> Unfortunately that's really painful in kernel since you really need to
> do state tracking over reboots, and even if you do that it's really
> not trivial.

No, I do not want to get _that_ advanced. But I'd really like to get
beyond "battery %age is linear function of measured battery voltage".

> > Plus you need to shutdown/suspend machine on battery critical. That
> > has to be in kernel and already needs those tricky parts.
> 
> Power failure detection based on voltage drop is much more reasonable
> but it's a very different thing to general battery capacity
> estimation.

Not sure...

> Normally you'd want to do the power failure detection separately anyway,
> monitoring the system supply voltage rather than the battery voltage.

Well, that way you'll discharge batteries too much and kill them
rather quickly, no? What is "system supply voltage" for PDA class
system, anyway? I don't think zaurus has ADCs on anything else than
thermistor, AC in voltage, battery voltage...

> Something like "Measure Battery Capacity Precisely in Medical Design"
> by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be
> useful here.

Thanks, it looks interesting. I'm not sure if it will be possible to
apply on zaurus, but... (While measuring voltage my underestimate the
old battery, I'm afraid they may overestimate it in bad conditions;
energy left is battery is useless if battery can't supply enough
current to keep CPU happy, because its too cold).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html