inconsistent battery charge state indications

[Quozl]

All three units were taken for a one hour 40 minute walk over outback terrain. During the walk, psu_0/capacity_percentage was logged along with wireless signal and noise level. The other battery monitoring parameters were not logged. Each unit experienced the same usage pattern as part of a structured coverage test, beginning with fully charged battery, according to the monitoring parameters.

On unit Quozl 3, the battery capacity remained at 100% throughout, and when it was returned to AC adapter power showed a green battery light, and the battery status showed "full".

On unit Quozl 2, the battery capacity declined as expected, and when returned to AC adaptor power showed a red-orange battery light, and the battery status showed "charging".

On unit Quozl 1, the battery capacity declined as expected, and when returned to AC adaptor power showed a light-orange battery light, and the battery status showed "charging".

All three units are on build 193 with A62 firmware.

[jg]

Mary Lou and I had noticed much lower battery life than one might expect (even giving the large power consumption of the CaFE FPGA, which will become a low power device in the next build as an ASIC).

Mike Bove has measured a power consumption of approximately 7 watts at the moment (no power management work has been done to speak of, and CaFE is an high power consuming FPGA), when running idle.

I sent mail yesterday on the topic, since we'd predict about a 3 hour life.

Thanks for the report; a day or two earlier and you'd have beaten us to the punch!

• Jim

Here's the answer:

Hi, Jim & Victor,

The battery life is indeed WAY off, and the EC code is the primary contributor. Just as you say, including the capacity that we are reserving for 2,000 cycles, the battery life should indeed be almost 3 exactly hours.

The pack capacity is 24.4 WH, and the current ON power without power management is ~7W. The EC should be reserving ~14% of the pack's capacity, meaning that the effective capacity should be 21 WH. If this were being done properly, the battery life would be 3 hours. Instead, it is about 1/2 this long.

The EC is reserving FAR more capacity than it should, plain and simple. The core problem is that the EC is currently computing the battery life from the battery sensor, rather than reading an actual gas gauge. I learned only after the fact that the "gas gauge" chip chosen by Quanta and Gold Peak isn't a true gas gauge - it's just a voltage/current/temperature sensor.

The battery sensor in the pack should be changed to a true gas gauge in the next build.

Best Regards, MarkF

[ywwg]

I am also getting a battery error in which the battery light flashes red (I assume this means "danger, low battery") while on AC power. Removing and reinserting the battery fixes the error (battery light goes orange, then green).

Build 193, A62, serial number PCL10EN646001A4

[mfoster]

The current EC code release is seriously broken. I've also seen this issue at Quanta, and showed it to Ted. I'm assigning this to Ted for correction.

[Quozl]

All three units were left on AC overnight, with batteries still installed. About 14 hours later, the following indications were observed:

On unit Quozl 1 and Quozl 2, the red battery LED is flashing, at about a four second interval. The olpc-battery driver reports "present critical".

On unit Quozl 3 (which last night had refused to admit loss of battery capacity) the green battery LED remained lit for much longer, but has now entered the same red flashing state.

On all units, the battery case is quite warm to the touch, as is the area of the screen behind the lower left.

Quozl 2 red LED flash timings 2006-12-20 11:42:07.145261000+11:00 2006-12-20 11:42:11.408156000+11:00 2006-12-20 11:42:15.592378000+11:00 2006-12-20 11:42:19.805560000+11:00

Quozl 1 red LED flash timings 2006-12-20 11:43:23.223914000+11:00 2006-12-20 11:43:27.432314000+11:00 2006-12-20 11:43:31.626666000+11:00 2006-12-20 11:43:35.776817000+11:00

I'm going to shut the units down, remove AC power, and remove the batteries, wait ten minutes, and then restore batteries.

[Quozl]

On removal of the three battery packs, the pack for Quozl 3 was too hot to hold continuously in hands. The other packs were merely quite warm.

Serial numbers:

QUOZL 1 PCL10EN6460012E

QUOZL 2 PCL10EN6460012F

QUOZL 3 PCL10EN64600169

[Quozl]

Now two units are charging their battery despite it being marked as full.

On restoration of battery and AC adaptor power over 40 minutes later, two units Quozl 3 and Quozl 2 went into charge mode (roughly 1.2 amp current shown on psu_0/current), and the other unit Quozl 1 did not.

Logs were captured, using the following fragment:

date --rfc-3339=seconds
cat /sys/devices/platform/olpc-battery.0/psu_0/{current,voltage,capacity_percentage,status}

Timestamps below meaningless, except relative to the file itself.

quozl-3:

2006-12-20 01:45:40-05:00 1127 7518 100 present full
2006-12-20 01:46:40-05:00 1207 7555 100 present full
2006-12-20 01:47:40-05:00 1208 7574 100 present full
2006-12-20 01:48:40-05:00 1208 7588 100 present full
2006-12-20 01:49:40-05:00 1208 7598 100 present full
2006-12-20 01:50:40-05:00 1208 7605 100 present full
2006-12-20 01:51:40-05:00 1208 7608 100 present full

quozl-2:

2006-12-20 12:46:52-05:00 1126 7525 100 present full
2006-12-20 12:47:52-05:00 1130 7556 100 present full
2006-12-20 12:48:52-05:00 1132 7578 100 present full
2006-12-20 12:49:52-05:00 1135 7594 100 present full
2006-12-20 12:50:52-05:00 1135 7605 100 present full
2006-12-20 12:51:52-05:00 1135 7611 100 present full

quozl-1:

