Aal77 Fdr Decoder Program, Decodes almost 4 more seconds Options

[rob balsamo]

Hi Rob,

It would have been a different version, however it appears to have the same bug.

Based on your "belief".

I brought the bug to the attention of L3 Communications so they can fix it. It may not show up on every decode.

So, its a "selective" bug. I see... (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/rolleyes.gif) .

At the time you filed your ASRS report, I did not have the decompressed file from the ROSE software. Now that I do, I have gained insight as to why I was able to decode more data from the FDR than the NTSB.

You claimed you were able to decode more data than the National Transportation Safety Board. A Govt agency tasked to investigate accidents and change regulation based on such investigations, to ensure the safety of the traveling public. The moment you produced more data than the NTSB, the crucial final seconds of a flight, is the moment there is a grave problem with flight safety. I find it odd you didn't feel the same way at the time. And now you do. It is especially puzzling you came out with this new "belief" of a "bug" just days after I updated my ASRS thread with a reply from NASA regarding my ASRS report. But I'm sure that is just coincidence.

Is the "last 4 seconds" you refer to from the CSV files on my web site?

Yes, they still do not add up to impact. Not to mention the increased speeds and G loading making it virtually impossible for a 757, especially for a kid who couldn't control a 172 at 65 knots.

What would they do with the program? Run it and produce the same modified file?

Exactly. They can see how and why it was modified and with what code.

Did you look at the original unmodified raw FDR file from the NTSB...

I did, after it was decoded by an FDR company employee. It doesnt match your decode.

I also sent the NTSB a CSV file from my AAL77 FDR Decoder so they can compare it with their CSV file. You've looked at both of them.

Have they said they found no such error?

The NTSB has made no claim of "missing seconds".

They have however corrected other errors not only in the AA77 data, but in other data as well. A simple 3 degree error was corrected on the LIT flight in a timely manner.

The Pressure Altitude is not the only thing wrong with the AAL77 DFL.

There is nothing wrong with the AA DFL as it is made for AAL aircraft by AAL. You think there is something "wrong" with it because it cannot decode the data you have in full. This tells the obvious observer with expertise that the data you are decoding is not from an AAL aircraft.

Different airlines have slightly different procedures. This is also why United makes their own custom DFL.

I'll let him speak for himself if he so chooses.

Warren.

He already has, and Frank claims that CWS was "reinstalled by the govt to aid in hijacker control". (among other absurd theories and logical fallacies).

Do you agree with him?

All pilots just laugh.

[wstutt]

Hi Rob,

<snip>

So, its a "selective" bug. I see... (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/rolleyes.gif) .

You claimed you were able to decode more data than the National Transportation Safety Board. A Govt agency tasked to investigate accidents and change regulation based on such investigations, to ensure the safety of the traveling public. The moment you produced more data than the NTSB, the crucial final seconds of a flight, is the moment there is a grave problem with flight safety. I find it odd you didn't feel the same way at the time. And now you do.

If only bugs showed up every time, my job as a debugger and tester would have been so much easier. I have seen bugs that show symptoms for some inputs and not others. I have seen bugs involving unintialised variables where whether or not the bug shows symptoms depends on what was previously loaded in to memory. Have you debugged any programs Rob?

You said earlier

... I suppose anything possible given the fact those who make excuse for the govt story scream from the roof tops it is all due to "Incompetence!", this is why I filled out a ASRS report last year, the moment I became aware of a possible grave situation in Flight Safety. ...

but most of your ASRS report covers your claims from long before I did my decode. I could ask you why you didn't file your ASRS report earlier.

It is especially puzzling you came out with this new "belief" of a "bug" just days after I updated my ASRS thread with a reply from NASA regarding my ASRS report. But I'm sure that is just coincidence.

Yes, they still do not add up to impact. Not to mention the increased speeds and G loading making it virtually impossible for a 757, especially for a kid who couldn't control a 172 at 65 knots.

It may not be a coincidence. I had previously phoned the NTSB before writing my letter. Perhaps they remembered my name from your ASRS report and decided they should now look in to your ASRS report.

If your case that there was no impact is so compelling, why waste your time with me?

Exactly. They can see how and why it was modified and with what code.

The "why" is clear from the letter. I could put the source code on my web site so they can see the "how", but would you be satisfied with that?

I did, after it was decoded by an FDR company employee. It doesnt match your decode.

Apart from the fact that ReadOut2 has 5 less seconds of data and may well have been affected by the same bug, what else doesn't match?

The NTSB has made no claim of "missing seconds".

They have however corrected other errors not only in the AA77 data, but in other data as well. A simple 3 degree error was corrected on the LIT flight in a timely manner.

You said earlier

