AeroACARS v0.16.24

v0.16.24 — Präzise Landebahn-Erkennung auch beim Ausweichen (Divert)

🇩🇪 Deutsch

Neu

• Landebahn-Erkennung bei einem Divert nutzt jetzt die echten
  Navigraph-Daten des TATSÄCHLICHEN Landeflughafens. Bisher korrelierte
  AeroACARS die Landebahn immer gegen die Navdata des GEPLANTEN Ziels.
  Weichst du aus (z. B. WMKK geplant, gelandet in WMKA), lag das geplante
  Feld ~250 nm vom Touchdown entfernt — der Navigraph-Lookup verfehlte und
  AeroACARS fiel auf die grobe eingebaute OurAirports-CSV zurück. Folge:
  jeder Divert verlor die präzise Bahn-Geometrie (LDA, versetzte Schwelle,
  TCH, Gleitwinkel) und damit die Rollout-/Bahnauslastungs-Bewertung.
  Ab jetzt bestimmt AeroACARS aus der Touchdown-Koordinate den
  TATSÄCHLICHEN Landeflughafen und schlägt dessen Navdata nach — der
  Divert bekommt dieselbe Jeppesen-genaue Geometrie wie ein planmäßiger
  Anflug.

• Vorab-Laden der Divert-Navdata schon im Anflug. Erkennt AeroACARS
  während eines sinkenden, stabilen Anflugs, dass der nächste Flughafen vom
  geplanten Ziel abweicht, lädt es die Navigraph-Daten dieses Feldes
  vorausschauend — damit der Cache zum Touchdown bereits warm ist. Das
  feuert nur bei echter Abweichung, ist pro Flughafen idempotent und
  entprellt (10 s stabil), damit ein bloß überflogenes Feld keinen Abruf
  auslöst.

