9/11 Pentagon

agreschk schrieb:Ein weiterer Punkt was ich ansprechen wollte ist die Bestätigung der NTSB. Wenn die NTSB sagt dass bestimmte Parameter "validated" sind was heißt das überhaupt? Heißt es dass man sich darauf verlassen muss dass die Werte als plausibel zu betrachten sind? Ich denke nicht...

wenn ein wert als validated geführt wird...ist er verifiziert und somit bestätigt.

agreschk schrieb: Wenn der Rekorder ein bestimmtes Parameter nur alle 20 Sekunden speichert, dann wird er nicht in allen Frames vorhanden sein.

ich nheme an wir reden dann hier im millisekunden bereich. wenn so kritische daten geschrieben werden sollen, dann werden diese (wie RADalt) alle 0.125 sekunden geschrieben.
(auf annahme, dass 1 frame = 1 sekunde)

agreschk schrieb:Es wäre denkbar, das der letzte CSV Wert für RadarAlt nicht aus dem letzten Frame sondern aus einem davor stammt, also einige Sekunden vorher aufgezeichnet wurde. Man müsste wissen in welchem Abstand die RadarAlt Werte gespeichert wurden, und ob der letzte Wert im letzen Frame steht oder nicht.

wie du wiollst, aber bist dir bewusst, dass die höhe dann eher immer mehr wird statt weniger....die rechnung bleibt immer die selbe.

thevienna2011 schrieb:wenn ein wert als validated geführt wird...ist er verifiziert und somit bestätigt.

das meinst du vielleicht. Valide bedeutet allgemein nur dass der Wert gültig ist. Also innerhalb des erlaubten Werte- und Definitionsbereichs. Wenn der Rekorder eine Geschwindigkeit von 0 aufgezeichnet hätte, wäre das ein gültiger Wert. Wenn bei der Aufzeichnung ein Paar Bits verloren gegangen wären, dann wäre der Wert nicht lesbar, oder im schlimmsten Fall lesbar aber falsch (weil bits verschoben sind).

Aus diesem Grund validiert man solche Datenströme indem man eine Paritätsprüfung durchführt welche dann aussagt ob die Werte innerhalb des Stroms gültig oder für die Tonne sind.

du kannst genre selber nachrechnen.
http://pilotsfor911truth.org/forum/index.php?showtopic=7163&st=40 (Archiv-Version vom 31.08.2013)

das video ist ziemlixch inder mitte der seite.
und vor allem....sie sagen am anfang, sie arbeiten mit den offiziell zur verfügung gestellten und freigegebenen daten der NTSB!

agreschk schrieb:das meinst du vielleicht. Valide bedeutet allgemein nur dass der Wert gültig ist. Also innerhalb des erlaubten Werte- und Definitionsbereichs. Wenn der Rekorder eine Geschwindigkeit von 0 aufgezeichnet hätte, wäre das ein gültiger Wert. Wenn bei der Aufzeichnung ein Paar Bits verloren gegangen wären, dann wäre der Wert nicht lesbar, oder im schlimmsten Fall lesbar aber falsch (weil bits verschoben sind)

wenn es haisst, the values are valideted by the NTSB...dann hat die NTSB sie validiert und nicht als
missing, false oder not working betitelt.
also sind diese zumindest nicht..... not valid, not working, not found...etc....

thevienna2011 schrieb:wenn es haisst, the values are valideted by the NTSB...dann hat die NTSB sie validiert und nicht als
missing, false oder not working betitelt.

also für mich heißt es nur, dass der Wert gültig und kein Datenschrott ist mit dem man nichts anfangen kann. Darauf kann man sich höchstens einbilden dass der Rekorder den Wert genauso aufgezeichnet hat. Aber auf keinen Fall, dass der Wert auch korrekt ermittelt oder berechnet wurde.

@thevienna2011

thevienna2011 schrieb:wie bei der FDR der 757 der UA93......die hat keine werte der cockpit tür sensoren im FDR.
und warum?
weil sie keine sensoren hatte.

Du willst also ernsthaft vorschlagen, für jedes Flugzeug ein eigenes FDR-Datenformat zu kreieren, damit es auf die jeweilige Konfiguration des Flugzeuges paßt?

Angenommen, das Flugzeug ist zunächst nicht mit GPS ausgestattet und hat dementsprechend ein Datenformat, in dem der Status nicht vorkommt.

Nun rüstet man das Flugzeug mit GPS nach. Also muß man nun auch noch das Datenformat wieder umändern.

Hälst du das für praktikabler als ein allgemeines Datenformat zu nehmen, das bei fehlendem System einfach einen nichtssagenden Wert aufzeichnet, nur damit Herr Vienna zufrieden ist?

Zäld

zaeld schrieb:Du willst also ernsthaft vorschlagen, für jedes Flugzeug ein eigenes FDR-Datenformat zu kreieren, damit es auf die jeweilige Konfiguration des Flugzeuges paßt?

der vorschlag ist an und für sich korrekt! nenne wir es "Sollteland"

Wirtschaftlich und damit Aufwandstechnisch geht das nicht, deshalb gibt es Standarts die Standarts heißen...

@thevienna2011
wenn ich das richtig verstanden habe, beziehen sich die P4T auch nur die CSV Datei und nicht auf die Rohdaten.

Wie können sie dann Aussagen darüber treffen wann welcher Wert aufgezeichnet wurde? Die CSV hat keine timestamps, die sind nur in den Rohdaten vorhanden. Der letzte Wert für die Höhe könnte genauso gut auch 10 Sekunden vor dem Aufschlag gemessen worden sein, stand die ganze Zeit in der record queue und wurde erst kurz vor dem Aufschlag aufgezeichnet.

Je mehr ich mich damit beschäftige um so mehr sieht es danach aus, als ob P4T nicht wirklich Ahnung von den Dingen haben worüber sie reden.

zaeld schrieb:Du willst also ernsthaft vorschlagen, für jedes Flugzeug ein eigenes FDR-Datenformat zu kreieren, damit es auf die jeweilige Konfiguration des Flugzeuges paßt?

im gegenteil...nein....es werden sicher so zeimlich alle daten ausgelesen die man auslesen kann.
nur eines ist auch tatsache....
der UA93 FDR hat absolut keine daten geschrieben für die FLT DECK DOOR.
weder default daten noch irgendwas....ja sogar der name des parameters ist nicht vorgekommen.

agreschk schrieb:wenn ich das richtig verstanden habe, beziehen sich die P4T auch nur die CSV Datei und nicht auf die Rohdaten.

die CSV daten welche die NTSB GEFLIEFERT HAT!!!!
ist das genug?

thevienna2011 schrieb:der UA93 FDR hat absolut keine daten geschrieben für die FLT DECK DOOR.
weder default daten noch irgendwas....ja sogar der name des parameters ist nicht vorgekommen.

Dann war der Parameter in diesem Datenformat eben nicht vorgesehen, oder das NTSB hat diese Daten gefiltert.

Wenn im Datenformat aber ein Wert vorgesehen ist, dann muß da ein Wert stehen. Das sollte dir als Programmierer doch klar sein. Es gibt keine Nicht-Werte.

Zäld

thevienna2011 schrieb:die CSV daten welche die NTSB GEFLIEFERT HAT!!!!
ist das genug?

eben nicht. Zunächst kann man sich darauf nicht verlassen dass es tatsächlich so ist. P4T mögen das behaupten, aber auf der NTSB Seite habe ich weder eine CSV Datei noch die Rohdaten gefunden. Im Telefonat von P4T sagt ein Mitarbeiter von NTSB auch dass die NTSB damit nichts zu tun hat und dass alles was sie veröffentlicht haben auch auf ihrer Seite zu finden ist. Wer weis, vielleicht stimmt das sogar?

Wer hat also diese CSV erstellt auf die sich P4T beziehen? Man weis es nicht.

Und nochmal zurück. Die CSV Datei auf die sich P4T beziehen enthält keine Timestamps. Es ist also unbekannt wann der letzte Eintrag für RadALT gemessen wurde und ob noch weitere Werte in der Queue waren welche aber nicht mehr geschrieben werden konnten weil die Maschine abgestürzt war. Diese Timestamps könnte man aus den Rohdaten entnehmen, doch wurden diese, meines Wissens auch nie veröffentlicht.