... NTSB has shown precedent that they usually correct their errors in less than a year, if such errors exist.

however you filed your ASRS report a year ago and they have just replied that they are looking in to it. So their error correcting process has taken longer than a year in this case.

There is nothing wrong with the AA DFL as it is made for AAL aircraft by AAL. You think there is something "wrong" with it because it cannot decode the data you have in full. This tells the obvious observer with expertise that the data you are decoding is not from an AAL aircraft.

No, the AAL DFL has internal inconsistencies as in my example which means it can not be used as is to decode any FDR.

Different airlines have slightly different procedures. This is also why United makes their own custom DFL.

United may well have correct DFLs for their aircraft.

He already has, and Frank claims that CWS was "reinstalled by the govt to aid in hijacker control". (among other absurd theories and logical fallacies).

Do you agree with him?

All pilots just laugh.

What Frank wrote in previous papers is not necessarily important to me.

Warren.

[rob balsamo]

Hi Rob,

If only bugs showed up every time, my job as a debugger and tester would have been so much easier. I have seen bugs that show symptoms for some inputs and not others. I have seen bugs involving unintialised variables where whether or not the bug shows symptoms depends on what was previously loaded in to memory. Have you debugged any programs Rob?

I've done some elementary debugging (I do run this website after all...), but nothing close to what you claim is your experience.

But, if you consider aircraft instrument cross-check and partial panel work, then most certainly. I also teach it.

Have you learned how to understand aircraft data yet and the reason the AAL DFL has a different formula for altitude?

You said earlier
but most of your ASRS report covers your claims from long before I did my decode. I could ask you why you didn't file your ASRS report earlier.

And yet you avoid my question by asking a question. That is what we call around here intellectual dishonesty, Warren. Answer my question and then I'll answer yours, But the answer to your question has already been given numerous times on this forum and at our website.

It may not be a coincidence. I had previously phoned the NTSB before writing my letter. Perhaps they remembered my name from your ASRS report and decided they should now look in to your ASRS report.

The NTSB does not receive the ASRS report. Read it again. Read who it goes to. Read who replies.

If your case that there was no impact is so compelling, why waste your time with me?

You're on our forum. I spend less than 5 mins replying to you when you get done researching for hours in an attempt to reply to me.

Are you claiming we haven't attempted to get answers from the FBI, NTSB and Boeing and only waste time with you on our forum?

If your claims/decode are so compelling to you in terms of an 'impact' and you are now satisfied, why waste any time at all on this topic?

The "why" is clear from the letter. I could put the source code on my web site so they can see the "how", but would you be satisfied with that?

Again Warren, you can do whatever you want. I was just giving you advice as to how you may get a response. The way it is now, I would be surprised you get a reply as all they see is a file you admit you modified. I would be surprised if they even open your files. But it still could happen.

Apart from the fact that ReadOut2 has 5 less seconds of data and may well have been affected by the same bug, what else doesn't match?

You just answered your own question, albeit with your "belief".

however you filed your ASRS report a year ago and they have just replied that they are looking in to it.

Wrong, they replied to me quite some time ago. I just got around to remembering to update the thread.

No, the AAL DFL has internal inconsistencies as in my example which means it can not be used as is to decode any FDR.

Wrong again. There is a very good reason the altitude formula is different for AAL aircraft.

United may well have correct DFLs for their aircraft.

I'm sure they do. As do all other airlines who make their own custom made DFL's.

It appears to me that not only are you saying that the NTSB is incompetent, but apparently so is L3 Communications and now so are American Airlines?

Wow, you better get going on your ASRS reports.

What Frank wrote in previous papers is not necessarily important to me.

It should be, considering Frank gets a lot of things wrong.

Here's the short list, there are many more.
http://pilotsfor911truth.org/forum/index.p...&p=10777266

From what I understand, he is about 2 months behind schedule publishing his new paper. Not feeling very confident? Again, if the email exchanges are any indication, we probably won't be seeing his new "paper" for quite some time. But as I told Frank, let us know when it's published and we'll take a look when we have the time, so he can start his revisions.

[wstutt]

<snip>

If your claims/decode are so compelling to you in terms of an 'impact' and you are now satisfied, why waste any time at all on this topic?

<snip>

Good point Rob, I won't waste any more time.

Warren.

[rob balsamo]

Good point Rob, I won't waste any more time.

Warren.

Just remember, no matter how you slice it, the data does not add up to impact, nor is control possible at the increased speeds in your "extra" data, for a standard 757 at any G load.


Take care Warren.

[wstutt]

I would like to thank Phaeton666 for this post. His link to a document he found on the Internet and his suggestion to use Google to translate it provided the final piece in the puzzle for me to write my AAL77 FDR Decoder program.