• Bestmögliche Daten beim PIREP-Filing — auf BEIDEN Oberflächen. Falls
  der Cache zum Touchdown noch nicht warm war (später Divert), stempelt
  AeroACARS zunächst das provisorische OurAirports-Ergebnis, stößt aber
  sofort einen gezielten Navdata-Abruf für den echten Landeflughafen an.
  Beim Filing (Minuten später) wird die Korrelation gegen den dann warmen
  Cache erneut ausgeführt und das bessere Ergebnis verwendet — und zwar
  BEVOR sowohl der phpVMS-PIREP-Score (score + Custom-Feld „Landing
  Score") als auch der lokale Landungs-Datensatz gebaut werden. Damit
  bekommt der autoritative, bewertete PIREP-Datensatz dieselbe
  Navigraph-LDA-/Rollout-Bewertung wie der lokale Datensatz; beide
  Oberflächen sind konsistent. Ist der Abruf nicht fertig, bleibt das
  OurAirports-Ergebnis erhalten — nie schlechter als heute, byte-identisch.

• Diagnose beim Fallback. Greift doch der OurAirports-Fallback, steht
  jetzt im Log/GlitchTip-Breadcrumb der tatsächliche Lande-ICAO, ob die
  Navdata im Cache lag (Cache-Miss vs. vorhanden-aber-zu-weit) und der
  AIRAC-Cycle — ein künftiger Fallback ist damit sofort diagnostizierbar.

QS-Härtung (Nachschärfung)

• Der bewertete phpVMS-PIREP-Score nutzt beim Divert wirklich die Geometrie
  des TATSÄCHLICHEN Landeflughafens — konsistent mit Datensatz und Payload.
  Der native score und das Custom-Feld „Landing Score" prüften die
  Bahn-Geometrie bisher gegen das GEPLANTE Ziel. Bei einem Divert, bei dem das
  Flugzeug > 2 nm von der Schwelle parkt, schlug diese Vertrauensprüfung fehl
  und der Rollout-/LDA-Sub-Score wurde übersprungen — obwohl der lokale
  Landungs-Datensatz und das MQTT-Payload (die den pilot-bestätigten
  Ausweich-Flughafen nutzen) ihn bekamen. Jetzt übergeben alle drei Oberflächen
  denselben effektiven Ankunftsflughafen; der autoritative PIREP-Score stimmt
  mit dem Datensatz überein. Planmäßige Landungen sind unverändert
  (byte-identisch).

• Ein Divert übersteht jetzt einen App-Neustart zwischen Touchdown und
  Filing. Die Runway-Korrelations-Felder (Quelle, AIRAC-Cycle, NavRunway-
  Geometrie, tatsächlicher Lande-ICAO, Fallback-Flag) werden persistiert. Wird
  die App nach dem Aufsetzen, aber vor dem manuellen PIREP-Filing neu gestartet,
  bleiben die Finalize-/Nachlade-Tore intakt und der Divert bekommt beim Filing
  weiterhin die Navigraph-Geometrie. Alte gespeicherte Flüge (vor dieser
  Änderung) laden weiter sauber (fehlende Felder → Standardwerte) — nie
  schlechter als bisher.

Warum das sicher ist

• Planmäßige Landungen bleiben byte-identisch. Bei einem Nicht-Divert
  IST der nächste Flughafen zum Touchdown das geplante Ziel — die Funktion
  liefert dann exakt denselben Cache-Lookup, dieselbe Bahn, dieselbe
  Quelle (navigraph), dieselbe Geometrie und dieselben Score-Eingaben wie
  bisher. Ein Test vergleicht die neue Korrelation Feld für Feld gegen den
  alten, auf arr_airport geschlüsselten Pfad und beweist die
  Gleichheit. Die Replay-Goldens (touchdown_v2 / phase_fsm / phase_v2)
  bleiben für alle Nicht-Divert-Fixtures byte-identisch.

• Der Score-Effekt bei Diverts ist GEWOLLT. Diverts bekommen jetzt die
  Navigraph-LDA-Geometrie, also rechnet der Rollout-/Bahnauslastungs-
  Sub-Score genau dort, wo er vorher übersprungen wurde. Diese Änderung der
  bewerteten Felder entsteht AUSSCHLIESSLICH, weil bessere Bahndaten
  vorliegen — nicht durch eine Logik-Änderung am Score selbst.

• Geschlossene/fehlende Zielflughäfen verwirren die Schlüssel-Logik
  nicht. Ist der geplante Flughafen gar nicht in OurAirports (eine
  geschlossene Buschpiste fällt aus der geparsten Bahntabelle), während ein
  ANDERER offener Flughafen in Reichweite liegt, schlüsselt der Cache nicht
  fälschlich auf das Nachbarfeld: weil das geplante Feld in OurAirports
  unauffindbar ist, bleibt die Cache-Schlüssel-Logik am Plan-ICAO verankert.
  Echte Diverts (geplantes Feld ist auffindbar, nur weit weg) lösen
  weiterhin korrekt auf das tatsächliche Landefeld auf.

• OurAirports bleibt der letzte Fallback. Ist keine Navdata verfügbar,
  ist das Verhalten identisch zu heute.

• Beide Korrelations-Pfade (50-Hz-Sampler-Pfad für Busch-/VFR-Hops und
  der FSM-Landing-Pfad) gehen durch dieselbe Logik — keine Inkonsistenz.

• Kein Server-/Bridge-Code geändert. Die serverseitige Korrelation
  (mqttSubscriber) ist separat und unverändert.

---

🇬🇧 English

New

• Divert runway detection now uses the real Navigraph navdata of the
  ACTUAL landing airport. Until now AeroACARS always correlated the
  landing runway against the navdata of the PLANNED destination. On a
  divert (e.g. WMKK planned, landed at WMKA) the planned field was ~250 nm
  from the touchdown — the Navigraph lookup missed and AeroACARS fell back
  to the coarse bundled OurAirports CSV. The result: every divert lost the
  precise runway geometry (LDA, displaced threshold, TCH, glide-path angle)
  and with it the rollout / runway-utilization score. Now AeroACARS derives
  the ACTUAL landing airport from the touchdown coordinate and looks up
  THAT field's navdata — a divert gets the same Jeppesen-accurate geometry
  as an on-plan approach.

• Approach-phase pre-fetch of the divert airport's navdata. When
  AeroACARS detects, during a stable descending approach, that the nearest
  airport has diverged from the planned destination, it pre-fetches that
  field's Navigraph data so the cache is warm at touchdown. This fires only
  on a genuine divergence, is idempotent per airport, and is debounced
  (stable for 10 s) so a merely overflown field never triggers a fetch.

• Finalize-with-best at PIREP filing — on BOTH surfaces. If the cache
  wasn't warm at touchdown (a late divert), AeroACARS stamps the provisional
  OurAirports result first but immediately kicks off a targeted navdata fetch
  for the real landing airport. At filing time (minutes later) the
  correlation re-runs against the now-warm cache and uses the better result —
  and it does so BEFORE both the phpVMS PIREP score (native score + the
  "Landing Score" custom field) and the local landing record are built. So
  the authoritative, scored PIREP record gets the same Navigraph LDA /
  rollout upgrade as the local record; the two surfaces stay consistent. If
  the fetch hasn't completed, the OurAirports result is kept — never worse
  than today, byte-identical.

• Diagnostics on the fallback. When the OurAirports fallback is used,
  the log / GlitchTip breadcrumb now carries the actual landing ICAO,
  whether the navdata was cached (cache-miss vs. present-but-too-far) and
  the AIRAC cycle — so a future fallback is diagnosable at a glance.

QS hardening (follow-up)

• The scored phpVMS PIREP score on a divert now really uses the ACTUAL
  landing airport's geometry — consistent with the record and the payload.
  The native score and the "Landing Score" custom field used to check the
  runway geometry against the PLANNED destination. On a divert where the
  aircraft parks > 2 nm from the threshold that trust check failed and the
  rollout/LDA sub-score was skipped — even though the local landing record and
  the MQTT payload (which use the pilot-confirmed divert airport) got it. Now
  all three surfaces pass the same effective arrival airport; the authoritative
  PIREP score agrees with the record. On-plan landings are unchanged
  (byte-identical).

• A divert now survives an app restart between touchdown and filing. The
  runway-correlation fields (source, AIRAC cycle, NavRunway geometry, actual
  landing ICAO, fallback flag) are persisted. If the app restarts after
  touchdown but before the manual PIREP filing, the finalize / on-demand-fetch
  gates stay intact and the divert still gets the Navigraph geometry at filing.
  Old persisted flights (saved before this change) still load cleanly (missing
  fields → defaults) — never worse than today.

Why this is safe

• On-plan landings stay byte-identical. For a non-divert the nearest
  airport to the touchdown IS the planned destination — the function then
  returns the exact same cache lookup, runway, source (navigraph),
  geometry and score inputs as before. A test compares the new correlation
  field-by-field against the old arr_airport-keyed path and proves
  equality. The replay goldens (touchdown_v2 / phase_fsm / phase_v2) stay
  byte-identical for all non-divert fixtures.

• The score change on diverts is INTENDED. Diverts now get the
  Navigraph LDA geometry, so the rollout / runway-utilization sub-score
  computes exactly where it used to be skipped. That change to scored
  fields happens ONLY beca...

AeroACARS v0.16.23

v0.16.23 — Geplante Flugplan-Route auf der Karte korrigierbar (Route-Sync)

🇩🇪 Deutsch

Neu

• „Route synchronisieren" im Cockpit — in jeder Flugphase. Korrigierst
  du deine Route in SimBrief (z. B. nach einem ATC-Reroute), lebt die
  korrigierte Strecke nur im NEUESTEN SimBrief-OFP — phpVMS/VPS und damit
  auch die In-App-Karte hielten bisher die alte. Der neue Button im
  aktiven Flug zieht den aktuellen SimBrief-OFP und übernimmt nur die
  Strecke (Routen-String, Navlog-Wegpunkte, ggf. Alternate). Die Karte
  zeigt sofort die korrigierte Route, und die Route wird an phpVMS gepostet
  (idempotenter Ersatz der bestehenden Route-Zeilen), damit Live-Map und
  PIREP-Detail die richtige geplante Strecke neben der geflogenen zeigen.

Warum das sicher ist

• Es wird KEIN Score-Feld angefasst. Die OFP-Treue- und
  Landungs-Bewertung liest ausschließlich Sprit-/Gewichts-Felder (Block,
  Trip, Reserve, ZFW, TOW, LDW und die MAX-Werte) — niemals die Route. Der
  Route-Sync schreibt deshalb ausschließlich planned_route,
  planned_waypoints und (falls vorhanden) den Alternate. Block-Fuel,
  TOW, LDW, ZFW, die MAX-Werte, die OFP-Kennung und die Plan-Quelle bleiben
  byte-identisch. Ein Unit-Test vergleicht den vollen Zustand vor/nach dem
  Sync und lässt nur die Routen-Felder wandern.
• Deshalb in jeder Phase erlaubt. Der bestehende OFP-Refresh (der die
  Sprit-/Gewichts-Werte aktualisiert) bleibt bewusst auf Preflight bis
  TaxiOut beschränkt, um die Loadsheet-/Score-Basis nach dem Takeoff nicht
  zu verschieben. Die Route ist kein Score-Feld — sie zu korrigieren ist
  immer unbedenklich.
• Schutz gegen falsche Routen bleibt. Der Sync holt den OFP nur über
  den direkten SimBrief-Pfad und prüft Start/Ziel: passt der neueste OFP zu
  einem ANDEREN Flug (anderer Start/Ziel), wird hart abgebrochen — eine
  fremde Route kann nie auf deine Karte geraten. Einen stale-Fallback gibt
  es bewusst nicht.

Bequemlichkeit

• SimBrief-Username automatisch aus dem phpVMS-Profil. Hast du in den
  AeroACARS-Einstellungen noch keinen SimBrief-Identifier hinterlegt, holt
  sich AeroACARS deinen SimBrief-Username aus deinem phpVMS-Profil (sofern
  dort gepflegt). Ein selbst eingetragener Identifier wird dabei NIE
  überschrieben — manuelle Einstellungen gewinnen immer. Fehlt beides,
  weist dich der Route-Sync mit einem klaren Hinweis darauf hin, den
  SimBrief-Username in den Einstellungen zu setzen.

Companion-Änderungen (separate Deployments)

Dieses Release ist die Client-Seite. Zwei begleitende Server-Änderungen
werden getrennt ausgerollt und sind nicht Teil dieses App-Updates:

• VPS-Recorder: ein erneutes Laden der geplanten Route auf dem
  aeroacars-live-Recorder, damit die externe Live-Map dieselbe korrigierte
  Strecke übernimmt.
• phpVMS /api/user: das Feld simbrief_username über das
  Profil-Endpoint ausliefern, damit das oben beschriebene Auto-Sourcing
  greift. Ohne diese Änderung funktioniert der Route-Sync weiterhin — der
  Pilot trägt seinen SimBrief-Username dann einfach selbst in den
  Einstellungen ein.

---

🇬🇧 English

New

• "Sync route" in the cockpit — available in every flight phase. When
  you fix your route in SimBrief (e.g. after an ATC reroute), the corrected
  track lives only in your LATEST SimBrief OFP — phpVMS/VPS, and therefore
  the in-app map, kept the stale one. The new button on the active flight
  pulls the latest SimBrief OFP and applies only the route (route
  string, navlog waypoints, and the alternate if present). The map
  immediately shows the corrected route, and the route is posted to phpVMS
  (an idempotent replace of the existing route rows) so the live map and
  PIREP detail draw the right planned track alongside the flown one.

Why this is safe

• No scored field is touched. OFP-fidelity and landing scoring read
  fuel/weight fields only (block, trip, reserve, ZFW, TOW, LDW and the MAX
  values) — never the route. The route sync therefore writes only
  planned_route, planned_waypoints and (if present) the alternate.
  Block fuel, TOW, LDW, ZFW, the MAX values, the OFP id and the plan source
  stay byte-identical. A unit test snapshots the full state before/after
  the sync and lets only the route fields move.
• That's why it's allowed in any phase. The existing OFP refresh (which
  updates the fuel/weight values) deliberately stays Preflight–TaxiOut so
  it can't shift the loadsheet/score baseline after takeoff. The route is
  not a scored field — correcting it is always safe.
• Wrong-route protection stays. The sync fetches the OFP via the direct
  SimBrief path only and verifies origin/destination: if your latest OFP is
  for a DIFFERENT flight (different origin/destination), it hard-aborts — a
  foreign route can never land on your map. There is deliberately no
  stale fallback.

Convenience

• SimBrief username auto-sourced from your phpVMS profile. If you
  haven't set a SimBrief identifier in AeroACARS settings yet, AeroACARS
  picks up your SimBrief username from your phpVMS profile (when present).
  An identifier you set yourself is NEVER overwritten — manual settings
  always win. If neither is available, the route sync tells you clearly to
  set your SimBrief username in Settings.

Companion changes (separate deploys)

This release is the client side. Two companion server changes ship
separately and are not part of this app update:

• VPS recorder: a re-fetch of the planned route on the aeroacars-live
  recorder so the external live map adopts the same corrected track.
• phpVMS /api/user: exposing simbrief_username through the profile
  endpoint so the auto-sourcing above can kick in. Without it the route
  sync still works — the pilot simply enters their SimBrief username in
  Settings themselves.

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, s...

AeroACARS v0.16.21

v0.16.21 — MSFS-Landerate bei Flare korrigiert (g-Kraft-validiert)

🇩🇪 Deutsch

Bugfix

• MSFS-Sinkrate beim Aufsetzen wird nicht mehr überschätzt. Der MSFS-
  Vertical-Speed-Wert hinkt beim Abfangen (Flare) dem tatsächlichen
  Flugzustand hinterher und las dadurch auf weich aufgesetzten Landungen
  eine zu hohe Sinkrate. Beispiel: eine Landung wurde mit -441 fpm
  bewertet, obwohl der echte Wert aus der geometrischen Höhen-Ableitung
  bei ~-251 fpm lag (die gemessene g-Kraft von 1,25 passt eindeutig zu
  -251, nicht zu -441). Wir korrigieren das jetzt auf den höhenbasierten,
  un-verzögerten Wert.
• g-Kraft-validiert — echte harte Landungen bleiben unverändert. Die
  Korrektur greift NUR, wenn die gemessene Aufsetz-g-Kraft (lag-frei) zu
  niedrig ist, um die hohe Sinkrate zu rechtfertigen. Eine echte feste
  oder harte Landung zeigt immer eine entsprechend hohe g-Kraft — diese
  Fälle werden nicht „weichgespült". Kalibriert an 278 realen MSFS-
  Landungen.
• Nur MSFS. X-Plane nutzt bereits die rohe local_vy-Sinkrate und
  bleibt vollständig unverändert. Helikopter und Wasserflugzeuge sind
  ausgenommen. Die Unfall-/Crash-Erkennung (≥ 1000 fpm) wird strukturell
  nie angetastet.
• Der Landungs-Klassenname (z. B. „Acceptable" statt „Firm") und der
  numerische Score stimmen jetzt nach der Korrektur überein.

Aufräumen

• FSLabs spoilers_armed korrigiert. Der v0.16.20-Versuch, den
  Armed-Zustand aus dem Speedbrake-Hebel (VC_PED_SPD_BRK_LEVER)
  abzuleiten, fing fälschlich die neutrale Hebelstellung und meldete den
  ganzen Flug „Spoiler armed". Kosmetisch (kein Einfluss auf Phase oder
  Score), aber falsch — FSLabs nutzt jetzt wieder die Standard-SimVar.

