• Security incident: ISF was recently accessed by intruders. Please change your password, and change it anywhere else you used it. Read more

AA77 FDR Data, Explained

It's nice to see JDX actually posting where people will be critical of his statements, rather than accepting them as gospel truth.
Bit of a reality check might shock him back into the woodwork where he can do less harm.
weedwacker was JDX, but committed suicide by mod. UnderTow is/was a contributor to LC and Pilots For Truth ( I believe ). Different people. Now having said that. Weedwacker was posting here for a week or two before he "lent" his ID to JDX.

All clear now :D
 
My mistake. So how about explaining some more of these mistakes you've found undertow? Underlining the word 'recorder' and 'recording' is supposed to mean what, exactly?
 
My mistake. So how about explaining some more of these mistakes you've found undertow? Underlining the word 'recorder' and 'recording' is supposed to mean what, exactly?

If you want to get information from him, you are going to need to know what you are talking about. I have underlined the parts that you got wrong.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
THIS ENTIRE SECTION IS SO FULL OF MISTAKES IT BOGGLES MY MIND. INSTEAD OF COMMENTING EVERY MISTAKE IN HERE I WILL JUST UNDERLINE THEM.
II. On-Aircraft Recording Systems

A recording system , then, is a system that samples data from around an aircraft, compiles it somehow into a fixed bit-rate serial data stream, and sends this data to a recorder. First, let’s discuss the type of data recorded on an aircraft. There are two main sources of data, as far as the recording system is concerned:
<snippage by TjW>

Since you underlined these words, UnderTow, am I correct in assuming that you do not consider the FDR to be an asynchronous sampled-data system?
 
The CSV file
Anti-S said:
The CSV (Comma Separated Values) is the main data source used by all Flight 77 “amateur” forensic analysis. First, we will discuss the reason for this files existence. This can be found in the NTSB Flight 77 FDR report, page 4:
Attachments II-1 to II-17 contain plots of those parameters that were recorded and validated. The timeframe of the plots is from 8:19:00 EDT to 9:39:00 EDT, with the last recorded data occurring at 9:37:44 EDT.
The data plotted in Attachment II are available in tabular format as a comma delimited (*.csv) file in Attachment III.

NTSB AA77 FDR Report Page 2 said:
The transcribed data[SSFDR Data on a hard disk] were reduced from the recorded binary values (0's and 1's) to engineering units (for example feet, knots, degrees, etc) using conversion forumlas obtained from Boeing and American Airlines for this airplane. The transcribed data were processed by the National Transportation Safety Board's Recovery Analysis and Presentation Systems (RAPS), which converted the raw data to engineering units and presented it in tabular and graphic form.

Why did you not refernece this very clear statement? Do you believe the NTSB RAPS system is not cabable of forensic output?
This simple Page 2 statement makes your next statement even more bizarro.

Anti-S said:
It is very important to note that the FDR data in the CSV file was processed to be made able to be plotted. I will explain what the purpose of this processing is, and what the effect of this processing had on the information contained in the CSV file.

Maybe you should be working for the NTSB. You seem to really have this all mixed up. Go back to Page 2.
RAPS converted the raw data to engineering units and presented it in tabular(CSV) and graphic(plotted) form

Anti-S said:
The single most important point of this entire document is to be found here: These frames represent just that: frames. The vertical axis represents the number of samples taken during that frame, not the time those samples were taken. Many conspiracy theorists, incorrectly, believe that each row of this file represents 1/8 of a second.
What "frames" are you talking about, what vertical axis. And which row of which column? Why don't you site an example of this "flawed interpretation" instead of being so ambigous.

Anti-S said:
The flawed interpretation is quickly disposed of by realizing a few key pieces of evidence. First of all, if you look at the longitudinal acceleration data above, you will see that it is sampled 4 times, and then the other 4 rows are blank. Without getting into the technical details, sampling at 0, 1/8, 2/8 and 3/8, and then not sampling again until 8/8 is absolutely silly. In digital signal processing, sampling out-of-phase like this would result in horrible aliasing effects and poorer reconstructed signal quality. It requires the same amount of effort, and the same amount of bandwidth to sample in equally spaced intervals, and the data is far superior. There is absolutely no way that the data was sampled “out-of-phase” like the incorrect interpretation would imply.

You must be referring to another part of you Scientific paper which you haven't posted yet. I can see how this might confuse people.