Warren.

[rob balsamo]

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

Warren.

I been doing a bit more research on this.

Yes, the RAPS software was capable of decoding the raw file according to the NTSB and numerous other sources.

Warren, your whole 'bug' theory is based on your speculation of the software used.

The NTSB did not use the ROSE software, they used RAPS from Flightscape Inc. Not only is it referenced in your cover letters, but it's also in the NTSB AA77 FDR pdf.

"The transcribed data were processed by the NTSB's Recovery And Presentation System (RAPS), which converted the raw data to engineering units and presented it in tabular and graphic form. An examination of the recovered data indicated that the recorder operated normally."
- Source, http://www.ntsb.gov/info/AAL77_fdr.pdf

"For your reference, the Safety Board has previously used a software program entitled "Readout and Playback Software, from Flightscape Inc." - Source, http://warrenstutt.com/NTSBFOIARequest2-1-09/index.html

... and just a random google search I did with respect to RAPS software. Note the underline and bold.

"April 1, 2004 - Flightscape Inc. (Ottawa, Canada) is pleased to announce that Southwest has recently chosen Flightscape's Insight|Animation and Insight|Analysis tools as part of their FDAP/FDM program. Insight is a fully compatible Windows® based derivative of Flightscape’s RAPS© (Recovery, Analysis & Presentation System) software that is currently used by the world’s leading flight data analysts and accident investigators. " - Source, http://www.flightscape.com/about/details.p...t=southwest.htm

"One of the main reasons that the RAPS software was commercialized in 2001 was to benefit from the increased collaboration that comes with a broader user base. Executive Director of the Transportation Safety Board, Mr. David Kinsman, stated, 'TSB is pleased that RAPS, an accident investigation tool originally developed by the TSB, has led to a commercially viable product that will advance transportation safety in Canada and around the world." Source - http://www.flightscape.com/about/details.p...;det=airbus.htm

Those who believe in Warren's decode must also believe that the NTSB, Flightscape Inc, L3 Communications, American Airlines and many other major airlines are all using software which jeopardizes flight safety.

In other words, those who believe in Warren's decode might not want to step on another flight until such a grave "bug" that infects multiple software packages and has escaped leading Aerospace software engineers, is resolved.

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)

[wstutt]

Hi Rob,

I been doing a bit more research on this.

Yes, the RAPS software was capable of decoding the raw file according to the NTSB and numerous other sources.

Warren, your whole 'bug' theory is based on your speculation of the software used.

The NTSB did not use the ROSE software, they used RAPS from Flightscape Inc. Not only is it referenced in your cover letters, but it's also in the NTSB AA77 FDR pdf.

<snip>

I had originally thought that the NTSB used ROSE to decompress the file since it is in a proprietary format and then used RAPS to convert it to engineering units. However, you may be correct that RAPS was both capable of reading FA2100 FDR files and converting them to engineering units and that the NTSB did not use the ROSE software with the AAL77 FDR file.

However, consider how Flightscape would have made the RAPS software capable of reading proprietary format FA2100 FDR files. I can think of two possibilities:
1) Get documentation of the file format from L3 Communications and use that to write code to decompress the file.
2) Get a software library from L3 Communications that can decompress the file and use that within the RAPS software.

If they chose option 2, and that software library was also used by the ROSE software, then both pieces of software could be affected by a bug in the software library.

So it is possible for a bug in one piece of code to affect software produced by two different companies.

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)

If you can find a programmer that you trust, there is a way for you to conclusively determine whether I fabricated the data or not. I can think of two possibilities:
1) You can either get the programmer to check through my source code.
2) I can write a program specification so that the programmer can write their own program from scratch to decompress the file and we can compare results.

Are there any programmers in your core member list or other programmers that you trust that would be willing to do this?

Also, I would still be interested in looking through the decompressed FDR file that UnderTow and Calum Douglas have got. As far as I know it is a .TSC file which is an Avionca file format.

Warren.

[rob balsamo]

However, consider how Flightscape would have made the RAPS software capable of reading proprietary format FA2100 FDR files. I can think of two possibilities:
1) Get documentation of the file format from L3 Communications and use that to write code to decompress the file.
2) Get a software library from L3 Communications that can decompress the file and use that within the RAPS software.

If they chose option 2, and that software library was also used by the ROSE software, then both pieces of software could be affected by a bug in the software library.

So it is possible for a bug in one piece of code to affect software produced by two different companies.

Warren, you are loaded with speculation.

Please read. Note the bold.


