• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

AA77 FDR Data, Explained

Apologies for not replying sooner. Real world deadlines and now even some hardware problems are keeping me away.

This is what I'm talking about, Turbofan. This graphics from Douglas' presentation proves that PffT's (and by inheritance yours) insistance on 500ms is wrong.



Their own data. Their own analysis. Their own guy! And now you come here, proudly showing off multiple lines, hooks and sinkers embedded into your throat. Why? Didn't you find anything wrong with that analysis by Douglas? Don't you think there is a very simple step missing? So simple, that it had to have been omitted by choice? Douglas is not as dumb as some of the other PffT leaders (which shall remain bibless).

Even if we take their magical "2 seconds at most" (BTW, the 2s for which they have failed to present any logical explanation either), even if we allow a 2000feet error for Douglas' analysis, the data still doesn't fit. The plane is still at very best 2.5s away from the Pentagon, but, according to Douglas' very own method, it's much more likely that it was about 4-6s out. Have you ever wondered why hasn't snowygrouch expanded on that? He did the analysis, he's got the method, why didn't he show the details?

And now you harp on about the infallable animation. Tell me Turbofan, if NTSB animations are produced automatically from FDR data (like PffT would have you believe - yup, just another one of them hooks in your throat), there shouldn't be any NTSB animations that were ever wrong or in need of corrections, right? What would you say, if I presented such a case?

An NTSB animation that had to be corrected during the investigation. It's not related to 9/11 (except for the NTSB, of course). Unlike 9/11 investigation, this one was not taken over by FBI, so NTSB had some more time to refine their findings. According to you, such an event is impossible, is it not?
 
The sad part of all of this is I already know their response. They are going to accuse me of calling L3 a liar and/or pretending I know more than the manufacturer of the thing, and that's it. Neverminding that it's an incredibly subtle mistake that I'm alleging.. something I'm not sure any guy answering the phone might catch when quickly answering questions.
 
Last edited:
The sad part of all of this is I already know their response. They are going to accuse me of calling L3 a liar and/or pretending I know more than the manufacturer of the thing, and that's it. Neverminding that it's an incredibly subtle mistake that I'm alleging.. something I'm not sure any guy answering the phone might catch when quickly answering questions.
Personally I don't understand why they are given a logical argument. Let them have their love in over at their own forum. If they come here they deserve no more than ridicule and derision. As long as they are abusing logic, there is no reason whatsoever in my mind that they deserve any in response.
 
If you are completely ignorant of how they are built, you might believe that. Someone with even the most trivial understanding of how solid state recording works understands perfectly well what will happen during failures to the locale being written to. This has absolutely nothing to do with the memory's capabilities to withstand g-forces.

It's amazing that even though Anti knows an L3 product was installed in
AA77, and said recorder must meet/exceed certifications, he still tries to
spin the standard. Not only does he deny the specification's meaning,
he states "It's not excatly what I think it means".

So that's supposed to clear things up then? What exactly does it mean
then? Are you bold enough to ignore three sources of informaton which
are clearly published and tell the world that..."it's not what I think it means"?

Well, please enlighten us. What exactly does it mean then?


This fact is completely and utterly irrelevant to the equally true fact that the data that was being written during the crash was most certainly corrupted.

I give you up to 500 milliseconds (typical), and a maximum of one second
(worst case) AFTER power was removed.

You are assuming that when the nose of the plane touches a solid surface
that power is instantly cut to the FDR.


Just like the "500ms" doesn't mean what you think it means, and doesn't cover as much as you think it does, equally, the 3400 Gs doesn't mean what you think it means and doesn't doesn't cover what you think it covers.

As mentioned above, I'd love to know your interpretation of the spec,
even though it has been clarified in documents and by L3 Communications
all available for you to read.

So let's read your theory about this spec.?

Irrelevant links that neither disprove my theory, not support your own.

That is your opinion and theory. Nothing more. Why don't you provide
some EVIDENCE to support your theory and interpretaion of the spec?

So? The animation wasn't made within "limits of altitude and DME tolerances". I repeat: neither the CSV nor the animation was made to be forensicly analysed. Therefore, your forensic analysis of both is fundamentally flawed before we've even gotten started.

PFT also has the capability to study the FDR file and they have clearly
shown that you are wrong.