Anti-S said:
The second major clue is that our serial multiplexed signal is a constant bit-rate signal. This means that the same amount of data flows during the same period of time, at all times. All data points in this file are squished towards the top of the frame. This would mean much more data has to travel out from 0 to 1/8 then has to travel from 6/8 to 7/8. This violates the principle of constant bit-rate.

The key point is worth reemphasizing, so I will do it again: the proper interpretation of each frame of in the CSV file is that N samples were taken during that second. We know nothing about the time of these samples other than the fact they were taken during the frame, and are equally spaced. Pressure altitude could have been sampled at 0.0 or 0.99, and they would both show up exactly the same in the CSV file.

A CSV file has no FRAMES, only rows and columns, you should get your terms corrects if this is a scientific paper.

Why don't you quote the actual spec for the parameters you question. Why don't you reference the ARINC, IEEE, and Industry Requirements which will tell you exactly.
Why are you making all of this up? If you had worked in this field you wouldn't need to create all these flawed interpretations and non-referenced unscientific arguments.

Anti-S said:
This means we can calculate an error rate, in time, for each data point, due entirely to not knowing where in the frame this particular data-point was recorded. For a data-point sampled at 1Hz, like pressure altitude, that sample could have occurred at any point from 8:19:00 to 8:19:01. This is an error range of 1 second. A similar calculation can be done to be show that the maximum error range is equal to the time period between samples. Samples done at 8Hz have an error range of 0.125s, and 4Hz has 0.25s, and so on.

Also note that the timestamps of the major frames have been processed from the original data (the NTSB FDR report mentions this on page 3). There is no way to know the error in these timestamps, nor do we know the precision. It is a mistake to try to correlate these timestamps with the outside world (like official time of impacts).

So now we are calculating based on a unkown. /sigh
The error range is stated quite clearly in ARINC standards. The maxium error range between samples is 1/64 of a second. All data is sampled within this scope and must appear within this error range through the entire data stream. The Correlation between the FDAU Time Stamp of the data, the FDR Frame Number, and the real world clocks does not affect the error range for the actual sampling of data and it's placement in the frame.
 
The CSV file
Why did you not refernece this very clear statement? Do you believe the NTSB RAPS system is not cabable of forensic output?
This simple Page 2 statement makes your next statement even more bizarro.

Because it's irrelevant? Nothing in that statement contradicts what I said. The NTSB converted analog readings into engineering units. If an analog sensor return 119 millivolts, it can be recorded as 119 millivolts, and it requires a conversion to engineering units, nothing more. That conversion I have taken for granted because it's not relevant to the issue.

You must be referring to another part of you Scientific paper which you haven't posted yet. I can see how this might confuse people.
And I quote, from me:
The full document contains some examples to illustrate teh concepts, but the tables don't translate very well, so I've gotten rid of several examples and paragraphs to do with those examples.
I thought you said you read it? Maybe you missed that part. Yes, I didn't fully remove all references to examples.

A CSV file has no FRAMES
Utterly false. Anyone with any background instantly recognizes the frames. The fact that you don't is my entire point.

Why don't you quote the actual spec for the parameters you question. Why don't you reference the ARINC, IEEE, and Industry Requirements which will tell you exactly.
Because it adds unnecessary complication and doesn't really further my point. Adding more superfluous complexity to a situation that is already difficult to understand isn't a smart thing to do. Everything I've said is in accordance with all available standards. If you think I've contradicted them, point out an example

So now we are calculating based on a unkown. /sigh
The error range is stated quite clearly in ARINC standards. The maxium error range between samples is 1/64 of a second.
Wrong. Between recording of samples. Not samples.

All data is sampled within this scope and must appear within this error range through the entire data stream.
Not sampled. Recorded.

The Correlation between the FDAU Time Stamp of the data, the FDR Frame Number, and the real world clocks does not affect the error range for the actual sampling of data and it's placement in the frame.
Except you don't have the FDAU time stamp of the data. You only have the time stamp for the frame. This has been shown, by me and your graphic, to be insufficient. Using the Frame timestamp as the basis for your measured time introduces error.
 
Since you underlined these words, UnderTow, am I correct in assuming that you do not consider the FDR to be an asynchronous sampled-data system?

I fail to see the word "FDR" in that part of his statement.
His overuse of non specific terms such as "recording system" is incorrect, as well as using words like "somehow". All of these concepts and componets are broken down in "for dummies" terms already from various sources on the internet.
But I guess everyone should just believe him w/o question when he says "I gathered up all the publically available flight-data-recorder information, looked at it closely".

I find it interesting that for someone who's creditials are stated as his, that he didn't just post the ARINC 717 Frame like I did. Hm?
It also seemed to surprise him and it did cause him to correct himself in one of his following posts (replacing FDR with DAU) after his saw that simplified diagram of a complete 'recording system'. It must've have been new to him.
 
I fail to see the word "FDR" in that part of his statement.
His overuse of non specific terms such as "recording system" is incorrect, as well as using words like "somehow". All of these concepts and componets are broken down in "for dummies" terms already from various sources on the internet.
But I guess everyone should just believe him w/o question when he says "I gathered up all the publically available flight-data-recorder information, looked at it closely".

I find it interesting that for someone who's creditials are stated as his, that he didn't just post the ARINC 717 Frame like I did. Hm?
It also seemed to surprise him and it did cause him to correct himself in one of his following posts (replacing FDR with DAU) after his saw that simplified diagram of a complete 'recording system'. It must've have been new to him.

Actually, I wasn't asking a thing about Anti-Sophist. I was asking you what I thought was a fairly specific question. What I mostly notice about your reply is that you didn't answer it.
 
Anti-sophist said:
Because it's irrelevant? Nothing in that statement contradicts what I said. The NTSB converted analog readings into engineering units. If an analog sensor return 119 millivolts, it can be recorded as 119 millivolts, and it requires a conversion to engineering units, nothing more. That conversion I have taken for granted because it's not relevant to the issue.
How is the RAPS system irrelevant? and if you really did understand the whole system you would not make a false statement like The NTSB converted analog readings into engineering units. You take that conversion for granted, in which case you are missing a very large chunk of the picture. No wonder your report is such a mess.

AntiS said:
And I quote, from me:
I thought you said you read it? Maybe you missed that part. Yes, I didn't fully remove all references to examples.
I know what you said, you missed this part, so I "critiqued" it for you. Something no one else here seems to care about doing. Hmm?

Anti-S said:
Utterly false. Anyone with any background instantly recognizes the frames. The fact that you don't is my entire point.
Regonizing how frames are represented and saying a CSV has frames are two different things. I thought this scientific report was for people who dont' have any background.

AntiS said:
Because it adds unnecessary complication and doesn't really further my point. Adding more superfluous complexity to a situation that is already difficult to understand isn't a smart thing to do. Everything I've said is in accordance with all available standards. If you think I've contradicted them, point out an example
It's your paper, you back it up. You created this incrediblly messy report, and you did not provide one signal reference to any standard by any agency. I gave you 2 graphics and I don't think you even understand the 2nd one really well. Maybe becuase it doesn't have volts/ampree/ohms in it's description.

Anti-S said:
Except you don't have the FDAU time stamp of the data. You only have the time stamp for the frame. This has been shown, by me and your graphic, to be insufficient. Using the Frame timestamp as the basis for your measured time introduces error.
I'm sorry, you are backwards. What we don't have is the timestamp of the frame (or the frame reference number), what we do have (and what the CSV file represents) is the FDAU time stamp of the data which was converted from it's stored UTC/GMT to EST.
 
Since you underlined these words, UnderTow, am I correct in assuming that you do not consider the FDR to be an asynchronous sampled-data system?

I underlined the following words:
recording system , then, is a system that samples data from around an aircraft, compiles it somehow into a fixed bit-rate serial data stream, and sends this data to a recorder. First, let’s discuss the type of data recorded on an aircraft. There are two main sources of data, as far as the recording system

How do you go from those ambigous non specifc words to your specific question about the FDR being an asynchronous sampled-data system?
 
Its funny when they get worried about painting themselves in a corner, but have no idea where the corners are.
 
I find it interesting that for someone who's creditials are stated as his, that he didn't just post the ARINC 717 Frame like I did. Hm?
If you're going to talk crap like this I suggest you refute his credentials and supply your own, or STFU about them.

I don't know if his credentials are valid or not, but I do know you are silent on your own.
 
Except you don't have the FDAU time stamp of the data. You only have the time stamp for the frame. This has been shown, by me and your graphic, to be insufficient. Using the Frame timestamp as the basis for your measured time introduces error.

