22.10.2022 | Piaggio 180 Avanti | D-IRSG | Costa Rica | Vor Küste vermisst

[Sherlock Newbie]

vor 2 Stunden schrieb Michi Moos:

Ein Flugzeug fliegt in diesen Modi nicht mit GPS Höhe oder GPS Vertical Speed, sondern rein barometrisch.

 

 

Danke für die Reaktion. In meinem zweiten Beitrag hatte ich m.E. ausdrücklich geschrieben, dass das Flugzeug in dieser Phase nach barometrischen Höhenangaben fliegt: "... obwohl das Flugzeug tatsächlich nach barometrischer Höhe fliegt ...". [Dazu hatte ich sogar auch die Standardabweichungen und die Varianz der kml-Tracks (Pressure vs. GPS) verglichen und das ist ziemlich eindeutig.]

 

Die Frage ist aber doch: Ist entweder a) die primäre Eingabe -2880 ft/min barometrisch und daraus ergibt sich einfach abgeleitet die Geom.  Rate oder ist b) die originäre Eingabe - 3008 ft/min und die barometrische Sinkrate (nach der dann geflogen wird)  ist dann davon abgeleitet. Wenn man a) für richtig halten würde, müsste man sagen, dass es erstens Zufall ist, dass sich ausgerechnet eine Sinkrate von -3.008 nach GPS ergibt (hätte auch jede andere sein können) und dass es zweitens dann auch ebenso nur Zufall ist, dass sich eine Übereinstimmung mit der "Select Alt: 3008 ft." ergibt und man hat dann drittens zusätzlich auch noch keine Erklärung dafür, weshalb sich bei der niedrigen Flughöhe die geom. Rate nicht adaptiert und bei 1925ft Altitude (baro) ab Time: 23:52:33 Z immer noch "-3.008 ft/min" geom. anliegen, während zugleich viertens keine barometrische Sinkrate mehr in ADS-B Daten übermittelt wird, sondern nur noch "n/a". Siehe z.B. den Zeitpunkt 10 Sekunden später also Time: 23:52:43 Z:

Spatial

Groundspeed: 267 kt

Baro. Altitude: ▼ 1425 ft

WGS84 altitude: ▼ 1400 ft

Vert. Rate:-3008 ft/min Altitude Barometric:▼ 1425 ft Baro. Rate: n/a Geom. WGS84:▼ 1400 ft Geom. Rate:-3008 ft/min   vor 2 Stunden schrieb Michi Moos: mit Ausnahme eines Final Approach Segments in speziellen GPS Modi, wo aber in einem "APP" Mode ein geometrisches Profil abgeflogen wird - ähnlich einem ILS.   Das ist mir grundsätzlich bekannt, wenn auch nicht in Details. Die Unterschiede zwischen RNAV, RNP, VNAV, Baro-VNAV, LNAV+V, LPV sind - vorsichtig formuliert - für eine nicht mit der Materie bewanderte Person schwer zu durchschauen. Wie auch immer. Ich habe anderenorts gelesen, dass das Collins Pro Line 21 in seinen Datenbanken synthetische "ILS-ähnliche" Approaches hinterlegt habe. Das ist auch der Grund, weswegen ich mir vorstellen kann, dass ab dem Zeitpunkt 23:52:33 Z auf eine GPS Höhennavigation umgestellt würde (und deshalb die Baro. Rate n/a zeigt). Es ist ja nicht unbedingt fernliegend, siehe Karte hier, dass der IAF um die GPS (guided/assisted) Gleitpfade aufzupicken auf 3000ft GPS Höhe liegen könnte. Das kann ich leider mangels Zugang nicht selbst recherchieren/klären. Grüße Stefan

Bearbeitet Samstag um 17:54 von Sherlock Newbie

[Frank Holly Lake]

Meine persönlchen Gefühle zu Herrn S habe ich schon geschrieben.

Es ist ein Muster ohne FDR ohne CVR , ein Muster was auch ein Pilot alleine  fliegen darf.

Wir wissen nicht wer gesteuert hat. Nur das 5 Personen tot sind.

 

