XO power draw

  This page is monitored by the OLPC team.

XO power draw

The XO laptop has many modes of operation so calculating the power draw can be complex. This page will try to describe the various modes and the methods of measuring the draw for each mode.

Tools

The following tools were used to take readings from the gas gauge chip housed inside the battery. Therefore these readings are valid running on battery only. Duplicating these readings with measurement tools using external power and no battery will end up sightly higher due to the efficiency loss of the DC/DC converter that powers the system power rail. If the XO is trying to charge an installed battery then it will be much greater.

olpc-pwr-log

This is the monitoring script that waits for some specified interval to pass and then takes a reading of information available from the battery. The sample interval is changed by editing the script. The default is around 12 seconds per reading

Where to get it

olpc-pwr-log will be in the upcoming 8.2.0 release. It has been in OS images since Joyride-2301. Simply type it at any command prompt. If you have an older build you may download a copy from http://dev.laptop.org/~rsmith/olpc-pwr_log

Output

The legend for the output to both the screen and the log file is:

<Timestamp>,<SOC>,<Voltage>,<Current>,<Bat Temp>,<ACR>,<Status>,<Overall Level>,<Net ACR>

Timestamp

POSIX time stamp of number of seconds since Jan 1, 1970

SOC

State of Charge. A % number between 0 and 100% indicating how charged your battery is. This number is normally between 7% and 97%. Due to variations from battery to battery its difficult to get an exact measurement down to 1%. Therefore low is anything less than 15% and full is anything greater than 93%.

Voltage

Battery voltage in microVolts ( x 10E-6 ) The resolution does not really go down to microVolts but it's easier not to do floating point math in the kernel driver.

Current

Signed number indicating the current into or out of the battery. Value in microAmps.

Battery Temp

Temperature of the battery in 100ths of degree Centigrade. The battery can have quite a bit of rise above ambient temperature during charge and discharge. In a normal 25 degree room its not uncommon to see values up in to the 30 C range.

Accumulated Current Register (ACR)

ACR is a 16-bit 2's complement value that counts up or down depending on the amount of charge into or out of the battery. The value is in units of the counter inside the battery but it can be converted to milliAmpHours (mAh) by multiplying by .4167. A single value does not tell you much but the difference between any 2 readings gives you the net charge or discharge during that period.

Status

"Charging", "Not Charging", or "Discharging". "Not Charging" occurs when the battery is full but you are on external power.

Overall Level

"Low", "Normal" , or "Full". A basic indicator of where your charge level is.

Net ACR

The net ACR since the script was started. Handy for looking at the data prior to processing. Net ACR is in mAh. Positive numbers indicated a charge and negative discharge.

process-pwr-log.py

http://dev.laptop.org/~rsmith/process-pwr_log.py

Python script that takes one of the log files from olpc-pwr-log and crunches measurements of power consumption between each reading. It creates a file of the same name as the input file with the text 'processed_' prepended to the filename.

The legend for the output of the script is:

<Net Time>,<Avg Current>,<Net ACR>,<Delta T>,<Avg Voltage>,<Watts>,<Net Wh>

Net Time

Relative time in hours from the start of the logfile.

Avg Current

Difference between the 2 ACR readings / difference in Time

Net ACR

Relative ACR reading from the start of the logfile.

Delta T

Difference in time in seconds between readings

Avg Voltage

(Previous voltage reading + Current voltage reading) / 2.

Watts

Avg Voltage * Avg Current

Net Watt hours

Iterative summation of power consumed for that reading times duration in hours for the reading

Modes

The following are definitions created by Richard with how I view their meaning. Probably subject to change and additions in the future. Some modes have lo and hi power levels.

Sleep

WLAN device disabled via no firmware. Lid Closed (Display off), CPU off

Ebook

WLAN device disabled via no firmware. Lid Open, Display Monochrome, Backlight Off, CPU off

Mesh

WLAN enabled, Lid Closed (Display off), CPU off

Suspend Lo

WLAN enabled, Display Color, Backlight at minimum setting, CPU off

Suspend

WLAN enabled, Display Color, Backlight Auto-dimmed by ohmd, CPU off

Idle

WLAN enabled, Display Color, Backlight full, CPU on, no load

Camera

WLAN enabled, Display Color, Backlight full, CPU on, high system load. Running the camera in full screen exercises nearly every bus on the XO so it draws a lot of power although it does not use a lot of CPU time.

• WLAN disabled by moving the firmware so it would not load. This was done because 'olpc-control-panel -s radio off' does not actually turn off the WLAN processor therefore it still uses a lot of power. The 8.2.0 release can more simply disable the WLAN, either automatically during a lid-close suspend when the mesh is not enabled, or by enabling "Extreme Power Management" in the Sugar control panel.

The Numbers

• Notes:
• Due to the way the logging works the wattage numbers are not exact because gas guage chip does not track the battery voltage with the same precision as the current (there is not an AVR register). So the voltage used is the midpoint between the sample from each reading. For the suspend tests this was less than .1V between readings. The exception is the Idle and Camera modes where the sample interval was set to 10 seconds so the voltage did not change much from reading to reading. This has the nice side effect that a few peak measurements showed up. During suspend peak readings are not possible with the battery logging script.
• All the suspend modes (Sleep,Ebook,Mesh,Suspend) have zero wakeups during the measurement so they represent a lower bound for the power draw.

2008-2-25 By rsmith

Sleep      .25W
Ebook      .71W
Mesh Only  1.1W
Suspend Lo 1.7W
Suspend    1.9W
Idle       3.9W 4.9W Peak
Camera     6.5W 8.7W Peak

2008-9-12 by gnu (OS 8.2-759)

These are single 10-second samples, not repeated for confirmation. The CPU and WiFi were nominally idle (except for the running of the power monitoring script), but some background processing undoubtedly occurred. When on, WiFi was associated with a nearby access point, except where Mesh is mentioned.

5.91W    Full brightness, CPU and WiFi on
5.76W    1 step  dimmer, CPU and WiFi on
5.62W    2 steps dimmer, CPU and WiFi on
5.49W    3 steps dimmer, CPU and WiFi on
5.35W    4 steps dimmer...
5.06W    5 steps dimmer...
5.08W    6 steps dimmer...
4.89W    7 steps dimmer...
4.90W    backlight off, CPU and WiFi on (reflective monochrome mode)
4.41W    screen    off, CPU and WiFi on (xset dpms force off)
3.88W    backlight off, CPU on, WiFi off (reflective monochrome, Extreme Power Management)
3.38W    screen    off, CPU on, WiFi off (xset dpms force off, Extreme Power Management)
5.14W    backlight off, CPU on, Mesh on (reflective monochrome)
4.41W    screen    off, CPU on, Mesh on (xset dpms force off)

Summary of gnu results: Normal power consumption of about 6 watts. By dimming the screen, you can save up to a watt. By turning the screen all the way off, you can save another 0.5 watt (total 1.5 watts for screen). By turning the WiFi chip off, you can save up to a watt. By using a WiFi access point rather than a mesh, you can save up to 0.2 watts. None of these techniques involve turning off power to the CPU (the "Automatic Power Management" option in the Sugar control panel).

I don't know why my measurements are much higher than Richard's (he got 3.9W to 4.9W where I got 5.9W). I tend to trust his more, since mine are one-shot samples, but my dimmer measurements do tend to corroborate each other (i.e. none of them got down to 4.9W until very very dim, yet he says the backlight was on full during his tests).