It seems to me UT is misunderstanding of what you have analyzed and wrote. Perhaps he missed some of your analysis. Please correct me if I am wrong here, but there is a distinction between data being sampled and being recorded. For a simplified example, suppose I am in a room full of people waiting to see a doctor. When my name is called at time X (sampled), I might not actually leave until time X+Y where Y might be the additional time needed to gather my stuff. Finally, when I arrive at the office down the hall there might be someone ahead of me. It won't be until some time X+Y+Z that the doctor will actually see me (recorded).

I believe this is what you have been saying but I don't think UT understands the distinction and thus does not understand why there could be wide variations of error introduced into the data.
 
How is the RAPS system irrelevant? and if you really did understand the whole system you would not make a false statement like The NTSB converted analog readings into engineering units. You take that conversion for granted, in which case you are missing a very large chunk of the picture. No wonder your report is such a mess.

No. I am not. I understand the conversion perfectly, and it's not relevant to the discussion. The fact that you think this is relevant further underlines (no pun intended) your lack of knowledge on this topic.

Do you want me to sit down and explain to you the basics of information theory and why data is encoded, digitally, the way that it is? If I tell you that they chose the encoding scheme that maximized the joint shannon entropy of the bits, would you believe me then? If I told you that sometimes they use a non-intuitive encoding because it provides optimal dynamic range and resolution tradeoffs (e.g, using integer encoding for a floating point value, or vice versa).

If I get into the gritty details of this process, just to prove I know it, what will it prove?

Your goal here is shoot your mouth off about a bunch of stuff that you don't understand but read about on the internet and hope something sticks to the wall. Inside the framework of my paper, the conversion between optimal digital encoding and engineering units is irrelevant. Yes, the issue is an important one for fully understanding how to design and build a digital recorded from scratch, but it's not important for understanding the flaws in CTers analysis of the actual FDR data.

This is a complex, but separate issue. Again, if you want to get into a pissing content of "who knows more than who", I am willing. You won't win, though.. and what will it change?

I know what you said, you missed this part, so I "critiqued" it for you. Something no one else here seems to care about doing. Hmm?

And I appreciate the critique of the style, semantics, and tone. I'll correct all of these stylistic issues when I finish the document. Of actual interest, however, is your crique of the science. And so far every scientific claim you've made has been proven false by your own graphic. You haven't even needed me, yet, to prove you wrong.

Regonizing how frames are represented and saying a CSV has frames are two different things.

Sounds like gibberish semantics to me.

I thought this scientific report was for people who dont' have any background.

It was expository and pedalogical (look them up). When you are writing expository papers, you don't bury people in technical details that they aren't expected to know, unless it's necessary. You provide motivation for the solution, before showing the solution. These are the basics of expository scientific writing, and you don't seem to get it. However, still, more stylistic talk... nothing of substance.

I gave you 2 graphics and I don't think you even understand the 2nd one really well.

You mean the one that contains two footnotse that submarines every substantive claim you've made? That one?

Maybe becuase it doesn't have volts/ampree/ohms in it's description.

Is that what you think electrical engineering is? Haha.


I'm sorry, you are backwards. What we don't have is the timestamp of the frame (or the frame reference number), what we do have (and what the CSV file represents) is the FDAU time stamp of the data which was converted from it's stored UTC/GMT to EST.

Completely and utterly wrong. This is the basic assumption on which all the CT analysis rests, and it's utterly wrong. Thanks for giving me a succinct pile of gibberish to point at.
 
I find it interesting that for someone who's creditials are stated as his, that he didn't just post the ARINC 717 Frame like I did. Hm?
It also seemed to surprise him and it did cause him to correct himself in one of his following posts (replacing FDR with DAU) after his saw that simplified diagram of a complete 'recording system'. It must've have been new to him.

I corrected myself? Try again. Your graphics perfectly illustrate the concepts I talked about in my paper. I even thanked you for them. Even down to the components.

The only thing I didn't describe was the term LRU, which is the input. I used the term "computer" because LRU is an unnecessary acronym. I don't need to explain to you, however, what an LRU is, and how the ADC, for example, is an LRU. You already obviously know (hint:google).
 
Last edited:

ISF - Join now!

Every member here is approved by hand. No bots, no spam, just people who care about evidence and honest debate.

Membership is free!

Create your free account

Back
Top Bottom