AA77 FDR Data, Explained

[beachnut]

The FDR also says the plane is too high to hit the pole making the official
story the dumbest thing ever believed.



Hey Beachnut, it seems you don't know how DME works. Do you think
the aircraft just hovered for all that time? Was "Hani" in a helicopter?




We[re busted again huh? This coming from the guy that says the plane is
1.724 nm, but measures 1.5 DME even though the tolerance is -/+ 0.1nm,
and the system is capable of writing 1.7. Yeah...."Hani's Helicopter"!



Six seconds at 1.5 DME, that's your math big guy.



Rob has been reading and giving me some pointers. He's much smarter than
you. I see your mistakes and I'm not even a pilot. Why don't you take this
up with PFT and Rob? Afterall, you claim to know it all!

The FDR only stores x.0, x.2, x.5, x.8 for DME. That means if the DME reports 1.624 NM when 77 is really 1.74 NM, the value stored in the FDR is 1.5 DME and 77 is really at 1.724 NM! This is true based on your accuracy. But you have a block on what x.0, x.2, x.5 and x.8 mean for storage!

You are not able to comprehend this you need help! Someone explain this in truther talk to Turbofan! Get help Turbo


The FDR only stores x.0, x.2, x.5, x.8 for DME. That means if the DME reports 1.624 NM when 77 is really 1.74 NM, the value stored in the FDR is 1.5 DME and 77 is really at 1.724 NM! This is true based on your accuracy. But you have a block on what x.0, x.2, x.5 and x.8 mean for storage!

You are not able to comprehend this you need help! Someone explain this in truther talk to Turbofan! Get help Turbo



Plus based on your correction to 3.2 DME at :29, and the average speed of 700 fps, impact is at :49 to :50, 77 is not too high, you are WRONG and you are not able to understand why? Is that a Balsamo block?

Rob is a dolt on flying procedures, he did not know how many feet are in a NM, did not know the frequency for RADALT, and he has a problem doing math, he makes up 34 Gs in error, and he made you look like a fool with the 3.2 NM slant range ERROR! Balsamo is a dolt on 9/11 and flying. You are mislead! lol grade school kids know more than Balsamo, the founder of p4t dolt ideas on 9/11. Rob is a terrorist loyalist, making implications of lies for you to repeat. His slant range was funny! I have to pass this on to everyone! What a dumb pilot! What else did I leave out! Oh, he has you believing the lie 77 did not hit the Pentagon. He finally figured out math but uses a formula you can get any G force you want with the Hockey stick approach his preference for high G idiot flying. Left out, p4t and Balsamo claim they cannot fly into building like the terrorists, making them the worse pilots behind the terrorist! What else? FDR non-expert! If you listen to all of Rob's interviews and review all Rob's posts on prtf, you will see what I said is true. He is not the sharpest tool in the shed.

Your posts are so bad, I think Rob is posting for you!


That dumb slant range stuff low to the ground is for 3.2 DME was a difference, to 3.15. Wowzer, you are using too much of Balsamo dumb input, you can do better than Balsamo if you try; if you can tune cars and make things right in the car world, you can figure out 9/11 and stop telling the 77 did not hit the Pentagon LIE.

You could do better than Balsamo, anyone can.


I have to tell you as an electrical engineer with 35 years experience flying and engineering, I have to say there are thousands of possible transient scenarios possible in the impact of 77 with the Pentagon. You lack the knowledge and experience to understand why other FDR lost data are possible and cling to some fantasy 77 can't be missing data for unknown reasons.

This is backed up by the fact the p4t decode team failed to decode random seconds in the FDR and missed the last second the NTSB decoded. This uncertainty is like the uncertainly involved with possible transients on impact. BTW, there was damage to the FDR beyond most accidents. But you fail to bring them up. I know other ways transients can be introduced, after the impact. But gee, I am only a poor boy with 35 years flying experience, and a masters in electrical engineering who worked with his betters in AFWAL. Mackey is cleaning up! I wish I was as disciplined and clear in explaining, we owe him tons of beer.

 

[Turbofan]

The FDR only stores x.0, x.2, x.5, x.8 for DME. That means if the DME reports 1.624 NM when 77 is really 1.74 NM, the value stored in the FDR is 1.5 DME and 77 is really at 1.724 NM! This is true based on your accuracy. But you have a block on what x.0, x.2, x.5 and x.8 mean for storage!

You are so washed up, you can't see that the NTSB data records x.7
after the third time I've shown you. What is the matter with you people
on this site?

The rest of your post is just 'parrot post'...the same over and over and over
and over again. It needs no reply.

Go look through the NTSB file and when you can think
and see x.7, come back and play.

 

[WildCat]

Turbofan, are there any real FDR experts who have corroborated the findings of the pretend FDR experts at PffffT?

Why do you think that is?

Does it bother you that you have been proven wrong on every one of your claims? Does it bother you that no one at the engineering forum agreed with you? Does it bother you that you are a laughingstock even amongst your fellow truthers?

 

[beachnut]

You are so washed up, you can't see that the NTSB data records x.7
after the third time I've shown you. What is the matter with you people
on this site?

The rest of your post is just 'parrot post'...the same over and over and over
and over again. It needs no reply.

Go look through the NTSB file and when you can think
and see x.7, come back and play.

I am washed up, was flying heavy jets left seat when I was 26 years old; something old Balsamo has never done! Washed up me flew heavy jets when I was 23 years old! Essentially a Captain equivalent at the age of 26 in heavy jets, Balsamo can only dream of the same. So I am washed up, that makes Balsamo what? A total failure? With 11.2 Gs, he is a total failure at understanding 9/11.


With Balsamo helping you, you will never understand the resolution and accuracy of DME and why 77 can be at the real position of 1.724 NM and the value is stored as 1.5 DME.

Poor Balsamo has no clue, what is your excuse? Balsamo is dumber than dirt with his lack of skill and 11.2 G embarrassment physics failure. Why are you unable to see 1.724 nm can be stored as 1.5 DME. Do the math and see for yourself.

Breakaway from the idiots in math and physics at p4t.

If you paid attention to Mackey, you could learn something; I could too. Good luck, this washed up guy has to shut down and build my new CPU, got to steal my PCI card for a few minutes to boot XP on the new build til the PCIe card arrives by truck!

Go to a math teacher!

Take 0.1 nm for accuracy.

Tell the teacher the DME is only stored in the FDR with 0.25 NM resolution.

Then ask what 1.724 nm would be stored at with a -0.1NM accuracy, making 1.624 the sensed value for a real value of 1.724, and what would be stored if only x.0, x.2, x.5 and x.8 can be stored. BTW, NTSB data has .8, the p4t data is stored as .7! But not sure you are understanding this.

I am looking at 09:37:39 and a value of 3.8 is stored in the NTSB data. Darn, I am washed up?

Why are you always wrong? Rob can't read, can he?

 

[Turbofan]

I don't need to do math to see that 1.5 nm gets recorded as 1.5 DME, and
1.7 nm gets recorded as 1.7 DME.

You on the other hand need to check your facts and x.7 my friend.

WC, does it bother you at all that I don't care for your opinion and the
fact that you are the most off-topic, non technical person on this site?

Does it also bother you that you swallow anything you read around here,
and your friends have yet to come up with a method of how a few seconds
of flash memory get erased?

 

[R.Mackey]

It's not an excuse. Is losing a tail and both engines anything other than
breaking up in flight?

You're barely responsive. Only the vertical stabilizer came off before the FDR shut down. That is not breaking up in flight.

Read the report!

Gee, you wont look at facts...what a surprise.

Non sequitur. The animation is not an estimate of structural damage, and it shows no damage other than the stabilizer coming off. Those are facts. Your knee-jerk rejection of this entire example -- which, I remind you, you asked for -- is based on your own reading, nothing more.

Until you, or anyone here can confirm only a few seconds can be erased
from flash memory (as opposed to a block), then you might have something.

Did it weeks ago.

Math has been done by PFT and their research team. It's out there if you
care to study it.

I'm quite familiar with their 11.2 g laugh-fest. I wrote a rebuttal destroying it, as you well know. But there is no calculation such as I asked for, namely one showing -- and doing the math correctly -- that the FDR measurements are beyond any plausible margin of error.

FYI, the device plugs directy into the DFDAU. How long do you think it takes
an electrical signal to move down the wire once transmitted by the altimeter?

Just give me a number and add it to 42 msec so we can debate it.

It might plug in directly, and it might not. How long it takes depends on how the signal is polled, what other signals the DFDAU is waiting for, how it assembles packets...

You can, of course, assemble a system that flows RADALT data direct to storage with extremely high throughput and low latency. But there's no guarantee that the AA 77 FDR system is one such. Besides, that's not the point. The point is that the specs you read off don't mean what you claim they mean. I don't know if you can't tell the difference, or you're just trying to mislead us, but the result is the same -- neither L-3 nor Rockwell can possibly tell you the whole story. You always seem to neglect what happens in the middle.

 

[dtugg]

Does it bother you that you have been proven wrong on every one of your claims? Does it bother you that no one at the engineering forum agreed with you? Does it bother you that you are a laughingstock even amongst your fellow truthers?

Of course not. If you are truly a smart, honest person, you will agree that a plane that looked like an American Airlines 757 really overflew the Pentagon. The eyewitnesses were fooled via the most risky and elaborate illusion of all time. The huge amount of physical evidence was faked without any experts or eyewitnesses noticing. Anybody that disagrees (99.999999% of the population of the US) is a liar/shill/disinfo or simply stupid. This is known because some people that were there say in interviews years later after being asked misleading questions that the plane flew on the other side of some gas station as the official story and its evidence states. It doesn't matter that these same people think the plane hit the Pentagon too. They were tricked! We know this because Beavis and Butthead say so!

But seriously, I am beginning to that think these Pentagon flyover people are just as stupid and delusional as the WTC no-planers, if that is possible.

 

[Arus808]

why are you guy entertaining this obvious trollling mouthpiece for the frauds at PFFFFT?

Attack the argument, not the arguer

Replying to this modbox in thread will be off topic  Posted By: Gaspode

 

[Turbofan]

You're barely responsive. Only the vertical stabilizer came off before the FDR shut down. That is not breaking up in flight.

Read the report!

Read it. So I guess plane just emit white smoke and drop engines for no
apparent reason. Nothing happening under that fuselage skin prior to those
pieces falling off. I mean the white streak could have been milk from the
food cart for all we know...

Did it weeks ago.

Not satisfactory and seems impossible from a flash memory design standpoint.
This is the reason we're debating your theory.

I'm quite familiar with their 11.2 g laugh-fest. I wrote a rebuttal destroying it, as you well know. But there is no calculation such as I asked for, namely one showing -- and doing the math correctly -- that the FDR measurements are beyond any plausible margin of error.

PFT took that rebuttal and ripped it apart using a scale layout and proper
equations. Your calcs are not even based on the flight data

It might plug in directly, and it might not. How long it takes depends on how the signal is polled, what other signals the DFDAU is waiting for, how it assembles packets...

No, that's not how electricity works. The signal is present at all times, when
the DFDAU is ready to clock-in the 'value', it will read the most recent transmitted
data from the device (IE: every 42 msec max).

The point is that the specs you read off don't mean what you claim they mean. I don't know if you can't tell the difference, or you're just trying to mislead us, but the result is the same -- neither L-3 nor Rockwell can possibly tell you the whole story. You always seem to neglect what happens in the middle.

There is nothing in the middle, that is what you fail to understand! You have
a length of wire connecting the device to the DFDAU. If you're so much
better than L3 and Rockwell, take the Tracking Number, write them back
and correct them.

My conversations and e-mails with them were very clear. There is no mistaking
the information, and I'm certainly not going to let you twist their reply into
something that makes sense for you! I specifically asked those questions to
put to rest the very garbage you are trying to spin yet again.

 

[jaydeehess]

jdh
Irrelevent, if the data for word #1 comes in to the buffer 1 second before the last word gets there, and only then is the entire frame of 256 words sent on to flash memory, that means the data for word # 1 has taken a minimum of 100% longer to get from sensor to storage than your interpretation of the 0.5 second spec.

If a sensor sends data several times during one frame that does not make the first instance of that reading get to the memory location any faster.

So you think it takes a complete second to transmit the frame?

Do you know what the clock rate happens to be?

Jay, that is 256 words per second (12 bits per word) for 3072 bits per second
into CPM minimum

You stated a data rate for which it would take 1 second for a full frame of data to be collected in the buffer,and you also stated that only after a 256 word frame frame had been collected would it be transmitted to the flash memory. That data rate is , according to you, 256 w/s as well. So yes at 256 w/s data rate then it would take 1 second to transmit 256 words, meaning it is taking much longer than 0.5 seconds for any particular data point to get to a protected memory location.

If it takes one second for the buffer to collect a full 256 word frame, and during that time the data still only resides in the (non-protected) buffer, then your interpretation of the 0.5 second spec MUST be incorrect. You have stated that the spec requires that all and any data point take no longer than 0.5 sec to move from the sensor send unit and into protected flash memory.

Your own statements are not internally consistent.

 

[MacGyverS2000]

While there always seems to be 50 rehashed questions popping up every day i step away form this board, two main ones keep popping up.

Q1: What is the smallest block size that can be erased (to all binary ones) in flash?
A1: This depends on the flash unit in use, but anything that is sized to hold megabits of data (such as the Intel unit posted way back when) will have page sizes in the 32kB (for boot blocks) to the more common 128kB-512kB range (for normal data blocks). You can see a smaller portion of a block get erased should a transient happen during the erasure cycle, but this is not standard operation.

Q2: What is the smallest block size that can be written?
A2: One byte. But this is dependent upon the firmware, and in real-world applications it is inefficient to write a single byte at a time. Typically writes will be at least a 16- or 32-bit word, and often these words are combined into a hardware-based buffer to be written in (relatively speaking) large chunks of 8-32 words all at once. I have already discussed how corrupt/incorrect words or bits may be written due to this buffered write scheme.

 

[Turbofan]

You stated a data rate for which it would take 1 second for a full frame of data to be collected in the buffer,and you also stated that only after a 256 word frame frame had been collected would it be transmitted to the flash memory. That data rate is , according to you, 256 w/s as well. So yes at 256 w/s data rate then it would take 1 second to transmit 256 words, meaning it is taking much longer than 0.5 seconds for any particular data point to get to a protected memory location.

If it takes one second for the buffer to collect a full 256 word frame, and during that time the data still only resides in the (non-protected) buffer, then your interpretation of the 0.5 second spec MUST be incorrect. You have stated that the spec requires that all and any data point take no longer than 0.5 sec to move from the sensor send unit and into protected flash memory.

Your own statements are not internally consistent.

No they are not inconsistent. You are just not taking into consideration the
other bits of information that go along with the hard data. Parity bits, sync
bits, SDI (source/destination identifier), etc.

 

[WildCat]

Turbofan, when can we expect your "circle of experts" to submit a paper detailing there findings in a respected engineering journal? Or is it really about pwning people on the internet and selling merch so Cap'n Bob doesnt have to get a job?

 

[jaydeehess]

Read it. So I guess plane just emit white smoke and drop engines for no
apparent reason. Nothing happening under that fuselage skin prior to those
pieces falling off. I mean the white streak could have been milk from the
food cart for all we know...

List the crash examples that have occured which meet your requirement that they are similar to AA77, or accept the examples of lost data from crashes that did occur, or admit that this was a once in a lifetime occurance.

Not satisfactory and seems impossible from a flash memory design standpoint.
This is the reason we're debating your theory.

Not according to the flash memory expert you contacted and who was good enough to post here.

PFT took that rebuttal and ripped it apart using a scale layout and proper
equations. Your calcs are not even based on the flight data

Which also means that Pft took their original page of meaningless arithmetic and ripped it apart. Mackey's calcs were based upon the parameters supplied by PfT in the original nonsensical page of arithematic. If those parameters were so worthy of rolled eyes then take it up with PfT.

However all PfT did to 'correct' their own nonsense was draw a picture and , with no explanation as to how they determined that their radial lines were perpendicular to a tangent of the arc they drew, fudged their way through to arrive at even larger g acellerations than they got using the original nonsense.

PfT will not however deign to try using the same math on any flight path that the plane might take to do what is claimed, fly from over Columbia Pike to a point(any point) that could be characterized as NoC to a point over(or at least close to) the accepted point of contact with the Pentagon wall, and having that flight path be consistent with all witness descriptions of a fast and low aircraft (low enough to fool people into believing it hit a low floor of the Pentagon) that did not display extreme bank angles.

Why no pretty drawings of the NoC flight path with radial lines and lateral g forces calculated? Why no pretty drawings showing the plane below the roofline of the Pentagon as it passes by the Citgo and then over the Pentagon as it passes over that building? Instead, only handwaving arguements about how the actual flight path cannot be analyzed?

No, that's not how electricity works. The signal is present at all times, when
the DFDAU is ready to clock-in the 'value', it will read the most recent transmitted
data from the device (IE: every 42 msec max).

Rockwell has no interest in how often the DFDAU polls, collects, ingests data from it's or any other reporting device.

Rockwell's spec is for how long their (Rockwell's) device takes to process signals and create a signal ready for the DFDAU to poll, collect or ingest.