https://asn.flightsafety.org/wikibase/300083

 

Es ist nur ein  

Preliminary report      Veröffentlicht worden. Eigentlich erwartet man schon im Oktober 23 den Abschlussbericht, oder zumindest Oktober 24 eine weiteren Zwischenbericht. Es sieht nicht so aus, als wenn die Untersucheungsbehörde sich an Vorschriften diesbezüglich  halten würde. Und selbst wenn man das Wrack finden würde, ob man da noch ev. technische Schäden nachweisen könnte, nach  so einer langen Zeit, ist fraglich.   Kein Notruf, 3 Leichen vermisst, kein Wrack  und außer der FD24 Daten hat man eben nichts.  Auch kein Verwandter, der da mittels Geld Druck machen will oder kann.   Wenn nicht irgendwas noch gefunden wird,  gibt es keine neuen Detais mehr. Also wird es mit großer Wahrscheinlichkeit ein CIFIT werden und geschlossen werden, mit dieser Faktenlage. Grüße Frank

Bearbeitet Samstag um 20:21 von Frank Holly Lake

[ArminZ]

4 hours ago, Sherlock Newbie said:

Die Frage ist aber doch: Ist entweder a) die primäre Eingabe -2880 ft/min barometrisch und daraus ergibt sich einfach abgeleitet die Geom.  Rate oder ist b) die originäre Eingabe - 3008 ft/min und die barometrische Sinkrate (nach der dann geflogen wird)  ist dann davon abgeleitet.

Nach meinen Verständnis ist die geom. Rate ein rein rechnerischer Wert, basierend auf GNSS-Daten (siehe hier ) :

Quote

alt_geom: geometric (GNSS / INS) altitude in feet referenced to the WGS84 ellipsoid
geom_rate: Rate of change of geometric (GNSS / INS) altitude, feet/minute

Bearbeitet Samstag um 22:16 von ArminZ

[Olindaguy]

vor 21 Stunden schrieb Sherlock Newbie:

Nach der Kurve auf Süd stellt sich wieder die "Geom. Rate: - 3.008 ft/min" ein, jedoch wechselt lt. ADS-B die übertragene barometrische Sinkrate von da ab (und für den Rest des Fluges) auf "n/a". 

 

 

Lieber Stefan,

 

Eine Anmerkung von meiner Seite: Ich habe als ATC Controller oft den ausgesendeten Daten (DABS) auf Mode S EHS (Enhanced) am Radar zugeschaut. Und die Piaggio Avanti P180 war da auffallend SCHLECHT - bis ganz schlecht (wie du auch anmerkst: n/a). Aber ich muss auch anmerken, dass ich nicht gleichzeitig auch Zugang auf die ADS-B Daten des Fluges hatte (nur auf Mode-S). Somit war ein Vergleich 1 zu 1 nicht möglich. Aber meine Vermutung ist, dass diese Daten auch eher schlecht waren (das ist nur ein anderes Register/System, aber die Grunddaten und die Grundverbindung Avionics - TRSP ist ja bekanntlich die gleiche).

 

Alles deutete (schon damals) darauf hin, dass die Avionics der Piaggo Avianti P180 eher schlecht mit dem Transponder verbunden ist/war ("unsicher" oder wackelig und eher störungsanfällig). Das ist ziemlich sicher ein Transponder Problem (und/oder der Interface/des Codings mit der Avionics) - des Rockwell Collins 94D Transponders. Ich bin sehr sicher, dass die DIRSG einen solchen TRSP auch am Unfalltag an Bord hatte. Auf Internet wird man da sehr schnell fündig (Internet) wie oft dieser Transponder Probleme hatte, inklusive der Publikation von ADs und Service Bulletins von FAA (und andere Behörden) um dies zu korrigieren. Und man kann feststellen, dass der Verkauf der HB-LUS (die vorherige Immatrikulation) nach Deutschland, wo sie zur D-IRSG wurde - mit dieser Avionics-Lösung/Equipment erfolgte.

 

