Flight Data Expert Confirmation: No Evidence Linking Fdr Data To American 77, FDR Data Exceeds Capabilities Of A 757, Does Not Support Impact Rating Options

[rob balsamo]

Flight Data Expert Confirmation: No Evidence Linking FDR Data to American 77
FDR Data Exceeds Capabilities Of A 757, Does Not Support Impact With Pentagon

(PilotsFor911Truth.org) - Flight Data Recorder Expert Dennis Cimino has confirmed that the data being provided through the Freedom Of Information Act (FOIA) by the National Transportation Safety Board (NTSB) is missing crucial information, which according to Dennis, should be present and link the data to a specific aircraft and fleet. The NTSB provided three sets of data through the FOIA for what they claim is from American 77, N644AA. A csv file, an animation reconstruction and a raw data file. Rob Balsamo of Pilots For 9/11 Truth along with numerous other aviation experts, including trained Aircraft Accident Investigators have analyzed these files and determined they do not support an impact with the Pentagon. The data also exceeds the design limitations and capabilities of a standard 757 by a wide margin. This is based on data, precedent and numerous verified experts, including those who have actual flight time in the aircraft reportedly used for the 9/11 attacks (See - "Flight Of American 77", "9/11: Attack On The Pentagon" and "9/11: World Trade Center Attack" at Pilotsfor911Truth.org for full detailed analysis and interviews).

One file in particular, the compressed binary raw file alleged to be a direct data dump from the Flight Data Recorder, was recently analyzed by an alleged computer expert. He has claimed to decode 4 more seconds worth of data, above and beyond the NTSB decode, although the "additional" data has not been verified by anyone. The claim was made that the reason the NTSB did not decode this "additional" data is because the software used by the NTSB, along with the software used by the manufacturer of the FDR (L3 Communications), has an alleged "bug". If correct, this has grave consequences for Flight Safety as Flight Data is used in the promotion of safe flight through changes in regulation and procedure. The NTSB and L3 have been contacted, along with an Aviation Safety Report being filed with NASA. There hasn't been any reply confirming such a "bug".

A paper was recently published by the mentioned computer "expert" along with an alleged Chemist as the authors. They claim the extra 4 seconds support an impact with the Pentagon. They base this claim on a Radio Altimeter parameter in which the NTSB has listed as "Not Working or Unconfirmed" in the NTSB FDR Report(1). When cross-checked with the "Working and Confirmed" Primary Altimeter True Altitude data, the aircraft is still too high to hit the Pentagon(2). This can only mean that the Radio Altimeter was measuring from an object above ground level.

Radio Altimeters do not guarantee measurement from the ground. The device measures whatever object you are flying over within a certain range (a building, trees... etc). The tracking capability of the Radio altimeter is 330 feet per second, or a little under 200 knots(3). According to the data, the aircraft was traveling at a speed of 460-480 knots. Well outside the limits of the Radio Altimeter tracking capability, not to mention well outside the capabilities of a standard 757.

It is interesting that the authors, editors and Journal in which the above mentioned paper is published is highly critical and skeptical of the National Institute Of Standards And Technology (NIST) data and reports with respect to the collapse of the World Trade Center, yet is now attempting to use unverified data from another government agency to support the government story regarding a Pentagon impact. Motives are even more puzzling especially when the NTSB data in fact does not support an impact while exceeding the performance limitations and capabilities of a standard 757 as set by the manufacturer based on wind tunnel and flight testing, by a wide margin. This is also corroborated by precedent. It is also clear the paper was not reviewed by any aviation expert prior to publish, as it is littered with speculation and gross errors. For more information regarding this paper and the numerous errors it contains, please see the discussion at the Pilots For 9/11 Truth Forum(4).

FDR Expert Dennis Cimino further goes on to state:

[I]t just all comes down to two data fields being zeroed out. no tickee, no laundry. without those, there 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.

[T]hose missing, that [data] could come from anywhere...


[N]obody flies boxes with that data zero'ed out or missing. without this data in the CPM [Crash Protected Memory], 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.

Dennis Cimino experience and qualifications:

Electrical Engineer
Commercial Pilot Rating, since 1981
Navy Combat Systems Specialist: RADAR, ECM, cryptographic communications
Flight Data Recorder Engineer Smiths Aerospace
BA-609, IDARS, Military and Commercial
Millimeter wave RADAR and countermeasures expert since 1973
Two patents held for Doppler RADAR ( Kavouras ):
long pulsewidth RADAR droop compensation network,
and wave guide arc detection for high powered RADAR

