TL;DR
- We don’t read the simulator’s “touchdown vertical speed” variable. It’s notoriously inaccurate.
- We don’t capture vertical speed on the single frame just before touchdown. A sim stutter ruins the number, and even a clean reading only describes the airframe’s angle at impact, not the force the gear actually absorbed.
- We do measure your gear’s distance to the runway across the final second of flight, fit a curve through it, and report the descent rate at the exact moment of touchdown.
- The result is more accurate, slope-aware (works on uphill runways), rewards proper flare technique, and is robust to single-frame noise.
Conventions. Landing rates are reported in fpm (feet per minute).
Negative values mean descending; the rate the wheels feel at touchdown is
always negative on a normal landing. A “good” landing is typically around -100
to -150 fpm.
Why other trackers get different numbers
Three common approaches show up in sim trackers, each with a specific failure mode:Reading the simulator’s “touchdown VS” variable
Most simulators expose a variable likePLANE TOUCHDOWN NORMAL VELOCITY that’s supposed to record your vertical speed at the moment of touchdown. It sounds authoritative: the simulator itself is telling you the answer.
In practice this variable is unreliable. The simulator latches a single value at the moment its on-ground bit flips, and that latched value often doesn’t reflect what actually happened. On many aircraft mods it’s never updated correctly, on others it reports the value from before the flare started, and on uphill runways it’s geometrically distorted by terrain slope. Every experienced VA pilot has seen a butter landing report -300 fpm and a slammed landing report -50 — that’s this variable.
Stratos ignores this variable entirely for its own calculation.
There’s also a deeper, conceptual problem with the whole idea of reading vertical speed at the touchdown frame, even if you could capture it perfectly. VS at the moment of wheel impact describes the airframe’s angular descent rate at that instant; it doesn’t describe the jolt the gear actually absorbed. A pilot could approach at -1000 fpm and flare aggressively in the final fraction of a second to bleed the rate down to -200 at gear contact. By any VS-at-touchdown metric that’s an excellent landing. But the deceleration required to shed 800 fpm in that little time would trip a hard-landing inspection on any real airframe. In actual airline operations, what’s measured at touchdown is the peak vertical g-force the gear and airframe experienced, recorded by accelerometers and graded by FOQA programs, not vertical speed. Descent rate isn’t the primary touchdown metric in real operations, though it is monitored, and maintenance even derives the impact g from it when the accelerometer reads unreliably (more on that in the grading-bands reference below). G-force itself is just hard to model meaningfully in a simulator, so VS is the most accessible analogue available, and that’s the one every tracker (including Stratos) ends up working with.
Capturing VS on the frame just before touchdown
This is the most common alternative. When the simulator reports the aircraft has touched down, the tracker reads the vertical-speed value from the previous frame and reports that as the landing rate. This works better than reading the touchdown variable, but it has a fundamental problem: it depends on a single sample being perfect. Sim stutters, frame drops, simvar lag, and momentary VS spikes are all common. If any of those happens at the wrong moment, the reported landing rate is wrong, and there’s no way for the tracker (or the pilot) to tell. Worse, it doesn’t reflect what the wheels actually felt. If you flared well, bleeding off descent rate in the last half-second, the frame just before touchdown might still show -300 fpm even though you actually touched at -150. Single-frame methods can’t capture that nuance.Averaging VS across the last second
Some trackers improve on the single-frame method by averaging vertical speed across the last second. This is more robust to noise: a single bad sample doesn’t dominate the result. But averaging has its own problem: it punishes good technique. If you actively flared, your VS started high (still descending) and bled off through touchdown. The average over that second is much higher than what your wheels actually felt. A pilot who decelerates from -700 fpm to -150 fpm at touchdown gets reported as -425 fpm (the average) instead of the -150 they actually achieved.What Stratos does
Three things, layered to give us both accuracy and reliability.1. We track the gear’s actual distance to the runway
Every simulator frame, Stratos records your aircraft’s gear height above the runway surface (along with vertical speed, ground speed, pitch, bank, position, and other state) into a high-frequency rolling buffer. At 60 fps that’s 60 samples per second of detailed flight data. Critically, we also calibrate the gear height for your specific aircraft. Heavy aircraft like the A380 and 747 report several feet of gear-AGL while parked because of how the simulator models the relationship between the aircraft’s centre of gravity and the gear positions. Without calibration, those aircraft would never appear to “touch down” because their gear-AGL would never reach zero. Stratos captures the calibration value when your flight starts on the ground, so every aircraft normalises correctly.2. We detect touchdown three independent ways
Knowing when you landed is just as important as knowing what the rate was. Stratos has three layers of touchdown detection that work together:- Frame-buffer detection finds the exact frame where the simulator’s on-ground bit flipped from false to true. When this works, it’s frame-accurate.
- State-level detection watches Stratos’s own internal state machine in case the buffer missed the transition (a single dropped frame, a quirky simvar, a custom-aircraft mod that handles its own gear logic).
- Phase-change backstop uses Stratos’s flight phase detector, which has its own debounced 5-second rolling window, as a final safety net. If something genuinely catastrophic happens (you opened the world map across the touchdown moment, the sim was paused mid-flare, etc.), this layer guarantees we still capture the landing.
landing_rate: 0 if you actually landed.
3. We fit a curve through your final second and read the slope at touchdown
Once a touchdown is detected, Stratos uses the gear-height samples from the last second to compute the descent rate. We fit two mathematical models to the data in parallel:- A straight line (linear regression): the best fit for a steady descent profile.
- A curve (quadratic regression): captures changing descent rates, like an active flare.
- Statistical: is the curve a meaningfully better fit than the straight line? Specifically, the increase in R² (variance explained) must exceed an F-test-style threshold that adapts to how clean the data is. The cleaner the linear fit, the more “explanatory power” the quadratic has to add to win, so a quadratic only takes over when it’s measurably doing more than fitting noise.
- Practical: does the curve imply more than 50 fpm of change across the window? Below that, even a real curve is too small to change the reported rate.
Why a quadratic specifically? And why a 1-second window?
Why a quadratic specifically? And why a 1-second window?
A quadratic is the simplest curve that can express a changing descent rate (constant acceleration). Cubic and higher fits add degrees of freedom that would readily fit random noise as if it were technique, so we cap the model order there.The 1-second window is a deliberate trade-off: long enough to cover a real flare (typically 0.3-0.8 s of active deceleration), short enough to exclude the stable descent before flare initiation, which would otherwise pull the linear fit toward an unrepresentative average.
What this means for pilots
A few worked examples to make this concrete.A typical commercial landing with a proper flare
Imagine you’re flying a 737 on a stabilised approach at -700 fpm. You begin your flare at about 30 ft, easing the descent rate down to -150 fpm at touchdown.| Tracker method | Reports | What it’s actually measuring |
|---|---|---|
| Sim’s “touchdown VS” variable | Whatever the simulator latched (often wildly off) | A single simvar that may not have updated correctly |
| Single-frame VS capture | ~-200 to -300 fpm | Whatever VS happened to be on the frame the wheels touched |
| Last-1-second average | ~-425 fpm | The average descent rate across your flare |
| Stratos | -150 fpm | The descent rate at the exact moment of touchdown |
A “kiss” landing where you floated it on
You flew the approach correctly but lingered in the flare, gradually settling onto the runway at almost zero descent rate.| Tracker method | Reports |
|---|---|
| Single-frame VS | ~-30 to -50 fpm |
| Last-1-second average | ~-150 fpm |
| Stratos | -1 to -10 fpm |
A slammed landing with no flare
You flew the glideslope all the way to the asphalt with no roundout.| Tracker method | Reports |
|---|---|
| Any method | ~-700 fpm |
A late or minimal flare: when Stratos reports worse than another tracker
The examples above all had Stratos report a kinder number than the averaging and single-frame methods. That isn’t a bias in our favour. It’s a consequence of measuring the touchdown moment honestly, and it cuts both ways. Imagine you carry a shallow float over the threshold at about -150 fpm, then run out of energy and let the aircraft settle in the last fraction of a second, with the descent rate building to -400 fpm just as the gear compresses. You flared, but late, and the rate was increasing rather than bleeding off at the moment of contact.| Tracker method | Reports | What it’s measuring |
|---|---|---|
| Sim VS / single-frame capture | ~-200 fpm | An instantaneous VS sample latched a fraction before the gear fully compressed — it misses the late settle |
| Last-1-second average | ~-250 fpm | Diluted by the gentle float that preceded the drop |
| Stratos | -400 fpm | The rate the gear was actually closing at, at the instant of contact |
touchdownNormalVelocity) for every sample in the final second. The per-frame value will usually line up with what the other tracker reported (confirming nothing is malfunctioning), while the curve fitted through the gear-height trajectory shows the steeper rate the airframe genuinely absorbed.
On uphill runways
Most airports have at least slightly sloped runways. Some (Madeira, Toncontín, Lukla, San Diego runway 27, and plenty of others) have noticeable gradients. On an uphill landing, your aircraft is pitched up to match the rising runway. Your altitude above sea level may not be decreasing during the flare even though your gear is closing on the asphalt at -150 fpm. Trackers that read vertical speed (in any of its forms) can report a positive number on uphill landings, sometimes labelling it “the simulator says you climbed onto the runway”. You didn’t climb. The runway rose to meet you. Stratos measures gear-to-ground distance, not altitude. Your gear is closing on the runway surface regardless of what the runway’s altitude is doing, so Stratos reports the rate the wheels physically experienced, on flat and sloped runways alike. This is one of the primary reasons our numbers can differ from other trackers, and it’s the case where the gear-distance method most cleanly matches physical reality.For VA administrators and staff
If you’re explaining landing rates to a pilot, an auditor, or a new staff member, here are the talking points that are true without being technical.What the number actually means
Stratos measures how fast your gear was closing on the runway in the final second of your flight, with the actual touchdown moment weighted more heavily than the moments before it. So a pilot who flares well, bleeding off descent rate just before touchdown, gets credit for that work. A pilot who lets the rate stay high all the way to impact gets the worse number they earned.
Why your numbers can differ from other trackers
Most trackers either read a single value from the simulator (which is often wrong) or average the descent rate across the last second (which doesn’t reward the flare). Stratos fits a curve through the gear-distance data and reads the rate at the exact touchdown moment. On uphill runways especially, this gives a different number to other trackers, and the Stratos number is the one that matches what the wheels physically felt.
Why -1 fpm isn’t necessarily a great landing
A landing at essentially zero descent rate usually means the aircraft floated past the touchdown zone before settling. A firm, positive touchdown of around -100 to -150 fpm is the practical target: firm enough for proper spoiler deployment and weight transfer to the gear, soft enough to be smooth. Below about -60 fpm you’re typically into “float” territory, which is technically poor airmanship even if it feels gentle.
The landing analyser plugin’s scoring system reflects this: peak scores are awarded in the “smooth target” band, with both “too soft” and “too hard” landings receiving lower scores. The measurement of the rate is honest; the grade applied to it is the right shape.
When a pilot disputes a landing rate
Every Stratos landing produces a frame-by-frame replay in the landing analyser plugin. The pilot can step through every sample we captured during the final second (gear height, vertical speed, pitch, bank, position) and see exactly how we arrived at the reported rate. The replay also shows which mathematical method we used (linear or quadratic regression) and a fit quality score. If something looks off, that’s where to start.
Reference: grading bands and the real-world hard-landing line
Stratos’s measurement is honest; the scoring you choose to apply to it is your VA’s call. It’s worth being precise about which part of this is genuinely “real-world” and which part is a sim convention, because the distinction is widely misunderstood. In real airline operations the authoritative measure of touchdown severity is peak vertical g-force, recorded by accelerometers and triggered automatically by the Flight Data Monitoring (FDM/FOQA) system. Boeing defines a hard landing on the main gear as a peak vertical acceleration above roughly 1.7 G (an incremental 0.7 G); Airbus A320 programmes flag escalating severity at about 1.5 / 1.6 / 1.75 G. The conventional hard-landing threshold is expressed as either ~2.6 G or a touchdown descent rate above ~600 fpm, and where the accelerometer reads unreliably, maintenance derives the touchdown g from the recorded rate of descent. So descent rate is genuinely monitored in real operations, and ~600 fpm is a real hard-landing line, not a sim invention. Notably, real-world practice derives severity from the rate of descent over time (exactly what Stratos does) rather than from a single instantaneous vertical-speed reading. What is not a real-world standard is the finer gradation below that threshold: the notion that -110 fpm is a “greaser” while -180 fpm is merely “smooth-firm”. Real airlines don’t grade every routine landing on a scale; they watch for the hard-landing exceedance and otherwise treat anything comfortably within limits as a non-event. The bands below are the landing-analyser / VA grading convention, a useful way to give pilots feedback and VAs something to score, anchored at the bottom to the one threshold that is real:| Rate (fpm) | Band (VA / landing-analyser convention) | Notes |
|---|---|---|
| 0 to -60 | Float / scrape | Past the touchdown zone, no firm contact — poor airmanship |
| -60 to -120 | Greaser / kiss | Smooth, especially in light/medium aircraft |
| -120 to -180 | Smooth (target) | Ideal for heavies |
| -180 to -240 | Smooth-firm | Very good |
| -240 to -360 | Firm | Acceptable — passenger-noticeable |
| -360 to -600 | Hard | Approaching the real-world limit |
| Below -600 | Hard-landing exceedance | The real-world threshold — reportable, triggers a maintenance check IRL |
What Stratos doesn’t do
A few clarifications worth being explicit about, because they come up often:- We don’t average the last second’s VS readings. Linear regression on clean data and endpoint averaging produce the same number, but our regression-based approach is robust to single-sample noise that averaging amplifies.
- We don’t use the simulator’s
touchdownNormalVelocityvariable. It’s exposed in the per-frame data only for plugin display purposes; it plays no role in our calculation. - We don’t infer flares from noise. Random noise in steady-descent data won’t be reported as a flare; the statistical guard rejects it.
- We don’t return zero on a missed detection. The three-layer fallback guarantees a meaningful rate as long as the aircraft actually landed.
Frequently asked questions
My landing in another tracker showed -150 fpm. Stratos says -10 fpm. Which is right?
My landing in another tracker showed -150 fpm. Stratos says -10 fpm. Which is right?
Both could be right, depending on what they mean. The other tracker is likely reporting the average descent rate across your last second of flight. Stratos is reporting the descent rate at the exact moment your wheels touched. If you flared smoothly and floated it on, the average will always be higher (worse-looking) than the touchdown-moment rate. Stratos’s number is more representative of what the airframe actually experienced.
My flight on an uphill runway showed +50 fpm in another tracker, but Stratos shows -200 fpm. How is that possible?
My flight on an uphill runway showed +50 fpm in another tracker, but Stratos shows -200 fpm. How is that possible?
On a sloped runway, your altitude (above sea level) and your gear’s distance
to the runway surface are different things. If you’re descending onto a runway
that’s rising under you, your altitude can stay constant or even increase,
but your gear is still closing on the asphalt. Other trackers measure altitude
change and report it as your landing rate. Stratos measures gear-to-runway
distance. On uphill runways the difference can be hundreds of fpm, and the
Stratos number is the one that matches what your wheels felt at touchdown.
What happens if there's a sim stutter at touchdown?
What happens if there's a sim stutter at touchdown?
Stratos’s regression analysis is mathematically robust to single-sample noise:
every sample in the last second contributes to the fit, so a single bad
frame can’t dominate the result. Single-frame VS-capture trackers don’t have
this property, which is why they sometimes report wildly different numbers on
the same flight if the user replays it.
My landing was clearly a kiss but Stratos shows -110 fpm, not -1. Why?
My landing was clearly a kiss but Stratos shows -110 fpm, not -1. Why?
Stratos reports what the wheels actually felt, not what it looked like on the
screen. A heavy aircraft cushioned by ground effect can feel like it’s gently
settling at zero rate, but the gear is still closing on the runway at
meaningful speed because the airframe inertia is significant. The -110 fpm
number is honest physics. (Also, -110 is in the “ideal smooth landing” band, which is a great landing, not a meh one.)
Can I see the raw data Stratos used for my landing?
Can I see the raw data Stratos used for my landing?
Yes. The landing analyser plugin includes a frame-by-frame replay of every
landing, with all the gear-height, vertical-speed, pitch, bank, and position
data we captured. You can step through it, see the regression fit, and verify
the reported rate yourself. Nothing is hidden in a black box.
Does Stratos work the same for all simulators?
Does Stratos work the same for all simulators?
Yes. The detection and rate-calculation logic is simulator-agnostic: it operates on per-frame data that both SimConnect (MSFS, FSX, P3D) and X-Plane provide. The only minor difference is that SimConnect coerces a small “low-and-slow → on ground” rule into its on-ground reading, which can help detect touchdowns on slow taxi-speed landings (helicopters, tail-draggers). For standard fixed-wing landings at normal airliner speeds, both simulators perform identically.
Further reading
The techniques Stratos uses are the same ones real-world airline safety programs use to analyse landing data:- ICAO Doc 10000 — Manual on Flight Data Analysis Programmes — industry standard for FDA techniques.
- FAA AC 120-82 — Flight Operational Quality Assurance — the regulatory basis for the techniques.
- Boeing AERO Magazine Q3 2007 — FOQA Programs — overview of how Quick Access Recorder data is analysed for landing rates on production aircraft.