Specifying a 0.23-Inch 640x400 Micro OLED for AR Glasses
Most AR display projects do not fail because the panel was wrong; they fail because the requirement was never written in a form anybody could test. "Bright enough outdoors" and "sharp enough for text" are intentions, not specifications. The work of specifying is translating each intention into a panel attribute, an acceptance threshold and a measurement method, and doing it before the mechanical design is frozen. A 0.23-inch 640x400 micro OLED is a useful worked example because its parameters are modest enough that the trade-offs are visible, which forces the requirements to be honest.
Key takeaways
- Every requirement needs three parts: the panel attribute it depends on, the threshold that counts as passing, and the method used to measure it.
- Field of view and pixel count must be specified together, because angular resolution is what the eye actually resolves.
- Luminance requirements belong in an optical budget that includes measured transmission through the full stack.
- Mechanical requirements such as panel thickness, connector height and flex bend radius constrain the enclosure more than the electronics do.
- Write the specification so a supplier can answer it in writing, with figures, rather than agreeing in principle.
A specification has one job: to let two parties agree on whether a delivered item is acceptable. That is a much narrower job than most specification documents attempt, and it is why so many of them are long, careful and useless at the moment of acceptance.
The failure mode is familiar. A team writes down the user experience it wants, sends it to suppliers, receives panel datasheets in return, and picks the one whose numbers look strongest. Nobody has connected the requirement to the measurement, so nobody can say whether the choice was right until users try it.
The corrective is mechanical rather than creative. For each requirement, write the attribute, the threshold and the method. The sections below show what that looks like for a small near-eye panel, and where the translation usually breaks down.
Start from the use case, not the panel
The first useful sentence in any display specification describes what the user is doing. Reading notifications while walking, following a navigation prompt, checking a camera framing, or reviewing a technical drawing are four different products with four different display requirements, even if they end up using the same panel.
Once the use case is written, the derivable requirements follow in a fairly predictable order: what has to be legible, at what angular size, in what ambient light, for how long, and with what tolerance for the device moving on the face. Only then does it make sense to talk about pixels and nits.
This ordering matters because it prevents a common inversion. Teams that begin with panel datasheets tend to select the panel with the most impressive numbers and then invent a use case that justifies it, which is how products end up heavier and more expensive than the problem required [1]. Working the other way round is easier when the panel data is published in full, as it is for DisplayModule product pages, because then the panel can be judged against the requirement instead of standing in for it.
Turning requirements into testable attributes
| Requirement | Panel attribute that answers it | How to verify it |
|---|---|---|
| Text must be legible while walking | Pixel count combined with the field of view the optics deliver [2] | Render representative text at the intended angular size and have users read it while moving |
| The image must remain readable in daylight | Luminance available at the eye after optical losses | Measure luminance at the exit pupil in controlled ambient conditions and compare against the threshold |
| Dark content must not look grey | Contrast behaviour with bright and dark areas in the same scene | Display a realistic scene rather than a full-screen test pattern and judge the dark regions |
| The device must be comfortable for an hour | Mass and thermal behaviour of the display assembly and its electronics | Wear a mechanically representative mock-up and measure surface temperature over a realistic session |
| The enclosure must fit a normal frame | Panel thickness, connector height and flex bend radius | Build a mechanical mock with real components and check clearances against the intended shell |
Writing a specification a supplier can answer
- State the attribute, not the feelingReplace "bright enough" with the luminance required at the eye, and the ambient condition in which it must hold.
- Give every requirement a number and a toleranceA threshold without a tolerance invites an argument at acceptance about whether a marginal result passes.
- Name the measurement methodSay where the instrument sits, what pattern is displayed and what conditions apply. Two labs measuring generously will disagree otherwise.
- Separate must-haves from preferencesMark each line as mandatory or desirable. This is what allows a supplier to propose a variant instead of declining the whole enquiry.
- Ask for written confirmation per lineRequest a response against each requirement. A general statement of capability cannot be filed as evidence later.
- Decide what you will test yourselfSome attributes are cheaper to verify on your own bench than to negotiate. Mark those, and plan the fixtures before the first article arrives.
Where AR specifications usually go wrong
Three mistakes account for most of the rework in near-eye projects, and each one is a specification problem rather than a technology problem.
Specifying the panel instead of the system
A panel attribute is an input, and the user experiences the output of the whole optical and mechanical chain. Writing the specification at the panel level makes the interesting trade-offs invisible: a slightly lower panel luminance with a more efficient optical path may outperform a brighter panel behind a lossy one.
The fix is to specify at the eye and let the supplier work backwards. Where a supplier cannot influence the optics, specify the panel attributes but show the arithmetic that connects them to the user-visible target, so both sides can see which assumptions are load-bearing.
Leaving interaction out of the display specification
How the user controls the device affects the display more than most teams expect. A design with no touch and no physical controls must communicate everything through the image, which means more content at once, which changes the angular resolution requirement. Deciding the input method after the display is specified frequently invalidates it.
Treating the input decision as part of the display specification is unusual but effective, because it forces the interaction and the image to be designed against the same set of constraints [3].
Acceptance criteria that arrive late
The worst time to invent an acceptance criterion is when the first article is on the bench and somebody asks whether it passes. Write the criteria with the specification, including which ones you will measure in-house and which ones you will accept on the supplier's data, and the acceptance meeting becomes a formality rather than a negotiation.
If a requirement cannot be traced to a measurement, it is not yet a requirement. The most useful review of any AR display specification is to read each line and ask who will measure it, with what instrument, and what result counts as a pass. Lines that cannot answer those three questions should be rewritten or deleted before the document goes anywhere near a supplier.
Sources
Frequently asked questions
How detailed should an AR display specification be?
Detailed enough that the acceptance decision is mechanical rather than a matter of opinion. That usually means a page or two of numbered requirements, each with an attribute, a threshold with a tolerance, and a measurement method, plus a clear split between mandatory and desirable items.
Should the specification be written in terms of the panel or the complete optical system?
In terms of what the user experiences, with the panel attributes derived from it. Where a supplier only controls the panel, state the panel attributes but show the calculation that links them to the user-visible target, so the assumptions behind the requirement are visible to both sides.
What is the biggest source of rework in near-eye display projects?
Requirements that were never made testable. When nobody can say what passing looks like, the design drifts towards whichever option looks most impressive on a datasheet, and the mismatch only becomes visible during user trials, after tooling decisions have been made.
How should input method be handled in the display specification?
Decide it at the same time as the display. Whether the user touches the device, uses buttons, or relies on voice and host software changes how much information the image must carry, which in turn changes the angular resolution and field of view requirements. Specifying the display first often means specifying it twice.