Further confirmation that there isn't any evidence linking the FDR data to "American 77", tail number N644AA is discussed here:

Can The Govt Get Their Story Straight? - Location Of Flight Data Recorder

Lies, Conflicting Reports, Cover-Up's - Location of American 77 Flight Data Recorder - Part II

9/11 Aircraft 'black Box' Serial Numbers Mysteriously Absent

Interview With Flight Data Recorder Expert

So, if the data is not from N644AA, does not support an impact at the Pentagon, and in fact exceeds the capabilities and performance of a standard 757, what caused the damage at the Pentagon? That is exactly what Pilots For 9/11 Truth are trying figure out and the reason there needs to be a new and truly independent investigation. Some wish to ignore this data, some without expertise attempt to analyze it while attempting to say, "nothing to see here folks, move along..". Please write your Congressional Representatives and Senators. Call into talk shows, tell them there is a growing list of aviation professionals who question the government version of events on 9/11. Tell them the data being provided through the FOIA does not support the government story.

Founded in August 2006, Pilots For 9/11 Truth is a growing organization of aviation professionals from around the globe. The organization has analyzed Data provided by the National Transportation Safety Board (NTSB) for the Pentagon Attack, the events in Shanksville, PA and the World Trade Center Attack. The data does not support the government story. The NTSB/FBI refuse to comment. Pilots For 9/11 Truth do not offer theory or point blame at this point in time. However, there is a growing mountain of conflicting information and data in which government agencies and officials refuse to acknowledge. Pilots For 9/11 Truth Core member list continues to grow.

http://pilotsfor911truth.org/core.html for full member list.

http://pilotsfor911truth.org/join to join.

(1) http://www.ntsb.gov/info/AAL77_fdr.pdf
(2) http://pilotsfor911truth.org/forum/index.p...&p=10778240
(3) http://www.rockwellcollins.com/ecat/at/LRA-900.html
(4) http://pilotsfor911truth.org/forum/index.php?showtopic=20960

[rob balsamo]

Looks like you have another problem Warren. The 757-3b_1.txt sampling rate is no where near the rate of your alleged A/C and Fleet ID fields.

You wouldn't happen to be feeding us more garbage would you?

By the way, your Type field also further conflicts with Aircraft Identification as N644AA is not a 757-200 technically... It is a 757-223.


Legge, Jones, Ryan... did you guys get anyone to verify the data Warren has "decoded" prior to publish?

It's already clear you didnt consult an aviation expert, because if you did, they would have immediately caught the wrong FAR sourced and the foundation for your "paper"..... This is basic stuff for even a private pilot.

It stuck out like a sore thumb to me. Thanks for the laughs though.

[wstutt]

Looks like you have another problem Warren. The 757-3b_1.txt sampling rate is no where near the rate of your alleged A/C and Fleet ID fields.

You wouldn't happen to be feeding us more garbage would you?

Good spotting Rob! I missed that 0.25 Hz sampling frequency. It's another example of a problem with this DFL.

What do you think the 15 listed under Frame(s) heading for those parameters means? Why doesn't it say ALL like some other parameters? Hint: Do you think those parameters could be recorded once every 64 seconds (0.015625Hz) rather than once every 4 seconds (0.25Hz)?

By the way, your Type field also further conflicts with Aircraft Identification as N644AA is not a 757-200 technically... It is a 757-223.

There is no code for 757-223. The codes are listed in section 3.1 of the Boeing data frame layout document. There are only 4 codes 757-200 RR, 757-200 PW, 757-300 RR and 757-300 PW.

Legge, Jones, Ryan... did you guys get anyone to verify the data Warren has "decoded" prior to publish?

Show me where in the code that my decoder program adds the extra data that I supposedly made up.

It's already clear you didnt consult an aviation expert, because if you did, they would have immediately caught the wrong FAR sourced and the foundation for your "paper"..... This is basic stuff for even a private pilot.

It stuck out like a sore thumb to me. Thanks for the laughs though.

The FAR reference is trivial. More soon.

Warren.

[rob balsamo]

Do you think those parameters could be recorded once every 64 seconds (0.015625Hz) rather than once every 4 seconds (0.25Hz)?

Not according to American Airlines.

