• 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

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


Beachnut, much like the others , fail to read the other data and just make
assumptions on one item until the believe in their hearts they are satisfied.

As you will note, the g force does not indicate such a maneouver, nor
can you explain hitting the light poles based on your THEORY.

It's unfortunate that most of you don't know what you're looking at within
the data file. You have to ensure your assumptions satisfy all of the
sensor data.

Care to go live with me Beachnut? Maybe you can answer the same questions
presented to Anti-sophist ealier.
 
By the way, Wildcat, who/where are your FDR experts?
The FAA and the airlines involved who extracted the data from the FDR's involved.

Here is a link to the professionals who studied the NTSB data:
http://video.google.com/videoplay?docid=2052484937239620900&hl=en
Sorry, I don't view videos unless you summarize the points you wish me to hear from it. This isn't argument by youtube/google video.

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.
How odd! You have what you consider conclusive proof of data manipulation exposing a conspiracy that has killed thousands, and you want to debate people on an internet forum about it? Why aren't you contacting the FBI? The FAA? American Airlines? FDR experts? The New York Times?
 
The FAA and the airlines involved who extracted the data from the FDR's involved..

No, I mean here...on this forum. No names, no faces...please provide the experts who are contesting PFT.

Sorry, I don't view videos unless you summarize the points you wish me to hear from it. This isn't argument by youtube/google video.

This video (audio) contains one of the data experts discussion the information
released by NIST. He is one of the experts you asked me to provide.


^QUOTEHow odd! You have what you consider conclusive proof of data manipulation exposing a conspiracy that has killed thousands, and you want to debate people on an internet forum about it? Why aren't you contacting the FBI? The FAA? American Airlines? FDR experts? The New York Times?[/QUOTE]

Don't play that card, it wont get you very far.

You know very well that PFT has contacted the NTSB, FBI, and other
organizations to get clarification.

They all refuse to comment and pass the buck.

Like I said early in this thread, or the Walter thread, if it takes a law
suit for them to talk, and 10 years...we're going to push for it.
 
Last edited:
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.

This is, of course, not true.

There is no reason for the altimeter to be incorrect unless someone
deliberately manipulated the animation.
This is, of course, also not true.

Here is a link to the professionals who studied the NTSB data:
http://video.google.com/videoplay?docid=2052484937239620900&hl=en
No one cares about your supposed "experts" credentials when they are so easily proven incorrect.

I also notice you've ignored the rather embarassing issue of you trying to explain to me how FDR's work and me pointing out that you have absolutely no idea what you are talking about.

Let me know when you, Balasamo, or Callum Douglas come up with a reasonably justified estimate for T1 + T2 + T3 + T4 + T5. Because without a reasonably justified timeslip estimation, all of your calculations are flawed. You guys have no idea when any of your measurements occured relative to the impact and all you can do is make unfounded assumptions.
 
Last edited:
This is, of course, not true.

Wow, thanks for the detailed explanation of how you THINK it works.

I guess when I open a file in MS Word, or other programs...the data
changes since my last save? :rolleyes:

So, now that you've conveniently ignored the other questions, i will ask
you to present your answers once again.

No one cares about your supposed "experts" credentials when they are so easily proven incorrect.

You can't even tell me how RAD ALT hop, skips and jumps over other data
on a serial bus , and you want all of us to believe you have something over
PFT?

Where are YOUR calcualtion to show the corrections? I think we're up to
a few pages of delay on your part now. If it's easier to talk about it,
give me a collect call and I'll record it for all of us to listen to.

I also notice you've ignored the rather embarassing issue of you trying to explain to me how FDR's work and me pointing out that you have absolutely no idea what you are talking about.

I have ignored absolutely nothing. I have given answers to your questions,
and your reply with "that's not how it works."

Real descriptive and accurate. Come on Anti, we're getting impatient here.
You need to show JREF what a tough and experience data transfer specialist
you really are.

You need to explain how certain sensors stop for a coffee break while others
update 4 and 8 TIMES PER SECOND...this should be good.

I will expect a detailed comprehensive answer upon your next reply.

Let me know when you, Balasamo, or Callum Douglas come up with a reasonably justified estimate for T1 + T2 + T3 + T4 + T5. Because without a reasonably justified timeslip estimation, all of your calculations are flawed.

See above.
You guys have no idea when any of your measurements occured relative to the impact and all you can do is make unfounded assumptions.