· Insight (formerly known as RAPS) originated at the Transportation Safety Board of Canada in 1985· CAE Flightscape has more combined Flight data experience than any other company· Uniquely designed to handle both complex investigations and work automatically for FOQA/FDA/FDM· Works interactively with unprocessed binary data; a must for accuracy and efficiency · Math tools built in for derivations/validation and automatic edit history· Unique binary Flight data editor for bit level analysis· Used by virtually all air safety investigators at major aircraft manufacturers· Used by majority of world's leading investigation authorities· Used by respected airlines for training, airport familiarization, FOQA and incident analysis· Interactive viewer technology which is freely distributable· CAE Flightscape is the exclusive technology partner for the IATA FDA Service· Participate in our annual Users Conference of industry leaders to share experiences CAE

Here's more -

Recovery is a bit level editing tool designed for accident investigators. It allows bit editing of tape-based and solid state recordings to recover data problems associated with dropouts and synchronization losses due to power interruptions and error codes. It is the only commercial application in the world which meets ICAO Annex 13 Appendix D guidelines for accident investigation.· Displays waveform for Harvard Bi-phase and NRZ formats· Search functions quickly locate dropouts and abnormal bit widths· Automatically detects inter-record gaps· Maintains automatic historical log of all edits· A must for accident investigation authorities Bit Level Flight Data Editing System

and more....

Insight|Analysis is a core component of other Insight applications and is a complete stand-alone ground station. This provides users with the ability to import Flight data from virtually every recorder type in the world, and perform detailed analysis and investigation of specfic events, incidents or accidents. It has an extensive plotting and curve fitting capability to allow users to work interactively with raw binary data in detail. The user can also create/perform mathematical and performance functions on the data and derive parameters that were not recorded. An extensive aircraft parameter database editor allows creation and management of the parameter data map layout. · Industry leading Flight data plotting and integrated math application· Highly intuitive and easy to use· Works interactively with raw binary Flight data for maximum accuracy and efficiency· Most extensive parameter database management system available· A complete and portable (laptop) ground station Data Import and Plotting System -



Warren, have you figured out why AAL DFL has a different formula for altitude yet? Why you weren't able to use the AAL DFL for many of your decodes? It seems you think American Airlines just arbitrarily derive formula's for their DFL to output nonsense?

How's that Legge paper coming along? (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/rolleyes.gif)

[wstutt]

Hi Rob,

Warren, you are loaded with speculation.

Please read. Note the bold.


· Insight (formerly known as RAPS) originated at the Transportation Safety Board of Canada in 1985· CAE Flightscape has more combined Flight data experience than any other company· Uniquely designed to handle both complex investigations and work automatically for FOQA/FDA/FDM· Works interactively with unprocessed binary data; a must for accuracy and efficiency · Math tools built in for derivations/validation and automatic edit history· Unique binary Flight data editor for bit level analysis· Used by virtually all air safety investigators at major aircraft manufacturers· Used by majority of world's leading investigation authorities· Used by respected airlines for training, airport familiarization, FOQA and incident analysis· Interactive viewer technology which is freely distributable· CAE Flightscape is the exclusive technology partner for the IATA FDA Service· Participate in our annual Users Conference of industry leaders to share experiences CAE

Here's more -

Recovery is a bit level editing tool designed for accident investigators. It allows bit editing of tape-based and solid state recordings to recover data problems associated with dropouts and synchronization losses due to power interruptions and error codes. It is the only commercial application in the world which meets ICAO Annex 13 Appendix D guidelines for accident investigation.· Displays waveform for Harvard Bi-phase and NRZ formats· Search functions quickly locate dropouts and abnormal bit widths· Automatically detects inter-record gaps· Maintains automatic historical log of all edits· A must for accident investigation authorities Bit Level Flight Data Editing System

and more....

Insight|Analysis is a core component of other Insight applications and is a complete stand-alone ground station. This provides users with the ability to import Flight data from virtually every recorder type in the world, and perform detailed analysis and investigation of specfic events, incidents or accidents. It has an extensive plotting and curve fitting capability to allow users to work interactively with raw binary data in detail. The user can also create/perform mathematical and performance functions on the data and derive parameters that were not recorded. An extensive aircraft parameter database editor allows creation and management of the parameter data map layout. · Industry leading Flight data plotting and integrated math application· Highly intuitive and easy to use· Works interactively with raw binary Flight data for maximum accuracy and efficiency· Most extensive parameter database management system available· A complete and portable (laptop) ground station Data Import and Plotting System -

This still doesn't get us any closer to determining how the RAPS software was given the capability to decompress and compress FA2100 FDR files. Without that capability a user would be no better off using RAPS or Insight than using a freeware Hex editor to read and write the raw binary data in the FDR file.

Warren, have you figured out why AAL DFL has a different formula for altitude yet? Why you weren't able to use the AAL DFL for many of your decodes? It seems you think American Airlines just arbitrarily derive formula's for their DFL to output nonsense?

