For indoor runners, the hardest problem is often not motivation. It is knowing whether the number on the screen is the number that should drive the workout.
A treadmill may display a target speed. A Runn sensor may measure the belt. A Stryd sensor may estimate the runner’s actual movement. A training platform may then use one of those values to determine pace, distance, interval completion, and the data saved to Garmin or another training log. When those signals disagree, a workout can look precise while quietly drifting away from the effort the athlete intended.
That is why PR #5279 in QZ is much more than a FitShow improvement. It introduces a generic, opt-in closed-loop speed-correction controller for supported treadmill drivers: QZ can use an external Runn/Stryd speed signal as feedback, while still sending commands to the treadmill itself.[1]
Table of Contents
The hidden problem with treadmill training
There is no single “treadmill speed” in every workout. The console shows the speed the machine is being asked to target. The belt has its own physical speed, which can change under load. A foot-mounted sensor can estimate the speed of the runner’s body. Those values may be close, but they are not interchangeable.
Stryd describes the same distinction explicitly: the console value, the belt speed, and the runner’s actual running speed can all differ. Its documentation argues that this matters because reliable indoor pace and distance make it possible to compare indoor and outdoor training more consistently.[2]
The problem becomes especially visible during intervals. When a runner changes from a recovery pace to a fast repetition, the treadmill motor needs time to accelerate. If software immediately compares a fast target with delayed sensor feedback, it can react to an old state rather than the current one. That creates overshoot, undershoot, oscillation, and inaccurate interval distance.
Runna’s own documentation acknowledges the same practical issue: acceleration and deceleration can distort short, fast laps by up to 15 seconds per kilometre unless the workout data is processed to account for the treadmill’s response time.[3]
From one-shot correction to a real feedback loop
The earlier approach could apply the difference between the treadmill and the external sensor immediately when a new speed was requested. That is tempting, but it is unsafe as a control strategy: at the beginning of an interval, both the motor and the sensor may still be in transition.
PR #5279 changes the model. The treadmill first receives the normal requested speed. QZ then waits for independent machine feedback and gathers fresh external-sensor samples after the treadmill has had time to settle. Only then does it apply a small, bounded correction.[1][4]
The controller is deliberately conservative:
- it filters stale, disconnected, noisy, or implausibly low sensor readings;
- it waits for the treadmill to settle before correcting again;
- it uses a deadband so tiny differences do not make the motor hunt around the target;
- it limits the size of each correction and the total correction range;
- it resets when a new workout interval starts;
- it stops correcting when the workout is paused or stopped, trustworthy feedback disappears, or the runner changes speed from the physical console.
This is the important conceptual shift: the external sensor is not treated as a number to copy blindly. It becomes feedback in a controlled system. The treadmill remains the actuator, while the sensor provides an independent measurement of what is actually happening.
Why this is bigger than FitShow
FitShow is part of the story, not the boundary of the feature. The correction policy now lives in QZ’s shared treadmill layer rather than inside a single device integration. The merged PR describes the logic as usable on drivers that expose fresh, independent machine-speed telemetry and accept QZ speed commands, with relevant paths including FitShow, Horizon/FTMS variants, and NordicTrack iFit ADB.[1]
That does not mean every treadmill is automatically compatible. The controller is intentionally conditional: without both independent machine feedback and a valid command path, QZ does not guess and does not generate a correction. The setting is also disabled by default, so existing behaviour is preserved unless the runner explicitly opts in.[1][4]
This architecture matters because treadmill support is fragmented. Different manufacturers expose different protocols, different telemetry, and different command semantics. A shared control policy means future integrations can reuse the same safety rules instead of inventing a new speed-correction algorithm for every brand.
The PR also includes regression coverage for delayed startup readings, deadband behaviour, stale feedback, manual console changes, stop handling, interval resets, bounded corrections, large mismatches, and abandoned targets.[5][1] That is exactly the kind of foundation needed if indoor training is going to become more data-driven without becoming more fragile.
The request was already out there
The need did not originate in a laboratory. Issue #4167 came from a runner using Runna, Garmin, a JTX Sprint 9 treadmill, and a Runn sensor. At a treadmill setting of 14 km/h, the sensor was reporting approximately 13.8 km/h. Over time, that difference caused interval distance to drift. The requested solution was simple to describe but difficult to implement correctly: use the external sensor for the training data, while adjusting the treadmill so the measured running speed converges on the workout target.[6]
The issue discussion also records the practical frustration: manually adding roughly 0.2–0.3 km/h to the treadmill, then seeing the system overshoot and undershoot when the delayed sensor feedback caught up.[6] The later report that the correction “seems to work well” is encouraging, but it is still a device-specific user report—not proof that every treadmill will behave identically.[6]
That pattern appears across the wider running ecosystem. Zwift has long documented the consistency problems that can occur with footpods and the response lag that can occur when a treadmill changes speed.[7] In Zwift’s running community, automatic incline and a more realistic treadmill experience have repeatedly been described as highly desirable.[8][9] Runners are not merely looking for another Bluetooth connection; they are looking for training data they can trust from one interval to the next.
What this changes for structured training
For athletes following pace-based or power-based plans, better feedback can improve more than the live display:
- interval targets can be closer to the intended effort;
- distance and pace can be more coherent across indoor sessions;
- completed workouts can be recorded using the sensor that the athlete actually trusts;
- indoor data can become more useful when compared with outdoor training;
- the runner can spend less time manually correcting the treadmill and more time training.
It also creates a bridge between ecosystems. A runner may use Runna for the workout, Garmin for the record, Zwift for the virtual environment, Runn or Stryd for the measurement, and a treadmill from a completely different manufacturer. QZ’s role is to make those pieces cooperate without forcing the athlete into a single hardware or software ecosystem.
The result is not a promise that every treadmill suddenly becomes laboratory equipment. Indoor running still has differences in biomechanics, cooling, incline, belt behaviour, sensor placement, and motor response. “Real data” should mean measured, inspectable, and consistent feedback—not a marketing number presented without context.
That distinction is precisely why this change matters. QZ is moving treadmill control away from a one-shot guess and toward a measured, bounded, device-aware feedback loop. For anyone who builds training around accurate intervals, repeatable effort, and trustworthy historical data, that is a much bigger development than a fix for one treadmill brand.
The direction of travel
The long-term significance of PR #5279 is architectural. It establishes a general pattern: use independent measurements to observe the physical machine, use the machine’s own control channel to correct it, and make every correction conservative enough to fail safely when the data is missing or ambiguous.
That is the foundation for a more honest indoor-training experience—one where the workout is driven by what the equipment and sensor actually report, rather than by the assumption that a displayed target is already reality.
For runners who have ever watched an interval drift, a pace bounce, or a Garmin file disagree with the workout they completed, this is the problem worth paying attention to.
Sources
- QZ PR #5279 — generic Runn/Stryd closed-loop speed correction
- Stryd: Treadmill & Stryd Common Questions
- Runna: Processing Treadmill Data
- QZ closed-loop treadmill support diagnostics
- QZ PR #5279 changed files and regression tests
- QZ Issue #4167 — Runn sensor control treadmill speed
- Zwift: Smart Treadmills vs Footpods
- Zwift Forums: Auto Incline On Treadmills
- Zwift Insider: Using the QZ App with Zwift Running