Re: Battery Life Estimation: First try
On Sat, May 03, 2008 at 02:32:52PM +0100, Martin Dengler wrote: > Based on a g-p-m presentation[1] and the results[2,3] of my 5-10 minutes > of looking through the g-p-m source, it seems that g-p-m relies on the > HAL making "battery.remaining_time" (time-in-seconds) available. Those who do not understand history...: http://dev.laptop.org/ticket/31#comment:30 is the last mention of g-p-m and OHM and battery time remaining I can find, and it both says (effectively) g-p-m does have such a time remaining calculation, and implies that OHM does not. AFAICS g-p-m doesn't so I need to be educated/corrected by someone with more time / knowledge. There seems to be hope that someone knows the answer, so I hope they're still reading this list... > Martin Martin (replying to myself again) pgpNTCxj6yZCi.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery Life Estimation: First try
On Fri, May 02, 2008 at 10:07:25PM -0400, Richard A. Smith wrote: > Martin Dengler wrote: > >Martin > > > >1. Obviously I wouldn't want to submit my hack as a patch, but what > >should be done? Should we add this logic to the Hal so I can retrieve > >it via dbus? > > Dunno. dbus should perhaps be able to feed up the ACR value when > requested but I don't think its the place for the math. How does gnome > power manager do it?. Based on a g-p-m presentation[1] and the results[2,3] of my 5-10 minutes of looking through the g-p-m source, it seems that g-p-m relies on the HAL making "battery.remaining_time" (time-in-seconds) available. So it would appear that a hal addon/backend would be the place for the math, but I think I've made clear how much experience I have in these matters :). > >2. when I unplugged the AC and my XO/battery went from charging to > >discharging, I got a divide-by-zero error: > > Integer math issue. I was watching for the avg draw to be zero but not > the instantaneous draw. I added a check for DRAW_INST to be zero as > well. I don't have any XO's with me though so I can't test. Thanks for the problem-pointer for the incredibly lazy (me). Martin 1. http://people.freedesktop.org/~hughsient/public/gnome-power-manager.pdf 2. Line 315 in gpm-cell.c: http://svn.gnome.org/viewvc/gnome-power-manager/trunk/src/gpm-cell.c?annotate=2786 3. http://www.gnome.org/projects/gnome-power-manager/hal.html pgpUerPnrkNDE.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery Life Estimation: First try
Martin Dengler wrote: > Martin > > 1. Obviously I wouldn't want to submit my hack as a patch, but what > should be done? Should we add this logic to the Hal so I can retrieve > it via dbus? Dunno. dbus should perhaps be able to feed up the ACR value when requested but I don't think its the place for the math. How does gnome power manager do it?. > 2. when I unplugged the AC and my XO/battery went from charging to > discharging, I got a divide-by-zero error: Integer math issue. I was watching for the avg draw to be zero but not the instantaneous draw. I added a check for DRAW_INST to be zero as well. I don't have any XO's with me though so I can't test. -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery Life Estimation: First try
On Fri, May 02, 2008 at 04:24:10PM -0400, Richard A. Smith wrote:
> The script is available at:
>
> http://dev.laptop.org/~rsmith/olpc-bat_ttl
I've hacked[1] my {model,view}/.../battery.py to use your TTL_INST for
showing the user the time remaining.
Thanks for putting this together.
Martin
1. Obviously I wouldn't want to submit my hack as a patch, but what
should be done? Should we add this logic to the Hal so I can retrieve
it via dbus?
2. when I unplugged the AC and my XO/battery went from charging to
discharging, I got a divide-by-zero error:
...
1209766969,25,6894220,1376692,2888,12588,Charging,Normal,431,743,-33,-34
1209767030,25,6901540,1368880,2886,12644,Charging,Normal,454,766,-34,-33
/home/olpc/bin/olpc-bat_ttl: line 124: ((3600 * 767) / ((0 * 3600) / 61)) / 60
: division by 0 (error token is ") / 60 ")
pgpn4BAJtxvx9.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Battery Life Estimation: First try
Over the past week or so during my walk to and from 1cc I've been pondering about about battery life estimation. I've also had a conversation with a G1G1 user who made me realize that it really doesn't even have to be that accurate. It just has to be reasonable. Since my power logging script already had most of what I needed, I added the ability for it to make lifetime estimations based on the the ACR readings. Its a pretty simple first guess. Comments and/or improvements welcome. This script does 2 different ttl calculations every loop. One is based on the ave current draw from the start of the script and the 2nd based on the power draw since the last loop. My initial loop time was 60 seconds. Since its in log format I can compare the estimations vs reality. Using the time from the start of the script until the time that the EC reports LOW as the official marker I'm getting errors ranging from 66% to 1% The script is available at: http://dev.laptop.org/~rsmith/olpc-bat_ttl -- Richard Smith <[EMAIL PROTECTED]> One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
