I've now completely implemented this, as well as enabling arbitrary battery
and volume level enums (and various other WPS features & fixes) - it's
exactly right.

Patch & demo WPS here: http://www.rockbox.org/bugs/task/4802

Note that there's a change from my previous example; there is no step 5
anymore - this wouldn't have worked as charging and draining %bl variations
need to work off the same enum count. It's not needed anyway.

Assuming the 'original' off + 4 segments, this gives us the same 0-4 as in
the Wiki, with these schemes:

Charging:
    0 = 0-24% no segments lit
    1 = 25-49% 1 segment lit
    2 = 50-74% 2 segments lit
    3 = 75-99%, 3 segments lit
    4 = 100% 4 segments lit

Draining:

    4 = 100-76% 4 segments visible
    3 = 75-51%, 3 segments visible
    2 = 50-26% 2 segments visible
    1 = 25-[danger-level+1] 1 segment visible
    0 = [danger_level]-0% no segments lit

Where danger level is currently < 15mins estimated remaining time.

--
gl
----- Original Message ----- 
From: "gl" <gl@ntlworld.com>
To: "Rockbox development" <rockbox-dev@cool.haxx.se>
Sent: Tuesday, March 07, 2006 2:55 AM
Subject: Re: WPS battery levels wrong?
>
> 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
>
>