This says nothing at all about how long it takes to get the radar data into memory. Perhaps you want how accurate the radar data is at the o/p signal of the radar. If the aircraft altitude above the ground was changing by 50 feet per second ( due to changes in the surface and the climb/desent rate of the aircraft), the difference between the altitude (agl) at the moment that the signal was received by the radar, to the time a signal was presented at its o/p, for the DFDAU to poll, collect or ingest at some later point in time, is about 2 feet



L3, and Rockwell now! Do either of these companies support the conclusions reached by PfT?
Why does PfT continue to argue inccessantly with internet persona whom they (PfT) claim do not have the expertise to offer any intelligent counter to PfT's claims? Why does PfT steadfastly refuse to write up a consise and objective technical paper illustrating how they arrive at the conclusion that the FDR data shows a grossly different flight path than the one illustrated by the lamp post damage?

 

[bje]

does the flight data recorder show it pull up over the pentagon?

The security cam video sure doesn't

Even Balsamo shows us what the security camera should have recorded.

But whats this? in three frames i see mysterious debris appear right there at the curb. from what CIT calls a "Hollywood shock and awe" fireball almost 600 feet away. if the demolition explosion was contained deep within the 16 foot hole in a blast resistant building. How did this debris make it all the way to the gate house almost parallel to the face of the building? Im just asking questions turbofan. Can you elaborate for us?

