9/11 Pentagon

thevienna2011 schrieb:okay...also ich sehe schon, es besteht ein grosses manko an vorstellungsvermögen und mathematisches wissen.

thevienna2011 schrieb:sind 88 -89 meter die wir in 2 sekunden zurücklegen müssen.

das sind bei 88 meter / 13.8 meter * 2 = über 3 mal...also 3 x 50 kmh
sind 150 kmh sinkgeschwindigkeit.....anders erklärt...wir kommen mit einem auto mit 150 oder mehr kmh
in 2 sekunden zu stehen...stellt euich die kräfte vor.

diese kräfte soll eine 757 aushalten????
abgesehen davon....nichts zeigt im FDR mehr an wie 1.75 G in der letzen sequenz

autsch.

Tut mir leid aber deine Rechnung ist total daneben.

Du schließt von der Sinkgeschwindigkeit auf die Beschleunigung, denn nichts anderes sind G Kräfte. Das ist ein ganz grober Fehler. Du kannst schnell sinken/steigen und dabei trotzdem keine Beschleunigung erfahren. Man kann einen Loop fliegen ohne dass dabei der Kaffeebecher von der Tischkante fällt.

Die G Kräfte werden erst dann frei wenn die Verzögerung eintritt. Wenn das Flugzeug also den Boden rammt. Erst da werden die Kräfte aus der Geschwindigkeit frei.

also mal eine andere perspektive die ich aufwarf....wie sieht eigentlich der FDR der UA93 aus, welche auch eine boeing 757 war...??
hier die antwort....

vienna:
since you told us that B757 UA93 didnt had a sensor at the flight-deck-door, it would be interesting which parameter (if) was written to the FDR.

P4T:
Nothing was written to the FDR regarding the FLT DECK DOOR on United 93. It does not exist in the "UA93" data. This is because United Airlines did not have a FLT DECK DOOR sensor installed.

also im FDR der UL93 war kein parameter FLT DECK DOOR vorhanden.
was sagt uns das?
dass ein sensor vorhanden sein muss, wenn ein FDR einen wert schreibt, oder aufzeichnet.
oder seh ich das falsch?

agreschk schrieb:Die G Kräfte werden erst dann Frei wenn die Verzögerung eintritt. Wenn das Flugzeug also den Boden rammt. Erst da werden die Kräfte aus der Geschwindigkeit frei.

das seh ich absolut so.....deshalb auch miene aussage...abbremsen auf fast 0 von 150 kmh innerhalb 2 sekunden.

thevienna2011 schrieb:das seh ich absolut so.....deshalb auch miene aussage...abbremsen auf fast 0 von 150 kmh innerhalb 2 sekunden.

dann muss ich dich falsch verstanden habe. Gebremst wurde die Maschine doch aber erst beim Aufprall.

agreschk schrieb:dann muss ich dich falsch verstanden habe. Gebremst wurde die Maschine doch aber erst beim Aufprall.

hier geht es darum ein wenig verständlich zu machen was passierte.

da war die maschine 2 sekunden vor aufprall in einer höhe von 91 meter. (ca.)
der einschlagspunkt lag so um die 1,2,3 meter über grund.....wenn man das pentagon so ansieht.

also....die maschine muss rund 88 meter sinken, damit sie die mauer am pentagon trifft.
wie schnell muss sie sinken? sie hat 2 sekunden zeit um von 88 meter aus 2,3 meter zu kommen.

meine berrechnung sind das auf kmh gerechnet....150 kmh mindestens.

nun war die maschine, laut offiziellen aussagen, fast auf level flug...was heisst sie ist nicht gesunken beim einschlag, da ja das fundament keinen einschlag zeigt. dies ist übrigens die offizielle version...die maschin ist leveled reingeflogen!

nun, wenn die maschine nun mit 150 kmh sinkt und dann auf level sein muss beim einschlag, dann muss dort genau die sinkgeschwindigkeit wieder bei rund 0 kmh sein....und was das dann ist, ist eben die querbeschleunigung...sind die G kräfte die wirken, wenn du von 150 kmh innerhalb 2 sekunden auf quasi 0 kommst.

wie gesagt hier geht es NUR um die SINK-geschwindigkeit..!

@kurvenkrieger

kurvenkrieger schrieb: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?

Das heisst ja nicht, dass die NTSB oder American Airlines diese Daten nicht dekodieren können. Das bedeutet nur, dass p4t dazu offensichtlich nicht in der Laage sind die Rohdaten selbstständig zu dekodieren, obwohl sie alles was sie dafür benötigen haben. Wie genau sie dekodiert werden steht im NTSB Abschlussbericht.

Ich finde es ist wichtig zu unterscheiden worauf man sich bezieht.

1. Es gibt einmal die kodierten Rohdaten, welche nicht ohne weiteres lesbar sind.
2. Dann gibt es die von der NTSB dekodierte CSV Daten
3. Und letztendlich gibt es den NTSB Abschlussbericht wo nur Plots zu sehen sind.