Hinweis

Reines Client-Update — aktualisiert sich automatisch. Score-Algorithmus-
Version 4. X-Plane und echte harte Landungen bleiben unverändert.

---

🇬🇧 English

Bugfix

• MSFS touchdown sink rate is no longer over-read. The MSFS vertical-
  speed value lags the airframe through the flare, so on softly-flared
  landings it read a steeper sink rate than really happened. Example: a
  landing scored at -441 fpm when the true rate from the geometric
  altitude derivative was ~-251 fpm (the measured 1.25 g clearly matches
  -251, not -441). We now correct this to the altitude-based, un-lagged
  value.
• g-force validated — genuine hard landings are unchanged. The
  correction fires ONLY when the measured (lag-free) impact g-force is too
  low to justify the high sink rate. A real firm or hard landing always
  shows a correspondingly high g-force, so those cases are never softened.
  Calibrated against 278 real MSFS landings.
• MSFS only. X-Plane already uses the raw local_vy sink rate and is
  fully unchanged. Helicopters and seaplanes are excluded. The
  accident/crash band (≥ 1000 fpm) is structurally never touched.
• The landing class label (e.g. "Acceptable" instead of "Firm") and the
  numeric score now agree after the correction.

Cleanup

• FSLabs spoilers_armed fixed. The v0.16.20 attempt to derive the
  armed state from the speedbrake lever (VC_PED_SPD_BRK_LEVER) wrongly
  caught the neutral lever position and reported "spoilers armed" for the
  whole flight. Cosmetic (no phase or scoring impact), but wrong — FSLabs
  now falls back to the standard SimVar.

