Budgeting Power for a 0.40-Inch 1440x1080 Near-Eye Module in AR Glasses

Key takeaways

1. At 1440x1080 across a 0.40-inch diagonal the module works at roughly 4,500 pixels per inch, so gate and column addressing stays a real line item even though the emitting area is tiny. ^[1]
2. The largest single consumer is usually the illumination or emitter path, because a transmissive display spends its energy on the backlight while an emissive panel scales with image content and is far cheaper on dark frames. ^[2]
3. A MIPI DSI link spends most of its energy during high-speed bursts, so returning the link to its low-power state between frames is a deliberate design decision with measurable consequences rather than a protocol detail. ^[3]
4. Standby is a family of states and not one switch: display off with the link retained, link parked in low power, host asleep and full power-down all carry different leakage and different wake latency.
5. Dimming strategy matters because average emitter power scales with duty cycle when PWM is used, and the switching frequency you choose trades converter efficiency against visible artefacts. ^[4]

In AR glasses the battery lives in the temple and the heat ends up next to the user's face, so every milliwatt is carried on the head and dissipated against skin. That makes the near-eye module's share of the budget unusually important: it is the component the user stares at, and it is also the one whose consumption changes fastest with what is on screen. A budget written as one number per component will not survive contact with a real product.

The module in question is a 0.40-inch near-eye optical module at 1440x1080 with a 30 degree field of view, 90% DCI-P3 colour coverage and a MIPI interface, intended for AR and VR glasses and head-mounted displays. The resolution and the field of view together fix the angular pixel density the eye will see, and the interface choice moves a specific amount of work to the host. None of that tells you the current draw, which is exactly why the budget has to be assembled from rail measurements and state definitions.

The sections below cover how to structure the budget around rails, where the current actually goes in a pair of glasses, how to define the standby states so they can be compared, a measurement sequence that catches mistakes early, how to drive the illumination path without wasting the cell, and why a bench standby figure rarely matches a worn product.

Build the budget from the rails, not from the battery label

Starting from the cell capacity and working backwards almost always ends in a redesign, because it forces every subsystem onto the same average current line without telling you which one is responsible. Work forwards instead: list every supply rail the module and its host need, name the load that sits on each one, and assign an owner for measuring it. A near-eye module usually needs a logic supply, one or more analogue rails for the source and gate drivers, a dedicated supply for the illumination or emitter path, and a supply for the interface physical layer. Each of those has a different behaviour under load and a different quiescent current when lightly loaded.

The second discipline is separating static from content-dependent load. A 1440x1080 panel showing a mostly dark field and the same panel showing a bright interface are not the same load, and a budget that records only one figure will be wrong in both directions. Split each rail into a fixed term, a term that scales with refresh and resolution, and a term that follows pixel content, then measure each contribution with a purpose-built test pattern.

Peak and average must be tracked separately as well. Average current decides runtime, but peak current decides whether the converter saturates and whether a rail droops far enough to reset the interface during a burst. Both numbers come from the same probe, so record the waveform rather than a multimeter reading.

Why a small 1440x1080 panel still has a real drive load

Physical size is a poor proxy for drive power. At 1440x1080 on a 0.40-inch diagonal the pixel pitch is a few micrometres, and by the usual definition of pixel density the module sits at roughly 4,500 pixels per inch. ^[1] Every one of those lines has to be addressed once per frame, and the dynamic current of the addressing and link paths rises with the number of lines, the line capacitance and the frame rate.

The practical consequence is that frame rate is a power knob, not only a smoothness setting. Dropping from a high refresh rate to a lower one cuts both the addressing activity and the volume of pixel data that must cross the interface, provided the host can gate its own frame pipeline in step. Partial updates are the other lever: if only a small window of the image changes, sending a full frame is wasted energy.

What the module documentation has to state, and what it usually leaves out

A module datasheet normally defines the interface, the resolution, the optical characteristics and the power-up sequence, because the integrator cannot bring the part up without them. What it rarely contains is average current for your content, because that depends on your frame rate, your dimming level and your image. The productive request is a rail map, the initialisation sequence, and current measurements at two or three representative patterns so the fixed term can be separated from the content term.

It is also worth asking which states the module supports by itself. Some parts can hold a stored frame and stop consuming interface bandwidth, others require a continuous pixel stream at all times. That single answer changes how much of the standby design lives in firmware.

