Aal77 Fdr Decoder Program, Decodes almost 4 more seconds Options

[wstutt]

Spoke to one of my FDR guys. this is what he had to say...

....in any N.T.S.B. recreation in the past, when a cockpit instrument's data is 'FF' (flag trip) the recreation is done with the FLAG TRIP shown on the recreation, meaning the display is 'not real' any longer due to error and or out of tolerance information being shown. It never stopped them in the past for inclusion of 'FF' data, but always made the instrument FLAG (RED FLAG) trip visible in the recreation.
so I don't get what [wstutt] is saying....

Is he talking about the NTSB's flight simulation or CSV file here?

..... And again, makes no sense. What constructive good would that make the L-3 recovery rack and software for any crash investigation? The rack and software had to have met some certification criteria to be used for the data dump and recovery operation in the first place. For it not to pass muster to provide ALL OF THE DATA, beforehand, is way outside the realms of credibility. I know the government is incompetent and in some cases 'moronic' and 'stupid' but for the N.T.S.B. to do a shoulder shrug over this shit is ludicrous, and on it's face, laughable. I don't believe that is the case. Someone is telling a huge fib here.

I estimate that this problem would occur in no more than 25% of crashes involving this make and model of FDR. It could be a lot less than 25% if the errror correcting codes are usually recorded in the event of a crash. I also have two FDR files for aircraft that were not involved in accidents and they do not have this problem.

Perhaps your FDR guy would like me to walk him through the data? Perhaps he can organise a decode of the corrected file like I suggested? Perhaps he would like to join this discussion here?

In other words, ROSE (or RAPS) software do not have any type of "bug" as Warren asserts. If an FF code is detected and more data is written to the CSMU, it is displayed in the recreation, albeit flagged as bad data or 'not real'.

<snip>

Again, are we talking about the flight simulation or the CSV file here?

Warren.

[rob balsamo]

Is he talking about the NTSB's flight simulation or CSV file here?

I estimate that this problem would occur in no more than 25% of crashes involving this make and model of FDR. It could be a lot less than 25% if the errror correcting codes are usually recorded in the event of a crash. I also have two FDR files for aircraft that were not involved in accidents and they do not have this problem.

Perhaps your FDR guy would like me to walk him through the data? Perhaps he can organise a decode of the corrected file like I suggested? Perhaps he would like to join this discussion here?

Again, are we talking about the flight simulation or the CSV file here?

Warren.

Warren,

Both the Flight simulation (better known as animation recreation) and CSV file terminate data at both the same time, 09:37:44. They are identical (except of course for the altimeter setting on the descent).

The NTSB also claims the above is correlated with Radar and ATC transcripts in their Time Correlation report.

Basically, you are claiming that when the ROSE (and/or RAPS) software detects an "FF" code, it stops detecting anything further. You speculate it's due to some sort of bug.

You are wrong.

The FF code is a flag trip. The software utilized in Aircraft Accident Investigations throughout the globe recovers all data after an FF code, if any exists.

When such data is recovered, it is included in recreations, but flagged as bad data and/or "not real", due to the FF code. In other words, there is absolutely no legitimate reason why the NTSB would NOT include data after an FF code in their recreations, if in fact such data existed, real or not. There is also no legitimate reason that a flag trip code would be recorded 4 seconds prior to impact, unless of course you believe Ryan Mackey and his absurd Bird Strike theory.

As for you walking our FDR guy through the data, I'm sure he'll get a good laugh from that. Thanks.

Again, be sure to post the Legge paper here when it's done. We'll take a look when we have the time and then Legge (and you) can start the revisions, like his last paper.

[wstutt]

<snip>

Basically, you are claiming that when the ROSE (and/or RAPS) software detects an "FF" code, it stops detecting anything further. You speculate it's due to some sort of bug.

You are wrong.

<snip>

Rob,

Your FDR guy said

....in any N.T.S.B. recreation in the past, when a cockpit instrument's data is 'FF' (flag trip) the recreation is done with the FLAG TRIP shown on the recreation, meaning the display is 'not real' any longer due to error and or out of tolerance information being shown. ....

Does that mean an FF can only be triggered by a cockpit instrument? The error correction codes that caused the problem are generated internally by this make and model of FDR as the data is stored in the CSMU. There purpose is to allow the decoding software to detect whether the CSMU was corrupted and to correct single bit errors after the data was written. They are not received from any cockpit instruments.

