FalconJockey Geschrieben 16. September Geschrieben 16. September vor 2 Stunden schrieb cosy: Ich kannte den Piloten persönlich und auf meiner Homebase gibt es praktisch nur Kollegen, die sich überhaupt nicht vorstellen können, dass ihm sowas passieren hätte können. Wenn es einen "besten* Piloten in der Westschweiz gibt-gab- dann ist es er. Wie gesagt: - Zeitverschiebung - Flug durch das WOCL (Window of Circadian Low) - Alter - Dunkelheit - unbekannte Umgebung Das sind alles Faktoren, die in Kombination den besten Piloten aus der Bahn werfen können. Oder warst Du schonmal nach 3 großen Bier im Flieger unterwegs und musstest Informationen auslesen und Entscheidungen treffen? Im WOCL passiert genau das! Darum hat man genau dafür zwei "Besoffene" im Cockpit, damit zumindest noch 20% Hirnkraft übrig sind, in Kombination. 2 Zitieren
Sherlock Newbie Geschrieben 16. September Geschrieben 16. September vor 19 Stunden schrieb FalconJockey: Und was diese Höhen von 3008ft angehen: Es gibt sicher Prozeduren, die ungerade Höhen im Profil haben, aber auch die sind in den allermeisten Fällen auf Zehner genau, also 3810ft oder 3820ft. In diesem Fall führt die Prozedur auf 3000ft über das VOR Könnte es einen Grund geben, warum der Pilot LIO VOR nicht auf exakt 3.000 ft anfliegt sondern auf 3.008 ft., z.B. denjenigen, dass der Pilot einen GPS-Gleitpfad am IAF aus einer leichten Überhöhung aufpicken möchte bzw. vermeiden möchte von unten und zu tief in den GPS-Gleitpfad einzufliegen? Laut timestamps wurden in den 2 Minuten zwischen 23:49:57 Z bis 23:52:02 Z 125 ADS-B Aussendungen erfasst, d.h. etwa 1 pro Sekunde. Hälst Du dennoch die "Sel. Alt.: 3.008 ft" für einen Fehler der ADS-B Daten? vor 1 Stunde schrieb cosy: Was Du meinst, ist vermutlich der Vertrauensintervall oder Konfidenzintervall in der Statistik Viel einfacher, viel simpler: In der von mir betrachteten Flugphase beginnend ab 23:49:07 Z gibt es in den nächsten knapp 3 1/2 Minuten etwas mehr als 200 erfasste ADS-B Aussendungen (laut timestamps). Wenn man jetzt möchte, dass die "-3.008 ft/min" Zufall sind, dann braucht man eine hohe Wahrscheinlichkeit dafür, dass man "-3.008" erwürfelt, weil sonst nicht erklärbar wäre, wie es möglich sein sollte, dass dieser Wert 10 mal in der Reihe wiederkehrt. Diese hohe Wahrscheinlichkeit ist hier gegeben, weil es tatsächlich nur 11 Werte für die geom. Sinkrate gibt (und nur 15 Werte für die baro Sinkrate). Wir würfeln also quasi mit einem Würfel der nur noch 11 Seiten hat. Jetzt müsste man aber als Konsequenz der eigenen Argumentation annehmen, dass die ausgesendeten ADS-B Daten nie zeigen, was Zielwerten des FMS/AP entspricht. Und wir suchen ja wohlgemerkt korrespondierende Werte für baro VS und geom. Sinkrate. Weshalb aber sollte man annehmen, dass die ADS-B Daten nie zeigen, was Zielwerten des FMS/AP entspricht? Und wieso sollte man das annehmen, wenn die Trendberechnung in der Tabellenkalkulation das Ergebnis -2.880 ft/min baro und -3.008 ft/min geom. errechnet? Nochmal der Klarheit wegen: Die Berechnung in der Tabellenkalkulation beruht nicht auf den ausgesendeten ADS-B Daten für die Sinkraten, sondern auf den absoluten Höhenangaben und dem Zeitstempel. vor 2 Stunden schrieb cosy: eine einfache Erklärung dafür wäre ein Aufwind von schlappen +128 ftpm. Ähhh, nein, und zwar deshalb, weil Deine Aufwinde quasi schon berücksichtigt sind. Ich hatte weiter oben die durchschnittliche tatsächliche Sinkrate errechnet, die sich ergibt wenn man einfach nur Beginn und Ende des Sinkfluges betrachtet und dann daraus die tatsächlichen Sinkraten in ft/min errechnet. Da ergibt sich schon eine Abweichung von etwa 100 ft von den hier genannten Zielwerten. Siehe bitte auch die fett markierte Berechnung der durchschnittlichen Sinkraten hier. Dass tatsächliche erflogene Sinkraten und Zielwerte des FMS/AP sich nicht decken, ist also auch bereits berücksichtigt. vor 3 Stunden schrieb cosy: Auf meiner Homebase gibt es praktisch nur Kollegen, die sich überhaupt nicht vorstellen können, dass ihm sowas passieren hätte können. Einmal mehr ein Grund, dass zu tun, was man in einer Fehleranalyse sowieso machen würde: nämlich sparsam mit Annahmen zu Fehlerursachen und insbesondere zu Pilotenfehlern umzugehen. Grüße Stefan P.S. Ich habe gestern die BFU kontaktiert und angefragt, wann mit einem Unfallbericht zu rechnen ist. Die BFU hat den Unfall in ihrem Bulletin aus Oktober 2022 erfasst und sie müsste bei der Flugunfalluntersuchung eines in D registriert Lfzg beteiligt sein. Zitieren
Tomi Geschrieben 16. September Geschrieben 16. September (bearbeitet) Hör doch auf mit den 3008 Füssen. Das ist schlicht nicht einstellbar, messbar und nicht ausschlaggebend für irgendetwas. Tomi P.S. die 3000 Fuss sind barometrisch, der Radiohöhenmesser funktioniert erst unter 2500 Fuss. Bearbeitet 16. September von Tomi Zitieren
Sherlock Newbie Geschrieben 16. September Geschrieben 16. September (bearbeitet) vor 2 Stunden schrieb Tomi: Hör doch auf mit den 3008 Füssen. Das ist schlicht nicht einstellbar. Ich glaube nicht, dass das den Stand der Diskussion und die bis hierhin gewonnenen Erkenntnisse in sachlich angemessener Weise wiedergibt: @FalconJockey hat bestätigt, was ich auch bereits vermutet hatte, dass nämlich eine Verwechselung von ALT und VS durch Eingabe von entweder baro -2.880 ft/min oder geom -3.008 ft/min am Guidance Panel weder wahrscheinlich noch - hinsichtlich dieser Werte - überhaupt möglich ist. Gar nicht explizit gesprochen wurde bisher über die Eingabemöglichkeiten an der CDU/Konsole des Collins ProLine 21. Hast Du belastbare Erkenntnisse dazu, dass dort weder -2.880 ft/min baro noch - 3.008 ft/min geom eingegeben werden können und könntest Du uns diese bitte mitteilen? Ich bin auf diesen Thread zurückgekommen, weil ich die Frage wenigstens hatte stellen wollen, die mich tatsächlich ziemlich früh beschäftigt hatte, nämlich ob auch Fehler in der Flugplanung denkbar sind. Zu den Eingabemöglichkeiten hinsichtlich einer VS von entweder -2.880 ft/min baro oder - 3.008 ft/min geom. in einer digitalen Flugpanungssoftware (und zu der Frage, wie solch eine Eingabe dann effektiv in der Software oder im FMS umgesetzt würde) habe ich hier rein gar nichts gelesen. Es gibt lediglich die knappe Einschätzung: "Die Flugplanung spielt meiner Meinung nach keine oder nur eine sehr untergeordnete Rolle." Ich kann aus dieser Einschätzung, der ich aus eigener besserer Kenntnis nicht entgegentreten könnte, nun aber nicht ableiten, dass es diese Eingabemöglichkeit in einer Flugplanungssoftware nicht gäbe. Hast Du dazu Kenntnisse, die Du uns mitteilen kannst? Explizit hatte ich auch die Möglichkeit angesprochen, dass das vertikale Flugprofil in ganz anderer Weise geometrisch definiert ist, z.B. FPA mit variablem Pitch/Trim, so dass dann nur als Ergebnis einer ganz andere Vorgabe im FMS/AP die Zielwerte -2.880 ft/min baro bzw. - 3.008 ft/min geom quasi "optisch" erscheinen. Bezieht sich die Ausage, das sei "schlicht nicht einstellbar" auch auf diese Möglichkeit? Es gibt aus der fliegerischen Praxis und Erfahrung heraus ggf. gute Gründe, warum man meine Erwägungen und Überlegung zurückweist. Konstruktiv wäre diese Zurückweisung insbesondere aber dann, wenn sie mit einer Erklärung einherginge, wie und durch welche Eingabe sich die hohen Sinkraten erklären. Erfreulich finde ich, dass der Ton der Debatte bis dato nicht unangenehm oder unfreundlich war. Das darf wegen mir gerne so bleiben. Grüße Stefan Bearbeitet 16. September von Sherlock Newbie Zeilenumbruch korrigiert Zitieren
Tomi Geschrieben 16. September Geschrieben 16. September Und tschüss. Tönt für mich nach TvB und Papa Lutz. Tomi Zitieren
FalconJockey Geschrieben 16. September Geschrieben 16. September vor einer Stunde schrieb Sherlock Newbie: Gar nicht explizit gesprochen wurde bisher über die Eingabemöglichkeiten an der CDU/Konsole des Collins ProLine 21. Hast Du belastbare Erkenntnisse dazu, dass dort weder -2.880 ft/min baro noch - 3.008 ft/min geom eingegeben werden können und könntest Du uns diese bitte mitteilen? Im FMS kannst Du keine Sinkraten eingeben! Höchstens einen Sinkwinkel (Path, Angle). Effektiv ist es so, dass man für den Anflug eine Prozedur aus der Navigationsdatenbank aufruft, z.B. hier den VOR DME approach runway 32. Der enthält die Wegpunkte der Prozedur inklusive aller Höhen- und Geschwindigkeitsrestriktionen. Die Sinkrate, die einem das FMS vorschlägt ist einfach das Resultat aus diesen Höhenrestriktionen: In diesem Fall das VOR auf 3000ft (oder höher), dann der Wegpunkt UVITA auf 1500ft oder höher und das FAF (Final Approach Fix) CAIRO auf 1500ft oder höher. Von CAIRO aus wird dann wohl der Sinkwinkel bis zur Landbahnschwelle und deren Höhe+50ft berechnet. Der Sinkwinkel bis CAIRO wird in der Regel mit 3 Grad berechnet, was in etwa 1000ft Höhenunterschied für 3 NM Strecke beträgt. Die Strecke zwischen dem VOR und CAIRO beträgt in etwa 10NM, also würde das FMS eine Überflugshöhe von 4800ft für das VOR LIO ausspucken. Das sind aber alles Dinge, die nicht in der "Flugplanung" auftauchen. Das geschieht dann im Flug nach Eingabe der geplanten Wegpunkte und Anflugprozeduren. Und Anflugprozeduren darf man nicht verändern, man muss sie so übernehmen wie es das FMS aus der Datenbank aufruft. Fliegt man eine Landebahn an, die keine Anflugprozedur hat, erstellt man sich höchstens eine verlängerte Anfluglinie, um den Anflug besser durchführen zu können: Dann wird es nämlich zu einem Sichtanflug. Bei Dunkelheit über dem Meer ist das nicht trivial, weil man in ein schwarzes Loch hineinfliegt. Gibt man bei so einem selbst gebastelten Anflug falsche Wegpunkte und/oder falsche Überflugshöhen ein, können solche Fantasiewerte herauskommen wie Du sie wiederholst. Folgt man diesen Werten? Nein, nicht wenn man bei Sinnen ist. Das lässt sich nicht alles in drei Sätzen erklären, darum braucht man ja auch bis zu 2 Jahre, um Linienpilot zu werden und dann weitere Jahre, um genug Erfahrung zu sammeln, um sowas schnell zu erfassen und zu prüfen. Es gibt sooooooo viele Faktoren und Einflüsse, auf die man richtig reagieren muss und dazu muss man Erfahrung haben und fit sein. 2 3 Zitieren
Sherlock Newbie Geschrieben 19. September Geschrieben 19. September (bearbeitet) Mich haben diese komischen krummen Werte immer irritiert - siehe schon hier: Am 22.11.2024 um 15:34 schrieb Sherlock Newbie: Warum immer 8ft. Differenz? Wenn man von -2880 ft/min hoch rechnet, damit sich eine WGS84 Sinkrate ergibt, kämen -3000 ft/min glatt heraus. Es fehlen 8 ft an -3008 ft/min.! Wenn man von -3008 ft/min runterrechnet auf baro Rate, kämen -2888 ft/min raus. Zu -2880 ft/min gibt es wieder eine Differenz von 8 ft. Und die "Select Alt: 3008 ft." ist wieder 8 ft von glatten 3000 ft. entfernt. Und dass man mit diesen Werten weder am Guidance Panel, noch an der CDU des Collins ProLine21 arbeiten kann, macht es nun ja auch nicht besser. Mir ist jetzt bei der Befassung etwas aufgefallen, was ich vorher schon irgendwie gesehen, aber geflissentlich ignoriert hatte. Es gibt nämlich 6 Werte für die Sinkrate, die sowohl bei den 15 Werten für die baro Sinkrate als auch bei den 11 Werten der geom Sinkrate auftauchen: Das hat mich auf die Idee gebracht, die ich vielleicht früher schon hätte prüfen sollen, nämlich dass das FMS/die Avionics diese Werte nicht kontinuierlich (also 2781, 2782, 2783,....) verarbeitet/darstellt, sondern nur in diskreten Schritten/Intervallen. Das habe ich überprüft und siehe da: Von den 15 Werten für die baro VS sind alle bis auf einen Wert Vielfache von 32 ft.. Und von den geom. Sinkraten sind alle Werte Vielfache von 64 ft. . Das kann man hier sehen: Das würde bedeuten, dass an jeder Stelle, an der das FMS Daten in der Weise verarbeiten würde dass sich daraus barometisch ein Vielfaches von 32 ft und geom. ein Vielfaches von 64 ft. ergibt, man die originären Daten (glatte Zielwerte, Messwerte, etc) quasi nicht sieht. Und da der nächstliegende Vielfache, der zu glatt 3.000 ft passt 94 ist, würde das von @spornrad beobachtete Am 26.10.2022 um 23:49 schrieb spornrad: Bis zu der Kurve nach Süden war 3000 ft alt selected (...), ist mit knapp 3000 fpm gesunken. in dem Falle aussehen in den ADS-B Daten, wie 94 x 32 ft = 3008 ft, also wie "3.008 ft alt selected (...), ist mit knapp 3.008 fpm gesunken" - wenn das oben so richtig ist... Grüße Stefan P.S. Kleiner Nachtrag: Die Sinkraten habe ich manuell aus dem ADS-B Track in die Tabellenkalkulation eingetragen. Der einzige "Ausreißer" bei der baro Rate, der also nicht auf 32 ft glatt aufgeht (2754 ft/min, statt nächster Wert 2.752 ft/min), kann also auch ein Übertragungsfehler von mir sein. Ich habe jetzt nur keine Lust das nochmal nachzuschauen.... Bearbeitet 19. September von Sherlock Newbie Orthographie / Zeilenumbrüche // - P.S. hinzugefügt // Grüße 1 1 Zitieren
cosy Geschrieben 24. September Geschrieben 24. September (bearbeitet) Am 16.9.2025 um 15:41 schrieb FalconJockey: Oder warst Du schonmal nach 3 großen Bier im Flieger unterwegs und musstest Informationen auslesen und Entscheidungen treffen? Im WOCL passiert genau das! Das ist jetzt aber gar heftig unter der "Stammhirn-Linie".. Wenn Du als Beispiel Sauerstoffmangel in nicht bedruckten Rümpfen ohne O2- Ausrüstung angeführt hättest.. dann würde mein analoger Datenbank-Indexer in meinem Kopf - auf die Erfahrung im Direktrückflug aus Ungarn zugreifend - herftig zustimmen. https://skybrary.aero/articles/window-circadian-low-wocl Aber sowas.. Ich kenne genau einen Piloten, der ungehemmt Weisswein stemmte, um dann fliegen zu gehen- mit Paxen. Und der fliegt schon lange nicht mehr. Ansonsten ist das ein NoGo und in diesem Sinne pure Provokation. Also lass das bitte. Wie war die Vorgeschichte, Schlafrythmus des Piloten? Hast Du da wenigstens Anhaltspunkte? Von seiner Tochter erfuhr ich, als ich ihn einmal tel. kontaktieren wollte, dass er grad eine ganuze Saison in Afrika als Buschflieger unterwegs war. U.a. Caravan. Die Zyklen in diesem Job waren durch die Bereitstellung der Transportwaren sowie das Wetter bestimmt. Da muss einer sich gewaltig dynamisch verhalten mit seinen biophysischen Bedürfnissen. Offenbar hat er das mehr als eine Saison gemacht, da gehe ich davon aus dass er sich wohl fühlte in diesem Extrem-Job. Cosy Bearbeitet 24. September von cosy 1 Zitieren
Dierk Geschrieben 24. September Geschrieben 24. September (bearbeitet) Am 19.9.2025 um 14:04 schrieb Sherlock Newbie: Mich haben diese komischen krummen Werte immer irritiert - siehe schon hier: https://digitalcollection.zhaw.ch/server/api/core/bitstreams/394d65a4-79a5-4e8e-9c29-a707e9017fab/content Fehlerquellen: Rauschen, Quantisierung, Clock Synchronization Issues, Aggregation, Preprocessing, Postprocessing Zitat This paper addresses the issue of noisy, uncertain and quantized data in crowdsourced ADS-B and Mode S data and explores propositions of implementations of preprocessing techniques to address them. After a description of ADS-B data focused on sources of noise and uncertainty, we present in detail a selection of filters that have been implemented in the traffic library, and widely used in the constitution of open datasets used in further research. We also illustrate the results of the filtering with trajectory data collected by The OpenSky Network and by inexpensive RTL-SDR receivers. Bearbeitet 24. September von Dierk 1 Zitieren
cosy Geschrieben 25. September Geschrieben 25. September Für meinen Geschmack dreht sich hier das Ganze etwas im Kreis. Ich möchte da nur noch ein bisher nicht beleuchteter Fact erwähnen, (und dann aus diesem Thread aussteigen): Die "ATC-Chain" (also vom Statikport bis zum ausgesendeten digitalen Mikrowellen-Funksignal (Transponder-Datenpaket, Mode C oder S ausgesendet) gilt folgende Genauigkeitstoleranz nach einschlägigen Unterlagen der EASA: - klassischer Fall mit separatem Encoder Toleranz beim Test: +/- 125 ft (die gesendeten Werte dürfen also bis + oder - 124 ft falsch sein) To check the correct operation of a transponder, these tests can be performed according to : 1) the above test procedure for the ATC system, or 2) the alternative procedure below. ... These readings should allow the comparison of the coded altitude with a reference pressure altitude for the following values : - 1200 ft - 3700 ft - 5500 ft - 7500 ft - 15700 ft, - 31000 ft Tolerance remains +/- 125 ft - integriertes System: Toleranzen gelten wie für die Höhenmesser definiert: Ein Beispiel für Encoder: (häufig in klassischen, auch IFR-zugelassenen Flugzeugen) sehr häufig in Leichtflugzeugen: die ACK A-30 Encoder in IFR-tauglichen und gewerblichen Flugzeugen sind es i.d.R. zwei Systeme redundant sowie eine Komparatorbox, welche eine allfällige Signaldifferenz im digitalsierten Höhencode erkennt und ein Errorsignal aktiviert. Damit kann der Pilot nach Erkennen die relevantere (bessere) Quelle an den Transponder aufschalten. Manche Transponder machen das automatisch, haben also 2 oder mehr Encoder-Eingänge. Somit entsteht bei der Erzeugung des Wertes die Quantisierung im Encoder, der tatsächliche (analoge) Wert am Statikport des Encoders ist im Cockpit nicht ersichtlich Beispiel für integrierte Systeme: (später 2012 +) - alle aktuellen (neusten) S-Transponder haben einen internen A/D-Wandler, der die barometrische Höhe 'stufenlos' auflöst. Der Transponder kennt die genau gemessene Höhe (1013) als digitale, stetig vorhandene Information. Die Quantisierung des Signals erfolgt für den Sendeteil durch die gegebene Form des auszusendenenden Codes (daher die Abstufung der Werte auf der HF-Empfangsseite). Aber das haben wir schon breit diskutiert. Im Transponder kann eine gemessene Abweichung zwischen Coder oder internem Signal und dem Höhenmesser kompensiert werden (Kompensationstabelle). Darum wird im Fall b) die Toleranz des Höhenmessers als Anforderung in der ATC-Prüfung gefordert. Bild: EFIS mit AeroCAN- Verbindung zu Transpondermodul Cosy 1 Zitieren
cosy Geschrieben 25. September Geschrieben 25. September Hier habe ich ein Video gefunden, das sehr schön zeigt, was passiert, wenn ein Draht des Kabels zwischen Dilham (oder Grey-) Encoder und Transponder (resp. Altimeter mit entspr. Eingang) ein Draht fehlerhaft ist: Im folgenden Beispiel ist der Pin C2 gestört, also die Stelle für die 100er. Darum wird beim rauf und runterdrehen der Höhe (im Labor) immer zwischendurch eine völlig falsche Sinkrate angezeigt: Cosy Zitieren
FalconJockey Geschrieben 29. September Geschrieben 29. September Am 24.9.2025 um 16:04 schrieb cosy: Das ist jetzt aber gar heftig unter der "Stammhirn-Linie".. Wenn Du als Beispiel Sauerstoffmangel in nicht bedruckten Rümpfen ohne O2- Ausrüstung angeführt hättest.. dann würde mein analoger Datenbank-Indexer in meinem Kopf - auf die Erfahrung im Direktrückflug aus Ungarn zugreifend - herftig zustimmen. https://skybrary.aero/articles/window-circadian-low-wocl Aber sowas.. Ich kenne genau einen Piloten, der ungehemmt Weisswein stemmte, um dann fliegen zu gehen- mit Paxen. Und der fliegt schon lange nicht mehr. Ansonsten ist das ein NoGo und in diesem Sinne pure Provokation. Also lass das bitte. Say again? Ich glaube, Du befindest Dich gerade als Geisterfahrer in dieser Antwort, oder war es die Sprachbarriere? Ich ging eigentlich davon aus, dass jedem ausgebildeten Piloten im Fach "Human Performance" die drastischen Auswirkungen von Übermüdung - gerade im WOCL - bekannt sind. Die kognitiven Einschränkungen haben in etwa den Effekt von 0.8 bis 1.0 Promille Blutalkoholgehalt, also etwa 2 bis 3 Bier. Und genau darum muss man rund um und im WOCL besonders gut aufpassen, oder sogar den Betrieb in dieser Zeit vermeiden. Wenn man der alleinige Pilot ist, sollte man sich das ernsthaft überlegen, denn wenn man schon zu zweit im Cockpit teilweise unsinnige Sachen sagt und tut, wie ist es dann alleine, wenn einen keiner korrigieren kann? 1 1 Zitieren
Sherlock Newbie Geschrieben 30. September Geschrieben 30. September Am 25.9.2025 um 15:59 schrieb cosy: Für meinen Geschmack dreht sich hier das Ganze etwas im Kreis. Das will ich durchaus selbstkritisch gerne zugestehen, dass das bis dato der Fall war. Ich jedenfalls habe die ganze Zeit in den falschen Alternativen gedacht. Für mich war es entweder so, dass die Zielwerte des FMS/AP in dieser Sinkphase des Fluges Am 22.11.2024 um 15:34 schrieb Sherlock Newbie: ... barometrisch -2880 ft/min und geometrisch -3008 ft/min sind oder es gilt: Am 17.11.2024 um 13:58 schrieb Olindaguy: Persönlich würde ich diesen öffentlchen ADS-B Daten (zB RadarBox) nicht sehr viel Glaubwürdigkeit geben (....). Das sind doch recht grosse Ausfaller, die nicht plausibel sind. Damit werden die ausgesendeten ADS-B Altitude Daten (...) sicherlich in Frage gestellt. Dass die Wahrheit quasi "dazwischen" liegt, habe ich erst bemerkt, nachdem ich meine eigene rethorische Frage, übrigens an Dich @cosy gerichtet, ernst genommen habe: Am 16.9.2025 um 16:46 schrieb Sherlock Newbie: Jetzt müsste man aber als Konsequenz der eigenen Argumentation annehmen, dass die ausgesendeten ADS-B Daten nie zeigen, was Zielwerten des FMS/AP entspricht. Und siehe da, die ADS-B Daten zeigen eben wegen Quantisierung/skalierten Intervallen (32ft/64ft) tatsächlich ggf. nie die wirklichen Zielwerte des FMS/AP und können eben trotzdem in Summe und im Ganzen zuverlässig und richtig sein. Und da mithin, was ich bis dato schrieb, sich keineswegs durch ein breitbeiniges und volltönendes "Hör doch auf mit den 3008 Füssen. Das ist schlicht nicht einstellbar, messbar." erledigt hätte, sondern vielmehr sich ja jetzt herausstellt, dass das seinerseits eine Aussage war, deren Beitrag zum Erkenntnisgewinn schlicht und auch nicht messbar war, kann man sich ja vielleicht auch erneut und mit frischem Geist der Frage öffnen, ob man erkennen oder begründet vermuten kann, mit welchen Zielvorgaben die Phase des Sinkfluges durchgeführt wurde. Das habe ich getan und nun auch die historischen Daten aus dem ADS-B Track in die Tabellenkalkulation eingegeben. Reminder: Bisher hatte ich nur mit den Daten aus dem KML-Track gearbeitet, weil mir (nach wie vor) keine downloadbaren ADS-B Daten zur Verfügung stehen. Ich habe nun also die Daten aus dem ADS-B Stream, d.h. Zeitstempel und zu diesem Zeitpunkt jeweils baro ALT, geom ALT, baro VS und geom VS, per Hand in die Tabellenkalkulation übernommen und mit dem KML-Track zusammengeführt. Was einem als erstes dann auffällt: Die absolute Höhenangaben scheinen selbst wieder quantisiert zu sein, und zwar, entsprechend dem von @Dierk dankenswerter Weise verlinkten Artikel, in 25ft Intervallen. Die erste Frage wäre: Welche Sinkrate, baro oder geom, geht der anderen zeitlich voraus laut ADS-B Datenstream? Wenn FMS/AP eine baro VS von z.B. -2.900 ft/min (oder -2.800 ft/min) steuern, dann sollte die geom Sinkrate sich dazu zeitlich bestenfalls parallel oder nachfolgend entwickeln (?). Das kann man sich aus dem ADS-B Track und den von dort übernommen "Rohdaten", hier anschauen. Damit das aber noch ein bisschen besser sichtbar wird, habe ich die Linien von baro VS und geom VS übereinander gelegt, damit man das klarer sieht. Siehe: hier. Und ich habe das zusätzlich mit geglätteten, gleitenden Durchschnittswerten auch noch einmal abgebildet (geom VS +150 ft nach oben verschoben zwecks besserer Sichtbarkeit). Das sieht man hier: Die rote Linie (für die geom Sinkrate) geht der blauen Linie (für die baro Sinkrate) zeitlich voraus (wie eigentlich auch aus den beiden vorherigen verlinkten Diagrammen ersichtlich). Das entspricht nicht meiner Erwartungshaltung, wenn die baro VS der Zielwert und die geom Sinkrate abgeleitet wäre und zeitlich dann "nachziehen" sollte. [Das kann aber mir unbekannte technische Gründe haben.] Die zweite Frage wäre diejenige nach der sachlichen Abhängigkeit der geom Sinkrate von der baro VS, wenn letztere die Zielgröße des FMS/AP wäre. Überspitzt/vereinfachend: Wenn zum Zeitpunkt t1 die baro ALT 10.000 ft beträgt und zu diesem Zeitpunkt die geom ALT 12.500 ft, dann verhält sich die geom ALT zur baro ALT wie = 1,25 (zu 1). Wenn zu diesem Zeitpunkt die baro VS auf -1.000 ft/min eingestellt wäre im AP, dann sollte sich daraus eine geom VS von -1.250 ft/min ergeben (?). Und das Verhältnis der geom VS zur baro VS wäre wieder wie = 1,25 (zu 1). Was man jedoch hier sehen kann: Die geom VS (im Verhältnis zur baro VS) fällt während des Sinkfluges relativ zu hoch aus bzw. ist höher, als den Höhenverhältnissen (geom zu baro) zum jeweiligen Zeitpunkt entspricht: Nur in der Phase des Kurvenfluges (von Kurs 96 auf Kurs 199) dreht sich das Verhältnis um und die baro VS liegt im Kurvenflug höher (bzw. die geom niedriger) als erwartbar. Und das kann man noch etwas klarer auch hier sehen (Werte über 1 = geom VS zu hoch): Die nächste, dritte Frage wäre, ob sich sonst rechnerisch ermitteln läßt, welche Sinkrate die andere bestimmt, bzw. welche Sinkrate sich abgeleitet aus der anderen ergibt. Das kann man prüfen wie folgt: Zu einem gegebenen Zeitpunkt t steht die geom ALT zur baro ALT in einem bestimmten Verhältnis, z.B. "1,05". Von diesem Verhältnis ausgehend kann man jeweils aus der baro VS eine hypothetische geom VS errechnen (-2.880 ft/min x Faktor 1,05 = -3.024 ft/min) bzw. umgekehrt aus der geom Sinkrate eine hypothetische baro VS (-3.008 ft/min / 1,05 = -2864 ft/min). Und die so errechneten "hypothetischen" Sinkraten kann man dann widerum vergleichen mit den tatsächlichen Sinkraten laut ADS-B. Also welche hypothetische Sinkrate korreliert besser mit den tatsächlichen Sinkraten laut ADS-B Datenstream. Ergebnis ist, dass die aus der geom Sinkrate errechnete hypothetische baro VS besser zu den tatsächlichen baro Sinkraten passt, als umgekehrt. Und ich meine das kann man auch sehen - siehe Diagramm hier. Nur ist dieser Unterschied in der Korrelation nicht sehr hoch, und darum allein nicht aussagekräftig. Fazit: Die ADS-B Daten im historischen Verlauf besagen, dass die geom Sinkrate, der baro VS zeitlich vorausläuft. Und die Verhältnisse der historischen Höhenwert laut ADS-B (geom ALT zu baro ALT) besagen, dass zu den jeweiligen Zeitpunkten (mit Ausnahme des Kurvenfluges, wo es sich exakt anders herum verhält), die geom Sinkrate (relativ zur baro VS) zu hoch ist (siehe dazu schon: hier) . Und die aus der geom Sinkrate abgeleitete (hypothetische) baro VS passt besser zu den tatsächlichen baro Sinkraten, als das umgekehrt der Fall ist. Gegencheck: Ich habe alle drei Fragen noch einmal mit den Daten aus dem KML-Track geprüft. Zu der Frage des zeitlichen Vorlaufs der einen Sinkrate vor der anderen ist das Ergebnis, dass im KML-Track die Sinkraten ziemlich synchron verlaufen. Da aber die Daten des KML-Track (vermutlich) im höheren Grade dem "postprocessing" unterliegen, würde ich das nicht als (allein) ausschlaggebendes Gegenargument erachten. Zu der Frage der sachlichen Abhängigkeit der geom Sinkrate von einer festgesetzten baro VS ist das Ergebnis so, dass die geom Sinkrate auch im KML Track jedenfalls gegen Ende dieses Sinkfluges zu hoch ist (relativ zu einer angenommenen baro VS). Das kann man in der hier verlinkten Graphik sehen. Und das hatte ich i.Ü. auch oben schon mal angemerkt. Und zu der letzten Frage: Auch wenn man nur mit den Angaben aus dem KML Track rechnet ist es wieder so, dass minimal die aus der geom errechnete baro VS besser zu den tatsächlichen baro Sinkraten passt, als das umgekehrt der Fall ist. Das sind mithin drei Indizien, die die These einer baro VS jedenfalls nicht unbedingt stützen. Es gibt noch anderes aus den ADS-B Daten zu sehen, aber da der Post jetzt schon lang genug ist, schreibe ich dazu ggf. später noch was. Grüße Stefan P.S.; Man kann das, was ich oben graphisch dargestellt habe, auch rechnerisch prüfen, bzw. ermitteln. Das habe ich parallel auch getan. Und das, was man rechnerisch ermitteln kann, stimmt mit allem o.g. überein, sonst hätte ich es nicht geschrieben. Ich habe nur auf die Wiedergabe von statistischen Berechnungen verzichtet, um der Anschaulichkeit den Vorzug zu geben. 1 Zitieren
cosy Geschrieben Donnerstag um 13:53 Geschrieben Donnerstag um 13:53 Hallo Sherlock (leg mal ein Moment Deine Lupe weg), Ich habe den Eindruck, dass Du mit extrem viel Fleiss Dich immer tiefer in den Schlamm wurstelst. Es wäre angebracht, eine kurze Denkpause einzulegen. Wenn Du ein Student wàrst, der eine Semesterarbeit abzugeben hat und so seine Fehleranalyse darlegt, würde bestimmt gefragt: - Welches sind die Datenquellen (Eigenschaften, Grenzwerte, Auflésung, Messfehler, Abtastintervall, Quantisierung...) - Data-processing: wie sieht die Verkettung der Verarbeitung der Informationen aus? - Verarbeitung / portieren der Rohinformation: korrekturen.. - Referenzen (z.B. Echtzeit) : Qualitàt der im Datenprozessing genutzten Referenzen * Mir erschliesst sich nicht, warum Du aus den ADSB Dataen die FMS Stützpunkt- und vertical profile Vorgaben "prüfen" willst. Es gibt da keine mathematisch belastbare Verbindung. Dazu bràuchte man den Flugdatenschreiber. Schliesslich haben wir einzig Koordinaten und Std-Flugflàchen mit entsprechender Unschàrfe bei der Zuordnung, sowohl in 2D (Zeitversatz, Auflösung), als auch vertikal (quantisierung der Höhe , Zeitversatz). * ein Beispiel: Ein ModeS ADSB-OUT Transponder sendet typisch jede Sekunde, aber mindestens alle 3 s einen ES-Dataframe ab . Die Std Baro-Höhe wird in einem Register des Transponders gespeichert. Wie hàufig / schnell ist dieses update? So kann th. ein Zeitversatz von z.B. +1s entstehen zwischen durchflogenem Wert und Zeitstempel des gèltigen Empfangs der Sequenz Cosy Zitieren
Sherlock Newbie Geschrieben vor 9 Stunden Geschrieben vor 9 Stunden Hallo Bruno @cosy, mir ist in der Sache nicht klar, was Du sagen willst: Jeder, der sich hier im Thread zu dem Flugverlauf und insbesondere der Phase des Sinkfluges in begründeter und faktenbasierter Weise geäußert hat, hat dies getan auf der Basis der ADS-B Daten (und zwar ganz unabhängig von meinen Beiträgen). Wieso diese Daten jetzt keinerlei Grundlage für eine Befassung mit diesem Flug und dieser Flugphase liefern sollten verstehe ich angesichts der gesamten Diskussion nicht. Meines Erachtens stellt sich die pauschale Frage, "Sind die ADS-B Daten zuverlässig oder unzuverlässig?", so nicht (mehr). Ein konkretes Beispiel aus diesem Thread: Am 17.11.2024 um 13:58 schrieb Olindaguy: ... im letzten Flug von Mexico (Palenque) nach Costa Rica (Puerto Limon) - im Cruise - hat es auf ADS-B mehrere Ups and Downs zwischen FL 330 und FL350. (...) (Stichwort Wellenflug). Das sind doch recht grosse Ausfaller, die nicht plausibel sind. Damit werden die ausgesendeten ADS-B Altitude Daten der DIRSG (...) sicherlich in Frage gestellt. In dem von Dierck oben verlinkten Artikel wird das Phänomen "Wellenflug" als Folgen von Rauschen und Quantisierung der ALT-Daten beschrieben: Quelle: Xavier Olive , Jan Krummen ,Benoit Figuet ,and Richard Alligier: Filtering Techniques for ADS-B Trajectory Preprocessing, Journal of Open Aviation Science (2024), Vol.2, p. 4 (https://digitalcollection.zhaw.ch/server/api/core/bitstreams/394d65a4-79a5-4e8e-9c29-a707e9017fab/content) Mit anderen Worten: Wenn sich aus den ADS-B Daten unter den dortigen Umständen ein Wellenflug ergibt, dann ist die Interpretation dieser Daten als Wellenflug ("Pilot besoffen, weil er in Wellen fliegt", AP hat Schaden, o.ä.) zweifelhaft und die Interpretation als Level Flight wahrscheinlich(er). Das stellt aber nicht die ADS-B Daten insgesamt in Zweifel, sondern nur die eine oder andere Interpretation dieser Daten angesichts möglicher Unschärfe der Daten. Diese Frage muss man aber konkret jeweils im Einzelfall beantworten. Was ich insbesondere nicht verstehe ist folgende Aussage von Dir: Am 2.10.2025 um 15:53 schrieb cosy: Mir erschliesst sich nicht, warum Du aus den ADSB Daten die FMS Stützpunkt- und vertical profile Vorgaben "prüfen" willst. Es gibt da keine mathematisch belastbare Verbindung. (...) Schliesslich haben wir einzig Koordinaten und Std-Flugflàchen mit entsprechender Unschàrfe bei der Zuordnung, sowohl in 2D (Zeitversatz, Auflösung), als auch vertikal (quantisierung der Höhe , Zeitversatz). Richtig ist, dass die KML-Tracks, die man bei ADSBexchange downloaden kann nur Lat, Long und Alt enthalten (neben Zeitstempel natürlich). Dass mit diesen Daten überhaupt keinerlei Einsichten gewonnen werden könnten, deckt sich nicht mit dem, was aus diesen Tracks zu ziehen ist (siehe: oben). (Die Frage der Interpretation ist damit allein natürlich nicht beantwortet.) Die ADS-B Daten selbst stehen mir bekanntlich nicht ohne weiteres zur Verfügung (kein Downloadmöglichkeit). Ich hatte diese zuletzt per Hand in die Tabellenkalkulation übernommen und dazu erst mit meinem letzten Post mich geäußert. Es gibt im ADS-B Stream gewisse "Selbstauskünfte", die ich mit Deinen Äußerungen nun aber nicht in Übereinstimmung bringe: Vielleicht magst Du noch erläutern/ergänzen? Grüße Stefan Zitieren
cosy Geschrieben vor 3 Stunden Geschrieben vor 3 Stunden OK, Stefan. Im Gegensatz zur Antwort eines Mode S Transponders auf eine Interrogation eines Radars ist ADS-B eine zyklisch ausgesendete Gruppe von Informationen. Dazu wird auch eine andere Modulation verwendet als für Mode A,C . Die gleiche Technologie, aber mit anderen Dateninhalten wird von TCAS, aber auch zum Daten-Downlink (COM-B) verwendet. Es gibt einige proprietäre Anwendungen die mit der technisch gleichen Technologie genutzt werden. Zunächst ein paar Punkte, um sicherzustellen, dass Deine Daten kohärent sind mit dem Decoding. ADSB-OUT wurde mehrmals verändert, es gibt historisch mindestens die Versionen 0, 1, und 2 im Betrieb (habe keine Infos zu neueren Varianten nach 2016 und weiss auch nicht, was die US am aushecken ist). Es gibt in der Community gute Literatur dafür, um anhand einiger Parameter und deren übermittelten Werte festzustellen ist, welche Version gesendet wird (ADSB codiert die Version nicht explizit mit ein). Einer dieser "Testmarker" sind die Flags und Codes für Genauigkeit, Zuverlässigkeit und Integrität (NUC, NAC, NIC, SIL..) Jeder ADS-B Frame ist immer 112 Bit lang, (und dauert zum Senden auch 112 Microsekunden plus Präambel und Stuss, siehe Wikipedia). Das erste Feld ist DF : Das Downlinkformat. Nun zu den Daten, die Du untersuchst. Falls DF=17 ist, handelt es sich um eine Antwort vom Mode-S Transponder im Format ES (extended Squitter), das kann sich zwischen die zyklischen ADS-B OUT Dataframes mischen. Mode-S ES Informationen enthalten IMMER die barometrischen Höhendaten und Speed und Vektoren sowie Headings sind immer aus dem (den) Airdata System(en). Anders beim DF=18. Das sind Daten aus der GNSS Quelle, die Vektoren sind auf GNSS Basis berechnet. Die Koordinaten werden nicht im "Klartext" übertragen, sondern codiert und komprimiert. Der Algorythmus zum Enschlüsseln der Positionsdaten ist komplex und hängt von der ADS-B Version ab. Die ADS-B Type Codes Wie gesagt, die Daten in einem ADS-B Out Frame sind immer gleich lang : 56 bit. Die ersten 5 Bits enthalten den Type Code , der die Arte der folgenden Daten (den Rest ) definiert. Wenn man den TC kennt, kann man herausfinden - was genau man da erhält - wie man die Daten decodiert - wie man die Daten interpretieren soll - und man kriegt Rückschlüsse auf die Version ADS-B TC Daten enthalten ------------------------------------- 1–4 Aircraft identification 5–8 Surface position 9–18 Airborne position (w/Baro Altitude) 19 Airborne velocities 20–22 Airborne position (w/GNSS Height) 23–27 Reserved 28 Aircraft status 29 Target state and status information 31 Aircraft operation status Wenn Du mit den decodierten Daten einen Hinweis auf das Label TC kriegst, kannst Du diese genau einordnen. Cosy Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.