Of course Turbofan can't. Neither can Craig Ranke who claims the security camera was "obviously tampered with."

 

[jaydeehess]

No they are not inconsistent. You are just not taking into consideration the
other bits of information that go along with the hard data. Parity bits, sync
bits, SDI (source/destination identifier), etc.

How would adding compression time, and more data points such as parity and sync or identifiers, (alll done in the DFDAU or a CPU prior to sending to flash) make the time between a device being polled for its signal to the time that signal is represented by a data word safely ensconced in flash memory, any shorter?

If the data rate is 256 words per second and the buffer only begins writing that word to memory after it has collected all the data for a 256 word frame( which will take one second) then it is going to be longer than 0.5 seconds before the first device's signal is represented by a data word in a flash memory location. Thus your interpretation of the 0.5 second spec must be incorrect.

Thank you MacGyverS2000. I could see that an erase block was much larger than a write block, you confirm that. I am not sure that TF understands this.

If an erase block is 40 times larger than a FDR data frame of 256 12 bit words, it would be quite feasible for 4-6 frames (4-6 seconds worth of flight data) to have been written to a block that had just been erased when a non-standard condition caused that block to be erased again.

 

[Jonnyclueless]

Turbofan, when can we expect your "circle of experts" to submit a paper detailing there findings in a respected engineering journal? Or is it really about pwning people on the internet and selling merch so Cap'n Bob doesnt have to get a job?