Persönlich würde ich diesen öffentlchen ADS-B Daten (zB RadarBox) nicht sehr viel Glaubwürdigkeit geben - vor allem nicht um dazu dann präzische (korrekte) Schlüsse auf ein Unfallszenario zu machen. Zum Beispiel 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. Und auch im Descent hat es auch recht grosse "Schwankungen" der Flughöhe (Stichwort Wellenflug). Das sind doch recht grosse Ausfaller, die nicht plausibel sind. Damit werden die ausgesendeten ADS-B Altitude Daten der DIRSG (zeitweise) sicherlich in Frage gestellt. Ich würde meine Finger davon lassen daraus gewisse Annahmen (oder Spekulationen) auf das Unfallszenario zu machen. Lassen wir doch die Untersuchungsbehörden dies machen - die haben ja bekanntlich noch andere Möglichkeiten gewisse Airborne und Broadcast-Daten (zB ADS-B) zu überprüfen (und zu crosschecken).

 

LG Chris

[Sherlock Newbie]

Hallo Chris,
eigentlich wollte ich jetzt nicht gleich wieder etwas posten hier, weil ich auf die hier versammelte fachliche Expertise vertrauen und schlicht etwas abwarten wollte. Dein Posting nötigt mich nun aber in gewisser Weise zu folgender Klarstellung: Ich hatte in meinen Beiträgen versucht, den Fakten- und den Datenanteil hoch und den spekulativen Anteil niedrig zu halten. Das ist ja auch eine Frage des Respekts im Umgang mit so einem Unfall. Und ich habe überhaupt nur deshalb hier etwas gepostet, weil die von mir angesprochene tatsächliche Koinzidenz zweier Daten während des Fluges vorher in diesem Thread explizit so nicht thematisiert worden war. Es ging mir also im Ausgangspunkt um einen Fakt.

Dass ich dabei auf Daten zurückgreife, die man ihrerseits in ihrer Verlässlichkeit anzweifeln kann, ist und war mir bewußt, wenn auch natürlich nicht mit der spezifischen Kenntnis, die Du jetzt dankenswerter Weise zu dieser Thematik beigesteuert hast. Es kann aber m.E. im Umkehrzug jetzt auch nicht die Ausgangsprämisse einer Beschäftigung mit diesem Unfall sein, dass alle ausgesandten ADS-B Daten random noise sind.

Konkret zu der Frage "n/a": Natürlich ist es möglich, dass ausgerechnet jetzt und dieser Flugphase auch noch der "Wackelkontakt" des Transponders zuschlägt und die Baro Rate n/a wird. Es gäbe aber doch auch eine nicht den Zufall bemühende Erklärung, nämlich Übergang zu GNSS/GPS Navigation (?). Warum aber immer noch (und wieder) "Geom. Rate:-3008 ft/min" bei nur noch 1.400ft Höhe? Zufall? Wackelkontakt?

Was ich leider im Sinne der Regeln hier nicht wirklich so hilfreich finde ist die implizite Aufforderung auf die Ergebnisse der Flugunfalluntersuchung zu warten. In jedem Falle trotzdem nochmal danke für die Erläuterungen zum Transponder.

Grüße
Stefan

 

Nachtrag
Es gibt vielleicht noch einen Erkenntnisgewinn, den man aus der Diskussion um die Zuverlässigkeit der Transponderdaten mitnehmen kann: Je höher die Rate an Fehlern bei der Sensorik, bei der AP-Steuerung und bei der Datenübertragung, desto wahrscheinlicher wird es, dass die Sinkrate einmalig auch einer "Geom. Rate: -3008 ft/min" entspricht (obwohl der AP/VNAV mit irgendetwas anderem programmiert war) und sich einmal zufällig die Übereinstimmung mit der "Sel. Alt.: 3008 ft" ergibt. Es wird aber gerade deshalb im Gegenzug umso unwahrscheinlicher, dass sich rein zufällig mehrfach wieder dieses gleiche Datum ergibt. Je mehr Fehlerursachen es gibt und je höher deshalb die willkürliche Schwankungsbreite angenommen wird, desto eher wird es statistisch signifikant, wenn ein gewisses Datum, wie hier, mehrfach (nämlich 10 mal) wieder auftaucht in einer Zahlenreihe. 

