OK, I've thought about this some more, and the current scheme seems wrong.

As a user I expect each battery segment to signify 25%, so when the first
segment disappears, this should mean 75% is left. Under the current scheme,
it means 80% is left. And worse, we are extinguishing all segments as early
as 19% - that doesn't make sense.

I think we can fix this and improve on it. First we can lift the battery
level count restriction (as I mentioned recently I'm working on this:
http://www.rockbox.org/bugs/task/4783) so a WPS designer can use however
many battery segment bitmaps they choose.

With that in mind, assuming the designer wants 4 battery segments as before,
I propose:

0 = 0-[danger level]%, no segments visible, device will shut off shortly

(assuming 4 enums are used)
1 = [danger-level+1]-25%, 1 segment visible
2 = 24-50% 2 segments visible
3 = 51-75%, 3 segments visible
4 = 76-99% 4 segments visible
(assuming 4 enums are used)

5 = 100% (optional, can be used to show a 'completely full' bitmap)

The danger level should be derived from the estimated time remaining, eg.
when only 10 mins are left, so it's consistent over a wide range of original
and replacement batteries.

This scheme would be backwards compatible, and should also correct the
segments on all existing WPS'.

Are there any problems with me implementing this?

--
gl
----- Original Message ----- 
From: "gl" <gl@ntlworld.com>
To: "Rockbox development" <rockbox-dev@cool.haxx.se>
Sent: Sunday, March 05, 2006 9:39 AM
Subject: WPS battery levels wrong?
>
> I'm confused about the number of WPS battery levels.  The CustomWPS online 
> docs suggest there are 5 ("0-4"), and 4-segment battery bitmaps are 
> common.
>
> However, the code in gwps-common.c does this:
>
> int l = battery_level();
> *intval = l / 20 + 1;
>
> Which produces 1-6, presumably:
> 1 =  0-19%
> 2 = 20-39%
> 3 = 40-59%
> 4 = 60-79%
> 5 = 80-99%
> 6 = 100% (fully charged)
>
> You can confirm this with:
> BATTERY: ?%bl<1,2,3,4,5,6>
>
> Shouldn't the code use / 25?
> --
> gl