Note

Pure client update — auto-updates. Score algorithm version 4. X-Plane
and genuine hard landings are unchanged.

AeroACARS v0.16.20

v0.16.20 — FSLabs A321 wird vollwertiges Premium-Profil

🇩🇪 Deutsch

Neu

• Die FSLabs A321 ist jetzt ein vollwertiges Premium-Profil — wie Fenix
  oder PMDG. Statt der von FSLabs gefälschten Standard-Werte lesen wir die
  echten FSLabs-Variablen aus dem WinWing-/StreamDeck-Forum-Profil:
  Parkbremse, Triebwerks-Master-Schalter, Baro-STD, Master Caution/Warning,
  Triebwerks-Feuer, Speedbrake, Triebwerks-Anti-Ice und der Transponder-Modus.

Bugfix

• Der Flug endet jetzt automatisch. FSLabs fälscht die Standard-SimVars:
  Am Gate mit wirklich ausgeschalteten Triebwerken und gesetzter Parkbremse
  meldete der Simulator dem ACARS fälschlich „Triebwerke laufen" und
  „Parkbremse gelöst" — die automatische Flug-Beendigung (Taxi-In → Blocks
  On → Angekommen) sprang nie an, und der Flug musste von Hand abgegeben
  werden. Jetzt werten wir die echten Schalter aus: Parkbremse gesetzt +
  Triebwerks-Master aus = Ankunft erkannt.