Unfortunately the American Airlines DFL will output incorrect values for any parameter that does not appear in every frame due to the superframe cycle numbers being incorrect. The American Airlines DFL is flawed as I indicated earlier.

How's that Legge paper coming along? (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/rolleyes.gif)

It's still under peer review. Have you ever been through a peer review process?

Warren.

[rob balsamo]

Hi Rob,

This still doesn't get us any closer to determining how the RAPS software was given the capability to decompress and compress FA2100 FDR files. Without that capability a user would be no better off using RAPS or Insight than using a freeware Hex editor to read and write the raw binary data in the FDR file.

What it does is further show why your inquiry to the NTSB is flawed and why they will most likely disregard your letter. You cite the ROSE software used has a "bug". The NTSB did not use ROSE software. Anyone who actually reads the FOIA cover letters (including yours), will understand this.

Let me break this down for you Warren as it appears you still dont understand and would rather speculate.

The RAPS software is loaded on a ground station (laptop) which directly imports the binary data from "virtually every recorder type in the world". This data is analyzed using the same software "to recover data problems associated with dropouts and synchronization losses due to power interruptions and error codes." using " Search functions [to] quickly locate dropouts and abnormal bit widths".

If you're still confused, there is no "ROSE" software associated. It is a direct download from the FDR CSMU in raw binary, input into software designed and developed by CAE. According to CAE, the software is so "accurate and efficient" that it automatically detects what you claim to have found through two years of developing a Microsoft Visual C# "decoder".

Are we to assume such a sophisticated piece of software developed by industry leading Aerospace Software Engineer's were unable to detect a "bug" that only "Warren Stutt" could detect with a "program" you fabricated using Microsoft Visual C#?

Really?

What's next, you going to try and sell the Brooklyn Bridge? I'm sure the J.REFer's will buy it.. :-)

Unfortunately the American Airlines DFL will output incorrect values for any parameter that does not appear in every frame due to the superframe cycle numbers being incorrect. The American Airlines DFL is flawed as I indicated earlier.

In other words, you are claiming American Airlines designed and developed a flawed DFL for their aircraft. Have you notified them yet?

It appears every piece of information you have received, whether it be from the NTSB, L3, American Airlines (and now CAE), is "flawed".

Hmmm... I'm starting to see a pattern here Warren.

It's still under peer review.

Is that like his last paper was "Peer reviewed"? Yet needed 8 revisions (with many more to go) after he had a real expert take a look at it?

Have you ever been through a peer review process?

I have, and here are just some of my peers which I consult.

http://pilotsfor911truth.org/core

The list is growing.

Who are yours?

Legge? A chemist? After reading his last paper which needed so many revisions, I beginning to seriously doubt his other conclusions based on his expertise.

Who does Legge have for "Peer Review"?

Have they informed him that CWS doesn't aid in "hijacker control" yet?

Warren, do you think CWS aids in hijacker control?

[wstutt]

I have now discovered that the reason that the NTSB didn't decode the last 4 seconds of data from the AAL77 FDR was due to error correcting codes not being recorded on two pages towards the end of the FDR data. More details are on my web site here.

Warren.

[rob balsamo]

I have now discovered that the reason that the NTSB didn't decode the last 4 seconds of data from the AAL77 FDR was due to error correcting codes not being recorded on two pages towards the end of the FDR data. More details are on my web site here.

Warren.

Just so we're up to date.

NTSB ROSE Software - Flawed
NTSB RAPS Software - Flawed
L3 Communications ROSE Software - Flawed
CAE Flightscape Software - Flawed
American Airlines Data Frame Layout - Flawed
DFDAU/FDR - Flawed

wstutt and his Microsoft Visual C# - Correct

Are we all up to speed now Warren?

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

How's that Legge paper coming? What is it, 4 months behind schedule now? Has he corrected his CWS nonsense in his last paper yet? Spoke with Capt Latas today regarding our next presentation, Legge's absurd theories provided some good comic relief. Tell him i said Thanks!

[wstutt]

Just so we're up to date.

NTSB ROSE Software - Flawed
NTSB RAPS Software - Flawed
L3 Communications ROSE Software - Flawed
CAE Flightscape Software - Flawed
American Airlines Data Frame Layout - Flawed
DFDAU/FDR - Flawed

wstutt and his Microsoft Visual C# - Correct

Are we all up to speed now Warren?

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

<snip>

So, do you still think I fabricated the data Rob?

If so, there is now a third way for you to conclusively determine whether I fabricated the data or not in addition to the two I already mentioned.

