AeroACARS v0.16.22

v0.16.22 — MSFS-Flare-Erkennung bei festen Landungen korrigiert

🇩🇪 Deutsch

Bugfix

• „Kein Flare" wird auf MSFS nicht mehr falsch gemeldet, wenn der Pilot
  abgefangen hat. Die Flare-Erkennung las ihre Sinkraten bisher aus dem
  MSFS-Vertical-Speed-Wert, der beim Abfangen ~0,5–0,7 s hinterherhinkt
  (dieselbe Verzögerung, die v0.16.21 am Aufsetzpunkt korrigiert). Dadurch
  zeigte der Wert kurz vor dem Aufsetzen noch den Sinkflug von ~0,6 s
  zuvor — also VOR dem späten Flare — und die berechnete Reduktion lag
  nahe null. Ergebnis: „kein Flare", obwohl der Pilot tatsächlich gezogen
  hat. Beispiel JBU323 (Fenix A320): verzögert peak −469 / Ende −440 →
  Reduktion 30 fpm → kein Flare; aus der lag-freien Höhen-Geometrie
  derselben Spanne ergibt sich eine echte Reduktion von ~188 fpm (die
  Nase stieg von 2,5° auf 5,2°).
• Flare-Metrik jetzt aus der lag-freien Höhen-Geometrie. Auf MSFS
  (Starrflügler) werden die Flare-Eckwerte aus der agl_ft-Spur über
  einen geglätteten lokalen Linear-Fit (±300 ms) berechnet statt aus dem
  verzögerten Display-Wert. Die Höhe/Position ist nicht der lagbehaftete
  SimVar, deshalb ist die Reduktion die ECHTE geometrische Reduktion.
• Keine erfundenen Flares. Eine feste Landung ohne echtes Abfangen
  zeigt eine flache Höhen-Steigung über das ganze Fenster → Reduktion
  ~0 → weiterhin „kein Flare" (z. B. DLH848: konstant −382 fpm). Die
  Verdikt-Stabilität ist über Fit-Fenster von 250/300/350 ms am realen
  Korpus identisch.
• Aufsetzrate und Klasse bleiben unverändert. JBU323 setzt weiter
  fest mit −423 fpm auf — nur die Flare-Auswertung ändert sich. Wir
  würdigen die Reduktion, machen aber aus einer festen Landung keine
  weiche.
• Nur MSFS. X-Plane nutzt die kaum verzögerte rohe local_vy-
  Sinkrate und bleibt vollständig unverändert (byte-identische Analyse-
  Ausgabe, keine neuen Felder). Helikopter und Wasserflugzeuge sind nicht
  betroffen.

Härtung gegen Phantom-Flares

Drei gestaffelte Schutzgatter verhindern, dass aus defekten Daten ein
„Butter"-Flare wird. Die Schwellen sind an einem 316-Landungen-Korpus von
den echten VPS-Flugprotokollen kalibriert; sie unterdrücken die zwei real
gefundenen Phantome, ohne eine einzige echte Landung (115 echte Flares,
inkl. JBU323) zu verlieren:

• Datenqualität. Friert die agl_ft-Spur ein oder wird sie zu grob,
  ist die Höhen-Geometrie wertlos — der Linear-Fit liest am Fensterende
  eine Steigung ≈ 0 ab und erfindet eine riesige Reduktion. Beobachtet an
  einer E195, deren AGL ~14 Samples lang bei exakt 9,96 ft hängenblieb →
  Reduktion 742, Score 100 auf einer festen −315-fpm-Landung mit der Nase
  nach UNTEN. Gatter: < 8 DISTINKTE AGL-Werte im Fenster (die einzigen
  zwei Flüge unter 8 in 316 sind die Phantome; der niedrigste echte Flare
  hat 18) ODER Median-Δt > 60 ms (< ~16 Hz) ODER ein lokaler Freeze am
  FensterENDE: < 4 distinkte AGL-Werte im Flare-Ende-Fit (fängt eine A320,
  die nur die letzten ~360 ms einfror — 25 distinkte Werte gesamt, vom
  Gesamt-Zähler also verfehlt — und so die Reduktion von ~8 auf ~168 fpm
  aufblähte). Auslösung → Rückfall auf den SimVar-Pfad,
  flare_vs_source = simvar_agl_unreliable.