As for you walking our FDR guy through the data, I'm sure he'll get a good laugh from that. Thanks.

<snip>

Good. When and where can your FDR guy and I discuss this?

Warren.

[rob balsamo]

Does that mean an FF can only be triggered by a cockpit instrument?

No.

The error correction codes that caused the problem are generated internally by this make and model of FDR

FF codes are generated by many FDR/DFDAU make and models... and at any portion during flight. (this can include the very beginning of a flight before it even leaves the ground)..... And when one is generated, there is a reason.

There purpose is to allow the decoding software to detect whether the CSMU was corrupted and to correct single bit errors after the data was written. They are not received from any cockpit instruments.

Wrong.

When and where can your FDR guy and I discuss this?

But Warren, dont you already have enough "experts" at J.REF? Anyone willing to put their name to their claims?

Has Beachnut figured out that the Boeing 767 A1NM Type Certificate Data Sheet includes altitude data, therefore the V-G diagrams offered are good up to almost 18,000 feet?

I've said too much.

Again Warren, let us know when you and Legge are ready to publish your "paper". No doubt it will be filled with speculation that is why you are here fishing for answers.

Get your answers from those you praise. Us real experts will correct your errors after you publish, if we have the time.

[wstutt]

<snip>

FF codes are generated by many FDR/DFDAU make and models... and at any portion during flight. (this can include the very beginning of a flight before it even leaves the ground)..... And when one is generated, there is a reason.

<snip>

The error correction codes that are used by this FDR are Hamming Code and Page Parity. Show me how they are equivalent to FF codes. Neither myself or anyone at J.R.E.F. are claiming that they are equivalent.

Also note that an "error correction code" is quite different from an "error code".

Warren.

[rob balsamo]

The error correction codes that are used by this FDR are Hamming Code and Page Parity. Show me how they are equivalent to FF codes. Neither myself or anyone at J.R.E.F. are claiming that they are equivalent.

Warren, not only does it seem it has to be pointed out to you what it says in the NTSB FOIA cover letters you received regarding the software used, but it appears it needs to be pointed out what you wrote just a few days ago.

http://www.warrenstutt.com/NTSBUpdateLette...2-10/index.html

See the "FF" you placed under "Original Value"?

Scroll down a bit on the above link.

There is a reason those codes are recorded and a reason the ones you substituted/modified were not.

Just like there is a reason the American Airlines DFL has different conversion factors and they didnt just pull them out of their ass to output "nonsense" (as you call it).

Again Warren, let us know when the Legge's paper is published, when we get the time, we'll look at it, then you guys can start the revisions. Just like his last paper. Be sure to include your theories as to why an FDR recorded FF codes 4 seconds prior to "impact". Try the Bird Strike theory. Mackey seems to like that one.

[wstutt]

Warren, not only does it seem it has to be pointed out to you what it says in the NTSB FOIA cover letters you received regarding the software used, but it appears it needs to be pointed out what you wrote just a few days ago.

http://www.warrenstutt.com/NTSBUpdateLette...2-10/index.html

See the "FF" you placed under "Original Value"?

Scroll down a bit on the above link.

There is a reason those codes are recorded and a reason the ones you substituted/modified were not.

<snip>

Rob,

I think I now see the misunderstanding here.

Did your FDR guy mean that when a parameter is invalid that all 1 bit's (which would be FF (hex) bytes) are recorded in that parameter's location within the DFL? If that is true, then I agree with him that the decoding software should have been able to handle that possibility without loss of data.

The FF (hex) bytes that I referred to in my letter are not for parameters within the DFL. They are for error correcting codes which are not parameters within the DFL. They are not data to be decoded. That's why my decoder ignores them. The first 1013 bits within each 128 byte page of the FDR file are data and the last 11 bits are error correcting codes. See figure 4.2-2 of this document (3.5MB) which shows the FDR memory layout. You can see "Hamming Code and Page Parity" towards the bottom left hand corner of the figure. The file layout is independent of the DFL.

Perhaps your FDR guy could communicate with me directly if he still disagrees or doesn't understand me.

Warren.

[rob balsamo]

There is no misunderstanding Warren.

Again, let us know when Legge's paper is published, when we get the time, we'll look at it, then you guys can start the revisions.

