Rockbox mail archiveSubject: Improved Battery Level Calculation w. Remaining Time Estimation (please test it!)
Improved Battery Level Calculation w. Remaining Time Estimation (please test it!)
From: Uwe Freese <mail_at_uwe-freese.de>
Date: Sun, 13 Oct 2002 01:40:10 +0200
The battery level was calculated in a very simple way: linear
interpolation between the BATTERY_EMPTY and BATTERY_FULL voltage, no
matter if the charger (recorder) was on or off.
I made some improvements, now I need some people to test it and your
opinion: Should I continue on this (and will the patch be accepted) or
do you find it useless (and the patch will be rejected). The patch is on
the sourceforge patch tracker:
You can find additional test results and explanations
(voltage graphs etc.) on http://www.uwe-freese.de/rockbox
my improvements in detail:
- The battery level (percentage) is more realistic and considers if the
charger is on.
- It considers the "lazyness" a battery shows when the charging has just
turned on or off (see below). But this is not perfect by now.
- The battery level is good enough to estimate the remaining running
time and the remaining charging time. And so the info screen now shows
- The maximum time of a charging cycle is now dynamically calculated out
of the battery level (percentage) and is not a fixed value.
- A minimum of 60 Minutes is waited after a charging cycle stops
before another one starts.
- Added another screen in the battery debug screen (press down three
Note: The charging algorithm (detecting the end of a charging cycle)
considers the raw voltage levels in the power_history-array. This is
- Two arrays (of 11 values, showing the voltage at 0%, 10%, ...100%)
build a realistic voltage curve (avg. of Magnus Holmgrens and my own
vales) that a NiMh cell shows when decharging and charging. The
percentage is calculated by linear interpolation between the two
values that fit most.
- The battery is "lazy". Example: When turning the charger on with 50%
full batteries, the voltage goes quickly up a little bit, but is lasts
some minutes to come close to the voltage level the battery would have
in the mid of the charging cycle when the charging had started with
empty (0% level) batteries.
To consider the lazyness, the voltage_to_percent values of both
arrays are taken and then an average is made. Not in the middle of
both values, but with an amount that depends on how long the current
charging/decharging cycle is running. That is implemented with another
- The remaining time is calculated out of a battery capacity (constant
in header file) and a usual decharging current (AJB is playing) or
usual charging current.
- For the player (where we don't control charging), the battery level is
always calculated out of the nocharge-array. Maybe we can detect a
charging start or stop by simply looking if the voltage goes up or
- The battery lazyness calculation is not good enough. Is is a first
approach. But a perfect one would mean no "jumping up and down" in the
current battery level when starting/stopping charging.
- The battery capacity should be configurable in the menu (1000, 1100,
... 2200 mAh).
- Consider if the backlight is on or maybe count how many seconds the
harddisk was on to make the remaining time est. better.
Now I want to know what you others think of my patch. If it is accepted
(what I hope), I would make it even better and complete the things I
- The patch should be tested with a recorder model to see the behaviour
when it's charging, but it does compile for the player also.
- The end-of-charging detection is untouched. So if this patch is not
perfect, this only means the new remaining time estimation is not as
good as it could be. But there should be no risk for the battery for
wrong charging. Anyway, test it with caution.
Received on 2002-10-13