• Behebt außerdem einen Schreibweisen-Fehler aus v0.16.14: die Autobrake-
  Lampen wurden nie gelesen (falsche Groß-/Kleinschreibung der Variablen).

Hinweis

Reines Client-Update — aktualisiert sich automatisch. Andere Flugzeuge
bleiben unverändert.

---

🇬🇧 English

New

• The FSLabs A321 is now a full premium profile — like Fenix or PMDG.
  Instead of the standard values that FSLabs fakes, we read the real FSLabs
  variables from the WinWing / StreamDeck forum profile: parking brake,
  engine master switches, baro STD, master caution/warning, engine fire,
  speedbrake, engine anti-ice and the transponder mode.

Bugfix

• Flights now end automatically. FSLabs fakes the standard SimVars: at
  the gate with engines genuinely off and the parking brake set, the
  simulator wrongly reported "engines running" and "parking brake released"
  to ACARS — so the automatic flight-end sequence (Taxi-In → Blocks On →
  Arrived) never fired, and the flight had to be filed manually. We now read
  the real switches: parking brake set + engine masters off = arrival
  detected.
• Also fixes a casing typo from v0.16.14: the autobrake lights were never
  read (the variable names had the wrong upper/lower case).

Note

Pure client update — auto-updates. Other aircraft are unchanged.

