XO power draw

  This page is monitored by the OLPC team.

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.

Data Usage

This data was intended for developer use while working on reducing the power consumption of the XO in various modes. Please do NOT use this information as the basis for computing the power draw of a pilot or large scale deployment. There are many other factors that must be considered when computing the power requirements of a pilot or deployment. Please contact OLPC for details if you need to do those calculations.

Nov 2012 Update: At the October 2012 OLPC Summit in San Francisco, Richard Smith and George Hunt presented slides which may be helpful in planning for adequate power in the developing world. See the slides

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 DC 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.

If you measure at the AC side then its an entirely different story. The efficiency of a AC->DC adapter depends on the the line voltage the line frequency and the load. With this many variables its very difficult to provide numbers. Complicating this is the fact that most commercial AC wattmeters are very inaccurate at low wattage levels. If you do wish to compare these numbers to those of an AC measurement then you need to account for both the XO's DC/DC converter eff% and your AC adapters eff% in your given environment. You may use 90% (.9) for the eff factor of the XO's DC/DC converter. For you AC adapter you should measure it with a known load.

AC Wattage = (Reading below) / (XO DC eff% * AC eff%)

example: 1.1W / (.9 * .6) = 2W in mesh mode @ AC side.

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 is in releases since 8.2.0. It has been in OS images since Joyride-2301. You can find the file in /usr/bin/olpc-pwr-log (or put it here if you are downloading the script). If you have an older build you may download a copy from http://dev.laptop.org/git/projects/olpc-utils/plain/usr/bin/olpc-pwr-log . The lastest released copy can be found at http://dev.laptop.org/~rsmith/pwr_scripts/olpc-pwr-log and the development repository is located here http://dev.laptop.org/git/users/rsmith/olpc-pwrlogs/

How to use it

Simply type 'olpc-pwr-log' (no quotes) at any command prompt.

• If run in the Terminal Activity: The olpc-pwr-log script will suspend (and stop logging) along with Sugar, and wake up (and resume logging) when Sugar wakes up.
• If run in the virtual console: Running olpc-pwr-log (as with anything that gives output to the VC) will prevent OHM from putting the XO into suspend.

One use of olpc-pwr-log is to measure the battery's capacity, with the following procedure:

1. Completely discharge your battery to the point where the laptop turns itself off.
2. Remove the battery and boot from AC power
3. Start olpc-pwr-log
4. Plug in the battery
5. Wait until fully charged, then look at the Net ACR value. The value for a healthy battery should range from 2800 to 3100. If it is less, then the battery is faulty, the cells are misbalanced, or the battery's capacity has just decreased due to a high number of charge/discharge cycles.

Output

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

<Timestamp>,<SOC>,<Voltage>,<Current>,<Bat Temp>,<ACR>,<Status>,<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 0.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 (trickle)", "Charging", "Full", "Not Charging", "Discharging", and "Critical". "Not Charging" occurs when the battery is full but you are on external power. "Critical" will occur (When all the code suppport lands) when the voltage nears the level where the EC does a hard shutoff of the power to protect the battery from damage. "Trickle Charge" occurs when the battery voltage is so low that the XO cannot enable the primary charge system. This can happen if the battery has sat on the shelf for a long time and self-discharged. When the voltage increases beyond the low voltage cutoff primary charging will be enabled.

Net ACR

The net ACR since the script was started. Handy for looking at the data prior to processing. Positive numbers indicate charging and negative discharging.

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

process-pwr_log also outputs a summary of the info processed to stdout. One line per file. See the header that it outputs for what the values are cause they are changing as needs change. It also takes some arguments that affect what output is in the summary.

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 XO-1 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).