You can take the "American 77 with Corrected Hamming Codes and Page Parities.fdr" file from the ISO Image of the CDROM that I sent to the NTSB and get it decoded with your choice of decoding software.

Unlike the other two options, you don't need to find a programmer that you can trust.

Warren.

[rob balsamo]

So, do you still think I fabricated the data Rob?

You freely admit that you fabricated the "decoding software" using freeware you can download off the net, while claiming industry leading software used in flight safety around the world, has a bug. You further claim that a Data Frame Layout Custom made by American Airlines, is flawed (i guess AAL just makes up conversion formula's out of thin air because they feel like it? No, they don't.). Now you claim the DFDAU is also flawed.

I was just reading more of your "letter".

....this is rich.....

From "wstutt" latest letter to NTSB dated Dec 29, 2010 -

"Although, as has been pointed out to me since my previous letter, the NTSB may not have used the ROSE Software to produce that file...."

Warren, why did such information need to be "pointed out to you" (by me), when clearly the NTSB states in your own FOIA cover letter dated almost 2 years ago, that the NTSB used RAPS from Flightscape Inc. ?

Warren, I have concerns with your lack of attention to detail.

I wouldn't be surprised if the NTSB places your letter(s) in their circular files (ie, the trash can). Why would they read any further than "I modified your files you used to decode with ROSE Software, which clearly has a bug. I found this bug using a program I fabricated with Microsoft Visual C#. You can download it free off the web!". (paraphrased of course, but that is how they will see it).

Sorry Warren, but i'll be surprised if they see your letters as anything more than a joke. If you want to get serious, fill out an ASRS report. Perhaps the Aerospace industry will switch to using Microsoft Visual C# and customers will no longer have to pay 10's of thousands of dollars for sophisticated industry leading software developed by Computer Scientists specialized in Flight Data recovery.

[wstutt]

You freely admit that you fabricated the "decoding software" using freeware you can download off the net, while claiming industry leading software used in flight safety around the world, has a bug.

No, Microsoft Visual C# Express Edition is not freeware, Rob. It can not be used for commercial work. You need to pay for one of the other editions if you want to use it for commercial work. And yes, Microsoft Visual C# is used for commercial work.

You further claim that a Data Frame Layout Custom made by American Airlines, is flawed (i guess AAL just makes up conversion formula's out of thin air because they feel like it? No, they don't.).

OK, since you are so sure it is not flawed, how would you determine which superframe cycle number a frame belongs to according to the American Airlines custom Data Frame Layout?

Now you claim the DFDAU is also flawed.

Not necessarily. The error correcting codes were recorded correctly at the end of the other flights when the FDR would have lost power when the engines were turned off. This problem showed up only in the crash.

I was just reading more of your "letter".

....this is rich.....

From "wstutt" latest letter to NTSB dated Dec 29, 2010 -

"Although, as has been pointed out to me since my previous letter, the NTSB may not have used the ROSE Software to produce that file...."

Warren, why did such information need to be "pointed out to you" (by me), when clearly the NTSB states in your own FOIA cover letter dated almost 2 years ago, that the NTSB used RAPS from Flightscape Inc. ?

Warren, I have concerns with your lack of attention to detail.

OK. I found the problem in the ROSE software first, which is why I thought it was a coding error. I now know that the problem will occur in any piece of software decoding that FDR file that uses the same error correction algorithm. My decoder ignored the error correction codes, which is why it didn't have the same problem.

<snip>

Sorry Warren, but i'll be surprised if they see your letters as anything more than a joke. If you want to get serious, fill out an ASRS report.

You already filed an ASRS report. Have you heard anything more than that they will be looking into it?

Perhaps the Aerospace industry will switch to using Microsoft Visual C# and customers will no longer have to pay 10's of thousands of dollars for sophisticated industry leading software developed by Computer Scientists specialized in Flight Data recovery.

So, what computer languages are sophisticated industry leading software written in?

Warren.

[rob balsamo]

No, Microsoft Visual C# Express Edition is not freeware, Rob.

"It was created using Microsoft Visual C# 2010 Express Edition which is freely available from Microsoft's website at http://microsoft.com/express/download" - Warren Stutt, Letter to NTSB, Dated Dec 29, 2010.

OK, since you are so sure it is not flawed, how would you determine which superframe cycle number a frame belongs to according to the American Airlines custom Data Frame Layout?

I ask again Warren, does American Airlines just make up conversion formula's out of thin air, for no apparent reason? Only to output "nonsense" (as you call it). Why would American Airlines develop a DFL which produces nonsense?

Not necessarily. The error correcting codes were recorded correctly at the end of the other flights when the FDR would have lost power when the engines were turned off. This problem showed up only in the crash.

