Motion-to-photon latency is the delay between a movement and the moment the matching visual change leaves the display and reaches the eye - the end-to-end responsiveness metric that decides comfort in VR and on screen. In a motion simulator it has a physical partner: the platform's end-to-end latency, the delay from a telemetry event to the actuator physically moving. Together they decide whether motion reinforces a training session or quietly turns into the cause of nausea. Keep both short and aligned and the felt motion stays locked to the seen motion. Let either drift and the eyes and the inner ear start disagreeing, which is the exact mismatch that makes people sick.
For simulator integrators, distributors, defense and government programs, automotive and aerospace R&D teams, universities, maritime trainers, VR operators, and medical neurorehabilitation providers, that alignment affects session length, trainee comfort, and whether the simulator delivers reliable results. This article explains what motion-to-photon latency actually measures, what counts as low enough, how the delay produces simulator sickness, where latency enters the simulator chain, and how a serious vendor measures it end-to-end rather than quoting a flattering component number. The examples are drawn from two product lines built by Motion Systems: Qubic System for compact VR and driving simulators, sim racing, training, and R&D builds, and the Professional Series for heavy training cabins. They sit at opposite ends of the same physics, which makes them useful for seeing where the threshold really bites.
Key takeaways
Two clocks decide comfort, and both are end-to-end measurements (trigger event to perceivable result, not the response time of one subsystem in isolation): motion-to-photon on the visual side - movement to the update on screen - and the platform's end-to-end latency, from telemetry event to physical motion.
Two physiological thresholds matter, not a marketing number: below roughly 20 milliseconds the delay sits under the perception threshold for seated VR, and below roughly 60 milliseconds simulator sickness stays at baseline before climbing steeply above it.
A number is only trustworthy if the vendor states how it was measured. Qubic System measures telemetry-out-of-the-game to physical motor movement (below 8 ms); the Professional Series runs below 30 ms end-to-end, measured.
What is motion-to-photon latency?
Motion-to-photon latency, often written as MTP latency, is the time between a movement and the moment the resulting visual change leaves the display and reaches the eye. The "photon" in the name points to the light leaving the display - the instant the rendered image reaches the human visual system - which makes it the standard responsiveness metric in virtual reality and on any head-mounted display (HMD). A motion platform adds a second, physical clock: its end-to-end latency, measured from the telemetry event to the actuator physically moving. A coordinated simulator keeps the two aligned, so the body feels the matching force at the same perceptual moment the eye sees the change.
The trigger can be many things. A tracked head turn in a VR headset. A simulated collision. A sudden loss of traction. A gust hitting an airframe. Whatever the event, a coordinated system has to update both channels - the virtual world the eye sees and the force the body feels - close enough together that the brain reads them as one experience.
Latency versus velocity
This is where a spec sheet can quietly mislead. Latency is not the same as how fast the platform moves. Latency is a delay, measured in milliseconds; velocity is a speed, measured in millimeters per second. A platform can move very fast and still feel disconnected if it starts moving late, and a platform with modest travel can feel glued to the scene if it starts on time. When a spec sheet leads with velocity and buries latency, it is answering the easier question.
What is an acceptable motion-to-photon latency for virtual reality?
For seated VR and motion simulation, the practical target is below roughly 20 milliseconds end-to-end - low enough that the delay stays under the perception threshold for most users. Above that, the lag becomes detectable, and detectable lag is where the trouble starts.
Why the threshold sits so low
The threshold is physiological, so a little context helps. Human reaction time to an unexpected event runs around 150 to 250 milliseconds. That number describes conscious reaction. The vestibular system, the balance organ in the inner ear, is extremely sensitive by comparison - it does not need a quarter of a second to sense a mismatch between what the eyes report and what the body feels. That sensitivity is why a delay of a few tens of milliseconds, invisible as a "reaction," still registers as something being wrong.
How firm is the 20-millisecond rule?
So treat the often-quoted twenty-millisecond figure as a guidepost rather than a law. It marks the rough boundary where, for typical seated content, the average user stops noticing the gap. Some people are more sensitive, a sudden movement of the head in VR is less forgiving than a steady driving scene, and the threshold shifts with the task. The rule is simple: aim well below the point where motion and vision drift apart, then verify it for the content actually being run.
How does latency cause simulator sickness?
Latency causes simulator sickness by arriving late and breaking sensory coherence. The brain continuously compares visual input from the eyes with vestibular input from the inner ear. When the two agree - the eyes see a banked turn, the body feels the tilt and the lateral load - the experience reads as coherent and the brain accepts it. When they disagree, the nervous system interprets the mismatch as a sign that something is wrong, and the result is nausea, spatial disorientation, and fatigue. This sensory-conflict mechanism has been the dominant explanation for simulator sickness for decades.
Within the low-latency zone the disagreement stays below the vestibular detection threshold, where it is generally imperceptible, so coherence holds. Push the delay past that threshold and the conflict surfaces into conscious discomfort. The scene shows the turn; the body registers the motion a beat later; the brain flags the error; the first symptoms occur and then climb steeply as the delay grows.
Definition - sensory conflict: the mismatch the brain detects when the eyes and the inner ear report different things at the same moment. Low latency is one of the main tools for preventing it. The other is motion cueing quality, which decides whether the platform moves in the right direction in the first place.
Why latency belongs at the top of a spec
This is also why latency belongs near the top of a specification, not the bottom. A platform that lags the visuals produces the very sensory conflict it was bought to resolve. Without latency held under the threshold, trainees start cutting sessions short, throughput on a training program drops, and the motion system meant to extend session length becomes the reason sessions end early. That is the real loss a latency spec protects against - not slow movement, but the motion sickness and lost training time that arrive when the seen and the felt come apart.
How is motion-to-photon latency measured?
Each clock is measured end-to-end: from the trigger event all the way to the final perceivable result, with the vendor stating where the clock starts and where it stops - movement to display photons on the visual side, telemetry event to physical motion on the platform side. Intermediate figures - processor time, controller-to-motor delay, raw actuator response - are components of the budget, not substitutes for it. A platform with an impressive internal actuator number can still show a large end-to-end delay if the telemetry pipeline, the cueing algorithm, and the display chain each add their own slice.
Where Qubic System starts and stops the clock
Qubic System defines the measurement precisely, and the precision is the point. The clock starts the instant telemetry data leaves the game and stops when the motor physically changes position. On the internal measurement diagram that window is labeled the time that matters - everything the user can actually feel. Across most of the range that window comes in below 8 milliseconds, and the stage-by-stage breakdown behind that figure shows where the budget goes:
| Stage (QS-220 signal path) | What happens | Contribution |
|---|---|---|
| USB transfer (game to controller) | Telemetry data travels to the motion controller | about 350-450 microseconds |
| Driver layer (power cabinet) | The drive translates the command for the actuator | about 1.2 ms |
| Motor response | The linear actuator physically reaches the new position | about 6.8 ms |
| End-to-end ("the time that matters") | Telemetry-out to physical movement | below 8 ms |
A small detail in that table shows the architecture is understood rather than guessed. The QS-220 adds a driver layer that a directly driven seat mover does not have, and that layer carries additional latency of its own, yet its end-to-end figure is lower (below 8 ms) than the directly driven seat-mover unit (below 10 ms), because its linear-actuator motor subsystem responds faster. The extra step is more than paid back. That is what a measured, broken-down number looks like - and it is the difference between an engineering claim and a marketing one.
The VR round-trip is counted separately
One more measurement nuance matters for VR. Compensating a VR headset so the virtual horizon stays locked to the cockpit needs a separate round-trip that reports the platform's current physical position back to the software. That round-trip is not part of the end-to-end motion figure - it applies only to the visual correction, not to the movement itself - so a spec worth trusting keeps the two separate instead of blending them into one flattering total.
Professional Series: the same convention at a bigger scale
The Professional Series states its figure the same way: below 30 milliseconds end-to-end, measured across the line. Worth a clarification here, because two different thresholds are in play. The roughly 20-millisecond figure earlier is the transparency threshold for seated VR - the point below which the average user stops noticing the gap at all. There is a second, more forgiving boundary for full-cabin simulation: end-to-end latency below roughly 60 milliseconds keeps simulator sickness at baseline, and symptoms only begin to climb above it. A professional training cabin with heavier payload and longer travel does not need to hit the VR transparency mark to stay comfortable; it needs to stay well under that 60-millisecond sickness boundary, and below 30 milliseconds sits comfortably inside it with margin to spare. Two different scales, one measurement convention.
What is the difference between latency and frame rate?
Latency is when a response arrives; frame rate is how often the picture updates. They are related but not the same, and a buyer can get one right while the other quietly ruins the experience.
Frame rate sets a floor under latency, and the refresh rate of the panel is what sets it: a display that refreshes 90 times a second cannot, on its own, respond faster than one frame, because a new frame reaches the panel only every 11 milliseconds or so, and a change that misses one waits for the next frame. So a higher refresh rate helps. But it does not guarantee low end-to-end latency, because every other stage in the chain still adds delay on top of that frame time. A simulator can run a high frame rate and still feel laggy - perceived latency stays high - if the telemetry pipeline, the cueing algorithm, or the display panel is slow.
There is a second, sharper distinction: consistency. A steady delay is a fixed time offset, and the vestibular system copes with it far better than with a delay that jumps around frame to frame. When the lag keeps shifting - sometimes 15 milliseconds, sometimes 40, depending on scene complexity and computational load - the inner ear gets a moving target it cannot adapt to, and that variability has its own effect on sickness beyond the average value. A platform with a stable, slightly higher latency can be more comfortable than one with a lower but jittery figure. Average latency is the headline; the steadiness behind it is the story.
Where does motion-to-photon latency come from?
End-to-end latency is a sum of contributions across the whole chain, and the factors below tell a buyer where a vendor spent the budget.
Simulation host. The host computer generates telemetry at its frame rate. Each update carries a delay of roughly one frame time, so a higher host rate trims this slice.
Telemetry transport. Moving data from the host to the motion controller adds a small amount over USB or Ethernet. Small, but not zero.
Motion cueing. The algorithm that turns raw telemetry into actuator commands adds processing time. More sophisticated cueing can add a little more, usually a fair trade for better direction and fewer false cues.
Actuator response. The mechanical time between a command and the actuator reaching position. Electric servo actuators respond in the low-millisecond range for small moves; large movements take longer regardless of technology, because acceleration limits cap how fast mass can travel.
Display and tracking. Projectors and panels add their own render and response time. In a headset, sensors such as cameras and IMUs feed the tracking system, which processes sensor data for motion estimation before rendering begins, so the scene cannot update until the device orientation is known; global shutter cameras also provide clearer tracking references than rolling shutters. Inside a headset the remaining budget is spent in a fixed order: IMUs operate continuously and report far faster than any panel can draw, render pipeline execution turns the predicted pose into a frame, distortion correction pre-warps that frame for the lens, and only then does the display light up. Because the HMD's display refreshes at specific intervals rather than on demand, a frame that misses its slot waits for the next one. Optical see through systems used in augmented reality run the same arithmetic against a harder deadline, since in OST systems the real world reaches the eye with no delay at all and any lag in the rendered layer shows against it. Panel physics closes the list: a pixel moving from one color to the next takes time to settle, and slow settling reads as motion blur and washed-out contrast during head movement rather than as latency.
Synchronization. Making the visual and the motion land in the same perceptual moment adds a small margin so the slower channel is ready. Done badly, this either shows as visible desync or inflates the whole budget.
A well-engineered platform keeps the total inside the comfort zone by trimming each slice deliberately. Achieving a good headline figure is arithmetic across the whole chain, not one clever component. A platform that lands above the threshold has accumulated delay somewhere a careful vendor would have caught - which is why the breakdown, not just the headline number, is worth asking for.
Why does a motion platform need low latency too?
A motion platform needs low latency because cue timing is the entire job. It is not enough for the visuals to be quick. Low latency is critical to platform performance for one reason: the felt force has to land with the seen event, or the platform reintroduces the conflict the visuals were trying to avoid. This is why latency is a platform spec, not only a headset spec.
Better visuals raise the stakes
The consequence shows up most clearly when visuals get better. Sharper resolution, a wider field of view, and VR make the image more convincing - which makes any motion delay more noticeable, not less. A high-fidelity picture paired with a late-arriving force can produce worse sickness than a plain setup, because the eyes are now fully convinced while the body is a beat behind. Paying for premium visuals without matching, low-latency motion can mean paying for the cause of the nausea that then has to be managed.
How the two Motion Systems lines state it
That is the reason both Motion Systems lines treat the figure as a hard target and state how it was reached. Qubic System runs below 8 milliseconds (the directly driven seat-mover system below 10), measured telemetry-out to motor movement, fast enough that a sim racer feels the rear step out the instant the screen shows it. The Professional Series runs below 30 milliseconds end-to-end, measured, which holds a full training cabin inside the comfort window through long sessions. Different payloads, different travel, same discipline: a number with a method behind it.
Does low latency alone solve VR sickness?
A fast, properly measured figure closes one conflict and leaves a second one open as soon as a VR headset joins the setup. When the platform tilts, the headset tracking system reads that tilt as head movement, because every new pose it reports describes relative motion between the headset and its tracking reference. The virtual horizon rolls the wrong way, the virtual head drifts out of the cockpit, and the mismatch simply moves to a new channel - visual this time instead of vestibular. Left uncompensated, a motion platform paired with a headset can produce more motion sickness than a static VR setup, which is the exact opposite of what the platform was bought to do.
Compensation is the second layer
The answer is compensation, and it belongs in the same conversation as latency. Motion Systems handles it in software, as VR HeadWay: the platform already knows exactly how it is moving, so that movement is subtracted from what the headset reports and only real head movement reaches the virtual world. This is what the round-trip described earlier is for, and it is why the round-trip stays out of the motion figure. Two layers, two different conflicts - the platform gives the inner ear the signal it expects, and compensation keeps the virtual content stable while it does so.
Frequently asked questions
What does motion-to-photon latency mean?
Motion-to-photon latency is the delay between a movement and the moment the matching visual change leaves the display and reaches the eye - the "photon" is that light from the screen, which is why it is the standard responsiveness metric in virtual reality and on any head-mounted display. A motion platform has a physical counterpart, its end-to-end latency, measured from the telemetry event to the actuator moving. Comfort depends on keeping both short and aligned: low latency keeps seen and felt motion together, high latency pulls them apart.
What latency is low enough to avoid VR sickness?
For seated VR and motion simulation, aim for below roughly 20 milliseconds end-to-end, low enough that the delay stays under the perception threshold for most users. Treat this as a guidepost rather than a hard rule: sensitivity varies between people, fast head movement is less forgiving than steady scenes, and consistency matters as much as the average. The safe approach is to target well under the detectable point and verify it for the content that will actually run on the simulator.
How is latency different from frame rate?
Latency is when a response arrives; frame rate is how often the picture updates. A panel with a 90 Hz refresh rate refreshes every 11 milliseconds or so, so a change that misses one frame waits for the next frame - which sets a floor under latency without guaranteeing a low end-to-end figure, since every other stage in the chain still adds delay. A simulator can run a high frame rate and still feel laggy if the telemetry, cueing, or display stages are slow.
How is motion-to-photon latency measured (in practice)?
It is measured end-to-end, from the trigger event to the final perceivable result, with the vendor stating where the clock starts and stops. Qubic System measures from telemetry leaving the game to the motor physically changing position (below 8 ms), broken down across USB transfer, the drive layer, and motor response. Component figures such as raw actuator response are parts of the budget, not the whole - a credible vendor provides the breakdown, not just a single number.
Why does a motion platform need low latency too?
Because the felt force has to arrive at the same perceptual moment as the seen event. If the platform lags the visuals, it recreates the exact sensory conflict that causes sickness, so latency is a platform requirement, not only a headset one. The need grows as visuals improve, because a more convincing image makes any motion delay easier for the body to detect.
What causes high latency in a simulator setup?
High latency accumulates across the chain: the simulation host frame rate, telemetry transport, the motion cueing algorithm, actuator response time, display and head-tracking delay, and synchronization margin. Any one of those factors can push the total past the comfort threshold, and a significant delay in one stage is usually easier to find than a little slippage spread across all of them. This is why the end-to-end figure, and the breakdown behind it, matter more than the response time of any single component.
