Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.skyvexsoftware.com/llms.txt

Use this file to discover all available pages before exploring further.

Landing rates are one of the most-discussed metrics in virtual aviation, and one of the most often misreported in sim trackers. Stratos takes a fundamentally different approach to measuring them. This guide explains what we do, why the numbers you see may differ from what other trackers report, and how to interpret your results.

​
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 or a single bad frame at the wrong moment ruins the number.
  • 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 like PLANE 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.

​
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.
The three layers are independent and idempotent. If your aircraft genuinely touched the runway, at least one of them captures it. Stratos contractually never reports 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) — best fit for a steady descent profile.
  • A curve (quadratic regression) — captures changing descent rates, like an active flare.
gear-AGL (ft)
  ▲
12├ ●
  │  ● ●
 8├      ●  ●         ── linear fit (constant slope ≈ average rate)
  │       ⌣ ●  ●
 4├          ⌣ ●  ●
  │              ⌣ ●  ●
 0├──────────────────⌣── touchdown (quadratic slope ≈ rate at the wheels)
  └────────────────────► time
   T −1.0 s         T = 0
Then we apply two checks:
  • 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.
If both checks pass, Stratos uses the slope of the curve at the exact touchdown moment. This is the rate your wheels actually felt at the instant of impact. Otherwise Stratos uses the linear slope, which is the average descent rate (and honest about that).
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 methodReportsWhat it’s actually measuring
Sim’s “touchdown VS” variableWhatever the simulator latched (often wildly off)A single simvar that may not have updated correctly
Single-frame VS capture~-200 to -300 fpmWhatever VS happened to be on the frame the wheels touched
Last-1-second average~-425 fpmThe average descent rate across your flare
Stratos-150 fpmThe descent rate at the exact moment of touchdown
You felt -150 fpm. Stratos reports -150 fpm. Other trackers report something between -200 and -425.

​
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 methodReports
Single-frame VS~-30 to -50 fpm
Last-1-second average~-150 fpm
Stratos-1 to -10 fpm
Stratos correctly recognises the kiss. Note: a -1 fpm landing isn’t necessarily good — see the VA administrator section below.

​
A slammed landing with no flare

You flew the glideslope all the way to the asphalt with no roundout.
Tracker methodReports
Any method~-700 fpm
When there’s no flare in the data, all methods agree. The math literally cannot invent a flare from data that doesn’t have one.

​
On uphill runways

Most airports have at least slightly sloped runways. Some — Madeira, Toncontín, Lukla, San Diego runway 27, 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. Real airline operating procedures grade an ideal landing at around -100 to -150 fpm — 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: real-world airline grading buckets

Stratos’s measurement is honest; the scoring you choose to apply to it is your VA’s call. For reference, real-world airline ranges (which the landing-analyser plugin’s default scoring approximates) tend to look something like:
Rate (fpm)Industry labelTypical grade implication
0 to -60Float / scrapePoor — usually past touchdown zone, no firm contact
-60 to -120Greaser / kissExcellent — especially in light/medium aircraft
-120 to -180Smooth (target)Peak — ideal for heavies
-180 to -240Smooth-firmVery good
-240 to -360FirmAcceptable — passenger-noticeable
-360 to -600HardPoor — would require maintenance check IRL
Below -600Hard-landing exceedanceReportable in real ops

​
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 touchdownNormalVelocity variable. 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

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.
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.
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.
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 — that’s a great landing, not a meh one.)
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.
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.
Stratos doesn’t invent new science. It applies mature aviation engineering carefully to a sim tracker, where most other tools have settled for a single-variable readout.