dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: I, battery man ;-) (was: Question to powermgm.c charging algorithm)

I, battery man ;-) (was: Question to powermgm.c charging algorithm)

From: Uwe Freese <>
Date: Mon, 12 Aug 2002 00:02:17 +0200

Hello Heikki,

Heikki Hannikainen wrote on Sunday, August 11, 2002, 9:11:04 PM:

>> >> if (delta < -50) { /* delta < -0.3 V */

HH> Right - please note that the code actually checks for delta of 0.05 V or
HH> so, and the comment in the code is wrong (I wrote the code before actually
HH> measuring the falloff and fixing the constant). I'm not sure if 50 is
HH> actually a good value either, it might need to be tuned a little.

So the values in powermgmt.c are in mV and 50 means 50mV.

>> If disk spinups (normal usage of the AJB) change the voltage too much so
>> that a "full" battery is detected too early, then it tells me that we
>> shouldn't load batteries in normal usage!!

HH> A lot of people want to use the device at home connected to the stereos,
HH> playing DJ gigs etc, where it's a must to charge during normal usage. We
HH> can reduce the interference caused by disk spinups by not taking samples
HH> while the disk is active, and calculating average voltages. Work in
HH> progress here...

Question: What happens if the AJB is connected to external power: Does
the power for the Archos come from the external power then? That means
if we don't switch the "charging pin" on, batteries are not used in
any way?

Then it is no problem for people who want long time usage with
external power..

But if AJB takes energy from the battery even when it's connected to the
AC adaptor, then we have to do some sort or charging all the time.

>> My tests with the AJB said that the Archos firmware changes the
>> "power strength" (how it is called in english? I mean "Amperes"). It
>> changed from 330 mA to about 200 mA. But it could be that this was only
>> because of the lower difference between battery voltage and charging
>> voltage.

HH> According to the schematics (if they're right), the only way to control
HH> the charger is the digital output pin which is used to turn the charger
HH> on/off. We can only control the effective current by turning the charger
HH> on and off very fast while adjusting the duty cycle (ratio of charger

One need not turn the power on and off very fast - some chargers turn
it on lets say 5 sec and off 15 sec to reach an ampacity (yes! I've
learned this word from! ;-)) ) of 1/4 of the maximum.
When AJB's ampacity is ~ 350 mA, it's no problem to switch it
1 sec / 3 sec for example.

The "very fast" switching of reflex charging algorithms needs much
more power, lets say 3 A and is switched 0.01 sec on and 0.09 off to
reach 300 mA ampacity. But we don't have that much power and so
we cannot make a reflex charging algorithm.
Also they usually use a quick "decharging" while charging so there's
no chance inside the battery to build "bubbles". And we don't have
that (high ampacity) decharging possibility, either.

>> I made a battery charger about 8 years ago, wired to the parallel
>> port and with an A/D converter. I wrote a (pascal) charging program and
>> tested very much with that. Because of that, I've some experience with
>> charging algorithms..
>> You can download the source at (see "Projekte und
>> Software"). It is not written so well, because I had not much
>> experience in programming then. But maybe it gives you some ideas for
>> the archos charging algorithm.

HH> Excellent! This is my first smart charger logic, soldered a dumb one 7
HH> years ago or so. 8-) Your feedback, testing results and, especially,
HH> tested modifications are very welcome.

>> One thing that could be used here, too:
>> I divided the charging in three phases (with typically high, low and
>> high gradient).
>> When the gradient goes lower -> start of phase 2.
>> When the gradient goes higher -> start of phase 3.
>> The gradient is going up now in phase 3. If is goes down again under a
>> percentage of the highest gradient in phase 3, I assume that the battery
>> is charged.
>> What about that? (I hope that you understood my explanation. If not -
>> ask!)

HH> I'm not sure I understood that, but I'll try to read the Pascal code
HH> within a few days.

The battery voltage of a charging cycle gives us a typical curve (that
I also found at the URLs given in powermgm.c). I tried to recognize
where I am in that cycle to detect if it is possible that charging is
finished now.

Now what I can do for Rockbox:

I've enough ideas that could be implemented. I don't know if you (the
main programmers) want me to do this or only to give comments to what
you've written.
What I don't want is to write much new code that nobody wants and
integrates into RockBox.
So please tell me what you want.

/If/ you want me to write and implement a charging algorithm, I'll need
your help for this (are you the main charging algorithm programmer?) -
especially for integrating it into the menu structure and the thread
things. That's because I'm not so good in C programming and think
there are others that know the RockBox structure better.

So what I think it should be and what I could maybe implement:

- 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. ;)
  How charging works:
  - constant and maximum charging power (the battery SHOULD get hot,
    because the voltage drop at the end comes from the battery getting
    hot which makes the voltage go down)
  - charging end detected if:
    - time > x
    - voltage > y
    - voltage is going down (delta peak) 0.02 v
    - the phase analysis says that we are in phase three and the
      gradient is lower than e.g. 1/5 of the maximum

So if such a thing is desired in RockBox, give me a patch against
current cvs that integrates a "charge" menu item and a new
procedure that is called when selecting that menu item. It would help
me very much if you implement a

 x = getVoltage;
 or however that works. So I can see how

 - lcd output
 - get voltage
 - set charge power on/off

 works. With this, I can test and implement and within some days
 you'll have a really good and new charging algorithm. :-)
Bye, Uwe.
Received on 2002-08-12

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy