9/11 Pentagon

thevienna2011 schrieb:dem kann ich sogar zustimmen

Damit können wir die Diskussion um FRT DECK DOOR und GPS wohl als abgeschlossen betrachten. Beide Parameter sind unter "not working or unconfirmed" und somit korrumpiert und irrelevant.

Branntweiner schrieb:Damit können wir die Diskussion um FRT DECK DOOR und GPS wohl als abgeschlossen betrachten. Beide Parameter sind unter "not working or unconfirmed" und somit korrumpiert und irrelevant.

ich würde sogar vorschlagen der ganze FDR ist irrelevant.
er beweist abolut nichts. nichts verwertbares.

thevienna2011 schrieb:ich würde sogar vorschlagen der ganze FDR ist irrelevant.

Oh nein! Es gibt "working parameters". Sprich: dem FDR konnten auch relevante Daten entlockt werden.

Branntweiner schrieb:Oh nein! Es gibt "working parameters". Sprich: dem FDR konnten auch relevante Daten entlockt werden.
.

ja aber 2 parameter fehlen um zu sagen wem diese parameter zugeordnet werden sollen...

Branntweiner schrieb:Damit können wir die Diskussion um FRT DECK DOOR und GPS wohl als abgeschlossen betrachten. Beide Parameter sind unter "not working or unconfirmed" und somit korrumpiert und irrelevant.

D´accord.
Wie würdest Du diese Aussage zur Inkompabilität der Systeme kommentieren?

DATA FRAME LAYOUT

Pilots For 9/11 Truth have been provided several files through the FOIA. One file in particular, a raw Flight Data Recorder file which is described as a direct download from the FDR, contains binary code which needs to be decoded for a proper readout in a spreadsheet such as Excel. In order to decode such data, a Data Frame Layout is required. Derived from a generic Boeing Data Frame Layout, American Airlines provided it's own custom made Data Frame Layout which was designed for decoding data from aircraft within the American Airlines fleet, based on airline needs exclusive to American Airlines (AAL). The custom made AAL Data Frame Layout was unable to decode the data in full, and in some instances, neither the AAL Data Frame Layoyut nor the generic Boeing Data Frame Layout were able to be utilized in decoding the data(3). Why would American Airlines design their own custom Data Frame Layout if it cannot decode data from their aircraft? Or perhaps the data being provided is not from an American Airlines jet?


Wie ist diese Aussage zu werten? Aus rein logischen Erwägungen hinsichtlich der Arbeitsoptimierung, bzw. des Workflows, würde eine inkompatible Kodierung natürlich keinen Sinn machen.

Beitrag von kurvenkrieger (Seite 370)

1234proximus schrieb:War doch eine Fed ex Frachtmaschine wenn ich mich nicht irre... Die war glaube ich vom Firmensitz aus gestartet. Und der Selbstmörder hatte die Sicherung für den Voice Recorder rausgedreht... Kann man für den FDR überhaupt die Sicherung rausnehmen?

Ja, kann sein, daß es um den CVR ging. Die Geschichte lagert gerade etwas weiter hinten in meinem Gehirn... aber mir ist so, als wäre es ein Passagierflug gewesen, bin bin mir aber auch nicht sooo sicher.

Auch bei mir ist jetzt Feierabend.

Zäld

@kurvenkrieger

kurvenkrieger schrieb:Wie ist diese Aussage zu werten? Aus rein logischen Erwägungen hinsichtlich der Arbeitsoptimierung, bzw. des Workflows, würde eine inkompatible Kodierung natürlich keinen Sinn machen.

Da ich kein Flugschreiberdatenretter bin, kann ich diese Aussage der P4T mal nicht bewerten.

Die Rohdaten aus dem Flugschreiber dürften die sein, die ich in meinem Blog gelinkt habe und die gestern von P4T gelinkt wurden. Der Header zeigt bei mir in einem HexEditor die Kennung der Firma, welche den Flugschreiber hergestellt hat. Weitere Programme zum Auslesen sind nicht in meinem Besitz.

Das Data Frame Layout von AA müsste das sein, das Stutt online hat, es kommt von NTSB und P4T hat gestern hier bestätigt (via thevienna2011), dass es genau das Layout ist, das für den Bautyp der Maschine gültig ist.

Jetzt haben P4T und Stutt unabhängig voneinander die Rohdaten ausgelesen und beide sind zu mehr Daten gekommen als NTSB in ihren ausgelesenen Daten gekommen ist (das sind Dateien mit der Endung .csv und in einem Tabellenkalkulationsprogramm lesbar).

P4T krallen sich an ausgelesenen Daten für die Kabinentür und das GPS fest, deren Werte von NTSB aber als "not working" eingestuft sind.

Stutt hat vier Sekunden mehr ausgelesen als NTSB, und diese Datenauslesung würde mit dem Schadensbild am Pentagon übereinstimmen.

Seitdem befetzen sich P4T und Stutt.

Dazu kommt, dass ein Computerwissenschafter der Northeast University Boston namens Will Clinger sich auf die Seite Stutts geschlagen hat und den P4T grobe mathematische Mängel unterstellt.

Womit deine Frage mit Ja beantwortet werden könnte: es ist im Bereich des Möglichen, dass aus den Rohdaten noch mehr ausgelesen werden kann, für mich bleibt die Frage, wie zuverlässig diese Daten sind.

Die NTSB bzw. diejenigen, die Flugschreiberdaten auswerten und deren Hauptaufgabe im Normalfall ist, Flugunfälle auf Basis von FDR-Daten zu analysieren, werden vermutlich nur die Daten eines FDR heranziehen, die auch gerichtsfest sind, also Daten, von denen sie zu 100% überzeugt sind, dass sie nicht korrumpiert sind. So meine Ausgangsthese.

Keine Ahnung, ob das hier schon gepostet wurde, vielleicht ist es ja für irgendjemandem von Nutzen:

http://www.ntsb.gov/doclib/manuals/FDR_Handbook.pdf (Archiv-Version vom 18.02.2013)

dh_awake schrieb:Keine Ahnung, ob das hier schon gepostet wurde, vielleicht ist es ja für irgendjemandem von Nutzen

Danke! Sehr cool.

Branntweiner schrieb:Womit deine Frage mit Ja beantwortet werden könnte: es ist im Bereich des Möglichen, dass aus den Rohdaten noch mehr ausgelesen werden kann, für mich bleibt die Frage, wie zuverlässig diese Daten sind.

Die NTSB bzw. diejenigen, die Flugschreiberdaten auswerten und deren Hauptaufgabe im Normalfall ist, Flugunfälle auf Basis von FDR-Daten zu analysieren, werden vermutlich nur die Daten eines FDR heranziehen, die auch gerichtsfest sind, also Daten, von denen sie zu 100% überzeugt sind, dass sie nicht korrumpiert sind. So meine Ausgangsthese.

Danke für Deine Ausführungen.
In Anbetracht Deiner Hypothese zur Daten"konsistenz" müsste man ja auch davon ausgehen, daß sie tatsächlich korrekte Flugdaten aufweisen, und daß damit die Diskrepanzen wie Höhendifferenz etc. vorerst als merkwürdige Tatsache abgehakt werden können.
Da wir scheinbar alle keinen Plan von den Details haben, könnte man das jetzt ebenfalls getrost ausklammern um sich auf den nächsten zu Punkt stürzen.
Was fangen wir mit dieser merkwürdigen Aussage hier an:
In order to decode such data, a Data Frame Layout is required. Derived from a generic Boeing Data Frame Layout, American Airlines provided it's own custom made Data Frame Layout which was designed for decoding data from aircraft within the American Airlines fleet, based on airline needs exclusive to American Airlines (AAL).
http://pilotsfor911truth.org/no-hard-evidence-aa77.html
Also unabhäng vom Inhalt der Daten: warum muß überhaupt ein Stutt irgendwas basteln, damit die Daten ausgelesen werden können? Seit wann sind die von Boeing gestellten Tools mit ihren eigenen Flugschreibern inkompatibel?
Versteh ich da irgendwas falsch?

Auch nicht schlecht:
http://www.faa.gov/documentLibrary/media/Advisory_Circular/AC%2020-141B.pdf (Archiv-Version vom 02.11.2013)


Auf der Seite kann man einiges finden:
http://www.faa.gov/regulations_policies/advisory_circulars/index.cfm/go/document.information/documentID/321002

@kurvenkrieger

kurvenkrieger schrieb:warum muß überhaupt ein Stutt irgendwas basteln, damit die Daten ausgelesen werden können?

Mit Stutt habe ich mich noch nicht auseinandergesetzt, wie er genau vier Sekunden mehr auslesen konnte. Ich kann mich nur so erinnern, dass er eine eigene Auslese-Software geschrieben haben soll. Das Data Frame Layout hat er von NTSB genommen, da hat er nicht gebastelt. Wenn ich mich jetzt richtig erinnere.

Recht viel anders als P4T dürfte es nicht sein, die sagen ja auch, dass in den Rohdaten mehr Infos steckt, als die .csv-Dateien von NTSB zeigen.

P4T: da ist noch Tür und GPS und RADALT ... der Flug war anders als gesagt wird
Stutt: da sind noch 4 Sekunden ... die beweisen den Crash ins Pentagon

Der Rest ist Streit.

@Branntweiner
Doch, er hat da was getuned:

Although the NTSB provided CSV files generated from the FDR file which were also included on the CDROMs, I have created this program so that parameters can be selectively included in the CSV files resulting in files with fewer columns and also to decode some information not included in the NTSB CSV files.

I have only included some parameters in this program. However there are many more listed in the NTSB's American Airlines Flight 77 FDR Report and in the data frame layouts in the attachments. Let me know if there are any more which you would like to see included.

In the interests of transparency in showing that the program is really generating its output from the raw FDR file, you can download the C# source code...

http://www.warrenstutt.com/AAL77FDRDecoder/index.html

Nur versteh ich nich ob jetzt die NTSB-gestellte Variante auch die gestellten CSV-Daten rauswarf, oder warum die "Parameterjustierung" tatsächlich nötig war.
Woher beziehen P4911 jetzt ihre Aussage:
The custom made AAL Data Frame Layout was unable to decode the data in full, and in some instances, neither the AAL Data Frame Layoyut nor the generic Boeing Data Frame Layout were able to be utilized in decoding the data(3).

Das würde ich einfach gerne nachvollziehen/ verifizieren können. Oder brauchen wir dafür tatsächllich Fachleute, die mit den Daten was anfangen können?
Es müsste doch Referenzfälle geben, waren die Daten vl. schon öfter nich zufriedenstellend mit den gestellten tools auslesbar? Das müsste sich doch prüfen lassen?

@thevienna2011

thevienna2011 schrieb:ich würde sogar vorschlagen der ganze FDR ist irrelevant.
er beweist abolut nichts. nichts verwertbares.

Oh endlich!!! Herzlichen Glückwunsch zu dieser Erkenntnis!
Immerhin bist du nach gefühlten 100 Seiten selbst zu dieser Erkenntnis gekommen, ist ja nicht so das einige hier das schon vorher mehrfach geschrieben haben. :-)

Ich hoffe damit können wir jetzt das Thema FDR als geklärt zur Seite legen.
Sonst noch offene Fragen? :-)

@thevienna2011

Wie ich sehe hast du dein "ichignorierealleswasmirnichtpasst" Stil immer noch nicht abgelegt :)

"und wenn du eine APU hast die den flieger mit allem versorgt was du brauchst, musst du nicht vor dem PB die engines starten."

Du hast also schon wieder ignoriert das der Pilot die Triebwerke startet um zu überprüfen ob sie einwandfrei funktionieren :-D
Bei Air Berlin ist es inzwischen sogar verboten die APU zu benutzen um Sprit zu sparen. Es dürfen nur die Generatoren benutzt werden ;)