Den NTSB Bericht habe ich angeschaut und keine Ungereimtheiten feststellen können. Sämtliche Höhenmesser stehen im letzen Moment auf 0. Die Rohdaten und CSV konnte ich ausserhalb von p4t nicht finden. Vielleicht könnte jemand die Primärquelle posten. Denn ich habe bis jetzt immer noch keine abweichende oder nicht plausible Daten gesehen. Wo genau steht der Wert mit den 277 fuss? Jedenfalls nicht im Abschlussbericht der NTSB.

es gibt mehr als nur eine ungereimtheit.

1. keine id's in der initialisierung des FDR.
2. wenn die daten aus der N644AA sind, warum gibt es GPS werte, wo die maschine keine hatte?
3. wenn die daten aus der n644AA sind, wieso ist die cockpit tür nicht geöffnet worden beim überfall?
(sensor war vorhanden)
4. wenn die daten aus der N644AA sind, und die NTSB hat die RADalt daten bestätigt, wie kann eine 757 so viel G kräfte ertragen ohne auseinander zu brechen?(mathematisch ganz simple nachzurechnen)

ich denke es gibt noch mehr fragen....muss mal auf die P4T seite und nochmals nachsehen.

@thevienna2011
ok, ich habe dich dann falsch verstanden. Ich glaube aber nicht, dass die Maschine vor dem Einschlag so krass abgefangen wurde. Die NTSB Plots zeigen jedenfalls einen geraden flachen Anflug bis zum ground.

Worauf bezieht sich deine Aussage? Wo stehen diese krassen Werte?

agreschk schrieb:Worauf bezieht sich deine Aussage? Wo stehen diese krassen Werte?

rechne es dir doch einfach selber aus....das ist eine ganz einfache rechnung.....
wir wissen wie hoch die maschine 2 sekunden vor einschlag war.
wir wissen in welcher höhe die maschine einschlug
und wir wissen, laut aussage der offiziellen behörden....das sie leveld...also nicht im sink und nicht im steigflug einschlug.

war auf 91 meter ca. und musste innerhalb 2 sekunden auf 2-3 meter runter kommen.
rechne dir die fall(sink) geschwindigkeit aus.....

@thevienna2011

thevienna2011 schrieb:wir wissen wie hoch die maschine 2 sekunden vor einschlag war.

Ich weiß es immer noch nicht. Wo steht denn das?

agreschk schrieb:Ich weiß es immer noch nicht. Wo steht denn das?

nimm das offizielle, von der NTSB zur verfügung gestellte CSV. dort steht die höhe drin (radar alt) welche die maschine als letzten wert hatte.
okay, laut NTSB gehen wir also hin und geben 2 sekunden delay noch dazu....also....
die höhe 272 fuss, welche dort steht, war also 2 sekunden vor einschlag.

272 fuss = ca. 91 meter

und nun rechne....

@thevienna2011
sorry, bei ntsb gibt es diese CSV Datei nicht. Ich kann sie jedenfalls nicht finden. Es gibt nur ein Abschlussbericht, und da steht die Höhe auf 0. Diese Datei finde ich nur bei p4t und anderen Verschwörungsseiten. Deshalb bettle ich die ganze Zeit um eine Primärquelle.

agreschk schrieb:sorry, bei ntsb gibt es diese CSV Datei nicht. Ich kann sie jedenfalls nicht finden. Es gibt nur ein Abschlussbericht, und da steht die Höhe auf 0. Diese Datei finde ich nur bei p4t und anderen Verschwörungsseiten. Deshalb bettle ich die ganze Zeit um eine Primärquelle

na ja....die daten bei P4T sind die daten welche NTSB bereit stellt. also offizielle und bestätigte daten. die manipulieren nichts herum...keine sorge.
und der wert 0 ist sicher auch stimmig....nur eben zum zeitpunkt des einschlages (ca.)
jedoch muss die maschine ja irgendwo ja auch höher geflogen sein.....und die 272 fuss sind bestätigt von der NTSB....als wert 2 sekunden vor einschlag.

ausserdem...ich denke es wäre eine reine freude für die NTSB und die offiziellen, wenn die P4T daten zur verfügung stellen wo sie sagen es seien originaldaten von der NTSB und diese dann manipulieren...denke die NTSB würde da sofort zuschlagen :-) das wäre urkunden fälschung.

@thevienna2011
naja ich kann mich halt nicht so einfach darauf verlassen, dass die NTSB tatsächlich die 272 fuss 2 Sekunden vor Einschlag bestätigte, nur weil P4T dafür die Hand ins Feuer legt. Wie kann ich mir denn sicher sein, dass P4T die CSV Daten auf Ihrer Seite nicht manipuliert haben? Das würde mich in der VT Szene nun wirklich nicht überraschen.

Das würde zu mindestens erklären warum NTSB am Telefon meinte, dass es nicht ihre Daten sind.

