Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
2009/12/15 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. 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 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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 b...@billgatliff.com ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
2009/12/15 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. 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 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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 ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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. ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [POWER] battery calibration parameters from sysfs
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 , 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,
