Aal77 Fdr Decoder Program, Decodes almost 4 more seconds Options

[wstutt]

I have created a new program to decode AAL77's raw FDR file.

I am making it available for download along with it's source code and some output files from the program.

You can read more about it here

It decodes almost 4 more seconds of data than what appears at the end of the NTSB CSV file.

I welcome suggestions for any more parameters you would like decoded or any other features you would like added.

I will also be discussing this on the J.R.E.F. "AA77 FDR Data, Explained" thread as well as here.

Warren.

mod edit: Although Pilots For 9/11 Truth do not have any reason to believe the above program is offered for any nefarious purpose, we felt the responsibility to add this disclaimer. Pilots For 9/11 Truth do not vouch for nor is responsible for any of the data provided above by Warren. Nor can we guarantee his program is free of malicious code. Download at your own risk.

This post has been edited by rob balsamo: Oct 22 2009, 05:38 PM

[rob balsamo]

Warren,

At quick glance... Your last 4 seconds do not add up to impact.

1. The second to last 4 seconds of travel according to your CSV is 2.25 DME, then the next/last 4 seconds is only .25 DME? (yes, i pulled up GE, fits perfectly with impact point. Neat how that works when Beachnut has been yelling the DME is in error for the past 3 years)

2. Your numbers still show a descent rate in excess of 4200 fpm.... which is still more than a 5 degree slope, still too high to hit light poles working backwards from the "impact" hole.

and.... finally...

-99 + 300 = 201. Still too high to hit the pentagon.