Wenn du in den Urlaub fliegst bekommst du mit was der Pilot an den Tower funkt? Nicht schlecht... Achja: wenn er durchgibt ready to Push and Start ist der Start des Flugzeugs gemeint nicht der, der Triebwerke. Der Pilot muss nämlich frühzeitig Bescheid geben ob er seinen Slot halten kann ;)

Uuuuund: Sobald jemand an einem Flieger zu tun hat ist da immer Strom drauf. Ohne geht da nämlich nix!
Flieger landet und kommt in Parkposition, Generator oder APU an, Passagiere steigen aus, Gepäck wird ausgeladen, fliegendes Personal erledigt abschließende arbeiten, LFZ wird gereinigt, im Bedarfsfall sehen sich Techniker das LFZ an, Bodenpersonal macht das LFZ wieder startbereit (Sprit, Wasser, essen usw.) neue Crew kommt an Bord und beginnt mit der Checkliste, Passagiere steigen ein, Gepäck wird verladen, Triebwerke werden gestartet und überprüft, ready for Push and Start, LFZ wird in Rollrichtung geschoben, fährt zur Startbahn, hebt ab... Es landet fährt in Parkposition und alles beginnt von vorn.

So lange keine Wartung und längere Standzeit vorgesehen ist steht ein LFZ immer unter Strom und die Geräte zeichnen auf!

Dein boot und zeichnen nur bei turbinenstrom auf ist doch nur wieder eine Behauptung weil du wie üblich uuuuunbedingt recht haben willst :)

Eine Erklärung warum niemand mitbekam dass nicht die Piloten sondern Hijacker im Cockpit gewesen sein sollen hast du auch schon wieder "vergessen" ;) oder kommt da jetzt wieder die Ausrede der "aufgezwungenen Prioritäten" ;)

Dein Vorgehen ist so leicht zu durchschauen :)

@1234proximus
danke für deine erklärungen. ich werde diese bis gegen abend/späten abend kommentieren. im moment hab ich nicht so viel zeit im büro.

@zaeld

Die Maschine war damals Fed Ex Flug 705 von Memphis nach San José. Am 7.4.1994. Eine DC10 Frachtmaschine. Da gibt es übrigens ein paar interessante Details... Um den Entführer kampfunfähig zu machen flog der schwer Verletzte Co-Pilot auf dem Kopf und ging dann in den Sturzflug. Also ein manöver wie ua93. Dabei erreichte die Maschine fast Schallgeschwindigkeit und brach nicht auseinander.
Pilot, Co-Pilot und der Hijacker waren ehemalige Militärflieger. Der Pilot hatte einen gebrochenen Schädel und war halbseitig gelähmt... Trotzdem schaffte er es die DC10 die für eine Landung noch 16 Tonnen zu schwer war, nach einer 90 grad Kurve und einer 180 grad Kehre mit viel zu großer Geschwindigkeit (382 km/h) sicher zu landen - ich finde es faszinierend wie viele "Unmöglichkeiten" möglich werden wenn es nicht anders geht.

Zu dem schaffte es der eine Entführer um ein Haar 3 Personen im Cockpit auszuschalten... Ohne Messer! Nur bewaffnet mit einem Hammer.

@1234proximus
jaa davon habe ich in der Zeitung gelesen. Ich fand das damals so krass, konnte das gar nicht glauben.

1234proximus schrieb:Die Maschine war damals Fed Ex Flug 705 von Memphis nach San José. Am 7.4.1994. Eine DC10 Frachtmaschine.

Das meinte ich nicht. Es war ein Flug, bei dem der Verdacht besteht, daß der Pilot Selbstmord beging, und in Vorbereitung dazu den CVR per Sicherung abschaltete. Definitv irgendwo im fernen Osten, Thailand oder weiter östlich.

Mal sehen, ob ich dazu was finde.

Zäld

@zaeld

Sorry hab ich vergessen. Der Selbstmörder hat vor dem Start mehrfach versucht die Sicherung für den Voice Recorder rauszunehmen. Es sollte ja. Wie ein Unfall aussehen wegen der Lebensversicherung. Es fiel dem bordingenieur aber immer wieder auf und er drückte die Sicherung immer wieder rein.