[rob balsamo]

Been awhile since i visited the Romper Room (it's so 2006). But with all the activity on this thread, i figured to see what your "experts" are saying...

Well, it appears Beachnut/jackcahill/10 other socks.... still hasnt recovered from his rumored stroke. He still hasnt a clue how to plot a Vg diagram. Poor guy.

Most of the others are the typical cheerleaders found in the Romper Room. Never confronting any real expert... instead cheering "Rah Rah!" to any idiot who comes along to support their bias.

But i did find this reply from Farmer interesting...

Of course the question is why those values were not recorded since at this point they seem to be pre-impact functions of the FDR. However, I suspect that is something that will remain in the realm of speculation.

Considering the fact Farmer is notorious for his flip-flop behavior, and the fact we have predicted many times when he would flip and then flop, i foresee another flip on the way.

Very good Farmer. None of you can explain exactly why there is FF posted as an Original Value "pre-impact".

Again, you might want to stick with Mackey's Bird Strike Theory.

BTW Warren, your claims in your latest letter to the NTSB does not match your "AAL77 Hamming Code and Page Parity Checker".

Then again, if past experience with you is any indication, i pretty much expected it wouldnt.

Good luck on that Legge paper!

[wstutt]

<snip>

BTW Warren, your claims in your latest letter to the NTSB does not match your "AAL77 Hamming Code and Page Parity Checker".

<snip>

Rob,

In what way do my claims not match? Can you give details?

Warren.

[rob balsamo]

Rob,

In what way do my claims not match? Can you give details?

Warren.

Your File Offset (Hex) values for incorrect Hamming codes in your checker output file are not the same Hex values as described in your letter to the NTSB for the incorrect values.

Matter of fact, the File Offset values in your letter to the NTSB are no where to be found in your checker output file.

[wstutt]

Your File Offset (Hex) values for incorrect Hamming codes in your checker output file are not the same Hex values as described in your letter to the NTSB for the incorrect values.

Matter of fact, the File Offset values in your letter to the NTSB are no where to be found in your checker output file.

There's a good reason for that Rob.

Note the following from the description of the parameters in the output file of my checker program.

File Offset
This hex value is the offset in bytes of the beginning of the page from the beginning of the file.

The Hamming code and page parity are stored in the last 11 bits of the 128 (80 (hex)) byte page. These bits are located in the last two bytes of the page which are offset 7E (hex) and 7F (hex) from the beginning of the page. The offsets from the beginning of the page need to be added to the file offset of the beginning of the page to find the file offsets of the bytes containing the Hamming code and page parity for that page.

The pages which my checker found to have incorrect Hamming codes and page parities begin at file offsets 38972A (hex) and 39952A (hex)

For the page which has the file offset beginning at 38972A (hex), the Hamming code and page parity is located in the bytes with file offsets 38972A (hex) + 7E (hex) = 3897A8 (hex) and 38972A (hex) + 7F (hex) = 3897A9 (hex).

For the page which has the file offset beginning at 39952A (hex), the Hamming code and page parity is located in the bytes with file offsets 39952A (hex) + 7E (hex) = 3995A8 (hex) and 39952A (hex) + 7F (hex) = 3995A9 (hex).

You can check these calculations with the Windows calculator or a hand held calculator that can work in hex.

I only changed the bytes containing the Hamming code and page parity for each of the two pages which had an incorrect Hamming code and page parity i.e. the bytes with offsets 3897A8 (hex), 3897A9 (hex), 3995A8 (hex) and 3995A9 (hex) as calculated above and that I listed in my letter to the NTSB.

Warren.

[wstutt]

Been awhile since i visited the Romper Room (it's so 2006). But with all the activity on this thread, i figured to see what your "experts" are saying...

<snip>

I'm curious Rob,

Why do you call them my experts?

Warren.

[rob balsamo]

Thanks for your explanation Warren, and for posting it publicly.

As you can see, I have moved this thread to the debate forum as much of the last few pages have been mostly speculation and theory which is up for debate.

Much ground has been covered and positions made clear regarding the data sets offered in this thread. I highly recommend readers start from page 1 if they havent already. Anything more will be repetitive.

If Legge ever gets around to publishing his paper, we may have more to add.

[rob balsamo]

More from my FDR Guy -

....what Stutts is saying, is that impartial or 'short' frames which would have seriously fucked up or missing altogether error correcting codes (parity checking) at the end of each frame, would negate further examination. This is not true. Once 'async' frames are encountered, it is normal procedure to look at the bit stream and look for any reference markers of any kind in the data, and then try to decode that data not using 'automated' methods. I call it 'data rocking' when you take the data stream and dump it to a recorder or tape, so you can 'rock it back and forth' if you don't have a good digital sample and hold method of doing this. I prefer an 'analog' method of looking at 'async' data in this way.

[wstutt]

More from my FDR Guy -

....what Stutts is saying, is that impartial or 'short' frames which would have seriously fucked up or missing altogether error correcting codes (parity checking) at the end of each frame, would negate further examination. This is not true. Once 'async' frames are encountered, it is normal procedure to look at the bit stream and look for any reference markers of any kind in the data, and then try to decode that data not using 'automated' methods. I call it 'data rocking' when you take the data stream and dump it to a recorder or tape, so you can 'rock it back and forth' if you don't have a good digital sample and hold method of doing this. I prefer an 'analog' method of looking at 'async' data in this way.

Rob,

If I understand him correctly, what your FDR guy is suggesting with the 'data rocking' method is that when some data is lost, subsequent data from the bit stream can be decoded by attempting to find it's start position in the DFL perhaps (I'll speculate here) by looking for a close match with previous good subframes or by eliminating impossible or unlikely start positions in the DFL due to the impossible or unlikely values that would be decoded.

Also, If I understand him correctly, 'automated' methods would be searching for the sync words at the start of each subframe.

I could see either of these methods being useful when working with uncompressed data.

If I understand him correctly, a decoding program will use 'automated' methods, although the 'data rocking' method could be used to manually patch up the data so that a decoding program could then decode it.

Have I understood him correctly?

When he says "would negate further examination", does he mean manually or with a decoding program?

Is he reading this thread?

Warren.

[rob balsamo]

Is he reading this thread?

Warren.

He has read it, yes, and I dont think you want to know most of what he is saying. I don't think he'll read much more... unless perhaps I ask. But i digress.

Here is some Q&A I had with him that may help.

Q - What would cause an error correcting code of FF in a parity check?

A - depends on where in the FDR this happens, frame by frame, the FDR has to take all data and
then code it, and unless it truth table compares validity data ranges per each data field in the frame prior to shipping it to memory, virtually should not happen till farther down the data path than the input data path to the FDR. In other words, to my knowledge, no known FDR truth table compares data fields in the stream before writing them to memory, so an FF (failed data) shouldn't happen till the memory write operation, where data accuracy coming in is not a question, but final data stream bit encoding into compressed HUFFMAN format occurs. then it can occur, but not before then.


Q - Would [FDR Recovery] software just stop recovery with an incorrect or unrecorded parity check value?

A - no.


Q - Can you expand on this? How does the software recognize an incorrect code, and how does it continue recovery beyond an unrecorded or incorrect code?

A - the software should show a parity bust in a red data box somewhere on the screen, and then still decode until there is absolutely no parity integrity of any kind left, and if it doesn't do this, then it potentially misses a lot of crash data due to busted parity that is NOT necessarily the end of the usable data record, by any means.

it would make no sense that it would stop at the first parity bust, for a number of reasons. and if I were the decoding person, I would have rerun the decode any number of times to make sure that the problem wasn't a bench setup issue. something as dumb as a 'ground loop' due to improper setup can cause just enough noise on the decode to cause data to bust parity even if it for the most part passes it. and to be honest, a known 'decode' of crash data should be run to see if the decoding of known degenerated crash data is decoded properly before submitting the actual crash data to the rack for decode. for a decode of this importance, you want to make sure your setup is totally correct and that you didn't hook up something that creates a noise issue that could cause an improper parity bust on good data that might pass on a second or third decode attempt. and to be honest, if I had to rely on an automated process, I'd make sure that I went for '10' out of '10' decodes, and then run a known decode again to validate, post decode of crash data, my test rig. but that's how I would do it, even if it meant stepping out of the boundaries of an over simplified procedure that is too basic to cover ground loops and noise on data busses.


I've troubleshot too many weird data bus issues that other 'digital' or 'bit bucket boys' who write code, had no idea what I was working on, on any number of systems which had ground loops (low frequency) that were present enough to cause some data integrity issues that nobody knew where they were coming from.

for me to wonder 'why' the N.T.S.B. would stop on the first 'FF' parity bust, is like me wondering why you didn't walk exactly, step by step, into your house or apartment the same exact way, twice, in one day. sounds goofy, but this process here is the kind that due to the very nature of it, should require pre-decode setup verification by probably a 'second person' and then a 'post data extraction' validity check to make sure the other guy did it all correctly.

I have a real problem with a 'parity bust' stopping decoding from a CPM core dump...strictly because even bad parity data that fails CRC checking protocols, may contain recoverable data that can be decoded and then analyzed. Until the CPM data totally degenerates down to total nothing data, fully asyncronous and mostly just errors due to the FDR disintegrating and failing itself, this shit should not be the place the NTSB's analysis would end at. There is a point where you have to just say that the data has degenerated to useless garbled crap, but the first 'FF' fields is not that place. Eventually you do get to that point, however. but not before a whole lot of indicators in the actually decoded data shows what disintegration and sensor losses have already happened, perhaps 100 or more milliseconds before EOR occurs. (END OF RECORDING)

here's the deal with this, nobody is going to convince me that the FDR could be installed in the plane without verifying it had been set up at the L-3 factory, per Boeing information to them, with the proper AC ID and FLEET ID data so the FDR could write that in the preamble, linking that CPM core to the airplane. And until some asshole with credibility shows me how that can happen on that plane, and still pass BIT test each power up in that state, because that shit is part of the system checks the firmware on the FDR does checks on with it's own PARITY testing of preamble data, then I just cannot buy this shit as reality. And you shouldn't either, because it's not. And nobody, not Jim Ritter [signed off on NTSB Flight Path Study] or Jesus H. Christ, is going to convince me otherwise, based on those two data fields being missing, regardless of the other bullshit they float about this crap. Because that missing preamble data is not missing because of equipment malfunction. It's missing because it was purposely OMITTED.


it just all comes down to two data fields being zeroed out. no tickee, no laundry. without those, there can and can never be any linkage of the FDR to an 'N' number in the F.A.A. registry. not because the 'N' number is in the AC ID field, but the AC ID FIELD number is directly traceable to an N-Number in the F.A.A. registry, and the FLEET ID shows which carrier it went to.

those missing, that crap could come from anywhere. and without it, I'm not buying it. it's that simple.

nobody flies boxes with that data zero'ed out or missing. without this data in the CPM, in the preamble, there can be no linkage to an aircraft N-Number.

I saw that on the first look....

....the test person who extracted that data should have seen the NO ACFT ID and NO FLEET ID and said; "oh, this is such bullshit" and then asked his supervisor why they were asking him to decode BULLSHIT.

Considering the NTSB offers a NTSB Flight Path Study, and calculates the "impact" time at 09:37:45, correlated to Radar and ATC Transcripts, one would think they would have performed an exhaustive recovery of all data.

There is much more we talked about, but i'll save that for when Legge puts all his eggs in your decode basket.

[wstutt]

He has read it, yes, and I dont think you want to know most of what he is saying. I don't think he'll read much more... unless perhaps I ask. But i digress.

Here is some Q&A I had with him that may help.

<snip>

here's the deal with this, nobody is going to convince me that the FDR could be installed in the plane without verifying it had been set up at the L-3 factory, per Boeing information to them, with the proper AC ID and FLEET ID data so the FDR could write that in the preamble, linking that CPM core to the airplane. And until some asshole with credibility shows me how that can happen on that plane, and still pass BIT test each power up in that state, because that shit is part of the system checks the firmware on the FDR does checks on with it's own PARITY testing of preamble data, then I just cannot buy this shit as reality. And you shouldn't either, because it's not. And nobody, not Jim Ritter [signed off on NTSB Flight Path Study] or Jesus H. Christ, is going to convince me otherwise, based on those two data fields being missing, regardless of the other bullshit they float about this crap. Because that missing preamble data is not missing because of equipment malfunction. It's missing because it was purposely OMITTED.


it just all comes down to two data fields being zeroed out. no tickee, no laundry. without those, there can and can never be any linkage of the FDR to an 'N' number in the F.A.A. registry. not because the 'N' number is in the AC ID field, but the AC ID FIELD number is directly traceable to an N-Number in the F.A.A. registry, and the FLEET ID shows which carrier it went to.

those missing, that crap could come from anywhere. and without it, I'm not buying it. it's that simple.

nobody flies boxes with that data zero'ed out or missing. without this data in the CPM, in the preamble, there can be no linkage to an aircraft N-Number.

<snip>

Rob,

Here's the text preamble in the .FDR file

CODE

// L3 Communications, Aviation Recorders
VERSION = 1
SEGMENT = 1
TYPE = FULL
FIRSTBLOCK = 0
NUMBLOCKS = 192
LOOPBLOCKS = 192
CUR_INDEX = 28 19328 28 19072
;EOH

Other people have also posted it e.g. here

Unfortunately, according to your FDR guy, since there is no AC ID FIELD or FLEET ID fields, the FDR file warrants no further consideration so there is no point me addressing his other points.

I have 4 other .FDR files from L3 Communications recorders and although their preambles have some fields that the above preamble does not, none of them have AC ID FIELD or FLEET ID fields either, so according to your FDR guy, my source should have been ignored them rather than ask me for help in decoding them.

If hypothetically someone wanted to falsify the AC ID FIELD and FLEET ID fields, why would they remove them? Why just not change them to the values we are expecting to see and therefore raise less suspicion?

Can your FDR guy show me some preambles from other L3 Communications recorders that do have the AC ID FIELD and FLEET ID fields?

I saw that on the first look....

....the test person who extracted that data should have seen the NO ACFT ID and NO FLEET ID and said; "oh, this is such bullshit" and then asked his supervisor why they were asking him to decode BULLSHIT.

Since this was supposedly standard practice, has anyone else raised this point? I'm talking specifically about what procedures the test person who extracted that data should have followed.

Also, why didn't UnderTow raise this issue when he got his decode done? Surely the decoding software would have warned of this? That would conclusively have shown the FDR data to be fake long ago.

Considering the NTSB offers a NTSB Flight Path Study, and calculates the "impact" time at 09:37:45, correlated to Radar and ATC Transcripts, one would think they would have performed an exhaustive recovery of all data.

I agree, however in this case they didn't which is why I wrote to them.

There is much more we talked about, but i'll save that for when Legge puts all his eggs in your decode basket.

Is there much point? According to your FDR guy, he has shown the FDR file to be fake, making the NTSB's decode, the Readout2 decode by UnderTow and my decode all irrelevant.

Perhaps you should put out a press release that the FDR data has been proven to be fake because it is missing the AC ID FIELD and FLEET ID fields. Wouldn't that be more conclusive evidence than your other claims?

Warren.

[rob balsamo]

Perhaps you should put out a press release that the FDR data has been proven to be fake because it is missing the AC ID FIELD and FLEET ID fields. Wouldn't that be more conclusive evidence than your other claims?

Warren.

As i have stated many times in the past....

If the FDR data being provided through the FOIA is fake, it is as alarming as it being accurate. I have repeated this many times over the years.

If the FDR data is fake, it is a felony. Tampering with evidence.

If the FDR data is real, it is a felony, as it does not support the 9/11 Commission Report claims in many significant ways including that a standard 757, N644AA, impacted the Pentagon, for either the NTSB decode, or yours.

Again Warren, this has all been explained right here in this thread, on this forum and through many of my interviews with more to come. We are just repeating ourselves at this point.

Warren, do you think the data is authentic/real? If so, can you please provide your evidence as the FBI and NTSB have failed thus far.

However, it is interesting that a person like Frank Legge, someone who is highly critical and skeptical of the NIST data and reports, is now attempting to use unverified data from another govt agency to support the govt story regarding a Pentagon impact. Legge's motives are even more puzzlling especially when that data in fact conflicts with an impact, performance limitations set by the manufacturer based on wind tunnel and flight testing, and precedent.

Anytime you wish to share your other claimed FDR files, so others can verifiy, feel free to post a link.

[Parrotsfor911tru...]

Sorry I don't get it. If the presented FDR data cannot be linked to Flt 77 then what ever scenario it apparently puts forth is irrelevant.
You cannot meaningfully use it to demonstrate that Flt 77 either did or did not hit the Pentagon.
All other evidence presented apparently confirms that a 757 did impact the Pentagon.
The important question is the actual identity of that aircraft and its previous history.