Roof of the Pentagon is roughly 110 feet above sea level. 35 ground elevation + 77 height of pentagon. (yes, i also looked at radalt, something fishy going on there as well. They dont match Pressure altitude descent rates and (edit to add) is too high to hit the light poles based on speed. Keep in mind Radalt is altitude above ground or any object on the ground in which the radar is bouncing off... you have to look at true altitude to get a more precise figure and correlate.

Speed also becomes more of an issue in terms of structural integrity and control effectiveness being more than 20 knots faster... not to mention now it doesn't correlate with any other "official" information or documentation. (/edit)

But, your last 4 seconds of decode is more in line with what the CIT witnesses describe for altitude as the NTSB plotted altitudes seemed a bit high compared to witness statements.

Thanks for putting it together.

Assuming your decode is accurate....

The next questions are, why didnt the NTSB show this when they decoded the file using specific software made to decode these files? .. and... why isnt this shown in our decode decoded by an engineer from an FDR Company?

(IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/smile.gif)

By the way, what is the time created for your raw file?

[wstutt]

<snip>

1. The second to last 4 seconds of travel according to your CSV is 2.25 DME, then the next/last 4 seconds is only .25 DME? (yes, i pulled up GE, fits perfectly with impact point. Neat how that works when Beachnut has been yelling the DME is in error for the past 3 years)

It appears that the DME values are not updated every time they are recorded by the FDR. The DME DISTANCE - LEFT (NM) value of 3.75 was recorded 5 times over a period of 16 seconds before being recorded as 1.5 4 seconds later, so the second to last 4 seconds of travel would have been less than 2.25 DME.

<snip>
Thanks for putting it together.

Your welcome.

Assuming your decode is accurate....

The next questions are, why didnt the NTSB show this when they decoded the file using specific software made to decode these files? .. and... why isnt this shown in our decode decoded by an engineer from an FDR Company?

<snip>

Perhaps the software that the NTSB used does not decode incomplete fames. The extra almost 4 seconds comes from a frame that only has 1007 of 1020 * 12 bit words.

As far as Undertow's Readout 2 goes, he said on his web site:

...
The software only processes full subframes. ...

I can see that indeed, for the ends of the sections of compressed data represented by the rows of #ERROR in rows 29, 47 and 74 in a77.2_complete.csv, only the last incomplete subframe has not been decoded, but at the end of a77.2_complete.csv, the last 4 complete subframes as well as the last incomplete subframe have not been decoded. I don't know the reason for this. BTW, subframe number 146102 in my program corresponds to the beginning of a77.2_complete.csv. I could produce a decode starting at that point if you like.

Warren.

[rob balsamo]

It appears that the DME values are not updated every time they are recorded by the FDR. The DME DISTANCE - LEFT (NM) value of 3.75 was recorded 5 times over a period of 16 seconds before being recorded as 1.5 4 seconds later, so the second to last 4 seconds of travel would have been less than 2.25 DME.

Yes, my wording was a bit unclear, sorry i had just woken up when i posted.

There seems to be many problems with the DME, it repeats 17.5 DME for 48 seconds, then in turn updates 1.5 to 1.25 in one subframe?

Perhaps the software that the NTSB used does not decode incomplete fames.[sic]

Perhaps, and that would be speculation at this point... but why would a govt agency tasked to investigate and ensure safety for the flying public not have software to analyze all the data and then draw erroneous conclusions based on incomplete data sets?

As far as Undertow's Readout 2 goes, he said on his web site:

Thanks. He also claimed his software was not certified for Aircraft Accident Investigation whereas the NTSB software is...

I could produce a decode starting at that point if you like.

I'm good for now with what you have provided. Thanks again Warren.

I have had a chance this afternoon to look over your data more thoroughly.. .I just opened your "FinalFlightComplete" (i opened your other csv file this morning). Given altitude is recorded once per second, and that the FDR cannot be missing more than 0.5, 'best' case scenario (for the GL "impact" theory in this case)....

-99 PA (174 True) being hypothetically recorded 1.5 seconds west of the wall means based on speed it would need to descend almost 100-120 feet in roughly 0.3 seconds to hit pole 1, and then pull level almost instantaneously...impossible.. or descend 129 in 1.5 seconds to impact the pentagon creating a more than 6 degree slope (86 f/s drop) which clears all the tops of the poles...

If trends are continued as shown in your data from last interval (59 f/s drop) and considering the descent would be less than 59 f/s based on positive G's over 1 for that segment, but, lets just do 1 G linear trend.. 59*1.5 = 88.5... 174 - 88.5 = 85.5. Still too high for the impact hole. Again, this is at 1 G linear descent rate using 'best' case scenario for an impact based on your data. If we incorporate the increase in positive G loads, whoosh... right over the top... and would be consistent with the radalt bouncing off the top of the pentagon and Turcious statements of "pulling up to clear...". (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/wink.gif)

Do the GL's now realize the FDR is not missing 6 seconds from the pentagon wall due to a "bird strike", compressor stall or some mysterious corruption due to "impact"? And that Ed Santana was correct when he stated FDR's cannot be missing any more than 0.5 seconds? Looks like an FDR "salesman" (as Beachy likes to marginalize Ed..) knows more than Beachy... (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/smile.gif)

Again, assuming you are correct, you might want to alert the NTSB their Flight Path Study, Time Correlation, "Impact time"... etc etc.. in the National Archives is wrong and the data they are distributing to the American Public through the FOIA is wrong. This has major ramifications for flight safety. We have tried to inform them, but they turned a blind eye.


Once again, no matter how you slice it, the data does not support the govt story of AA77 impact with the Pentagon as reported.

[wstutt]

<snip>
Perhaps, and that would be speculation at this point... but why would a govt agency tasked to investigate and ensure safety for the flying public not have software to analyze all the data and then draw erroneous conclusions based on incomplete data sets?

I agree that I am speculating on this. At some point the NTSB, or someone working for the NTSB must have used some code within some program to decompress the data compressed in this particular way. I believe there is no standard for the compression of FDR data. As far as I know, new FDRs no longer perform compression since flash memory is so much cheaper now. Perhaps the NTSB has not had to decode data from many FDRs with this particular compression and the NTSB has not found out that the incomplete frames are not being decompressed and therefore not decoded.

<snip>

I'm good for now with what you have provided. Thanks again Warren.

Your welcome.

<snip>
Again, assuming you are correct, you might want to alert the NTSB their Flight Path Study, Time Correlation, "Impact time"... etc etc.. in the National Archives is wrong and the data they are distributing to the American Public through the FOIA is wrong. This has major ramifications for flight safety. We have tried to inform them, but they turned a blind eye.
<snip>

Does the NTSB have established procedures to correct previously issued reports? Something like an appeals process?

Warren.

[rob balsamo]

Does the NTSB have established procedures to correct previously issued reports? Something like an appeals process?

I am not aware of an established internal or external procedures aside from attempting to notify the NTSB (which we have done starting in 2006 via various methods), however there are also other methods where flight safety is concerned as described and shown here.

http://pilotsfor911truth.org/forum/index.php?showtopic=18247

The NTSB also has set precedent in correcting their errors in a timely fashion if in fact they exist, most notably is a small 3 degree error in their animation for AA1420 runway overrun at LIT.

http://www.ntsb.gov/events/2000/aa1420/anim_boardmtng.htm

And of course with AA77, instead of fixing the animation, the NTSB now just makes a note of the clock annotation error in their FOIA cover letters (EDT/GMT), the NTSB does not mention any other errors in the animation. The only other errors the NTSB mentions are errors in the MCP (autopilot) in one of their pdf's.

[wstutt]

<snip>
The NTSB also has set precedent in correcting their errors in a timely fashion if in fact they exist, most notably is a small 3 degree error in their animation for AA1420 runway overrun at LIT.

http://www.ntsb.gov/events/2000/aa1420/anim_boardmtng.htm

And of course with AA77, instead of fixing the animation, the NTSB now just makes a note of the clock annotation error in their FOIA cover letters (EDT/GMT), the NTSB does not mention any other errors in the animation. The only other errors the NTSB mentions are errors in the MCP (autopilot) in one of their pdf's.

Do you know if any actions by people outside of the NTSB resulted in the NTSB correcting any of the errors that you mentioned above?

Warren.

[rob balsamo]

Do you know if any actions by people outside of the NTSB resulted in the NTSB correcting any of the errors that you mentioned above?

Warren.

I do not, but that doesn't mean there aren't any instances that have been corrected by outside influence. As you can see by precedent set, the NTSB usually corrects their information in a timely manner or at least posts a side letter of explanation if in fact such errors exist. I don't think it matters who takes the credit for the find.

[wstutt]

I do not, but that doesn't mean there aren't any instances that have been corrected by outside influence. As you can see by precedent set, the NTSB usually corrects their information in a timely manner or at least posts a side letter of explanation if in fact such errors exist. I don't think it matters who takes the credit for the find.

I am speculating here. Perhaps the difference in the case of AAL77 is that it was treated as a criminal investigation where the NTSB is only providing support to the FBI. Perhaps the NTSB was more interested in evidence that could be gathered for criminal trials rather than what could be learnt to improve public safety for normal aircraft crashes where the FBI does not become involved. In other words, perhaps normal processes of the NTSB are overridden by the fact that the work is for the FBI.

Warren.

[rob balsamo]

I am speculating here. Perhaps the difference in the case of AAL77 is that it was treated as a criminal investigation where the NTSB is only providing support to the FBI. Perhaps the NTSB was more interested in evidence that could be gathered for criminal trials rather than what could be learnt to improve public safety for normal aircraft crashes where the FBI does not become involved. In other words, perhaps normal processes of the NTSB are overridden by the fact that the work is for the FBI.

Warren.

Warren,

Either the RAPS software that the NTSB uses decodes incomplete frames or it doesn't. I don't think there is a check-box in the RAPS software for "Criminal Investigation" or "Civil Aircraft Accident" in which the software then decides what to decode followed by the NTSB completing a "Flight Path Study" and drawing conclusions based in such a decode.

(IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/smile.gif)

[wstutt]

Warren,

Either the RAPS software that the NTSB uses decodes incomplete frames or it doesn't. I don't think there is a check-box in the RAPS software for "Criminal Investigation" or "Civil Aircraft Accident" in which the software then decides what to decode followed by the NTSB completing a "Flight Path Study" and drawing conclusions based in such a decode.

(IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/smile.gif)

Does anyone know whether the RAPS software was capable of decoding the raw FDR file? I speculate that the NTSB may have had to use the ROSE software from the FDR manufacturer to decompress the file, so that they could then use the RAPS software on it.

Warren.