He's already stated that they have no intention of doing so and instead just want to sell DVDs.

 

[R.Mackey]

Read it. So I guess plane just emit white smoke and drop engines for no
apparent reason. Nothing happening under that fuselage skin prior to those
pieces falling off. I mean the white streak could have been milk from the
food cart for all we know...

All of which verifiably happens after the FDR record ends.

Are you sure you read the report?

Not satisfactory and seems impossible from a flash memory design standpoint.
This is the reason we're debating your theory.

I don't see you debating it anywhere. The simple fact is that voltage transients can cause damage to flash memory through a variety of mechanisms, including but not limited to improper block erase, tunnelling, parasitic capacitance, bridging faults, physical board-level faults due to cold solder joints or flexure, and the flash controller going berzerk. This is verified by experiment, in the papers I showed you before, and I have no doubt you haven't bothered to look at.

AA 587 shows a clear example of such weird behavior. Not quite identical, but once again, your position demands AA 587's record is also "impossible." You're wrong here, and you're wrong on AA 77. All you have to offer so far is excuses.

PFT took that rebuttal and ripped it apart using a scale layout and proper
equations. Your calcs are not even based on the flight data

You "ripped apart" nothing, and my calculation was based on Cap'n Bob's setup of the problem. He set it up, he just couldn't solve it properly, despite it being a freshman High School algebra problem.