@thevienna2011
ich habe einen Experten für Flugunfalluntersuchungen kontaktiert. Ich würde es gern versuchen mit seiner Hilfe die Rohdaten selbstständig zu dekodieren. Die Ergebnisse würde ich dann hier vorlegen. Dazu brauche ich aber die original Datei und nicht eine, die von P4T als solche ausgegeben wird.

agreschk schrieb:ich habe einen Experten für Flugunfalluntersuchungen kontaktiert. Ich würde es gern versuchen mit seiner Hilfe die Rohdaten selbstständig zu dekodieren. Die Ergebnisse würde ich dann hier vorlegen. Dazu brauche ich aber die original Datei und nicht eine, die von P4T als solche ausgegeben wird

ich bin sicher du bekommst die daten direkt bei der NTSB. die haben die sicher.
im übrigen, würd mich auch interessieren was dein experte sagt wenn er in den rohdaten keine ID's findet...die beweisen, welches flugzeug diese daten schrieb

@thevienna2011
mag sein. Nur wüsste ich nicht wie ich die Anfrage begründen sollte. Sie würden sich einfach auf den veröffentlichten Abschlussbericht beziehen, und der scheint ja in Ordnung zu sein. Warum sollten sie mir also die Rohdaten zur Verfügung stellen? Objektiv gesehen habe ich keinen Anhaltspunkt, dass mit den Daten etwas nicht stimmen könnte, außer der Einwände der P4T denen ich aber nicht ohne weiteres trauen kann.

Sackgasse.

agreschk schrieb:mag sein. Nur wüsste ich nicht wie ich die Anfrage begründen sollte. Sie würden sich einfach auf den veröffentlichten Abschlussbericht beziehen, und der scheint ja in Ordnung zu sein. Warum sollten sie mir also die Rohdaten zur Verfügung stellen? Objektiv gesehen habe ich keinen Anhaltspunkt, dass mit den Daten etwas nicht stimmen könnte, außer der Einwände der P4T denen ich aber nicht ohne weiteres trauen kann.

ich denke mal, hier drüber zu vermuten und so ist sicher nicht das was dich weiter bringt.
ich würde an deiner stelle losgehen....NTSB anschreiben und fragen wie du zu den daten kommst.
dann wirst du sehen ob es klappt und wie.

@thevienna2011

thevienna2011 schrieb:sinn würde es auch ergeben, dass eigentlich IMMER nur systeme gelesen werden, die auch installliert sind, und der rest nicht.
wäre auch eine möglichkeit......

Wie soll das Nicht-Lesen aussehen? Im Datenformat des FDR ist schließlich weiterhin ein Bit für den GPS-Status vorgesehen.

Zäld

zaeld schrieb:Wie soll das Nicht-Lesen aussehen? Im Datenformat des FDR ist schließlich weiterhin ein Bit für den GPS-Status vorgesehen.

es würde wie folgt aussehen....
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.

ergo:
es gab keinen sensor....es wurden keine daten geschrieben, nicht mal default daten :-)

war aber auch eine auch eine boieng 757/200.

2 identische (ziemlich) maschinen, 2 verschiedene datenstrukturen.
ich, und das kann natürlich jeder halten wie er will, gehe mal davon aus, wenn default werte in FDR gelesen werden dann für alle. aber dass AA77 türsensor werte hat und ua93 nicht, sagt mir, dass diese daten geschrieben werden, aber nur dann, wenn sie auch da sind.

aber....nähern wir uns nun dem thema cockpit tür erneut, dann haben wir denke ich viel mehr fragen als ob sie da war oder nicht :-)

@thevienna2011
Na toll, da würde ich also sagen, ich hätte die Daten von irgendwelchen Dritten. Dann können sie wieder sagen, dass sie für diese Daten keine Verantwortung übernehmen und dass alles relevante bereits im Abschlussbericht steht. Und damit können sie jede Klage abschmettern weil keine Grundlage besteht.

Um am Abschlussbericht vorbei zu kommen braucht man schon einen sehr guten Grund. Und der fehlt mir einfach.

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

Valide bedeutet gültig, und nicht unbedingt plausibel. Als Computerfachmann solltest du mit dem Begriff "Parität" etwas anfangen können.

Daher wird "validated" viel eher bedeuten, dass die Quersumme der einzelnen Bits für ein bestimmtes Parameter durch alle Frames stimmt. Mit anderen Worten, der Wert ist lesbar und konnte dekodiert werden. Das würde aber noch lange nicht bedeuten, dass der Wert auch fehlerfrei gemessen bzw. errechnet wurde.

Und ein weiterer Punkt.
Wir reden hier über einen seriellen Datenstrom welcher in Frames bestimmter Bitlänge aufgeteilt ist. Manche Parameter ließt der Rekorder in regelmäßigen Abständen von den Instrumenten ab. Andere kommen per Interrupt vom Bordcomputer. Die Abstände der Mess- und Signalpunkte können aber länger sein als ein Frame. Wenn der Rekorder ein bestimmtes Parameter nur alle 20 Sekunden speichert, dann wird er nicht in allen Frames vorhanden sein.

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.