Die Zweifel die von P4T hervorgebracht werden, haben also keinerlei Grundlage. Keiner weiß worauf sie sich konkret beziehen und woher diese Daten tatsächlich stammten. Vielleicht ist das der Grund warum P4T die NTSB noch nicht verklagt hat?

zaeld schrieb:Dann war der Parameter in diesem Datenformat eben nicht vorgesehen, oder das NTSB hat diese Daten gefiltert.

Wenn im Datenformat aber ein Wert vorgesehen ist, dann muß da ein Wert stehen. Das sollte dir als Programmierer doch klar sein. Es gibt keine Nicht-Werte.

korrekt
aber dass dann der wert nicht von einem vorhandenen system kommt, sondern ein default wert sein muss, ist schlichtweg eine simple annahme und somit spekulation.

wenn die piloten sagen, es waren cockpit tür sensoren an board und es gab kein GPS, dann wird es mal so sein.
die müssen es wissen....wir nicht.

und noch etwas....bezüglich kaputte daten oder falscher daten....
VOR jeden flug macht der FDR einen self test....ist irgendetwas nicht i.O. geht der flieger nicht in die luft...sprich....die daten waren alle korrekt und sytseme wurden korrekt gelesen!!!

wenn die piloten sagen, es waren sensoren an board und es gab kein GPS, dann wird es mal so sein.
die müssen es wissen....wir nicht.

das stimmt ja auch vielleicht. Man weis halt nur nicht, ob die CSV Daten authentisch sind. Ich habe nirgends die NTSB sagen hören:
"hier sind die CSV Daten und wir garantieren, dass sie so stimmen."

agreschk schrieb:das stimmt ja auch vielleicht. Man weis halt nur nicht, ob die CSV Daten authentisch sind. Ich habe nirgends die NTSB sagen hören:
"hier sind die CSV Daten und wir garantieren, dass sie so stimmen."

P4T sagt, dass sind die csv daten von NTSB.....
jetzt sag ich nur eines.....bevor du was aussagst denk mal über das wort urkundenfälschung nach.
das nämlich wäre der tatbestand wenn du ein amtliches dokument veränderst und es dann als authentisch titulierst!!!
und jemanden das vorzuwerfen, kann konsequenzen haben.....

thevienna2011 schrieb:.bevor du was aussagst denk mal über das wort urkundenfälschung nach.
das nämlich wäre der tatbestand wenn du ein amtliches dokument veränderst und es dann als authentisch titulierst!!!

Hoffentlich wissen die Leute von P4T das auch ^^

Galaxys81 schrieb:Hoffentlich wissen die Leute von P4T das auch

zwar tut dies absolut nichts zur sache...aber ich nehme an das tun sie.

@thevienna2011
Warum denn? Stören ein Paar Spinner aus dem Netz die sich für Experten ausgeben etwa? NTSB gerät dadurch nicht unter öffentlichen Druck. Sie können sich wunderbar auf ihren Abschlussbericht beziehen und jeden Zweifel damit abschmettern, dass die Originaldaten nie veröffentlicht wurden. Daher sind die jämmerliche Versuche seitens P4T die NTSB in den Dreck zu ziehen haltlos und einfach nur peinlich.

agreschk schrieb:Warum denn? Stören ein Paar Spinner aus dem Netz die sich für Experten ausgeben etwa?

na ja, sie stören weder, als auch bewegen im moment.
aber die P4T leute (die piloten, ingeneure, experten..etc...) als spinner hinstellen.
na ja, wie du willst ist deine meinung. und du musst es nicht mal untermauern.

agreschk schrieb:Daher sind die jämmerliche Versuche seitens P4T die NTSB in den Dreck zu ziehen haltlos und einfach nur peinlich

auch das ist ein vermutung deinerseits, die absoluten keinen halt hat. zeig uns bitte mal einen beweis, der aussagt, dass P4T die NTSB nur in den dreck ziehen will?

soweit ich es noch weiss, seid ja grad ihr einem laien auf den leim gegangen. dieser laie dachte er könne es besser als die NTSB....die NTSB hat nie auch nur ein statement des Warren....irgendwas, bestätigt!