Besides, my calculations are not based on the flight data, because it occurs after the end of our data. They are, however, consistent with the flight data, and that's what matters.

No, that's not how electricity works. The signal is present at all times, when
the DFDAU is ready to clock-in the 'value', it will read the most recent transmitted
data from the device (IE: every 42 msec max).

No. The signal is not present at all times. The RADALT assembly only sends a signal on each pulse, after computation, and it may or may not be stored in a read-many register. Since you said the output was "ARINC-ready," that implies it's sent at intervals as part of a negotiated packet structure. It has nothing to do with "how electricity works."

What the DFDAU does with it is also not continuous and instant. It will surely wait to poll other information to merge it into a subframe. That takes time. Could be 125 milliseconds, could be seconds, who knows for sure -- you don't, because you haven't asked these questions. The specs you quoted have nothing to do with these design realities. You should find better advice, as you are clearly well out of your field if you believe, or expect me to believe, your claims.

There is nothing in the middle, that is what you fail to understand! You have
a length of wire connecting the device to the DFDAU. If you're so much
better than L3 and Rockwell, take the Tracking Number, write them back
and correct them.

Handled above.

My conversations and e-mails with them were very clear. There is no mistaking
the information, and I'm certainly not going to let you twist their reply into
something that makes sense for you! I specifically asked those questions to
put to rest the very garbage you are trying to spin yet again.

