XO battery/performance [Devel Digest, Vol 76, Issue 21]

[Richard Smith]

>
> After that test, I run bat-recover once more I noticed several strange things.

Running bat-recover is unnecessary and for your battery basically
useless.  Also bat-recover runs outside of normal battery processing
so your SoC values (the %) may be invalid until you do a full
discharge or charge.

> What I can decipher from all these is that
> a) the battery has decreased capacity (or for some reason stops charging after ~70% full)
> b) at times, the controller is not transmitting/sensing the battery state properly.
> c) The battery indeed looses too much charge while in the XO and this may not be related to its decreased capacity.
> You can hopefully see more things from these.

d) You have hit a rare EC bug.

The gas gauge chip in the battery tracks the ACR value with a signed
16bit number but the counter does not wrap when it reaches the end.
The number of ACR counts between charge and discharge is never equal
so over time the counter will tend to drift one way or the other.

In the 1.75 EC code I deal with this by manually wrapping the count to
the other extreme.  This keeps the 1% SOC values ticking since they
are relative, however, I failed to realize that this totally screws up
my logging scripts which measure the net difference in ACR from the
start to the finish of the run.  I _just_ discovered this last week on
my battery testbed.

You can see this in the logs:

1340445105,72,6442210,-593359,3126,-13648333,Discharging,-861250,87
1340445125,72,6438550,-597135,3125,-13652083,Discharging,-865000,87
1340445146,72,6425740,-596744,3126,13650416,Discharging,26437499,88
1340445166,72,6439160,-629427,3122,13646666,Discharging,26433749,88

Notice it jumped from -number to +number and the net ACR reading went
off the scale.

XO-1 and 1.5 do not have the manual wrapping code so when they reach
and extreme the counter just stops.  In theory its self correcting as
once you hit a stop then the amount of ACR in the other directly would
be much more and would pull the counter back the other way but perhaps
there's more to it than that.

This may or may not be the source of your original problem but it does
prevent the power measurement script from getting an accurate reading.

The fix is simple.  Put the battery in an XO-1.5 and boot to OFW.
Then at the ok prompt do the following.  Note that it has to be a 1.5
as batman does not work on a 1.75

ok 0 bg-acr!

Thats a zero not an O.
This will reset the ACR register to zero.

you can then look at it with:

ok bg-acr@ .bg-acr

After you do that then please run another discharge/charge/discharge
cycle while running olpc-pwr-log and resend the results.

-- 
Richard A. Smith
One Laptop per Child