• Bounce / Ballon. Ein on_ground=true-Sample IM Fenster oder ein
  nicht-monotones Auf-Ballonieren der AGL (> 1,5 ft über ein vorheriges
  Minimum) ist ein Aufsetzen mit Nachfedern, kein Flare. Beobachtet an
  einer DA40, die bei −1626 ms aufsetzte, ~2,4 ft zurückstieg und sich
  setzte; die gutgeschriebene „Reduktion" war das Nachsetzen, die Nase bei
  −6°. Auslösung → Rückfall auf SimVar, keine Erkennung.
• Pitch-Bestätigung. Zusätzlich wird flare_detected nur dann
  zurückgehalten, wenn der Nase-Trend über das Fenster klar nach UNTEN
  zeigt (Settle/Abladen statt Ziehen). Bewusst konservativ: echte
  Halte-Attitude-Flares zeigen auf MSFS auch leicht negative Fenster-
  Pitch-Deltas (der Pilot stellt die Flare-Lage früh ein und HÄLT sie),
  deshalb sind Datenqualität + Bounce die Hauptverteidigung — die
  Pitch-Veto ist Gürtel-und-Hosenträger.

Nachschärfung (Code-Review v0.16.22)

• AGL-Spannweite am Fensterende (Datenqualität-Backstop). Der
  Distinkt-Zähler am Flare-Ende lässt sich von einem VERRAUSCHTEN Freeze
  überlisten: zittert die Spur über ≥ 4 quantisierte 0,01-ft-Eimer, während
  sie real nahezu null Höhe überstreicht, liest der End-Fit trotzdem eine
  Steigung ≈ 0 → riesige falsche Reduktion → Phantom-Score 100. Neu wird
  zusätzlich die AGL-SPANNE im Ende-Fit-Fenster (±300 ms) geprüft: < 0,3 ft
  = flaches Plateau → eingefroren → Rückfall auf SimVar. Begründung: der
  langsamste ECHTE Flare im Korpus (extra_y8Y5, Ende −95 fpm) überstreicht
  in diesen 600 ms ≈ 0,95 ft, JBU323/jbu322 4–6 ft; ein Freeze ~0. 0,3 ft
  liegt eine Größenordnung unter der langsamsten echten Spanne und eine
  Größenordnung über Quantisierung+Jitter (~0,01–0,05 ft).
• Bounce-Kontamination des End-Slopes. Der End-Fit (nächster Punkt zu
  flare_hi = Kante −100 ms) reichte bisher bis Kante +200 ms. Bei einem
  sauberen Aufsetzen-dann-Bounce (erster Bodenkontakt AN der Kante, danach
  ein Ballon mit STEIGENDER AGL) verflachten diese Nach-Kante-Samples die
  End-Steigung → aufgeblähte Reduktion → Phantom; Gatter 2 sah nur den
  Bereich vor der Kante. Behoben: (a) der Endpunkt-Fit überschreitet die
  Aufsetz-Kante nicht mehr (Samples ab edge_ms fließen nicht in die
  Flare-Endpunkte ein), und (b) der Ballon-Scan von Gatter 2 reicht jetzt
  bis zur vollen Fit-Spanne (Kante +200 ms), sodass ein Nach-Kante-Ballon
  das Gatter auslöst. Feste Landungen ohne Bounce (JBU323) sind unberührt,
  da ihre Nach-Kante-Samples on_ground und ohnehin ausgeschlossen sind.

Forensik

• Die roh-verzögerten SimVar-Werte bleiben als Forensik-Felder erhalten
  (peak_vs_pre_flare_fpm_raw, vs_at_flare_end_fpm_raw); flare_vs_ source markiert die Quelle (msfs_agl, simvar bzw. neu
  simvar_agl_unreliable, wenn ein Datenqualitäts-Gatter zurückfiel).
• Konsistente Diagnostik (Code-Review). Der Pilot-Client zeigt jetzt
  die kanonische Backend-Reduktion flare_reduction_fpm direkt an, statt
  sie aus |peak| − |edge| neu zu berechnen (das mischte den AGL-Peak mit
  der de-lagged Kante und konnte dem Backend und flare_detected
  widersprechen) — Sinkrate-Forensik und Landungs-Panel stimmen nun
  überein. Außerdem nutzt flare_dvs_dt_fpm_per_sec dieselben Endpunkte wie
  die veröffentlichte Reduktion (AGL auf dem AGL-Pfad, SimVar im Rückfall),
  sodass die beiden Diagnosen nie mehr im Vorzeichen abweichen (JBU323:
  dVS/dt vorher −12, jetzt +68, im Einklang mit der +188-Reduktion).