AeroACARS v0.16.19

v0.16.19 — Aircraft-Aliase greifen ohne Neustart

🇩🇪 Deutsch

Bugfix

• Neu im VA-Admin angelegte Flugzeug-Typ-Aliase greifen jetzt automatisch
  — auch auf dem Auto-Start-Pfad und ohne ACARS-Neustart. Bisher lud der
  Auto-Start-Wächter die Aliase nur einmal (bei leerem Zwischenspeicher);
  ein danach hinzugefügter Alias wurde erst nach einem Neustart aktiv.
• Jetzt frischt der Client die Alias-Liste regelmäßig auf (alle 5 Minuten);
  Hinzufügen, Ändern und Löschen wirkt ohne Zutun. Der erste Abruf beim
  Start bleibt unverändert schnell.

Hinweis

Reines Client-Update — aktualisiert sich automatisch.

---

🇬🇧 English

Bugfix

• Newly added aircraft-type aliases now take effect automatically — on
  the auto-start path too, without an ACARS restart. Previously the
  auto-start watcher fetched aliases only once (when its cache was empty),
  so an alias added afterwards needed a restart.
• The client now refreshes the alias list periodically (every 5 minutes);
  adds, edits and deletes apply on their own. The initial fetch at startup
  stays as fast as before.

Note