I'll post this again since it seems you missed it the first time. I'll bold the parts you need to focus on....

The RAPS software is loaded on a ground station (laptop) which directly imports the binary data from "virtually every recorder type in the world". This data is analyzed using the same software "to recover data problems associated with dropouts and synchronization losses due to power interruptions and error codes." using " Search functions [to] quickly locate dropouts and abnormal bit widths".

OK. I found the problem in the ROSE software first, which is why I thought it was a coding error. I now know that the problem will occur in any piece of software decoding that FDR file that uses the same error correction algorithm. My decoder ignored the error correction codes, which is why it didn't have the same problem.

See the capabilities of the RAPS software above.

You already filed an ASRS report. Have you heard anything more than that they will be looking into it?

Not yet, Im assuming because Im not the individual claiming "missing seconds" and/or making the claims through modified files. You are making those claims. I was just a conduit in case you are correct. I dont expect a response or any changes if you are incorrect.

With that said, if such industry leading and sophisticated software truly has some sort of a bug which only you could find with Microsoft Visual C# (freely available at microsoft.com/express/download), then there is a serious problem with Flight Safety around the globe as the final crucial seconds of many flights may be missing from past investigations, while regulation and safety changes may have been based on incomplete data sets. That is, if you are correct. You should fill one out detailing your findings if you are feeling so confident. Either that, or you should think twice about getting on another airplane until the problems you claim (which will no doubt cause a domino effect) are rectified.

So, what computer languages are sophisticated industry leading software written in?

Have you asked Flightscape? It's been written on your FOIA cover letter for almost 2 years, yet you needed it pointed out to you a few short months ago when you claimed ROSE was used.

Why do you avoid my questions Warren?

How's that Legge paper coming? What is it, 4 months behind schedule now? Has he corrected his CWS nonsense in his last paper yet?

Warren, do you think CWS aids in hijacker control?

I'll add another.

Have you seen the simulator reconstruction done by Capt Rusty Aimer on the Ventura show?

Bottom line Warrren, the NTSB data (or your additional data) does not support an impact with the Pentagon for a standard 757 (matter of fact, your additional data makes matters worse for the govt story), especially considering the claim that it was controlled by a kid who couldn't control a 172 at 65 knots.

I'm thinking this is why the FDR or any aircraft parts, were never positively identified. But again, if this is what satisfies your curiosity, everyone has their standards i suppose. This list continues to grow.

(Keep an eye on it as we have yet another large update coming).

Looking forward to you answering my above questions.

[wstutt]

"It was created using Microsoft Visual C# 2010 Express Edition which is freely available from Microsoft's website at http://microsoft.com/express/download" - Warren Stutt, Letter to NTSB, Dated Dec 29, 2010.

OK, so I used the freely available Express Edition. If I had paid for and used one of the other editions of Microsoft Visual C#, how would that have made any difference to my programs?

I ask again Warren, does American Airlines just make up conversion formula's out of thin air, for no apparent reason? Only to output "nonsense" (as you call it). Why would American Airlines develop a DFL which produces nonsense?

The DFL contains mistakes. A DFL contains more than just conversion formulas. To be of any use, a DFL needs to also specify the locations within the data to which to apply the conversion formulas. Superframe cycle numbers are part of how the locations are defined. You did not answer my question about the superframe cycle numbers.

I'll post this again since it seems you missed it the first time. I'll bold the parts you need to focus on....

The RAPS software is loaded on a ground station (laptop) which directly imports the binary data from "virtually every recorder type in the world". This data is analyzed using the same software "to recover data problems associated with dropouts and synchronization losses due to power interruptions and error codes." using " Search functions [to] quickly locate dropouts and abnormal bit widths".

That's correct! The software's attempt to "to recover data problems associated with dropouts and synchronization losses due to power interruptions and error codes." caused the problem. If the correct error correction codes are placed in the FDR file, the problem goes away!

<snip>

Not yet, Im assuming because Im not the individual claiming "missing seconds" and/or making the claims through modified files. You are making those claims. I was just a conduit in case you are correct. I dont expect a response or any changes if you are incorrect.

Are you referring to this ASRS report? What about the rest of it that deals with your claims? They constitute most of that report.

With that said, if such industry leading and sophisticated software truly has some sort of a bug which only you could find with Microsoft Visual C# (freely available at microsoft.com/express/download), then there is a serious problem with Flight Safety around the globe as the final crucial seconds of many flights may be missing from past investigations, while regulation and safety changes may have been based on incomplete data sets. That is, if you are correct. You should fill one out detailing your findings if you are feeling so confident. Either that, or you should think twice about getting on another airplane until the problems you claim (which will no doubt cause a domino effect) are rectified.

