Battery life in an instrument is usually decided by the display, and the display’s consumption is usually decided by how it is used rather than by which panel was chosen. A modest panel driven inefficiently will outlast a premium panel driven well only if the drive strategy is right.

This article sets out how to build a budget that reflects reality, where the energy actually goes, and which design levers give the largest return.

Building an honest energy budget

A duty-cycle table makes the budget auditable. List each state – off, idle with display on, active with touch, updating – with its measured current and the hours per day it is expected. When someone proposes a design change, the table shows immediately which state it affects and by how much, which keeps later trade-offs grounded in the same numbers.

A duty-cycle table makes the budget auditable. List each state – off, idle with display on, active with touch, updating – with its measured current and the hours per day it is expected. When someone proposes a design change, the table shows immediately which state it affects and by how much, which keeps later trade-offs grounded in the same numbers.

A duty-cycle table makes the budget auditable. List each state – off, idle with display on, active with touch, updating – with its measured current and the hours per day it is expected. When someone proposes a design change, the table shows immediately which state it affects and by how much, which keeps later trade-offs grounded in the same numbers.

A duty-cycle table makes the budget auditable. List each state – off, idle with display on, active with touch, updating – with its measured current and the hours per day it is expected. When someone proposes a design change, the table shows immediately which state it affects and by how much, which keeps later trade-offs grounded in the same numbers.

Start from the operating cycle, not from a datasheet. Write down what the product does over a typical day: how long it sits idle, how long the display is on, how often the content changes, and how often someone touches the screen.

Then multiply each state by its power and its duration. The result is usually surprising, because the idle state that nobody thinks about often dominates. A display that idles at a few tens of milliwatts for twenty hours consumes more than one that runs at several watts for ten minutes.

Measure the states you do not know rather than estimating them. A bench supply with a current readout is enough to characterise most states, and the measurements remove the largest source of error in the estimate.

Backlight as the dominant load

The table below is the form the budget usually takes. The states are defined by the product’s behaviour, and the current in each is measured rather than estimated.

State	What is drawing current	Typical duration	Lever that reduces it
Off	Regulators quiescent, touch controller if not stopped	Hours to days	Quiescent current, stopping touch scanning
Idle, display on	Backlight at low brightness, panel refresh, controller	Most of the working day	Dimming, auto-brightness, refresh rate
Active interaction	Backlight at working brightness, touch scanning, graphics updates	Minutes	Brightness ceiling, partial updates
Updating	Interface active, panel redraw, memory access	Seconds per update	Update frequency and region size

In a transmissive display, the backlight is almost always the largest consumer. Its power scales with brightness and with the area lit, and it is on whenever the display is on.

For products that stay on mains power, the conventional route is covered in the guide to low-power TFT displays. Three levers follow. Reduce brightness to the level the user actually needs rather than the panel’s maximum. Dim automatically with ambient light, so the display is not running at full output in a dark room. And turn the backlight off rather than dimming it when nobody is using the product – the difference between 5 per cent brightness and zero is larger than the difference between 100 per cent and 5 per cent in most designs.

Refresh and update strategy

The interface’s refresh rate is a design decision, not a property of the panel. A display refreshed at 60 Hz for a static interface burns power on timing, memory access and panel drive that a 10 Hz update would largely avoid.

Where the panel or controller supports it, partial updates that change only the affected region reduce both the data traffic and the panel’s drive activity. For interfaces with a slowly changing value – a temperature, a level, a counter – updating only that region at a low rate is usually imperceptible to the user and materially cheaper.

Controller and interface power states

The display controller, the graphics engine and the interface itself all have power states that the software can control. Two questions determine how much is available: whether the controller can be placed in a low-power state while retaining the panel’s image, and whether the interface can be disabled between updates without losing sync.

Where the panel holds its image without refresh, the whole chain can sleep between updates. Where it does not, the display must be refreshed continuously or turned off, and the choice becomes a user-experience decision rather than a technical one.

Regulator efficiency and quiescent current

Regulators contribute in two ways: conversion losses while the load is active, and quiescent current while it is not. In a product that spends most of its life idle, the second matters more than the first.