It's pretty simple. Wall of Pentagon as reference point. Angle of damage from ASCE report. Position data from data files.
Distance from DME. Alt from RAD and Pressure. Speed of aircraft. Clearly shows yoù`re wrong, and the official flight path
is incorrect.

Still waiting for your calcs on this as well.

I'm hoping the rest of the public viewing this forum can see the nice
dance moves going on.
 
Last edited:
well, I think PFT has done a bang up job of proving they don't know what happened. Good for them. I'm sure they will continue for a long time proving they don't know what happened. And they will continue to try and let as many people know as possible that they don't know what happened.

Good job turbofan!
 
You know very well that PFT has contacted the NTSB, FBI, and other organizations to get clarification.
How were the NTSB and FBI contacted. What information was presented to them and how was it presented. Who replied and what did they say.

Please be specific.
 
I'm hoping the rest of the public viewing this forum can see the nice dance moves going on.

Yup. We sure can. I'm especially fond of the "Turbofan Tango".



P.S. Props to Anti-sophist and others. I'm learning a lot by lurking on this thread.
 
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.

Source, please

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

This sounds like a personal opinion. Do you have a source to back it up?
 
Wow, thanks for the detailed explanation of how you THINK it works.

I guess when I open a file in MS Word, or other programs...the data
changes since my last save? :rolleyes:

Your own ignorance of how animations are produced isn't my problem. I've explained at least partially the reasons that your assumptions are wrong many many many many times in threads you refuse to read. I have no onus to repeat myself for the sake of your laziness.

We already know, beyond any shadow of a doubt, that human intervention is required in the creation of the animation. The easiest piece of evidence is the underlying map that is laid into the animation.

You can't even tell me how RAD ALT hop, skips and jumps over other data
on a serial bus , and you want all of us to believe you have something over
PFT?
I've explained this in grave detail in the original post and previously, above. You refuse to read and understand both.

See:
http://www.internationalskeptics.com/forums/showpost.php?p=3852374&postcount=1 (sections 1, and 2)
http://www.internationalskeptics.com/forums/showpost.php?p=3852374&postcount=655

I also pointed out the ARINC standard block diagram showing you the buffer that you claim is fantasy. I showed you the buffer that you claim doesn't exist.

Where are YOUR calcualtion to show the corrections? I think we're up to
a few pages of delay on your part now. If it's easier to talk about it,
give me a collect call and I'll record it for all of us to listen to.
I have provided calculations for every claim I've made. I have no idea what you are talking about.

You need to explain how certain sensors stop for a coffee break while others
update 4 and 8 TIMES PER SECOND...this should be good.
That's the entire purpose of this thread. Try reading it.

See:
http://www.internationalskeptics.com/forums/showpost.php?p=3852374&postcount=1 (sections 1, and 2)
http://www.internationalskeptics.com/forums/showpost.php?p=3852374&postcount=655

It's pretty simple. Wall of Pentagon as reference point. Angle of damage from ASCE report. Position data from data files.
Distance from DME. Alt from RAD and Pressure. Speed of aircraft. Clearly shows yoù`re wrong, and the official flight path
is incorrect.
They only show I'm wrong if you make unfounded time slip estimations that you cannot and will not justify. All of your calculations rely on an answer to the T1 + T2 + T3 + T4 + T5 equation that is UNFOUNDED. Therefore your calculations prove nothing except your own ignorance.

Your calculations are flawed because you have no idea when the measurements occurred because you have no idea how FDR systems work. For christ's sake, you think the digital buffer in a DFDAU is a fantasy despite having seen the block diagram.
 
Last edited:
Don't play that card, it wont get you very far.

You know very well that PFT has contacted the NTSB, FBI, and other
organizations to get clarification.

They all refuse to comment and pass the buck.

Like I said early in this thread, or the Walter thread, if it takes a law
suit for them to talk, and 10 years...we're going to push for it.

As far as I know PfT has only made phone calls to the NTSB and FBI and demanded immediate answers to questions posed over the phone.
That is not how things work in the real world and Balsamo knows this, or at least should know it.


Once again I see that you and PfT and others are very convinced that the DFDR data and the flight path described by the physical damage do not agree. PfT states they make no theory on what actually happened at the Pentagon on 9/11/01. Therefore they, and you if you also claim no theory to what happened, have only the issue that the data is incorrect.

Therefore I ask again why, given the gravity of such a situation in the matter of flight safety, there has not been a technicall paper outlining the problems with the recording of the DFDR data?

You completely ignore this it seems. If you have answered this question before please by all means point me to the post and I apologise in advance for having missed it the first time.

ETA: I see above that ypu claim that at least one parameter was "manipulated" in the DFDR data. On the other hand you absolutly failed to understand that there are several times during a frame that certain parameters are recorded and how this is accomplished. Man, I learned that in 1982. There is but one data bus, and each sensor has an output. A value sits on that output until the output device of that sensor is switched to the bus. If one desires to switch that data onto the bus several times a frame while switching data from another device only once per frame that is simply written into the software that controls the switching. It goes like this, simply put;

