lkml.org 
[lkml]   [2008]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] power_supply: support CHARGE_NOW in OLPC battery
Anton Vorontsov wrote:

> Cool, I believe this is exactly same thing as we have on DS2760. ACR
> counts up and down. For example, if there was a current of 10 uA for
> 30 minutes, ACR will show 5 uAh. Additional 30 minutes with current
> -10 uA will result in 0 uAh in ACR... Right?

Yes. Exactly correct.

>> The units for the ACR register in the DS2765 are:
>
> Do you have any specs for the ds2765? I'd like to see one, if
> it isn't restricted matter. google:ds2765 pdf wasn't helpful...
>

Ooop. Sorry my typo. DS2756.

http://wiki.laptop.org/images/e/e9/DS2756.pdf
or
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/5104

>> 6.25 uVh / Rsense
>> OLPC Rsense = .015 Ohms
>>
>> The integer math conversion for ACR to mAh that I use in my scripts is:
>>
>> (ACR2 - ACR1) * 625 / 1500
>
> Just curious.. What does the final value mean and how do you use it?
> ACR is the Ah counter. You're subtracting one from another, and that
> value will show you.. difference of Ah between T2 and T1..?
>
> You'll get something useful (current) if you divide the value by T2-T1
> though... ;-) But I believe OLPC can report current by itself...

There is no final value. Only relative values. The EC can detect the
ends of the spectrum. Battery empty and battery full. At those
endpoints it sets the SOC% to x% (exact x varies depending on the
battery type) But lets use full and 90% as the example.

So you charge the battery until the criteria for a full battery are met
and then you set the SOC% to 90%. This value is stored in the EEPROM of
the DS2756. So then when the EC senses that the battery is discharging
it monitors the relative ACR change. It uses that to compute how much %
loss and updates the SOC%. If you are partially discharged and Ext
power is provided so that the battery begins to charge then the reverse
happens. The absolute value of the ACR is never used. Only the
difference. The corrections of any errors happen when the full or empty
conditions are met.
>> Is CHARGE_NOW supposed to be an absolute indication of the level of
>> charge in the battery? If so then thats not ACR.
>
> This depends. On DS2760 ACR is the only way to determine battery's
> "charge" at the given time (thus the capacity in percents, since ds2760
> can't report it).

Ours is the same way. The EC just does the extra work to keep an SOC%
value.

> It needs calibration though... ds2760_battery.c doing this: resetting the
> ACR to CHARGE_FULL value when battery is in charging state with current
> flow < 10 mA.
>
> Works quite good here.

Ah.. I see now. You are using the ACR directly as the SOC value.
Whereas OLPC does not.

If your battery capacity stays reasonably constant across the operating
temp range then I see how that would work fine. With NiMh chemistry the
capacity changes quite a bit wrt temperature. Li chemistries capacity
are much less temp sensitive.

I can't say for certain because I didn't do the original code design but
from what I see in the EC code it tries to compensate for that capacity
change when using NiMh. So they record the net ACR change and use that
to try and compute the real SOC% change. I suppose you could still make
it work with just the ACR register but thats not how Quanta chose to do
the implementation.

>> That would be SOC% *
>> battery capacity. The EC uses the relative motion of the ACR to update
>> the SOC%.
>
> Since you don't seem to use ACR as CHARGE_NOW, I think maybe we indeed
> should implement PROP_ACR or better PROP_CHARGE_COUNTER? With units of
> uAh... would that work?

That would work fine.

--
Richard Smith <richard@laptop.org>
One Laptop Per Child


\
 
 \ /
  Last update: 2008-05-08 22:47    [from the cache]
©2003-2011 Jasper Spaans