Firstly as I said, it is possible to verify my data without using Microsoft Visual C# or any other programming language. Secondly, I don't know how often this problem occurs. Thirdly, why would filling out an ASRS report be more effective than contacting the NTSB directly when it was the NTSB that decoded the data?

Have you asked Flightscape? It's been written on your FOIA cover letter for almost 2 years, yet you needed it pointed out to you a few short months ago when you claimed ROSE was used.

I'm not interested in what programming language Flightscape was written in. It was you who was implying that it was not Microsoft Visual C#.

I've snipped the rest of this post which is not directly relevant to decoding the FDR data, although perhaps one of your new or existing core members can check whether or not my decode is correct.

Warren.

[rob balsamo]

OK, so I used the freely available Express Edition. If I had paid for and used one of the other editions of Microsoft Visual C#, how would that have made any difference to my programs?

It doesnt. What I'm concerned with is the fact that you claim the NTSB, L3, American Airlines and now the DFDAU are all flawed, but yet you are somehow correct with a program you used that you downloaded from the net for free.

The DFL contains mistakes.

Yes, we know Warren, all data, information and programs contain "mistakes" except for yours which you downloaded for free from Microsoft. /sarcasm

Let me guess, you can also hit the Pentagon with Microsoft Flight Simulator at 110-130 knots over Vmo while pulling 2-3 G's?

Have you notified American Airlines of the "mistakes" in their DFL?

A more correct conclusion is that the DFL custom made by American Airlines does not decode the data you have been given.

Again, this is probably why the FDR nor parts have never been positively identified.

That's correct! The software's attempt to "to recover data problems associated with dropouts and synchronization losses due to power interruptions and error codes." caused the problem. If the correct error correction codes are placed in the FDR file, the problem goes away!

What if there isnt time to place/record the "correct error codes" due to a crash? Read the rest of the above quote I copied for you to find out. I see you conveniently evade that portion (for the second time).

Are you referring to this ASRS report? What about the rest of it that deals with your claims? They constitute most of that report.

I never claimed the NTSB is wrong, nor American Airlines, nor L3 Communications, in terms of the data. You did.

Pilots (and passengers) rely on their work daily to get from point A to point B, safely.

What I have claimed is that the data provided by the NTSB does not support an impact of a standard 757 with the Pentagon. This is a factual statement and it does not pertain to flight safety. Your additional data does not change anything (and as i said, in fact makes matter worse for the govt story), except the fact now you claim they are all "flawed". This is pertinent to flight safety if you are correct and we should expect changes. No changes have occurred, why is that Warren?

Once you claimed they were all wrong. I filled out an ASRS. Why havent you?

Firstly as I said, it is possible to verify my data without using Microsoft Visual C# or any other programming language. Secondly, I don't know how often this problem occurs. Thirdly, why would filling out an ASRS report be more effective than contacting the NTSB directly when it was the NTSB that decoded the data?

ASRS is a third party which can put pressure on those who do not take steps to rectify problems with aviation safety. Please do some research on it.

The ASRS collects, analyzes, and responds to voluntarily submitted aviation safety incident reports in order to lessen the likelihood of aviation accidents.

ASRS data are used to:

* Identify deficiencies and discrepancies in the National Aviation System (NAS) so that these can be remedied by appropriate authorities.
* Support policy formulation and planning for, and improvements to, the NAS.
* Strengthen the foundation of aviation human factors safety research. This is particularly important since it is generally conceded that over two-thirds of all aviation accidents and incidents have their roots in human performance errors

I'm not interested in what programming language Flightscape was written in.

Clearly. You also didnt even know the NTSB used Flightscape software till I had to point it out to you in your own FOIA cover letter dated from almost 2 years ago.

I've snipped the rest of this post which is not directly relevant to decoding the FDR data,

Are you saying Legge's new paper will not be relevant to FDR data?

Of course you snipped it, because you know once you answer, Legge's credibility will be diminished even further.

...perhaps one of your new or existing core members can check whether or not my decode is correct.

Again Warren, it doesnt really matter if it is or it isnt except to flight safety and my bases are already covered with that. I filled out an ASRS. Why havent you? Your additional data makes matters worse for the govt story. That is the bottom line.

We also rather get a response from the NTSB considering your claims are detrimental to Flight Safety combined with the fact that there is absolutely no evidence linking the data you decoded to N644AA, serial number 24602.

Looking forward to Legge's paper of which you now indirectly claim is not based on FDR data. If it is, please feel free to answer my questions.

[rob balsamo]

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


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

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

I guess we are back to Mackeys Bird strike theories for recording an FF code to the CSMU 4 seconds prior to "impact". (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/laughing1.gif)

More to come when Legge gets done with his paper.