On a wearable, the display is often the largest single load and the one whose consumption varies most with what the user is doing. A 0.66-inch 64x64 colour PMOLED makes that variability explicit: with 65,536 colours and three emitters per pixel, the current depends on the average brightness of the picture rather than on a fixed backlight. A status screen with thin white text on a dark background is cheap; a full-screen saturated colour panel is not. Building a rail that survives both cases, and a firmware policy that keeps the product in the first case as often as possible, is the whole job.
Key takeaways
- The panel's current follows the average picture level, so the interface design is part of the power budget rather than a separate concern.
- Three emitters per pixel means a colour panel costs more than a monochrome one at the same perceived brightness, especially with large filled areas.
- Dimming by switching keeps colour stable at low brightness but adds driver activity that shows up as a small fixed cost.
- The charge pump or boost that feeds the panel has its own efficiency curve, and its light-load behaviour often dominates the idle figure.
- A wearable rail should be characterised with the real user interface rather than with a test pattern of maximum brightness.
Wearable power budgets are usually written around the radio and the sensor, with the display added afterwards. That order is a mistake on an emissive panel, because the display is the only load whose consumption is directly controlled by a design decision the team makes every day: what the screen looks like.
The second difference from a phone is the duty cycle. A wearable display is glanced at, not watched, so the average is far below the peak, and a rail sized for the worst case will be oversized for almost every second of the product's life.
The sections below look at where the current goes on a colour emissive panel, how dimming choices change the picture, and how to measure the rail in a way that predicts battery life rather than a datasheet condition.
Average picture level on a 64x64 colour wearable display
An emissive panel produces light per pixel, so its current scales with how many pixels are emitting and how hard they are driven [2]. On a monochrome display that reduces to the number of lit pixels. On a 65,536-colour panel each pixel carries three emitters, so a soft pastel background costs considerably more than the same layout drawn as thin strokes on black.
That gives the interface designer real authority over battery life. A dark theme with white text, which suits a glanceable status screen anyway, is also the cheapest option. A full-screen coloured card that appears for two seconds every minute is not, and if it runs at the panel's maximum brightness the average consumption can be several times higher than the dark alternative.
The measurement consequence is that a single current reading means very little. What matters is the current during each distinct screen state, multiplied by how long that state is shown. Recording those pairs turns a vague power discussion into an arithmetic one, and it usually identifies one or two screens that dominate everything else.
Starting from a module that already integrates the controller and the charge pump simplifies that work, because the rail behaviour is then a property of a documented part rather than of a design assembled from separate pieces. A DisplayModule module in this class gives the firmware a small set of defined states to switch between, which is exactly what a per-state measurement needs.
Dimming, colour and the behaviour at low brightness
At night, a wearable display is often dimmed to a small fraction of its daytime brightness, and the way that dimming is done changes both the appearance and the rail.
Pulse-width modulation keeps the emitters at a constant drive point and varies the fraction of time they are on, so colour coordinates stay stable as brightness falls [1]. This is why the method is common for low-brightness night modes: the display does not shift colour as the user drags the brightness slider down.
The cost is switching activity in the driver, which appears as a small fixed current plus a possible flicker at very low duty cycles. A user glancing at a dimmed wearable from an angle may perceive flicker that is invisible straight on, so the lowest usable duty cycle should be found by testing rather than by assuming the full range is usable.
The alternative is amplitude control, which has no switching overhead and can suffer a colour shift at the low end. A hybrid is common: amplitude control for most of the range, switching only at the bottom, with the crossover chosen by looking at the display rather than at the register map.
Rail design choices for a wearable colour panel
| Choice | What it affects | What to watch |
|---|---|---|
| Boost converter selection | Efficiency across the load range | Light-load efficiency, which decides the idle figure more than peak rating |
| Rail capacitance | Supply ripple during screen changes | Inrush at power-up and the resulting reset behaviour |
| Panel brightness policy | Average current and emitter ageing | Default level, maximum user-selectable level, night mode floor |
| Dimming method | Colour stability against low-brightness flicker | Where amplitude control hands over to switching |
| Screen state reporting | Firmware's ability to budget power per screen | A defined state per user interface screen, logged during testing |
Measuring a wearable display rail honestly
- Enumerate the screen states firstList every distinct thing the display can show, from the watch face to the settings list. If two screens differ only in colour, treat them as different states.
- Measure current per state at the default brightnessUse the shipping firmware and the shipping brightness, not a test pattern. Record the value against the state name so the table can be reviewed later.
- Weight each state by its real duty cycleEstimate how many seconds per hour each screen is visible in normal use, and multiply. Most wearable battery life is decided by two or three states.
- Repeat at the night brightness floorThe dimmed case is where flicker and colour shift appear, and where the converter's efficiency is often worst. Measure it rather than interpolating.
- Re-run the table after interface changesA redesign that adds a bright card to the rotation can change the daily average more than a firmware optimisation ever will.
If the battery estimate looks worse than expected, do not start with the converter. Sort the screen states by weighted current and look at the top of the list. On colour emissive wearables the fix is almost always a design change to one screen, such as replacing a filled card with text on black, rather than a change to the power circuitry.
Sources
Frequently asked questions
Why does a colour PMOLED use more power than a monochrome one?
Because each pixel contains three emitters rather than one, and producing a given perceived brightness from a mixture of colours generally requires more total emission than producing it from a single colour. The difference is largest on screens with big filled areas and smallest on text-heavy dark layouts.
Does dimming by switching really save power on a wearable?
It reduces the energy delivered to the emitters in proportion to the duty cycle, which is a genuine saving, but it adds driver switching activity that does not fall to zero. At very low brightness the fixed part becomes significant, and flicker may become visible, so the bottom of the range should be tested rather than assumed.
How should the display rail be sized for a wearable?
Around the weighted average of the screen states rather than around the peak, with enough headroom for the brightest state the product allows. Sizing purely for the maximum brightness usually produces an oversized converter whose light-load efficiency then wastes more than the headroom gains.
What is the most common mistake in wearable display power budgets?
Measuring a single test pattern and treating the result as the display's consumption. The number depends entirely on what is on the screen, so a budget built from one reading is usually wrong in whichever direction the real interface happens to differ.