Battery life estimation considered impossible?

[Martin Dengler]

On Thu, Apr 17, 2008 at 06:40:21AM -0400, Richard A. Smith wrote:
> Martin Dengler wrote:
> 
> >3. minutes_left = battery_capacity_pct / 0.59. 
> > [. . .] but of course the approach is fatally flawed.
> 
> Sorry I'm a bit late to respond.  My attention has been elsewhere.

It was well worth the (very small) wait.  Thanks.

> Accurate battery life estimation is going to present a challenge.  
> The first issues that come to mind are:
> 
[. . .]
> 
> The power draw is of course going to dominate the above issues and 
> the good news is that by using the data from accumulated current 
> register inside the battery you can get a very accurate reading on 
> how much juice you have used between any 2 instances in time. 
> (Assuming the battery isn't removed)  So if you were to take ACR 
> readings and build up some sort of usage profile then that might get 
> you close enough.

Notwithstanding the high accuracy and interest value of your list of
issues, the statement that power draw dominates and the ACR data would
very useful is very promising.

> Batteries are also uniquely identifiable since the gas gage chip has 
> a 64-bit unique id and we repoort that in the battery driver.  So I 
> suppose you could build up a little database over time of the 
> profiles of all the batteries the XO has seen.

Cool.  I wonder where such code should live - presumably not sugar's
model/devices/battery.py?

> I use the ACR and battery ID in my power profile script.
> 
> http://dev.laptop.org/~rsmith/olpc-pwr_log
> 
> See here for how to process ACR data:
> 
> http://dev.laptop.org/~rsmith/process-pwr_log.py

Cool...

> I do think some sort of current power draw indication and history 
> would be a useful item.

So much so that extending the battery UI might be interesting?  If
not, see my next comment...

>  In particular it would be useful in assisting the user when working
> with a solar panel.  To maximize your results on solar you have to
> align the panel with the sun.  Watching the power draw should allow
> you to figure that out.  It just needs a few extra options for
> setting a faster sample rate, telling ohm not to suspend, and then
> present some sort of workload that makes the power draw fairly
> constant.

Sounds like enough of a spec for an activity.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080417/3cd3075a/attachment.sig>