The DFDR switches device #1 to the bus, that data value is read and sent it to the processor to be recorded along with any ID bits, Then the controller(an electronic control system not a person) switches device # 2 to the bus and at that time device #1 will happliy be changing the value on its output BUT it (device #1) will not be connected to the bus at that time since only one device at a time can be.
If the engineers then want to record the value of the parameter on device#1 again they instruct the controller to again switch device #1 to the bus to be read and recorded again before then proceeding to device #3. etc., etc., etc.

If one wanted to one could have the programming that determines what will be switched to bus and when, sample the alt data on every third (for instance) word in the frame and sample all other parameters only once per frame. How often something gets switched to the bus and recorded is determined by engineers who want to make the best use of the available data storage.
 
Last edited:
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.

...
Good day.
The animation, a working copy declared such by the NTSB, shows clearly the Pressure Altitude. You have no point!

The animation is manipulated, the ground has to be added by "hand" because there is no ground in the DATA and the best you can place 77 with the FDR is 2000 to 4000 feet.

How will you tie this to 77 not hitting the Pentagon when 77 FDR was found in the Pentagon. BTW, the FDR data decoded by p4t source, proves the FDR was 77! Good job.
 
So does the computer program that just generates everything automatically form the data also get the images of the ground and the buildings and the trees and everything also from the FDR?
 
This video (audio) contains one of the data experts discussion the information
released by NIST. He is one of the experts you asked me to provide.
No, I asked you to provide an expert on FDRs, not a "data expert". You don't have an FDR expert, do you? No problem admitting it, but when you're trying to overturn the dominant paradigm you'd better have something better than what you've brought to the argument so far. An actual FDR expert would be a good start.


Don't play that card, it wont get you very far.

You know very well that PFT has contacted the NTSB, FBI, and other
organizations to get clarification.

They all refuse to comment and pass the buck.
Do you think all those organizations are involved in this conspiracy? How many people are in on this conspiracy? Just a ballpark figure will do.

Like I said early in this thread, or the Walter thread, if it takes a law
suit for them to talk, and 10 years...we're going to push for it.
And they won't talk now because they're in on it? Threatened? Paid off?

And none of these people have blown the whistle? None has a conscience?
 
So does the computer program that just generates everything automatically form the data also get the images of the ground and the buildings and the trees and everything also from the FDR?


Yeah just like when the mechanic plugs your autos computer into the diagnostic machine it displays all the roads and scenery you drove by in the past week.

or maybe its the computer game "grand theft plane" turbofan is thinking of?
 
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.

Yes, fantasy buffer in the sense that RAD ALT magically remains in the
buffer while all other data is clocked out.

If RAD ALT is polled once every second, then you can certainly figure out
that a value was STORED in the crash protected memory (CPM) at least one
second before impact.

YOu see, the data from the sensor passes through the buffer, and down
the serial bus and into CPM within <=500 ms no matter what the poll request
for any sensor will be.

My arguement and the one you are not understanding is, all of the parameters
before and after RAD ALT have been stored in CPM at least one second before
impact.

That value is 273 AGL

If you want to argue that the FDR magically lost power, or was interrupted...
or the coffee was too cold...or the plane was blue...while the last RAD ALT
was writing, then I'll give you an extra second.

That is still TOO high based on distance from the wall and speed of the plane.
The g force shows nothing in the way of descent from the recorded altitude
within the 1, or 2 second time frame.

Once again. Parameters before and after RAD ALT traveled down the serial
bus and were stored.

RAD ALT cannot park itself on the wire, or buffer while other data is clocked
into CPM.
 
Last edited:
YOu see, the data from the sensor passes through the buffer, and down
the serial bus and into CPM within <=500 ms no matter what the poll request
for any sensor will be.
This is where you go horribly wrong.
 
This is where you go horribly wrong.
No, not at all.

But...let's pretend I am wrong (and those links are wrong, etc), then how
do you explain the parameters before and after RAD ALT storing themselves
into CPM?

That is a clear indication that RAD ALT was stored at least one second
before impact with a value of 273 AGL.
 
No, not at all.
Yes. And this is why you'd be wise to talk to an actual FDR expert, since you seem to ignore anything anyone here says.

Hint: There aren't any at PffffT.

You make a whopping assumption upon which your entire theory rests, and have provided nothing to back up that assumption. It's time to back it up or shut up.
 

Back
Top Bottom