You asked the wrong questions of the wrong people. The people you need are at Boeing, not Rockwell or L-3. You need a systems-level perspective of the avionics and air data bus. This has been explained to you repeatedly in the 70+ pages of this thread.

And, what's worse, it doesn't matter. At worst, the AA 77 FDR record means the AA 77 FDR was out of spec. AA 587 proves this kind of behavior happens sometimes. You've failed to understand, let alone disprove, any of the various mechanisms that could lead to this situation, and furthermore you cannot provide an alternate explanation that makes any sense whatsoever.

Just try it, and see.

 

[Turbofan]

List the crash examples that have occured which meet your requirement that they are similar to AA77, or accept the examples of lost data from crashes that did occur, or admit that this was a once in a lifetime occurance.

I don't admit anything without a logical explanation my friend.

Not according to the flash memory expert you contacted and who was good enough to post here.

Yes, he is good for posting here. Have we determined how a few seconds
of info gets wiped out once written to memory? No, not yet.

Once that gets hammered out, you still have to deal with DME and clock
sync errors.

There is quite a bit to chew don't you think?

Which also means that Pft took their original page of meaningless arithmetic and ripped it apart. Mackey's calcs were based upon the parameters supplied by PfT in the original nonsensical page of arithematic. If those parameters were so worthy of rolled eyes then take it up with PfT.

The trouble is, Mackey's calcs are not based on the flight data.

PfT will not however deign to try using the same math on any flight path that the plane might take to do what is claimed, fly from over Columbia Pike to a point(any point) that could be characterized as NoC to a point over(or at least close to) the accepted point of contact with the Pentagon wall, and having that flight path be consistent with all witness descriptions of a fast and low aircraft (low enough to fool people into believing it hit a low floor of the Pentagon) that did not display extreme bank angles.

The reason for that is we believe in a flyover. It's easy enough to
throw together and a flight path NoC; I've already offered to do that.
This has already been covered in the other thread, so no need to go off
topic here.

This says nothing at all about how long it takes to get the radar data into memory.

That is correct so we've established the signal generation and transmit
time.

We also have the MAX allowable time of 500 msec for this signal to store
itself to CPM.

L3, and Rockwell now! Do either of these companies support the conclusions reached by PfT?

No, neither of them will comment (1000th time I've said this now), and neither
of them have submitted a statement supporting the OGCT. So they are
not taking any side, they are simply not commenting.

Why does PfT continue to argue inccessantly with internet persona whom they (PfT) claim do not have the expertise to offer any intelligent counter to PfT's claims? Why does PfT steadfastly refuse to write up a consise and objective technical paper illustrating how they arrive at the conclusion that the FDR data shows a grossly different flight path than the one illustrated by the lamp post damage?

Just trying to put to rest the myths that stem from people on this site.
Besides it's fun.

 

[bje]

I don't admit anything without a logical explanation my friend.

Then why do you claim the jet flew over the Pentagon? You can't claim that it did without positive evidence and you refuse to provide any evidence when asked.