Pure client update — auto-updates.

AeroACARS v0.16.18

v0.16.18 — PIREP kennt jetzt den gebuchten Flug

🇩🇪 Deutsch

Verbesserung (Events & Touren)

• Der Client übermittelt beim Flugstart jetzt die Flug-ID des gebuchten
  Flugs an phpVMS. Damit ist der PIREP sauber mit dem geplanten Flug
  verknüpft — Events und Touren mit festem Flug (z. B. die WM-Specials)
  matchen exakt, nicht nur über die Strecke.
• Gilt für beide Startwege (SimBrief-Briefing und manueller Start mit Bid).
• Bei einer Diversion entfernt phpVMS die Verknüpfung weiterhin bewusst
  selbst (umgeleiteter Flug zählt nicht als der geplante).

Hinweis

Reines Client-Update — aktualisiert sich automatisch.

---

🇬🇧 English

Improvement (events & tours)

• The client now sends the booked flight's ID to phpVMS at flight start,
  linking the PIREP cleanly to the planned flight — events and tours with a
  fixed flight match exactly, not just by route. Applies to both start paths
  (SimBrief briefing and manual start with a bid). On diversion, phpVMS
  still deliberately drops the link itself.

Note

Pure client update — auto-updates.

AeroACARS v0.16.17

v0.16.17 — Hängende Flüge räumen sich jetzt selbst auf

🇩🇪 Deutsch

Bugfix (verwaiste Flüge)

• Hängende Flüge räumen sich jetzt selbst auf — der Flug-Clean-Up
  (Einstellungen → Technik) sieht endlich alle verwaisten Flüge
  (nicht nur die letzten 20), und beim Start eines neuen Flugs räumt
  der Client alte Überbleibsel (> 24 h) automatisch ab. Kein
  Admin-Eingriff mehr nötig.
• Hintergrund: phpVMS liefert die PIREP-Liste paginiert (20 pro Seite,
  neueste zuerst). Der Client las bisher nur Seite 1 — ein hängender
  Flug, der älter als die letzten ~20 Flüge war, war damit für
  Clean-Up-Panel, Resume-Banner und den Kollisions-Check beim Flugstart
  unsichtbar. Jetzt fragt der Client gezielt nur IN-PROGRESS-Flüge ab
  (Server-seitiger Filter) — die Liste ist immer vollständig.
• Frische Überbleibsel (< 24 h) bleiben bewusst liegen: sie gehören dem
  Resume-Banner (Flug fortsetzen) bzw. dem manuellen Clean-Up. Die
  24-h-Grenze schützt außerdem Piloten, die gerade auf einem zweiten
  PC fliegen — ein lebender Parallel-Flug ist immer jünger.
