XO power management
Richard A. Smith
richard at laptop.org
Mon Apr 4 13:58:10 EDT 2011
On 03/31/2011 03:43 PM, Ismael Schinca wrote:
> Richard, Ceibal about to start working heavily in reworking how to
> classify used batteries. Due to the number of batteries involved, we
> were asked to devise a "good enough" procedure to estimate the battery
> condition in less than 10 minutes. The plan would be to get several
> parameters from the batteries and try to estimate it's condition based
> on them. Have you been able to analyze the results from the logs I sent
Sorry. I've been very busy lately and its taken me a while to look at
them. I'm currently in route to Taiwan where I'll be for the next 2
weeks. I've been looking at your logs on the plane. Note that after
about 4pm PST I'll be out for a day or so . After that I'll be out of
sync with your timezone (I'll be +11 or +12 or so from you) and I'll be
very busy so my responses my lag quite a bit.
I'm afraid its difficult to make any judgments from the data you have
sent so far. You are going to have to test many more batteries to get
I'm going to have to do some work on my processing tools to help with
the comparison. I'll try to get to that later on.
Here's a quick look at the capacity of the batteries you have tested so
far. Thank you very much for the battery serial number in the filename
that is very helpful. Please continue to do that. I've broken up the
serial number so that we can see the age easily. The 2nd column is the
ammount of Watthours that was extracted from the battery sorted into
ascending order of Watthours.
00401 071229 110002160OLD.csv -4.177
00401 071229 110002221OLD.csv -11.663
00602 080608 110000600.csv -13.915
00802 100751 10002447NEW.csv -13.992
00602 080616 110002384.csv -14.405
00802 100804 110003201NEW.csv -14.803
00802 090331 110002400.csv -15.066
00802 081130 110001133.csv -15.768
10102 080109 310000524.csv -15.863
00702 080710 110000901.csv -16.009
00802 090829 110001062.csv -15.914
00802 081231 110000683.csv -16.576
00702 080714 110000474.csv -16.826
00802 090415 110001059.csv -16.995
00802 090429 110002159.csv -17.705
00802 090206 110001307.csv -18.489
The first thing to notice is that it roughly correlates with age which
makes sense. The both the 004's are suffering from charge balance.
Something you can see from the charging voltage logs. If you want a
quick first pass of segregating the batteries then you can use the first
3 digits as guide. Any battery with the first 3 digits that are less
than 008 (ie, 007,006,005,004...) is subject to charge balance. I
recommend you group your batteries int < 008 and >= 008. Depending on
how many you have you may or may not want to even try to analyze the <
The next thing to notice is that your batteries that you marked as NEW
are showing a capacity that is much less than expected. Those should
have had a capacity of 18Wh or more. Please re-run the test on those
batteries and see if the data is consistent.
I've estimated that the capacity loss should be .025% per/cycle. If we
assume the rough age of the batteries is 2 to 3 years and that they
average 1 cycle per day then I'm expecting the available capacity to be
in the 73% to 82% range or 15-16 Wh. Looking at your numbers I say its
right on par. So perhaps you can also use the battery age as a guide.
What is the minimum capacity you want to allow to be re-used?
The attached graph shows your charging voltage in detail. As you can
see the the screen turning off and on has an effect on the voltage.
This graph also illustrates why this is going to be a difficult thing to
accomplish in only a 10 minute test.
> Another question. Is there information in the battery controller
> regarding total number of charge/discharge cycles?
There is an attempt to do that and the logs extract that information
from the EEPROM. However, I don't have any idea how accurate it is.
Its legacy code that I've never had a reason to examine closely. I'll
examine the code that does that in detail and then add decoding of the
values to my processing script next so I can take a look at the numbers.
Richard A. Smith <richard at laptop.org>
One Laptop per Child
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 23818 bytes
Desc: not available
More information about the Devel