A linear regulator that is 60 per cent efficient under load may draw microamps at no load; a switching regulator that is 90 per cent efficient under load may draw tens of microamps quiescent. For a device that sleeps for months, the switching regulator’s quiescent current can exceed all the energy used while awake.

This is the point where a system-level power budget beats a display-level one: the correct question is not “how efficient is the display’s regulator” but “what does the whole display chain draw when the product is idle”.

Touch scanning power

A capacitive touch controller scans continuously to detect contact, and that scanning current is present whenever the display is active – and often when it is not, unless the firmware stops it.

Two measures help. Reduce the scan rate when no touch has been detected for a period, since the first contact will still be detected with a brief delay that most users do not notice. And stop scanning entirely when the display is off, unless the product’s interaction model requires a wake-on-touch.

Display-off and partial-update strategies

Wake latency is the hidden cost of sleeping the display. A panel that needs a full refresh and a backlight ramp before it shows a usable image adds a visible delay to every interaction, and users respond by not letting it sleep – which destroys the saving. Measure the wake time and design the interaction around it rather than assuming it is negligible.

Wake latency is the hidden cost of sleeping the display. A panel that needs a full refresh and a backlight ramp before it shows a usable image adds a visible delay to every interaction, and users respond by not letting it sleep – which destroys the saving. Measure the wake time and design the interaction around it rather than assuming it is negligible.

Wake latency is the hidden cost of sleeping the display. A panel that needs a full refresh and a backlight ramp before it shows a usable image adds a visible delay to every interaction, and users respond by not letting it sleep – which destroys the saving. Measure the wake time and design the interaction around it rather than assuming it is negligible.

Wake latency is the hidden cost of sleeping the display. A panel that needs a full refresh and a backlight ramp before it shows a usable image adds a visible delay to every interaction, and users respond by not letting it sleep – which destroys the saving. Measure the wake time and design the interaction around it rather than assuming it is negligible.

Turning the display off is the single most effective measure, and the design question is how to do it without degrading the user experience. Common approaches include a timeout based on inactivity, a proximity or ambient-light trigger, and an explicit user action.

Partial-update strategies deliver smaller savings but work in products that must remain visible. They also change the interface design: an interface that updates one region at a time needs a layout that tolerates it, rather than a full-screen redraw with an animation between states.

Measuring real consumption

Measure the states, not the average. A bench supply with current logging, or an inline current monitor, will show whether the idle state is what the budget assumed and whether the sleep states actually engage.

Two measurements are worth making on the first prototype: the current in each defined state, and the current after a full operating cycle has completed, to establish that nothing failed to return to its low-power state. The second one catches the bugs that turn a good budget into a short battery life.

Trade-offs with readability and responsiveness

Every measure has a cost. Dimming reduces readability in bright conditions; a lower refresh rate can make a scrolling list look uneven; a slower touch scan adds a perceptible delay to the first touch; sleeping the interface adds the time it takes to wake.

Decide which of these the user will notice, and accept the trade explicitly. A design that dims aggressively to save power but is unusable outdoors has optimised the wrong variable. For the technology side of the decision, the comparison is in the article on e-paper and reflective displays.

Setting the day-one energy budget target

Set the target before the design is fixed, and express it in operating hours rather than in milliwatts, because that is what the product promises. Then allocate it: display active time, idle time, sleep current and the energy cost of each interaction.

A target that is written down at the start is the only thing that keeps the trade-offs honest later, when each individual decision looks reasonable and the total does not. For the brightness-control side of the same problem, see the article on flicker-free dimming.

Frequently asked questions

What percentage of battery life does the display usually consume?

In portable instruments it is usually the largest single load, often more than half. The proportion depends on the operating cycle, which is why the cycle has to be defined before the budget.

Is a lower refresh rate always better for power?

Usually, for static interfaces. It becomes a problem when the content moves, because a low refresh rate makes motion look uneven.

Does the panel or the drive strategy matter more?

For most products the drive strategy matters more, because it determines how long the display is lit and how often it redraws. The panel choice sets the floor.