• Jede automatische Aufräumaktion erscheint im Aktivitätsprotokoll
  („Verwaister Flug … automatisch aufgeräumt"); schlägt sie fehl,
  startet der neue Flug trotzdem ganz normal.

Hinweis

Reines Client-Update — aktualisiert sich automatisch.

---

🇬🇧 English

Bugfix (orphaned flights)

• Stuck flights now clean themselves up — the flight clean-up panel
  (Settings → Technical) finally sees all orphaned flights (not just
  the last 20), and when you start a new flight the client automatically
  clears old leftovers (> 24 h). No more admin intervention needed.
• Background: phpVMS returns the PIREP list paginated (20 per page,
  newest first). The client only ever read page 1 — so a stuck flight
  older than your last ~20 flights was invisible to the clean-up panel,
  the resume banner, and the collision check at flight start. The client
  now requests IN-PROGRESS flights specifically (server-side filter) —
  the list is always complete.
• Fresh leftovers (< 24 h) are deliberately left alone: they belong to
  the resume banner (continue flight) or the manual clean-up. The 24 h
  threshold also protects pilots currently flying on a second PC — a
  live concurrent flight always has a fresher start time.
• Every automatic clean-up shows in the activity log ("Orphaned flight …
  cleaned up automatically"); if it fails, the new flight still starts
  normally.

Note

Pure client update — auto-updates.

AeroACARS v0.16.16

v0.16.16 — LAN-Fernbedienung merkt sich den Schalter

🇩🇪 Deutsch

Verbesserung (LAN-Fernbedienung)

• Die LAN-Fernbedienung merkt sich den Schalter — war sie an, startet sie
  nach Neustart/Update automatisch wieder mit; gekoppelte Geräte bleiben
  verbunden (Token bleibt gültig).
• Kann der Server beim Start ausnahmsweise nicht binden (z. B. Port schon
  belegt), startet die App ganz normal — der Hinweis erscheint im
  Aktivitätsprotokoll und der Schalter zeigt „aus".
• Wer die Fernbedienung nie eingeschaltet hat, merkt nichts: Sie bleibt
  wie bisher aus, bis man sie in den Einstellungen aktiviert.

Hinweis

Reines Client-Update — aktualisiert sich automatisch.

---

🇬🇧 English

Improvement (LAN remote control)

• The LAN remote control now remembers its switch — if it was ON, it
  automatically comes back up after a restart or update; paired devices
  stay connected (the token remains valid).
• If the server exceptionally can't bind on launch (e.g. the port is
  already taken), the app starts normally — a note appears in the
  activity log and the switch shows "off".
• If you never switched the remote on, nothing changes: it stays off
  until you enable it in Settings, as before.

Note

Pure client update — auto-updates.

AeroACARS v0.16.15

v0.16.15 — Höhe wie am Höhenmesser

🇩🇪 Deutsch

Verbesserung (Anzeige)

• AeroACARS zeigt jetzt die Altimeter-Höhe — also das, was dein PFD
  anzeigt (z. B. FL360 = 36.000 ft), statt der geometrischen GPS-Höhe.
  Die konnte je nach Wetter um über 1.000 ft abweichen und sah nach
  einem Fehler aus (war keiner — Temperatur-Effekt der Atmosphäre).
• Gilt für die Cockpit-Kachel (GPS-Höhe steht klein daneben, wenn sie
  deutlich abweicht), den Sim-Inspektor, die Live-Map und die
  phpVMS-Karte.
• An Auswertung, Phasen und Scoring ändert sich nichts — intern wurden
  immer schon alle Höhen getrennt erfasst.

Hinweis

Reines Client-Update — aktualisiert sich automatisch.

---

🇬🇧 English

Improvement (display)

• AeroACARS now shows the altimeter altitude — what your PFD shows
  (e.g. FL360 = 36,000 ft) instead of the geometric GPS altitude, which
  could differ by 1,000+ ft depending on weather and looked like a bug
  (it wasn't — atmospheric temperature effect).
• Applies to the cockpit tile (GPS altitude shown small when it differs
  noticeably), the sim inspector, the live map and the phpVMS map.
• Analysis, phases and scoring unchanged — all altitudes were always
  captured separately internally.

Note

Pure client update — auto-updates.