I've commented no less then 4 times. Nothing in ANY of your links supports your assertion because you've neglected to take into account numerous other effects. I am trying to explain this to you but you absolutely positively refuse to discuss the issue. Instead, you continuously change the subject.

Right, again that;s your opinion and theory. You have done nothing to
show support of your claims. I've asked several times for you to post
up data , or SOMETHING to prove you have any idea of what's happening
here.

Talk about dancing around the questions. How many pages ago did I ask
the questions? :rolleyes:

What that means is that a parameter sampled once per frame (once every 4 seconds) can sit in the digital buffer up to T2 = 4 seconds. 4 seconds > 500ms. Now, RADALT I believe was sampled every second, so for RADALT this number (T2) is 1 second. Please note that 1 second > 500 milliseconds. So unless one of the steps requires negative amounts of time, T2 + T3 cannot be less than 500 ms.

I had to bold this, and I hope everyone here clearly sees that Anti has no
concept of FDR recording function after clearing this up.

DME is once every 4 seconds
Altitude is once per second
Pitch is 4 times per second
Vert Accel is 8 times per second
Pitch, roll, Vert Accel, etc etc all have values recorded and plotted by the NTSB between 09:37:44-:45.

There arent ANY seconds missing according to the NTSB in the CSV File. However, they did stop the animation 1 second prior to their calculated "impact" time. Most likely because if they continued the animation plots from the data, it would show it doesnt hit the pentagon!

Anti-sophist can you explain HOW Pitch and Vert Accel is recorded 4 and 8
times per second in the Excel file if your RAD ALT is waiting in some sort of
fantasy buffer?

Does the Pitch and Vert JUMP over the RAD ALT on the bus and dive into
the crash protected memory?

You see everyone, once Anti-sophist can explain how the data from one
sensor can magically jump the buffer, and all other sensors then I will
send him a cookie (maybe an Oreo).

I'm sure knows these sensors are polled in a specific order each cycle,
and not randomly, or some other bogus method.

Waiting for this one...

As for me avoiding your question about Time from X to ABC, 123 I did
post a video link and cell data to support and justify my answer. I guess
you don't like the fact that I'm efficient and post links to previously concluded
facts, but here's a break down of my estimate of time anyway:

DME 1.5 nm at last recorded value puts the object approximately 2700 feet
from the impact hole.
The RAD ALT shows 273 AGL at the intersect point of DME and the official
flight path.

The plane is flying 781 feet per second, so based on that inforation alone,
the object would be about 3-4 seconds from the Pentagon.

It doesn't add up.

If you use the alternate flight path, the object coincides with the
1.5 DME intersect point, and puts the plane two seconds from the wall.

This would correlate to 9:37:43 in the data file.

I'll patiently await your reply, especially the magical Vert. Accel's ability to
hop over RAD ALT while it's waiting in the 'buffer' :D

P.S. The data file also show no indication of g force to come close to the
impossible dive to hit light poles from 273 AGL in one second from the
calculated distance.

There's your lesson for the day. :cool:

"Quiet thread from facts" hahaha

I'll see you all when Anti, or anyone else can show a basic understanding
of data transfer. Until then, you have some 'splanin' to do.
 
Last edited:
Well, please enlighten us. What exactly does it mean then?
It means you don't have the slightest clue. If you were correct the PffffT might actually have some FDR experts on board, as it turns out the number of FDR experts in the PffffffT is... exactly 0. Oddly enough, that's the same amount of FDR experts who are truthers.

But don't let the facts get in the way of your fantasies.
 
There arent ANY seconds missing according to the NTSB in the CSV File. However, they did stop the animation 1 second prior to their calculated "impact" time. Most likely because if they continued the animation plots from the data, it would show it doesnt hit the pentagon!
Now you are contradicting yourself! You claim the data was faked, yet you're using the data from the FDR to claim that Flight 77 didn't hit the Pentagon?

Was the data faked or not Turbofan?
 
...here's a break down of my estimate of time anyway:

DME 1.5 nm at last recorded value puts the object approximately 2700 feet
from the impact hole.
The RAD ALT shows 273 AGL at the intersect point of DME and the official
flight path.

The plane is flying 781 feet per second, so based on that inforation alone,
the object would be about 3-4 seconds from the Pentagon.

