Rockbox mail archiveSubject: AW: AW: AW: AW: Bug: Battery Charging with low voltage
AW: AW: AW: AW: Bug: Battery Charging with low voltage
From: Matthias Klumpp <Matthias.Klumpp_at_gmx.de>
Date: Fri, 4 Feb 2005 19:59:02 +0100
Hi Jerry & Linus (hope you've seen this mail ;-)),
# -----Ursprüngliche Nachricht-----
# Von: rockbox-bounces_at_cool.haxx.se
# [mailto:rockbox-bounces_at_cool.haxx.se]Im Auftrag von Jerry Van Baren
# Gesendet: Donnerstag, 3. Februar 2005 21:52
# An: Rockbox development
# Betreff: Re: AW: AW: AW: Bug: Battery Charging with low voltage
# Throwing in my free advice (and worth almost as much)...
# Looking at powermgmt.c I picked out the following two snippets of code.
# The first snippet shows that if the deltaV charge completion isn't
I also browsed a little bit through the code:
charge_max_time_now is the estimated charging time (depending on bat. cap.
and current bat. level), right ?
CHARGE_PAUSE_LEN (=60min) is the timeout after that the algo re-tries to
charge, right ?
If I understand correctly, that means:
I'm sepcifying the correct bat.cap. in the settings, but due to low charging
voltage the algo. fails and pauses charging for 1h.
Meanwhile my real bat. cap. is much lower than estimated by the algo. and
because the JB is playing, batteries are even more discharged.
After 1h the algo. tries to charge again, possibly fails again and sets the
JB to pause charging again for 1h.
That would now explain to me, that the bat's are successively discharged.
By the way:
The battery symbol is running all the time, implying that the device is
charging (but it isn't).
That's pretty confusing for the user :-?
# all charging (trickle AND top-off) is disabled,
# leaving the recorder running strictly on batteries (i.e. DISCHARGING,
# even though it is plugged in).
Jepp, that's it (I guess ;-))
# In my limited experience, the deltaV detection is
# fairly tricky: the amount of voltage that the charge voltage
# declines by is quite small (and may be masked by other things happening
# like disk accesses).
IMHO that's exactly the point.
I know deltaV charging only from "stand-alone" battery chargers.
There you ONLY have the charger itself applying a defined load to measure
the bat. voltage (from time to time).
In our case we do have possibly several "additional" loads (like e.g. HD
running, spinning up, ear phone connected or not....) that pull down the
bat. voltage. Sometimes just at the moment the voltage is measured, and that
way fooling the algo. - isn't it ?
# The second snippet I cut out because the max charging time is
# algorithmaticly dependant on the battery capacity setting.
# If you have high capacity batteries (which Matthias has) but don't have
# configured correctly in your config settings
Not in my case.
I do have 2000mAh batteries and the same value in the settings.
# this will aggrevate the charging problems because you will
# be charging to 135% * (450 minutes)
# without scaling for the higher capacity batteries.
In case of 1500mAh:
i = CHARGE_MAX_TIME_1500 * battery_capacity / 1500 = 450 * 1500/1500 = 450
In case of 2000mAh:
i = CHARGE_MAX_TIME_1500 * battery_capacity / 1500 = 450 * 2000/1500 = 600
IMHO it is scaled.
But due to low power (that's what the algo. doesn't know) it timeout's
# OK. Here are my humble opinions:
# 1) We should always do a top-off charge. This is only slightly more
# aggressive than a trickle charge. Currently, if the deltaV charge
# termination isn't detected, top-off doesn't occur. This is BAD IMHO.
# 2) We should always trickle charge forever. Remove all algorithmic
# trickle disabling (unless turned off in the configuration).
# if the deltaV charge termination isn't detected, top-off
# doesn't occur.
# Disabling is unnecessary IMHO.
# Rationale: Given our charging capacities vs. battery capacity, the
# trickle charge PWM control (which is allowed to use a maximum charge
# current of 40% of the full strength charge and throttles
# itself down to as little as 1.7%) is always safe to run the charger at
Is this the same as my proposal (not sure if I understood) ?
Received on 2005-02-04