How to Measure Battery Life on a Windows Handheld

A projection estimates full runtime from a shorter measurement. It must be labelled as projected, state the formula and retain the original measurement. Do not place a projection in a field intended for completed measured battery life.

HandheldAtlas should prefer a completed rundown. When only a fixed-duration result is available, publish the consumption result and leave completed runtime blank.

Record the hardware first

Write down:

• exact manufacturer and handheld model
• processor or APU variant
• total memory
• battery design capacity when documented
• current full-charge capacity from a recent battery report
• battery cycle count when the device reports it
• BIOS and firmware versions when known
• Windows build and graphics-driver version when known
• test date

Keep different battery sizes and revisions separate. A ROG Ally result cannot silently stand in for an Ally X. Steam Deck LCD and OLED battery data also belong in separate records.

Generate a Windows battery report

Windows includes the powercfg battery report. Open Terminal or Command Prompt and run:

powercfg /batteryreport

Windows writes an HTML report and displays its location. Preserve the report with the test evidence when it contains no personal path information you do not want to share.

The report can show installed battery information, design capacity, full-charge capacity, recent usage and capacity history. It helps explain why two units of the same model may not deliver identical runtime.

Do not calculate “battery health” from one fluctuating reading and present it as laboratory accuracy. Firmware estimates can move after calibration, updates and normal battery behavior. Record the values and date instead of smoothing them into a more attractive number.

Prepare a repeatable game workload

A built-in benchmark is repeatable, but many benchmarks are too short for a useful battery test. If it can loop without changing settings, document the loop count and total duration.

For real gameplay, define:

• game and version when an update may affect performance
• exact save, mission or map
• start and end points
• camera and movement route
• combat or NPC conditions
• test duration
• whether menus, cutscenes and loading screens are included

Avoid online matches as the primary test when server conditions and player behavior dominate the workload. If random events cannot be controlled, perform more runs and report the variation.

Lock every handheld setting

Record and keep fixed:

• manufacturer performance mode
• manual TDP or stock profile
• GPU clock limit, if used
• fan profile
• VRAM or UMA allocation
• internal or external display
• resolution and refresh rate
• frame-rate cap and V-Sync
• HDR state
• variable refresh rate state
• RGB lighting state
• speaker volume or connected headphones
• Wi-Fi and Bluetooth state
• connected USB devices
• keyboard, controller or dock use

Do not call a vendor profile “15 W” unless the actual power limit is known. If only the profile name is verifiable, publish the profile name and leave manual TDP blank.

Lock every game setting

Save the complete graphics configuration, including:

• render and output resolution
• graphics preset and every manual override
• upscaler and quality mode
• sharpening
• frame generation
• dynamic resolution
• ray tracing
• motion blur and other post-processing
• frame cap

A battery comparison is invalid when the second run quietly uses different graphics or a different frame cap.

Control display brightness

Screen brightness materially changes battery life. UL Solutions explicitly highlights brightness as a major source of variation in battery benchmark results.

Use a measured luminance in nits when you have a suitable meter. Otherwise use a fixed Windows brightness percentage and identify it as a percentage, not as nits. Never convert a slider percentage into an invented luminance value.

Disable adaptive brightness and content-adaptive brightness when the device supports those controls and the test requires a fixed display output. Keep HDR, refresh rate and RGB lighting unchanged across runs.

Prepare the software environment

Before measuring:

1. 1Finish Windows, game and launcher updates.
2. 2Pause downloads and cloud synchronization.
3. 3Restart the handheld.
4. 4Close unrelated launchers, browsers and monitoring tools.
5. 5Confirm the intended power and fan profile.
6. 6Launch the game and allow shader compilation to finish.
7. 7Perform one warm-up pass.
8. 8Return the device to a consistent starting temperature.

Airplane mode may improve repeatability, but it is not representative of every use case. If networking is required, keep Wi-Fi enabled and document it. Do not compare an offline run with an online run as though only TDP changed.

Set the battery interval

For a completed rundown, start and stop at repeatable thresholds. A practical test may begin after the device reaches its stable full state and end before Windows forces emergency shutdown.