It doesn't add up.

It seems reasonable to me. 2700 feet out puts it right around the Navy Annex building, 270 feet up, descending at 70 ft/s, or somewhat more initially followed by somewhat less after clipping the light poles.

70 ft/s is 4200 ft/min, an unexceptional descent rate for an airliner at-speed.

What doesn't add up about that?


P.S. The data file also show no indication of g force to come close to the
impossible dive to hit light poles from 273 AGL in one second from the
calculated distance.
What? If it's a constant descent rate, it's a 1-G descent. And why one second? From 2700 feet out, it still has more than 1700 feet to hit the first light pole.
 
Last edited:
It seems reasonable to me. 2700 feet out puts it right around the Navy Annex building, 270 feet up, descending at 70 ft/s, or somewhat more initially followed by somewhat less after clipping the light poles.

70 ft/s is 4200 ft/min, an unexceptional descent rate for an airliner at-speed.

What doesn't add up about that?
You must be a Bush-loving neo-nazicon! Now, watch the monkeys until you go back to sleep.

monkey3_small.gif
 
Turbo, we're still waiting for your answer to Anti-Sophist's question (among others):



[/B][/I]That means YOUR answer, not a link to the data.

It would be nice if you actaully read this thread before responding, but here
it is again for YOU:

DME 1.5 nm at last recorded value puts the object approximately 2700 feet
from the impact hole.
The RAD ALT shows 273 AGL at the intersect point of DME and the official
flight path.

The plane is flying 781 feet per second, so based on that inforation alone,
the object would be about 3-4 seconds from the Pentagon.

It doesn't add up.

If you use the alternate flight path, the object coincides with the
1.5 DME intersect point, and puts the plane two seconds from the wall.

This would correlate to 9:37:43 in the data file.

You will NOTICE that I stated the cell data location in the file which the
video link does not. This was based on my math which I clearly added
in the quoted text.
 
Now you are contradicting yourself! You claim the data was faked, yet you're using the data from the FDR to claim that Flight 77 didn't hit the Pentagon?

Was the data faked or not Turbofan?

The data was manipulated to show an incorrect altitude. If you watch
the animation, you will see that the altimeter is not corrected for altitude.

This is a clear indication of tampering. The animation also stops short
of the FDR data presented in the files. Why?

There is up to 2 seconds missing!!!
 
It seems reasonable to me. 2700 feet out puts it right around the Navy Annex building, 270 feet up, descending at 70 ft/s, or somewhat more initially followed by somewhat less after clipping the light poles.

70 ft/s is 4200 ft/min, an unexceptional descent rate for an airliner at-speed.

What doesn't add up about that?

For one:

the DME value doesn't line up with the offical flight path at 1.5nm
and impact time according to speed.

Second:

There is no indication of g force shown in the data to indiciate such
a rate of descent.

Slowly but surely, you will all see that your theories are contradicted
by the data.
 
The data was manipulated to show an incorrect altitude.
So you claim the data was faked.

If you watch
the animation, you will see that the altimeter is not corrected for altitude.
Once again, you use the animation for a purpose for which it was never intended.

This is a clear indication of tampering.
And yet the total number of FDR experts who are truthers stands at zero. Are they all in on the conspiracy Turbofan?

The animation also stops short
of the FDR data presented in the files. Why?
Because it was for illustrative purposes only and not meant to be used the way the hacks at PffffT are using it.

There is up to 2 seconds missing!!!
If they were manipulating the data as you claim, why not simply manipulate it to account for that? Your speculation makes no sense at all.
 
<snip ad-hom gibberish>

There arent ANY seconds missing according to the NTSB in the CSV File.
See previous explanation on why using the CSV file is fundamentally flawed.

However, they did stop the animation 1 second prior to their calculated "impact" time. Most likely because if they continued the animation plots from the data, it would show it doesnt hit the pentagon!
See previosu explanation on why using the animation is fundamentally flawed.

Anti-sophist can you explain HOW Pitch and Vert Accel is recorded 4 and 8
times per second in the Excel file
Because it has 4 and 8 equally spaced spots, respectively, in the bitstream per subframe. Please read my original post to understand how the bit stream works.

if your RAD ALT is waiting in some sort of fantasy buffer?
Fantasy buffer? Are you kidding me? All digital parameters are buffered in every recorder. You are completely and utterly ignorant of how they work so I suggest you stop pretending to know what you are talking about.