Bekannte Folgepunkte (kein Bug, dokumentiert)

• Gatter 3 Pitch-Sub-Fenster überlappen, wenn die Luftspanne < 600 ms
  ist (das Veto kann sich auf sehr kurzen Fenstern selbst entschärfen).
  Gatter 3 ist Gürtel-und-Hosenträger und feuert auf ~0 echten Flügen;
  Gatter 1+2 sind die Hauptverteidigung — geringes Risiko.
• agl_geometric_vs_fpm_at scannt pro Kandidat den vollen ~15-s-
  Touchdown-Puffer (O(Kandidaten × Puffer)). Heute vernachlässigbar
  (einmal pro Landung); auf das Flare-Fenster begrenzen, falls die Puffer je
  wachsen.
• Zwei parallele AGL-Schätzer (der estimate_*_touchdown_vs_from_agl
  der De-Lag-Korrektur und dieser Least-Squares-Helfer) — eine künftige
  vereinheitlichende „lag-freie AGL-V/S"-Naht.

Hinweis

Reines Client-Update — aktualisiert sich automatisch. Die Flare-Anzeige
ist eine private Forensik-/Coaching-Kennzahl und fließt NICHT in den
Master-Score ein — der Landungs-Score bleibt unverändert (Score-
Algorithmus-Version 4). X-Plane und die Aufsetzrate/-Klasse bleiben
unverändert.

---

🇬🇧 English

Bugfix

• MSFS no longer falsely reports "no flare" when the pilot did flare.
  The flare detector read its sink rates from the MSFS vertical-speed
  value, which lags the airframe ~0.5–0.7 s through the flare (the same
  lag v0.16.21 corrects at touchdown). So just before touchdown the value
  still reflected the descent from ~0.6 s earlier — BEFORE the late flare
  took effect — and the computed reduction read near zero: "no flare",
  even though the pilot genuinely pulled. Example JBU323 (Fenix A320):
  lagged peak −469 / end −440 → reduction 30 fpm → no flare; the lag-free
  altitude geometry over the SAME window shows a real reduction of
  ~188 fpm (the nose rose 2.5° → 5.2°).
• Flare metric now from the lag-free altitude geometry. On MSFS
  (fixed-wing) the flare endpoints are computed from the agl_ft trace
  via a smoothed local linear fit (±300 ms) instead of the lagged display
  value. Altitude/position is not the lagged SimVar, so the reduction is
  the REAL geometric reduction.
• No phantom flares. A firm landing with no real flare shows a flat
  altitude slope across the whole window → reduction ~0 → still "no
  flare" (e.g. DLH848: constant −382 fpm). The detection verdict is
  identical at fit windows of 250/300/350 ms on the real corpus.
• Touchdown rate and class are unchanged. JBU323 still touches down
  firm at −423 fpm — only the flare metric changes. We credit the
  reduction without turning a firm landing soft.
• MSFS only. X-Plane uses the barely-lagged raw local_vy sink rate
  and is fully unchanged (byte-identical analysis output, no new fields).
  Helicopters and seaplanes are unaffected.

Hardening against phantom flares

Three layered guards stop broken data from being credited as a "butter"
flare. Their thresholds are calibrated on a 316-landing corpus from the
real VPS flight logs; they suppress the two phantoms QS actually found
without losing a single real landing (115 real flares, incl. JBU323):

• Data quality. If the agl_ft trace freezes or goes too coarse, the
  altitude geometry is worthless — the linear fit reads a slope ≈ 0 at the
  window end and invents a huge reduction. Seen on an E195 whose AGL stuck
  at exactly 9.96 ft for ~14 samples → reduction 742, score 100 on a firm
  −315 fpm landing with NOSE-DOWN pitch. Guard: < 8 DISTINCT AGL values in
  the window (the only two flights under 8 in 316 are the phantoms; the
  lowest real flare has 18) OR median Δt > 60 ms (< ~16 Hz) OR a localized
  freeze at the window END: < 4 distinct AGL values in the flare-end fit
  (catches an A320 that froze only the final ~360 ms — 25 distinct overall,
  so the whole-window count misses it — and thereby inflated the reduction
  from ~8 to ~168 fpm). On trip → fall back to the SimVar path,
  flare_vs_source = simvar_agl_unreliable.