2006-12-20 12:46:13-05:00 7 6912 100 present full
2006-12-20 12:47:13-05:00 7 6912 100 present full
2006-12-20 12:48:13-05:00 7 6911 100 present full
2006-12-20 12:49:13-05:00 7 6911 100 present full
2006-12-20 12:50:13-05:00 7 6910 100 present full
2006-12-20 12:51:13-05:00 7 6910 100 present full

[Quozl]

Have begun testing with Q2B11 firmware, so as to close this one out, but waiting on advice on #634.

[jg]

Hmmm... I have a battery, when inserted the battery light does not light at all.

A different battery lights up green when inserted into the same machine.

This is running Q2B11 firmware.

[Quozl]

Have begun testing with Q2B16 firmware.

The original problem here is not reproduced, but one unit considers the battery at 100% capacity despite the terminal voltage being something like 6.2V - 6.5V ... caused by reflashing with the battery less than fully charged. I'm not sure if this is right. I shall continue to monitor.

Is there a way to ask the EC to trickle charge the battery, say with a C/20 rate? Or is the charge circuit only either on or off? If there was such a way, I'd be able to bring the battery actual capacity closer to the EC perception of capacity.

Moot in later versions when a gauge chip is used, of course.

[ted.juan]

Replying to Quozl:

Thanks your great test and comment.

Have begun testing with Q2B16 firmware.

I think it should be Q2B15, not Q2B16 ?

The original problem here is not reproduced, but one unit considers the battery at 100% capacity despite the terminal voltage being something like 6.2V - 6.5V ... caused by reflashing with the battery less than fully charged. I'm not sure if this is right. I shall continue to monitor.

What is "reflashing" meaning?

Thanks.

[Quozl]

No, I'm testing with Q2B16, I've just checked, and the dmesg confirms:

[   27.231210] OLPC board with OpenFirmware: CL1   Q2B16  Q2B

reflashing means erasing and programming the firmware.

See the attached graph. This is a monitoring of a discharge of three units, suggesting to me that the charging decision is dependent on the EC's capacity belief. My understanding of the terminal voltage suggests that the batteries involved could do with more charging.

[Quozl]

discharge cycle for three units, monitoring voltage and capacity variables

[ted.juan]

Hi, Do you make an EC reset (or all power remove) immediately after reflashing"? The OFW flash has issue the EC command, but olpcflash need to do by yourself.

After you reflash, you must power cycle by physically removing power from the system. A warm-start or button-induced restart is not sufficient. Please remove both the battery pack and wall adapter for 10 seconds.

The data from battery should be continuous updated to BMS (battery manage system) to calculate real capacity. Once the EC stop running for a few seconds then the BMS may update data in an inaccurately. After calibrating (discharging to low voltage), maybe the capacity will be properly.

But if we can have a command to inform EC to stop BMS before host issues special process to EC (such as reflashing, shadowing, access 2K ROM...). The commands will implement in the EC firmware.

[Quozl]

Replying to ted.juan:

Do you make an EC reset (or all power remove) immediately after reflashing"? The OFW flash has issue the EC command, but olpcflash need to do by yourself.

The OFW olpcboot.fth was used, and it powered down each unit after firmware upgrade reflashing was complete.

After you reflash, you must power cycle by physically removing power from the system. A warm-start or button-induced restart is not sufficient. Please remove both the battery pack and wall adapter for 10 seconds.

This is not in the instructions, please pass this on to the Wiki page Autoreinstallation_image.

Between the time Q2B16 was used and my reply on 2007-01-04, a full removal of power sources was done on each of the three units.

[vance.ke]

Just reminding some matters needing attention which are as follows:

(1) System Power-Off procedure should be done by setting registers of South-Bridge ("Power Management Controller Register") instead of setting 0xFF14 address of EC register.

==> /arch/i386/kernel/olpc.c (123) : static void olpc_power_off(void)

==> /arch/i386/kernel/olpc-pm.c

==> ......

(2) The correct EC reset procedures describe as follows:

(a)Send prepare EC reset command 0xD8. Example codes are as follows:

while ((inb (0x66) & 0x02)); //waiting for input buffer empty

outb((unsigned char) 0xD8, 0x66); //send prepare_EC_reset command 0xD8

while ((inb (0x66) & 0x02)); //waiting for complete process

(b)Send EC_RESET_COMMAND -- 0x05 extended command (By 68/6C port).

(3) This EC also implements the command 0xD5 for shutting down system. Example codes are as follows:

while ((inb (0x66) & 0x02)); //waiting for input buffer empty

outb((unsigned char) 0xD5, 0x66); //send 0xD5 command

while ((inb (0x66) & 0x02)); //waiting for complete process

[Quozl]

With six units on Q2B73 (three B1 units, three B2 units), during a discharge test, two of the six units are reporting "critical", and flashing the red power LED.

However, the battery voltage and remaining battery capacity seems nominal.

Affected units Quozl-1 (B1) and Quozl-5 (B2). These have the new sample battery with LiFe chemistry.

% dsh --group xo tail -1 battery-monitor.log
2007-03-06 17:07:25+11:00 -1228 6310 58 present discharging critical 31746 49753
2007-03-06 17:07:26+11:00 -1140 6319 56 present discharging 31804 49753
2007-03-06 17:07:27+11:00 -1123 6185 51 present discharging 30820 49753
2007-03-06 17:07:27+11:00 -1236 6327 61 present discharging 30664 49753
2007-03-06 17:07:27+11:00 -1014 6353 61 present discharging critical 31007 49753
2007-03-06 17:07:29+11:00 -1255 6311 60 present discharging 30917 49753

[David.Lin]

We also see this situation. The EC will misjudge the LiFe battery. The bug will be fixed in next version.

[Quozl]

Tried Q2B81, so far the problem does not appear.

[jg]

Gee, maybe we can close this one now!!!