Wenn man die implizite These von Chris oben mal durchrechnen möchte, sieht es aus meiner Sicht so aus: Wir haben einen Track von ungefähr 4 Minuten, der sich ungefähr alle 3 Sekunden refresht. Das macht ganz grob 100 Datensätze (lt KML Track sind es 80). Wir unterstellen, dass die Vertikalgeschwindigkeit um +/-200ft um einen uns unbekannten Wert beliebig zufällig schwankt (die Standardabweichung der Daten lt KML Tracks liegt deutlich höher). Und dieser Zufall bewirkt dass die Geom Rate eben auch mal mit -3008 ft/min angezeigt wird, was aber der Hypothese gemäß Zufall und bedeutungslos ist. Das ist wie, wenn man 100 x mit einem 400-seitigen Würfel würfelt und 10 mal davon erwürfelt man dieselbe Zahl, z.B. "308". Die Wahrscheinlichkeit dafür beträgt 0,000000000798 %

Bearbeitet Sonntag um 20:47 von Sherlock Newbie
Beitrag um Nachtrag ergänzt / Wahrscheinlichkeit berechnet

[cosy]

On 11/17/2024 at 3:35 PM, Sherlock Newbie said:

Die Wahrscheinlichkeit dafür beträgt 0,000000000798 %

Edited Sunday at 09:47 PM by Sherlock Newbie

Mal mit etwas weiter gefassten Randbedingungen können solche Annahmen wie Schnee an der Sommersonne schmelzen:

* Du gehst davon aus, das die Geräte sowie die Kommunikationskanäle fehlerfrei und stetig funktionieren

* Du gehst davon aus, dass jede Komponente merkt, wenn eine andere Instanz ein Fehler verursacht 

* Begrenzungen der erlaubten Wertebereiche sind bei Deiner Abschätzung nicht berücksichtigt

Ein Allgemeines Beispiel: die int. Darstellung einer Mobilnetznummer hat 10 Stellen: das sind 10 Milliarden Kombinationen. Wirklich möglich real sind aber lediglich etwa 50 Millionen, also 200 mal weniger.

 

Im vorliegenden Fall müsste man sich ein paar offene Fragen stellen und suche gehen, bevor man annimmt, dass die Häufung dieses Wertes in der Anzeige wirklich 'natürlich verteilt' ist:

- handelt es sich bei dem Wert vielleicht um eine Limite (immer wennn (transient) ein sehr grosser Sinkwert resultieren würde, wird somit dieser Wert ausgegeben)?

- gibt es bei der Transformation der Daten (Bus) oder (ältere Systeme (analoge Werte*) gar ein Verlust vom Originalwert?

 

usw..

 

*) sehr lange wurden A/P Systeme per analoge Elektronik realisiert. Diese Technologie ermöglichte eine Kontrollierte Dynamikbegrenzung in allen Fällen , auch bei Teilausfall von Sensordaten oder Systemteilen, denn die Eckwerte der Stellsignale, wie Verstärkungsfaktor, Dämpfungsfaktor und elimination von Abweichungen (Soll/Ist) wurde in physischen Bauteilen (Schaltungen) erzeugt, die unabhängig von (äusseren) Störungen immer die gleichen Ausgangsfunktionen lieferten.  Mit diskreten Signalen und getakteten digitalen Schaltungen/Prozessen wird das Rauschen fast eliminiert, aber es kommen eine unglaublich grosse Zahl an 'verbotenen' Konstelationen von möglichen Fehlern hinzu, die es gilt zu erkennen und zu eliminieren.

 

Wie man so schön sagt, jeder Code der länger als ein Screen voll ist, hat Fehler. Entweder man erkennt sie und handelt sie im Prozess, oder sie schlummern auf immer ewig und warten auf den Sankt. Nimmerleins Tag...

 

Cosy