Show me where in the code that my decoder program adds the extra data that I supposedly made up.

So, in other words, Legge, Ryan nor Jones have verified your data, but published it in their "peer-reviewed" Journal. Not surprised. Not to mention the fact that the parameter you are using is listed as "Not Working or Unconfirmed" by the NTSB. Perhaps they listed it as such because it was flying so far outside it's tracking capability that any data retrieved from it is garbage? Ya think?

The FAR reference is trivial. More soon.

Warren.

Then why is it in your "Scientific" paper?

So, in other words, you havent found your errors regarding the FAR.

Your whole paper is based on an FAR you referenced for Altimeter errors. You quoted the FAR for a Cessna 172, combined with the FAR at Wiki is quoted wrong. It is not for the "operational speed range" of the aircraft.

Once you learn the correct FAR, combined with an Air Data Computer, you'll realize your whole paper is garbage.


Warren, still waiting for you to answer our questions. Why do you keep avoiding therm?

When are you going to provide the other FDR files which you claim are also missing AC ID and Fleet ID so they can be cross-checked? Can you please tell us which flights they are alleged to have came from?

Have you figured out yet that you have used the wrong FAR as the whole premise for your "paper"? Combined with the fact that the wiki source you provided has the FAR quoted incorrectly? (this one you partially answered... but still got wrong)

Can you also walk us through this equation using the last Pressure Altitude data point?

Static pressure (in Hg) = 29.9213 * (1 – 0.0019812 * A / (273.15 + 15)) ^ (32.174 / (0.0019812 * 3089.8))
where A = raw altitude (ft).
True Altitude (ft) = ((273.15 + T) / 0.0019812) * (1 – (P / S) ^ (0.0019812 * 3089.8 / 32.174))
where T = temperature at sea level (deg C); P = static pressure (in Hg); S = altimeter setting (in Hg).


Why have you not provided output files for the previous flights listed in your paper? Are laymen supposed to just take your word for it?

[wstutt]

Rob,

<snip>

Warren, still waiting for you to answer our questions. Why do you keep avoiding therm?

I have now answered your questions here, here, here, here and here.

When are you going to provide the other FDR files which you claim are also missing AC ID and Fleet ID so they can be cross-checked?

What would providing the other FDR files prove? If you fail to find the AC IDs and Fleet IDs, what's to stop you claiming that I removed them? You already think I fabricated the last 4 seconds of data for AAL77:

<snip>

My opinion?

I think I could have fabricated 4 seconds of data in less time than it took Warren, using Microsoft Flight Simulator or Xplane. (both output .fdr files)

Can you please tell us which flights they are alleged to have came from?

<snip>

I wasn't told which flights they were from or even which airline. It wasn't necessary for me to know that to help my source decompress the files.

Warren.

[rob balsamo]

Rob,

I have now answered your questions here, here, here, here and here.

None of the above answered my questions.

Here they are again, with a few more.

Have you figured out yet that you have used the wrong FAR as the whole premise for your "paper"? Combined with the fact that the wiki source you provided has the FAR quoted incorrectly? (this one you partially answered... but still got wrong). If the FAR is so "trivial" why is it in your "Scientific" paper attempting to support your claims of "Altimeter errors"? If the paper was "peer-reviewed", why was this not flagged as the incorrect FAR? Do you intend to correct it?

Can you also walk us through this equation using the last Pressure Altitude data point?

Static pressure (in Hg) = 29.9213 * (1 – 0.0019812 * A / (273.15 + 15)) ^ (32.174 / (0.0019812 * 3089.8))
where A = raw altitude (ft).
True Altitude (ft) = ((273.15 + T) / 0.0019812) * (1 – (P / S) ^ (0.0019812 * 3089.8 / 32.174))
where T = temperature at sea level (deg C); P = static pressure (in Hg); S = altimeter setting (in Hg).


Why have you not provided output files for the previous flights listed in your paper? Are laymen supposed to just take your word for it?

What would providing the other FDR files prove? If you fail to find the AC IDs and Fleet IDs, what's to stop you claiming that I removed them?

So in other words, you made a claim you refuse to back up. Are you now saying that such data does not exist anywhere in your other FDR files? If so, why is Legge claiming they are "authentic"? (see below).

You already think I fabricated the last 4 seconds of data for AAL77:

Wrong. Read it again. I said I could have fabricated the data faster than the time it took you [for your "decode"].

Better?

I wasn't told which flights they were from or even which airline. It wasn't necessary for me to know that to help my source decompress the files.

Warren.

Then why is Legge claiming they are "authentic" in his "rebuttal" piece?

How can he claim them as "authentic" when you dont even know which flight they are from?

Let me guess, Legge lied. Big surprise.

[wstutt]

None of the above answered my questions.

Here they are again, with a few more.

Have you figured out yet that you have used the wrong FAR as the whole premise for your "paper"? Combined with the fact that the wiki source you provided has the FAR quoted incorrectly? (this one you partially answered... but still got wrong). If the FAR is so "trivial" why is it in your "Scientific" paper attempting to support your claims of "Altimeter errors"? If the paper was "peer-reviewed", why was this not flagged as the incorrect FAR? Do you intend to correct it?

I don't know whether we will correct it. Both Frank and I regard the FAR reference as trivial. Perhaps we'll just remove it.

Can you also walk us through this equation using the last Pressure Altitude data point?

Static pressure (in Hg) = 29.9213 * (1 – 0.0019812 * A / (273.15 + 15)) ^ (32.174 / (0.0019812 * 3089.8))
where A = raw altitude (ft).
True Altitude (ft) = ((273.15 + T) / 0.0019812) * (1 – (P / S) ^ (0.0019812 * 3089.8 / 32.174))
where T = temperature at sea level (deg C); P = static pressure (in Hg); S = altimeter setting (in Hg).

Substituting A = -99 ft in to the first formula gives
P = 29.9213 * (1 - 0.0019812 * (-99) / (273.15 + 15)) ^ (32.174 / (0.0019812 * 3089.8)) = 30.0285 inHg
Substituting T = 22.91 deg C, S = 30.2194 inHg and P in to the second formula gives
True Altitude = ((273.15 + (22.91)) / 0.0019812) * (1 - ((30.0285) / (30.2194)) ^ (0.0019812 * 3089.8 / 32.174)) = 180 ft

<snip>

Then why is Legge claiming they are "authentic" in his "rebuttal" piece?

How can he claim them as "authentic" when you dont even know which flight they are from?

Let me guess, Legge lied. Big surprise.

Perhaps you should ask him.

Since I don't know which flights the FDR files are from, then according to you, I can't show that they are authentic, so there's no point me releasing them is there?

Warren.

[rob balsamo]

I don't know whether we will correct it. Both Frank and I regard the FAR reference as trivial. Perhaps we'll just remove it.

So it appears you found your error. Very good. Now answer the rest of the questions please.

If it was so "trivial", why did you put it in your "Scientific" paper to support your argument? If the paper was "peer-reviewed", why was such a "trivial" (it's actually pivotal in your case) and elementary error made?

Let us know when your next revision comes out.

Substituting A = -99 ft in to the first formula gives
P = 29.9213 * (1 - 0.0019812 * (-99) / (273.15 + 15)) ^ (32.174 / (0.0019812 * 3089.8)) = 30.0285 inHg
Substituting T = 22.91 deg C, S = 30.2194 inHg and P in to the second formula gives
True Altitude = ((273.15 + (22.91)) / 0.0019812) * (1 - ((30.0285) / (30.2194)) ^ (0.0019812 * 3089.8 / 32.174)) = 180 ft

Warren, i asked you to "walk us through" the above calculation. Not show us the equations and their output.

Surely you know the difference?

Perhaps you should ask him.

Perhaps you shouldnt be using files to support your claims when you dont even know which flight they came from nor if they are authentic, nor provide such files to back up your claims.

Since I don't know which flights the FDR files are from, then according to you, I can't show that they are authentic, so there's no point me releasing them is there?

Warren.

Perhaps you shouldnt be using files to support your claims when you dont even know which flight they came from nor if they are authentic, nor provide such files to back up your claims.

For the fourth time Warren, why have you not provided output files for the previous flights listed in your paper? Are laymen supposed to just take your word for it?

[wstutt]

Rob,

<snip>

Perhaps you shouldnt be using files to support your claims when you dont even know which flight they came from nor if they are authentic, nor provide such files to back up your claims.

<snip>

Does it really matter which flights they came from? Remember we were only interested in verifying that there is no A/C NUMBER and FLEET IDENT in the text preamble since Dennis Cimino say they should be there, not decoding the files.

If the files were not authentic why would my source ask me for help decoding them? In other words, if they were not authentic why would I have them? Why would my source want to waste time working with me to decode files if he knew they were not authentic? So, I have no reason to think they are not authentic.

As far as I know, these files were extracted for FOQA, so there would be no accident records. Also, since my source does not live in the US, the flights and airline(s) could also be outside of the US.

You now have the A/C NUMBER and FLEET IDENT from the AAL77 FDR file. Is your organisation of aviation professionals going to verify them?

Warren.

[rob balsamo]

Rob,

Does it really matter which flights they came from? Remember we were only interested in verifying that there is no A/C NUMBER and FLEET IDENT in the text preamble since Dennis Cimino say they should be there, not decoding the files.

If the files were not authentic why would my source ask me for help decoding them? In other words, if they were not authentic why would I have them? Why would my source want to waste time working with me to decode files if he knew they were not authentic? So, I have no reason to think they are not authentic.

As far as I know, these files were extracted for FOQA, so there would be no accident records. Also, since my source does not live in the US, the flights and airline(s) could also be outside of the US.

You now have the A/C NUMBER and FLEET IDENT from the AAL77 FDR file. Is your organisation of aviation professionals going to verify them?

Warren.

Sorry, i missed the above.

We have already gone through this Warren. You have no evidence linking the data to any aircraft.

Read this statement from Dennis again, read slowly.

....to propose that AC ID and FLEET ID are buried in the flight parameter stream after the preamble, where it always always always is, is so beyond the pale and absurd,

Since you still might be confused, your "35" and "1", mean nothing.

Considering you admit your other files dont have a Fleet ID nor A/C number, they also mean nothing. Frank should stop lying when he makes the claim they are authentic if he has no evidence to support such claims.

Here, let me help you Warren...

These are the steps you need to follow in order to hold onto your theory.

First you need to get the NTSB to accept your "bug" theories and correct their possible errors. This will create a large domino effect in the aviation industry worldwide.

Then you need to get evidence linking your data to an actual 757 or N644AA.

Then you need to find data, precedent or perhaps at least one verified expert willing to put his name to the claim that the aircraft can operate 110-130 knots in the Structural Failure Zone as depicted below, pull G's, and remain controllable, stable or survive.

(IMG:http://i47.photobucket.com/albums/f178/myphotos1960/767_V-G_Diagram_Illustrated_Guide_To_Aerodynamics.jpg)

So far, all evidence, data, precedent and numerous verified experts agree, a standard 757 could not perform as depicted in the NTSB data, or yours.

Then you need to come up with a theory as to why the Altimeter was highly accurate in a phase of flight known for it's worst and expected errors, yet 100+ in error in a phase of flight where the static system is rated and calibrated (to Mach 0.86), while all other static system indications were functioning normally, particularly, the Airspeed data.

After you get done with all that, then you may actually have an argument. Then you will need to take on the multiple witnesses who "bet their life" on the fact that the aircraft observed approaching the Pentagon, was opposite the physical damage.

No amount of speculation on your part is going to make the above facts disappear. (Well, perhaps for you and Legge it will, but not for the rest of us)

[wstutt]

Rob,

I'll respond to some points for now.

<snip>

Read this statement from Dennis again, read slowly.

....to propose that AC ID and FLEET ID are buried in the flight parameter stream after the preamble, where it always always always is, is so beyond the pale and absurd,

OK, so Dennis is saying that the AC ID and FLEET ID are always in the preamble, but never in the flight data?

Then you need to get evidence linking your data to an actual 757 or N644AA.

I don't need to do that to check your claim that the data you received from the NTSB shows the plane was too high to hit the Pentagon.

<snip>

Then you need to find data, precedent or perhaps at least one verified expert willing to put his name to the claim that the aircraft can operate 110-130 knots in the Structural Failure Zone as depicted below, pull G's, and remain controllable, stable or survive.

<snip>

How about Jeff Scott. The following quote is close to the bottom of that page:

These restrictions do not mean it is impossible for a plane to fly at those conditions but that it is extremely hazardous to do so, and safety was obviously not a concern to the terrorists on September 11. An aircraft flying at those high speeds at low altitude would also likely experience shaking due to the loads acting on it, but commercial aircraft are designed with at least a 50% safety margin to survive such extremes.

Warren.

[rob balsamo]

Rob,

I'll respond to some points for now.

As you usually do with your trolling.

OK, so Dennis is saying that the AC ID and FLEET ID are always in the preamble, but never in the flight data?

That's what the man said. He has 30+ years as an FDR Expert. Who do you have? A Chemist? An idiot who cannot determine the difference between a Boeing 757 and an Airbus A320 and hasnt flown since before color photography was invented?

I don't need to do that to check your claim that the data you received from the NTSB shows the plane was too high to hit the Pentagon.

Glad you finally agree the NTSB data does not support an impact.

How about Jeff Scott. The following quote is close to the bottom of that page:

These restrictions do not mean it is impossible for a plane to fly at those conditions but that it is extremely hazardous to do so, and safety was obviously not a concern to the terrorists on September 11. An aircraft flying at those high speeds at low altitude would also likely experience shaking due to the loads acting on it, but commercial aircraft are designed with at least a 50% safety margin to survive such extremes.

Warren.

"Jeff" is either wrong or you are misinterpreting his statements. If he is attempting to equate G loading (150% margin) with Airspeed limitations and margins, he is wrong. But if he is a real pilot, and if my experience with you is any indication, you are misinterpreting what he is saying, to suit your bias. If my past experience with "aerospaceweb" is any indication, they attempt to positively identify an aircraft part through a photograph, using a human leg as a measuring device to conclude an "approximation". A part which Legge contradicts himself, and still has yet to correct from his last paper.

Vd is a hard limit and corroborated by precedent. The "Safety Margin" is between Vmo and Vd and is mandated by the FAA. There is no "additional" Safety Margin above Vd (as you and Legge attempt to speculate in your 'paper') let alone is there one 50% above Vd. This is why you do not have a source for such claims, nor precedent, while I do. I have repeated this to you numerous times. It seems to either fall on deaf ears, or... you only hear what you want to hear, or worse, you have an agenda.

Warren, do you know the difference between Vmo and Vd? While I was reading your paper, it appears you do not. This was another major red flag screaming to any pilot reading... "This paper was never really peer-reviewed".

Has Legge, Jones or Ryan verified your decode yet? You have already admitted they didnt verify anything prior to publishing your "data" in their alleged "peer-reviewed" Journal. Have they bothered to check now?

Warren, how do you think Aircraft are certified? Do you think they just pull numbers out of their ass? We went over this before as well. Not surprisingly, you avoided it.

Have you removed your incorrect FAR from your paper yet? Or are you leaving it in there for purposes of spreading disinformation as Legge is doing with his last paper regarding CWS "aiding hijacker control".

[wstutt]

Rob,

<snip>

That's what the man said. He has 30+ years as an FDR Expert. Who do you have? A Chemist? An idiot who cannot determine the difference between a Boeing 757 and an Airbus A320 and hasnt flown since before color photography was invented?

<snip>

I have both of the data frame layout documents that the NTSB used to decode the FDR file and that describe the locations of the parameters within the flight data. The document that the NTSB mainly used is from Boeing and has A/C NUMBER and FLEET IDENT parameters. Their location within the flight data is specified in their document. So do we believe Boeing that these parameters are stored within the flight data or do we believe someone who decided that the information wasn't in the FDR file because he couldn't see it in the only part of the FDR file he put in enough effort to interpret, namely the easily interpreted plain text preamble outside of the flight data?

<snip>

Warren, the reason the FAR in your paper was so pivotal, is because it describes when the largest errors occur, on landing, at high AOA, in the dirty configuration. You thought it was for all "operational speed ranges" of the aircraft in any configuration (+/- 30 feet per 100 knots) because that is what Wiki told you. You then used this as your theory for the possible error at such high speed at the Pentagon.

<snip>

No we didn't. Here's the part of the paper where the FAR is referenced.

US Federal Aviation Regulations appear to permit an altitude error up to +/- 30 feet per 100
knots,²⁷ which would give a maximum permitted error on final approach, ranging from 130
to 140 knots in the data file, of 39 to 42 feet. In none of the sets of landing data examined
was the discrepancy with radio height greater than 17 feet when recording of radio height
commenced, hence there is no reason to suspect that the altimeter was malfunctioning or
badly out of calibration, yet the observed errors were 50 to 83 feet just prior to normal
landings. It therefore appears that this calibration standard is not applied at low altitudes.

The FAR reference (²⁷) is used to conclude that an altitude divergence of 17 feet on final approach would not indicate that the altimeter was malfunctioning or badly out of calibration. We noted that it appeared to not be applied at low altitudes which would include the final moments of high speed at the Pentagon.

Have you found a technical explanation of what LRRA tracking capability means yet that has more technical details than "it gets behind"?

Warren.

[rob balsamo]

Rob,

I have both of the data frame layout documents that the NTSB used to decode the FDR file and that describe the locations of the parameters within the flight data. The document that the NTSB mainly used is from Boeing and has A/C NUMBER and FLEET IDENT parameters. Their location within the flight data is specified in their document. So do we believe Boeing that these parameters are stored within the flight data or do we believe someone who decided that the information wasn't in the FDR file because he couldn't see it in the only part of the FDR file he put in enough effort to interpret, namely the easily interpreted plain text preamble outside of the flight data?

The information used to link the data to the aircraft and Fleet is in the Preamble always according to Dennis, not to mention serial numbers are also used. The "35" and "1" you claim to have decoded means nothing. Feel free to call CAE Flightscape and ask. Tell them you think their industry leading software has a "bug" while you're at it.

No we didn't. Here's the part of the paper where the FAR is referenced.

US Federal Aviation Regulations appear to permit an altitude error up to +/- 30 feet per 100
knots,²⁷ which would give a maximum permitted error on final approach, ranging from 130
to 140 knots in the data file, of 39 to 42 feet. In none of the sets of landing data examined
was the discrepancy with radio height greater than 17 feet when recording of radio height
commenced, hence there is no reason to suspect that the altimeter was malfunctioning or
badly out of calibration, yet the observed errors were 50 to 83 feet just prior to normal
landings. It therefore appears that this calibration standard is not applied at low altitudes.

The FAR reference (²⁷) is used to conclude that an altitude divergence of 17 feet on final approach would not indicate that the altimeter was malfunctioning or badly out of calibration. We noted that it appeared to not be applied at low altitudes which would include the final moments of high speed at the Pentagon.

Yes, a mangled mess of words for sure. It is one of the worse contradictions, double-speak and spin i've seen yet from Legge (mixed in with a good Legge dose of speculation of course), and he has some whoppers in the past. Mostly due to his bias and the fact he hasnt a clue of what he is talking about.

First you offer +/- 30 feet per 100 knots over the "operational speed range" [of an aircraft such as a Cessna 172] (both wrong for your purposes), then you claim there was no error greater than 17 feet in the "landing data", then you claim "observed errors were 50-83 feet prior to normal landings". Then you claim the standard doesn't apply. Implying errors at low altitudes are greater than the standard.

Any layman reading that paragraph will think, "Hmmm... the Pentagon aircraft traveling close to 500 knots, 30 feet per 100 knots... 150 feet discrepancy. Legge figured it out!"

Wrong.

The expected and worst errors are down, dirty and slow with high AOA. At those points in the data (3-6 RA), the discrepancy is less than 2-8 feet over a known position, the runway. Meaning, there would be less error in the phase of flight at the end of data clean and fast, well within the operational range of the static system and calibrated with an ADC up to Mach 0.86. Meaning, the aircraft was too high to hit the Pentagon. Meaning, your data does not support an impact.

Have you found a technical explanation of what LRRA tracking capability means yet that has more technical details than "it gets behind"?

Warren.

It certainly doesnt mean an "implied negative" 0-330 fps in the vertical if that's what you're asking. (I couldnt believe you actually tried to float such absurd speculation. That was an all new low for you Warren)

Again Warren, click and learn.
http://pilotsfor911truth.org/forum/index.p...&p=10793876

Feel free to email Rockwell yourself. Let us know how you make out.

Your trolling is becoming very annoying Warren. You are once again ignoring all questions asked of you while expecting people to answer yours, you ignore all information which literally destroy your arguments proving your "altitude divergence" was due to RA measuring from objects other than the ground along the approach (what i have been trying to tell you from the beginning), you then have no choice but to cherry pick quotes where you think you may have some bit of argument left. Consider this your first warning. I think i've given you enough latitude and you are abusing it.

[rob balsamo]

It certainly doesnt mean an "implied negative" 0-330 fps in the vertical if that's what you're asking. (I couldnt believe you actually tried to float such absurd speculation. That was an all new low for you Warren)

I have expanded more on Tracking Capabilities here using Warrens speculation demonstrating how absurd such speculation upon speculation can be.

http://pilotsfor911truth.org/forum/index.p...&p=10794159