• Bounce / balloon. An on_ground=true sample INSIDE the window, or a
  non-monotone AGL balloon (rising > 1.5 ft above a prior minimum), is a
  touchdown-and-rebound, not a flare. Seen on a DA40 that touched at
  −1626 ms, ballooned ~2.4 ft, and settled; the credited "reduction" was
  the settle, pitch at −6°. On trip → fall back to SimVar, no detection.
• Pitch corroboration. flare_detected is additionally withheld only
  when the net pitch trend across the window is clearly NOSE-DOWN (a
  settle/shed, not a pull). Deliberately conservative: real held-attitude
  flares on MSFS show slightly negative window pitch-deltas too (the pilot
  sets the flare attitude early and HOLDS it), so data-quality + bounce
  are the primary defense — the pitch veto is belt-and-suspenders.

Follow-up hardening (code review, v0.16.22)

• End-window AGL span (data-quality backstop). The flare-end distinct
  count is fooled by a NOISY freeze: a trace that dithers across ≥ 4
  quantized 0.01 ft buckets while spanning near-zero true height still reads
  an end-slope ≈ 0 → a huge fake reduction → phantom score-100. We now also
  check the AGL SPAN across the end-fit window (±300 ms): < 0.3 ft = a flat
  plateau → treat as frozen → fall back to SimVar. Rationale: the slowest
  REAL flare-end in the corpus (extra_y8Y5, end −95 fpm) covers ≈ 0.95 ft in
  that 600 ms window, and JBU323/jbu322 span 4–6 ft; a freeze spans ~0.
  0.3 ft sits an order of magnitude below the slowest real span and an order
  of magnitude above quantization+jitter (~0.01–0.05 ft).
• Bounce contamination of the end slope. The end fit (nearest point to
  flare_hi = edge −100 ms) previously reached edge +200 ms. On a clean
  touchdown-then-bounce (first ground contact AT the edge, then a balloon
  with RISING AGL) those post-edge samples flattened the end slope →
  inflated reduction → phantom; Gate 2 only inspected the pre-edge window.
  Fixed: (a) the endpoint fit no longer crosses the touchdown edge (samples
  at/after edge_ms never enter the flare endpoints), and (b) Gate 2's
  balloon scan now reaches the full fit span (edge +200 ms) so a post-edge
  balloon trips the gate. Firm landings with no bounce (JBU323) are
  unaffected — their post-edge samples are on_ground and already excluded.

Forensics

• The raw lagged SimVar values are preserved as forensic fields
  (peak_vs_pre_flare_fpm_raw, vs_at_flare_end_fpm_raw); flare_vs_ source marks the source (msfs_agl, simvar, or the new
  simvar_agl_unreliable when a data-quality guard fell back).
• Consistent diagnostics (code review). The pilot client now shows the
  canonical backend flare_reduction_fpm directly instead of recomputing it
  from |peak| − |edge| (which mixed the AGL peak with the de-lagged edge
  and could disagree with the backend and with flare_detected) — the
  sink-rate forensics panel and the landing panel now agree. And
  flare_dvs_dt_fpm_per_sec now uses the SAME endpoints as the published
  reduction (AGL on the AGL path, SimVar on fallback), so the two
  diagnostics never disagree in sign (JBU323: dVS/dt was −12, now +68,
  consistent with the +188 reduction).

Known follow-ups (not a bug, documented)

• Gate 3 pitch sub-windows overlap when the airborne span < 600 ms (the
  veto can disarm itself on very short windows). Gate 3 is belt-and-
  suspenders and fires on ~0 real flights; Gates 1+2 are the primary
  defense — low risk.
• agl_geometric_vs_fpm_at rescans the full ~15 s touchdown buffer per
  candidate (O(candidates × buffer)). Negligible today (once per landing);
  bound it to the flare window if buffers ever grow.
• Two parallel AGL estimators (the de-lag's
  estimate_*_touchdown_vs_from_agl and this least-squares helper) — a
  future unifying "lag-free AGL V/S" seam.

Note

Pure client update — auto-updates. The flare readout is a private
forensic/coaching metric and does NOT feed the master score — the
landing score is unchanged (score algorithm version 4). X-Plane and the
touchdown rate/class are unchanged.