Record:

• displayed starting percentage
• displayed ending percentage
• start and end timestamps
• elapsed time
• whether a charge limit was temporarily disabled
• whether the charger was disconnected before or after launching the game
• any low-battery power-saving behavior

Do not assume the interval from 100% to 0% is linear. The first and last displayed percentages can behave differently, and Windows may change power behavior near critical charge.

If the normal charge cap is 80%, you may either test from that real-world starting point or temporarily allow a full charge. State which choice you made.

Run the test without cherry-picking

Keep the route and conditions unchanged. Log interruptions, crashes, updates, accidental menus and thermal warnings.

For a completed rundown, the elapsed time is the measured result for the recorded interval. Do not silently add estimated time for the unused percentage.

For a fixed-duration test, report the direct result, for example:

• 60-minute run
• battery changed from 90% to 64%
• 26 percentage points consumed

If reliable battery energy telemetry is available, also report watt-hours consumed. Do not substitute APU package power for total battery discharge.

Repeat the test

One run establishes a baseline, not universal truth. Repeat the same workload at least three times when publishing a comparison or recommendation.

Compare:

• elapsed time or fixed-duration consumption
• starting and ending battery state
• average FPS and frame pacing
• device temperature
• unexpected background activity
• whether performance changed near low charge

Keep every valid run. Exclude a run only for a documented interruption, not because it produced an inconvenient result.

Report variation instead of hiding it. A range from three honest runs is more useful than a single over-precise number.

Battery life and performance belong together

A longer result is not automatically better when the game ran below the intended target. Preserve average FPS and clearly labelled low or frametime evidence alongside battery data.

A lower TDP may reduce performance without proportionally reducing total device draw. Conversely, a frame cap can improve efficiency when it reduces unnecessary rendering. Measure the complete profile rather than assuming one setting guarantees a particular runtime.

Evidence package

A publishable battery result should retain:

• exact handheld and battery identification
• Windows battery report or recorded capacity values
• complete device, display and game settings
• starting and ending battery percentages
• timestamps and elapsed time
• test route and duration
• run count
• average FPS and frametime evidence when performance is claimed
• screenshots of settings
• raw monitoring logs when available
• ambient temperature when known
• last-verified date

Remove personal file paths or account information before sharing a battery report. The evidence URL must open the actual proof rather than a logo, channel page or unrelated image.

What not to claim

Do not publish:

• full runtime extrapolated from a momentary watts reading
• battery life inferred from TDP
• a one-run result as a guaranteed value for every unit
• APU package power labelled as total system power
• an overlay battery estimate labelled as completed runtime
• FPS or 1% lows reconstructed from a screenshot
• a brightness percentage relabelled as measured nits
• results that merge different handheld or battery revisions

When a value was not measured, leave it blank.

Publication checklist

• Exact handheld and battery revision recorded
• Full-charge capacity recorded when available
• Windows, firmware and driver versions recorded when known
• TDP or exact manufacturer profile recorded
• Resolution, refresh rate, brightness and HDR state fixed
• Wireless, audio, RGB and peripherals documented
• Complete game settings retained
• Repeatable workload defined
• Warm-up completed
• Start and stop thresholds documented
• At least three runs retained for comparisons
• Completed and projected runtime clearly separated
• Performance evidence preserved
• Missing fields left blank

Official and primary sources

UL Solutions: Procyon Battery Life Benchmark https://benchmarks.ul.com/procyon/battery-life-benchmark

UL Solutions: battery-test brightness sensitivity https://benchmarks.ul.com/hardware/phone/OnePlus%2B9%2Breview

Dell Support: Generate a Windows battery report with powercfg https://www.dell.com/support/kbdoc/en-uk/000130117/how-to-generate-battery-report-using-the-powercfg-command

Microsoft Support: Use Smart Charging in Windows https://support.microsoft.com/en-us/windows/experience/power-battery/use-smart-charging-in-windows

Final note

Battery life is a system result, not a TDP sticker. Lock the handheld, display, game and environment; measure a named battery interval; repeat the workload; preserve the performance evidence; and publish only the result you actually observed.