XO LiFePO4 Recovery Procedure
This is a repair procedure for XO laptop batteries, and is part of the Troubleshooting and Repair Guides.
Problem Symptoms
A small percentage of LiFePO4 batteries are exhibiting a problem where they do not charge correctly. The parameters that the Embedded Controller (EC) watches while charging change in such a way that the EC thinks the battery is full and marks it as full. On some batteries this seems to happen in the first few minutes and on others it happens much later on. The end result in all cases is an abrupt shutoff when the voltage on the battery drops below the critical level where it can sustain operation. This is currently believed to be caused by a cell imbalance but full analysis is still pending.
Verifying the problem
The first step in verify if this is the problem with your battery is to check what the current capacity is. The tool to do this is olpc-pwr-log. You must download this script from http://dev.laptop.org/~rsmith/olpc-pwr-log and transfer it to your XO. One way is to save that link on another computer and transfer to the XO via a USB flash drive or SD card. Or you can download it directly on the XO by running wget in a Terminal Activity:
wget -O olpc-pwr-log http://dev.laptop.org/~rsmith/olpc-pwr-log
(*NOTE: This is a capital O not a zero, and pwr-log is hyphenated, not underscored)
There have been a few reports of windows corrupting the file when it downloads it. If you download from a computer running a Windows OS then please get the .zip version instead and extract it to your storage media. olpc-pwr_log.zip is located in the same place as olpc-pwr-log.
Once its downloaded and on the XO then make sure its executable by typing
chmod +x olpc-pwr-log
Then you run the script with
./olpc-pwr-log
After a battery is detected, a series of numbers will start listing on the screen. See XO Power Draw for the details.
Basic procedure
- plug up your XO to external power and allow the battery to charge until the EC thinks it is full ie. green charge LED lit.
- start olpc-pwr-log and let it report at least 1 line of data
- unplug external power
- let the XO run on battery until it dies
- remove the battery
- power the XO back up on external power without the battery.
- start olpc-pwr-log
- insert the battery
- allow the battery to charge until the charge LED is green again.
- exit the script with 'ctrl-c'
Exceptions
In many cases the battery despite being very low will have marked as fully charged by the EC. If this is the case then the EC will not attempt to enable the charging circuits. Yet if you unplug external power the XO shuts down immediately or within a few seconds and the battery is not marked as low. In this state its not possible to obtain any data with olpc-pwr-log. To fix this the Open Firmware commands in batman.fth allow you to reset the state of the battery and manually mark it low. This allows the EC to resync with the actual state of the battery and allow charging to be enabled. See batman.fth in XO Troubleshooting Battery for the details.
Reading the log file
The numbers we care about for for diagnosing this problem are SOC (column 2), Voltage in uV (column 3), Current in uA (column 4) and Net ACR in mAh (last column). In batteries that are suffering from the "won't charge" problem the CV point (7.4 Volts) of the battery is reached much too soon. Then the voltage continues to rise and when it reaches above 7.5V the over voltage shutoff of the battery is activated. The EC senses that the current has dropped below the level that indicates the battery is full and marks it full even though very little charge was delivered to the battery. This pattern is fairy easy to recognize. Below is an example:
1214213331,72,6524560,1418229,3192,898,Charging,72,0
time passes
1214213649,76,7116870,1293098,3544,1185,Charging,76,119 1214213659,76,7171770,1280208,3560,1194,Charging,76,123 1214213670,76,7241920,1266536,3578,1203,Charging,76,127 1214213680,76,7511540,130,3589,1205,Not charging,76,127 1214213690,76,7507880,260,3576,1205,Not charging,76,127 1214213701,76,7511540,0,3567,1205,Not charging,76,127 1214213711,81,7506660,130,3551,1205,Not charging,81,127 1214213721,81,7512150,260,3539,1205,Not charging,81,127 1214213732,81,7510320,130,3521,1205,Not charging,81,127 1214213742,81,7510320,390,3508,1205,Not charging,81,127 1214213752,81,7506050,390,3493,1205,Not charging,81,127 1214213763,97,6745990,390,3477,1205,Full,97,127
In the above log the charging current is running along line normal at about 1.2 amps but at time 1214213680 the voltage suddenly jumps to 7.5V and the current falls to 130 uA which is down in the sensor noise. The EC first switches to CV mode (time 1214213711) and then when in CV mode and the charge current is < 200mA the EC marks the battery as full. This happens in the space of 114 seconds (1214213763-1214213649). This is much to quick. A normal charge would take a lot longer. The key measurement however is the net ACR which is the last column. It shows that across the entire time olpc-pwr-log was running the charging system only delivered 127 mAh. The LiFePO4 batteries are rated between 2800 and 3100 mAh so for a full continuous charge this number should be at least 2800 mAh. Anything less for a new battery means that your battery is not charging to its rated capacity.
If you batteries are old then a slight decrease is normal. Each battery charge/discharge cycle decreases the capacity of a battery a tiny bit. The OLPC batteries are rated for at least 50% remaining capacity after 2000 cycles. This means if you discharge/charge your battery every day then you will lose about 9% per year.
If you have any questions about the data reported in the olpc-pwr-log then open a help ticket by sending e-mail to help at laptop dot org with your log file attached and someone will help answer your questions.
Recovery Procedure
By using a slow charge procedure it appears to be possible to recover the problem batteries. The long term results of this procedure are still unknown which is why its still considered experimental. The procedure itself is simple but since each case is unique it requires the user to watch for some conditions to be met and for other conditions which require a restart of the procedure recording the results of each stage. It also take a long time. Typically 30 - 40 hours worth of charge.
Procedure
- obtain a developer key and unlock the XO
- discharge your battery by running the XO on battery until it shuts off.
- remove the battery
- power up the XO and go to the 'ok' prompt
- fload batman.fth (details see http://wiki.laptop.org/index.php?title=XO_Troubleshooting_Battery§ion=26#batman.fth)
- insert the battery
- run bat-recover
- watch and wait
At this stage the screen should start streaming lines of data. This data is similar to the data reported by olpc-pwr-log but it being read directly from the the gas gauge rather than reported from the EC. The 'bat-recover' command plays with the charging system in a way that limits the amount of current used to charge the battery. The idea behind bat-recover is to slow charge the battery and keep the voltage from rising above the over voltage trip point. This allows the unbalanced cell to charge up while not damaging the cell that is fully charged. Until the battery voltage begins to approach 7.4V bat-recover seems to do a good job. However when the bat voltage nears 7.4V the over voltage circuit does periodically get tripped. When this happens the XO needs to be reset and the procedure needs to be re-started.
Because the batman.fth recovery procedure has to completely disable the embedded controller while running all the buttons and the keyboard are disabled. Including the power button. The only way to stop or reset the procedure is to remove the battery and external power.
The data reported to the screen is:
Battery temp, Battery current, Battery voltage and Net ACR. Each value has the units after it.
Current, Voltage and Net ACR are the values that need to be monitored.
A perfect charge run would be a continuous run until the voltage rises to 7.4V and the current falls below 100mA. The net ACR delivered in this case should be about 3000 mAh or greater. The exact number depends on how low the battery was when the procedure was started.
A non-perfect run will trip the over voltage and require several stages. Since the charging current is limited to < 200mA for the entire procedure it can be difficult to tell the difference between a fully charged battery and one where the cells are still out of balance and causing over voltage to trip. To tell the difference the net ACR across each stage needs to be tracked. Every time a stage is restarted the net ACR is reset. Therefor while running the procedure the total ACR delivered should be monitored. The battery can be assumed to be fully charged when its reached 7.4 volts and you have delivered 3000 mAh or more worth of charge.
If the problem battery is continually tripping the over voltage without getting anywhere near 3000 mAh of charge then please e-mail OLPC (help at laptop dot org) with the summary of your results.
Once the procedure is completed use olpc-pwr-log to measure your available capacity by doing a discharge and re-charge cycle with the EC operating normally.
[Based on my experience (N=1) a faster alternative is to completely discharge the OLPC until power shuts off automatically. Then remove battery, plug in the power adapter, boot to a the Sugar command prompt and start olpc-pwr-log. Reinstall the battery and let the OLPC charge until "full." Note the total charge (in mAh). Then, having more than half charged the battery over an hour or so, reboot the computer into the maintenance mode, and at the ok prompt fload batman.fth and run bat-recover. The total charge in the battery is the sum of the values from olpc-pwr-log and the charge delivered by bat-recover. I was able to charge my OLPC to 3100 mAh in about 12 hours using this technique. I was subsequently able to get almost 4 hours of run time from my XO, and automatic shutoff did not occur until charge level was less than 5%! Your time to full charge is likely to vary depending on the degree of disparity between the cells (that is, how low the charge indicator is going before automatic shut off)]