Rockbox mail archive

• Next message: John Wood: "RE: max 200 entries in a dir. why?"
• Previous message: Uwe Freese: "Re[10]: Load time lags"
• In reply to: Heikki Hannikainen: "Re: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Next in thread: Uwe Freese: "Re[3]: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Reply: Uwe Freese: "Re[3]: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Reply: Heikki Hannikainen: "Re: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Hello Heikki,

Heikki Hannikainen wrote on Monday, August 12, 2002, 3:58:14 PM:

HH> The device is not powered from the charger unless the charger is
HH> connected to the batteries (charging enabled).

Hm. Understood.

>> - Charging algorithm 1 that can be used while using rockbox. Mainly a
>> simple trickle (if lower than x volts, turn on charging power).
>> x adjustable in menu (maybe only two values as it's now).
>> - Charging algorithm 2 that is started from inside the menu. The user
>> starts it and the AJB does a complete charging. The battery has to
>> be < 50% full for this (check voltage before). AJB cannot be used in
>> parallel when charging. The charging status is displayed with a
>> curve, time, voltage and everything that is interesting or even
>> useful. ;)

HH> I don't see why the charging should be started in the menu. After the

I thought that doing a complete charging and without using AJB in
parallel (for playing music), the parameters of the algorithm or the
algorithm itself would be different. (For ex. a smaller delta peak
value.)

Now I think it's best to make only one charging algorithm as it is
now. But: It could help to set variables "battery_was_empty" and
"ajb_unused" that can be used for the detection of the end of the
charging.

For example:

if ((ajb_unused && delta < -0.01) || (delta < -0.05))

HH> All of this can be seen in firmware/powermgmt.c and apps/debug_menu.c's
HH> view_battery(). The power thread cannot directly write to the LCD without
HH> messing up with whatever is currently running there, so it updates a
HH> global char[] variable and the foreground applications (the status bar,
HH> view_battery() etc) display them.

How about adding a status string of the charger thread to the battery
status display in the debug menu? It would be helpful for testing a
charging algorithm to see what it actually does! But I don't know how
I can do that.

-

Thanks for your hints. I'll look into the actual cvs code this
evening and test a little bit.

Bye, Uwe.

• Next message: John Wood: "RE: max 200 entries in a dir. why?"
• Previous message: Uwe Freese: "Re[10]: Load time lags"
• In reply to: Heikki Hannikainen: "Re: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Next in thread: Uwe Freese: "Re[3]: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Reply: Uwe Freese: "Re[3]: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Reply: Heikki Hannikainen: "Re: I, battery man ;-) (was: Question to powermgm.c charging algorithm)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]