Where the current actually goes in a pair of AR glasses

The point of the table is ownership: every row needs one engineer who can produce a measured number for it, otherwise the total is an opinion.

Standby is a state machine, not a switch

Products lose runtime in standby because the word hides at least four different conditions. There is the state where the display is dark but the interface is still clocking, the state where the link has been parked in its low-power mode, the state where the host has suspended its frame pipeline, and the state where every rail above the always-on domain is off. Each one has a distinct current and a distinct wake latency, and the user only ever notices the latency.

The interface matters here because MIPI DSI is designed with high-speed and low-power transmission modes, and a link that is idle in the low-power state costs a fraction of what a continuously bursting link costs. ^[3] In command mode the panel holds its own frame memory and the host can stop sending pixel data between updates, whereas in video mode the host has to keep feeding frames at a constant rate. Choosing the mode that matches the content is the single most effective link-level decision in a near-eye product.

Wake latency has to be budgeted like current. The path from a motion threshold to a visible image includes sensor sampling, host resume, link exit from low power, the module's own wake sequence and the ramp of the emitter path. If that chain is slow, firmware compensates by waking earlier and more often, and the standby current quietly drifts back up. Design the policy so that wake events are driven by what the user is doing rather than by a periodic timer.

Finally, decide what the always-on domain contains. A sensor that must run continuously should be chosen and configured for that job, and everything else should be gated. Anything left powered because it was convenient during bring-up becomes permanent standby loss.

State the maximum number of wake events per hour you are willing to pay for; that single number constrains more of the design than any peak current figure.

A measurement sequence that produces a budget you can defend

1. Instrument the rails before the first firmware build. Place shunts on the illumination path, the display analogue rail, the interface supply and the host rail. A single system-level measurement cannot attribute current to a cause, and by the time the fix is needed the board is already dense.
2. Measure with real content, not with a white screen. Run the shipping interface, a fully dark frame and a worst-case bright frame. The spread between them is the content-dependent term that a datasheet figure will never give you.
3. Log every standby state explicitly. Record current in each state with the display dark, the link in low power and the host suspended, so leakage can be traded against wake latency with numbers instead of impressions.
4. Sweep temperature before trusting a runtime estimate. Battery capacity, leakage and converter efficiency all move with temperature, and eyewear runs warmer than a bench supply because it is worn against the head.
5. Keep the waveform, not just the average. Average current predicts runtime, but the peak tells you whether the converter saturates and whether a rail droops enough to restart the interface during a burst.

Making the standby figure hold once the glasses are worn

A standby number measured on the bench at room temperature rarely survives a worn product. The temple warms against the head, and warmer semiconductors leak more; the battery gauge, protection circuitry and any always-on sensor keep drawing even when the display domain is dark. Firmware that suspends the panel but leaves its converters enabled is the most common single cause of a runtime estimate that misses by a wide margin.

The fix is usually structural. Gate the display rails rather than relying on the module's own dark state, because a converter left enabled to serve a load of nearly zero can consume more than the load itself. Keep the interface physical layer in step with the rest of the domain, since a powered lane holds its clock alive and prevents the host from entering its deepest state. Then re-measure with the product on a head-form or a warm enclosure, and compare against the bench figure to see how large the thermal term really is.

Supply questions belong in the same review. Ask for the rail map, the initialisation sequence and current at representative patterns rather than a single headline figure, because a module such as the 0.40-inch 1440x1080 near-eye optical module offered by DisplayModule displays is documented by its 30 degree field of view, 90% DCI-P3 colour coverage and MIPI interface, and everything that decides battery life starts where that document ends.

Converters that stay awake to serve nothing

Every switching converter has a quiescent current and an efficiency curve that falls off sharply at light load. A rail sized for a bright frame is badly matched to a dark interface that draws almost nothing, so the converter itself becomes the load. Where a design has several display rails, consider whether the light-load states can be served by a linear regulator or by gating the switching stage entirely, and check the transition cost of doing so.

Policies that keep the display useful while costing less

In glasses, most of the time the user is not reading dense content. Dimming the output when attention is elsewhere, refreshing at a lower rate for static overlays, and updating only the region that changed all reduce average power without changing peak capability. The engineering task is to make those transitions invisible, which means choosing thresholds from measured wake latency rather than from a guess, and testing the transitions with the product worn in motion.

Frequently asked questions