Click on it to make it bigger. I highlighted the part of the system you consider to be a fantasy. Feel free to read the entire thing. It's clear you have absolutely no idea how the bitstream is created and in what order things are stored. I strongly suggest you read the footnotes as well at the bottom. You have alot of learning to do.

Does the Pitch and Vert JUMP over the RAD ALT on the bus and dive into
the crash protected memory? You see everyone, once Anti-sophist can explain how the data from one
sensor can magically jump the buffer, and all other sensors then I will
send him a cookie (maybe an Oreo).
I'll patiently await your reply, especially the magical Vert. Accel's ability to
hop over RAD ALT while it's waiting in the 'buffer' :D
You have absolutely no idea how this system works. Your ignorance is palpable. It is painfully obvious you have absolutely no idea how digital fixed-rate bitstream data works. Please read the original post -- and look at the above image. Maybe it can explain it to you.

The bitstream order is predetermined via a data-frame layout. The parameters _ALL_ wait until their turn in the bitstream. Things that are sampled more often just have more frequent slots in the bitstream. This isn't rocket science. Nothing is jumping anywhere. Everyone is just waiting their turn in the bitstream.

As for me avoiding your question about Time from X to ABC, 123 I did
post a video link and cell data to support and justify my answer. I guess
you don't like the fact that I'm efficient and post links to previously concluded
facts, but here's a break down of my estimate of time anyway:
You still haven't answered my question. You keep answering some other question. I'm not asking you for your mythical theory of how much time has been removed. I'm asking you to tell me how long before the impact the RADALT was taken, in a properly operating recorder.

Let's say we took a plane, and crashed it into the ground, and sent the FDR to the lab, and they released a CSV and raw file to the public. Totally legit. No ********. The final RADALT reading that you get, how much time passed between the plane was X feet until the crash. You keep trying to tell me it's 500ms even though I've already demonstrated that to be impossible.

That's all I want to know.


P.S. The data file also show no indication of g force to come close to the
impossible dive to hit light poles from 273 AGL in one second from the
calculated distance.
The g-force-required calculation that you are basing this nonsense on depends on your flawed calculation of how much time you have left to do such a maneuver. All of your calculations are based on timeslips that you cannot justify. No one at PfT has given an adequate justification of their insane estimations of the equation I gave in my previous post: T1 + T2 + T3 + T4 + T5
 
Last edited:
It would be nice if you actaully read this thread before responding, but here

Missed that initially, corrected now.

I would still like your answer to the following:

turbofan said:
A working copy would still contain sensor
reading within their tolerances.

A working copy of animation would not contain a MAN MANIPULATED
error of altitude!



Do you have sources for either of these claims or are they arguments from personal incredulity?
 
TF, I'm still waiting for you to answer this question:

What does the data in cells K37806-37809 show?
 
Wow, he presents a solution for 77 hitting the Pentagon from 2700 feet out at 273 feet above the ground inside the parameters the terrorist has demonstrated.

The terrorist has demonstrated just before impact VVI as high as 6600 feet/min. And the last stick input, the last data point has the most forward stick yet!!! Funny how some people right there saw a pitch down, a significant pitch down and followed 77 into the Pentagon with Mark1 eyeballs, the NWO secret tool!

Disrespect, is not having evidence. 9/11 truth is pure disrespect...
 
Last edited:
Missed that initially, corrected now.

Do you have sources for either of these claims or are they arguments from personal incredulity?

I have already posted links to the tolerances of the sensor data.

The omission of the altimeter setting is quite simple:

You open the data file. Upload it to the animation. The software reads
the values and plots the plane movement and sensor inputs as stored.

There is no reason for the altimeter to be incorrect unless someone
deliberately manipulated the animation.

You can ask any of your 'experts' here about that one.

By the way, Wildcat, who/where are your FDR experts?

Here is a link to the professionals who studied the NTSB data:
http://video.google.com/videoplay?docid=2052484937239620900&hl=en

You will also note Calum's e-mail address and you can directly reply to
him about any of your questions.

Anyone here can also talk to me live on record about questions and
we'll upload the interview for all to listen. Once again, at my expense.

Good day.
 

Back
Top Bottom