AA77 FDR Data, Explained

[DavidJames]

Originally Posted by Dazed

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

[Dazed]

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?

[Anti-sophist]

Originally Posted by Dazed

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.

[TjW]

Originally Posted by UnderTow

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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?

[UnderTow]

The CSV file

Originally Posted by Anti-S

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.

Originally Posted by NTSB AA77 FDR Report Page 2

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.

Originally Posted by Anti-S

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

Originally Posted by Anti-S

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.

Originally Posted by Anti-S

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.

Originally Posted by Anti-S

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.

Originally Posted by Anti-S

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.

[Anti-sophist]

Originally Posted by UnderTow

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.

Quote:

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:

Quote:

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.

Quote:

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.

Quote:

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

Quote:

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.

Quote:

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

Not sampled. Recorded.

Quote:

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.

[UnderTow]

Originally Posted 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?

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.

[TjW]

Originally Posted by UnderTow

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.

[UnderTow]

Originally Posted by Anti-sophist

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.

Originally Posted by AntiS

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?

Originally Posted by Anti-S

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.

Originally Posted by AntiS

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.

Originally Posted by Anti-S

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.

[UnderTow]

Originally Posted 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?

I underlined the following words:

Quote:

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?

[TjW]

I see you didn't answer.

[UnderTow]

Niether did you.
But okay, I will. You are not correct in assuming.

[TheGrunion]

Its funny when they get worried about painting themselves in a corner, but have no idea where the corners are.

[UnderTow]

Isn't it.

[DavidJames]

Originally Posted by UnderTow

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.

[TheGrunion]

Originally Posted by UnderTow

Isn't it.

I'm glad to see that you can laugh at yourself.

[beachnut]

Originally Posted by UnderTow

Isn't it.

does this mean you can not explain flight 77 data as presented else where etc?

do you agree with the assumtions made about the flight 77 FDR?

what do you say about the FDR and the data presented?

[Qubit]

Quote:

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.

[Anti-sophist]

Originally Posted by UnderTow

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?

Quote:

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.

Quote:

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

Sounds like gibberish semantics to me.

Quote:

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.

Quote:

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?

Quote:

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

Is that what you think electrical engineering is? Haha.

Quote:

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.

[Anti-sophist]

Originally Posted by UnderTow

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

[Anti-sophist]

Originally Posted by Qubit

Please correct me if I am wrong here, but there is a distinction between data being sampled and being recorded.

Essentially. Allow me to clarify the vocabulary for our dear friend, so he doesn't post another 10 page analysis of my use of terminology. In effect (please note I am using the terms "in effect" to convey a sense of abstractness. Not what is necessarily actually occuring), data is "sampled" twice. Essentially, the DAU takes a sample from the aircraft data source, time stamps it, individiually (if necessary), and stores it. Basically, this is the "measurement" sample. Later, the recorder/controller will sample the DAU's buffer of the most recent value, and store it. This is the "recorded" sampling.

You will notice that the graphic he posted shows this "parameter pool" in the DAU (what I call the digital buffer). The footnote also alludes to the fact that the "recorded" implied timestamp is not necessarily the measured time stamp. He has safely ignored this footnote because he doesn't understand that it submarines his entire argument.

Anyway, the implied timestamp (the frame's time stamp + location in the frame of the data) is the time of the "recording" sampling (That is to say, from the buffer to the recorded). The use of the term "implied" is of consequence. It means we aren't actually storing any information. Given the bit position of the data, and the distance from the most recent timestamp, we can calculate the implied timestamp of that recording.

On the other hand, the measured timestamp (from the aircraft, to the buffer) is lost, unless it has been specifically recorded as additional data.

Quote:

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.

He understands, I think. What he mistakenly believes (because he's misreading the standard) is that the measured time to recorded time need to differ by some relatively small delta-t. What he's actually looking at is the delta-t error between recorded samples.

As an example, if I'm sampling something at 1hz, and I record the first sample at 0.51s, I'd need to record the second sample at 1.51s +/- delta-t. None of this has bearing, at all, on when those samples were actually measured.

This particular requirement has to do with digital clock error and bit-synching.

[beachnut]

Originally Posted by Anti-sophist

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.

UT, his only reason to be posting here is to cut you as he stated in his first post, but that is my opinion after seeing his intro post in the intro area or somewhere

I was looking for an actual info on what happens in a big crash, what happens to the final data and how much data is lost,

You have contributed to your post with good work, UT is just trying to cut your stuff, and I am not so sure he has a clue, or understands the level of abstraction you are at, or why he thinks he can interpret the information he is finding without reference, to why it and his conclusions are correct when he could just fess up some info on the real topic and if he can explain to anyone what is going on and how to explain the FDR as you have done

Some info on the FDR, and then explain why it may be missing seconds, how many seconds and other ideas.

UT has no contribution yet on this area

The NTSB is the expert, next stop NTSB or some data on what they have found

But I will tell you this, I have investigated Air Force accidents, and after you learn about how the data is presented and the limitations you use it as facts to make your conclusion

The FDR presented facts on what flight 77 was doing during flight. The data presented matched what happen on 9/11. The FDR prove the terrorist pilot was not good, everyone agrees he was a poor pilot, his final turn is proof, his turn sucked, nice turn if you are just cruising but it was very poor if you would grade a turn.

It fills in the speed, then you can use the speed to confirm the aircraft destruction due to the KE. The Kinetic Energy of collision was close to a ton of TNT. Confirmed by speed read out on the FDR. Why was he speeding, he pushed up the throttles on his final run at the Pentagon, the FDR confirms it.

Is flight 77 still in the air 400 feet above the ground? No, it was brutally crashed into the Pentagon by cowards who defile their own religion by the very act. How do we know flight 77 hit the pentagon, darn the FDR was found inside the pentagon.

Pretty much leaves out the missile never seen, the little plane never flown, and other theories only poor researchers can come up with.

So unless UT comes up with some good ideas on the FDR, I have to assume the errors and general ideas you have worked on are good examples of possible errors and explain that we could be missing an unknown amount of information not recorded to the non-volatile area of the FDR.

[UnderTow]

You paper is full of assumptions, you don't reference a single standard for your error assumptions. You assume arguments from somewhere else without reference. You create your own error values. You state the the CSV file is not FDR data, when in fact, it is derived from it and through some poor software engineering your +-2 seconds and +-1.5 seconds assumptions are aboslutely ridiculous.

You can not even state one case world wide to demostrate your thoery of error despite having "gathered all publicly available informartion". Can you?

Yes, anything is possible. Especially when your attempting to create a case from scratch without reference to any real world examples. Of course, if it was up to you, I'm sure you would work on removing all these errors you have created from scratch in the design of your flight recording system. After all, it would have to be certified by several angecies before even being installed in the airframe.

Such as this statement here

Originally Posted by AntiS

a digital reading in the CSV file, like Computed Airspeed, which comes from the Air Data Computer, has an enormous error range, in the vicinity of 2 seconds, although 1.5 seconds is probably a safe estimate (0.5s for the buffering latency, and 1s for the uncertainty of when the sample was actually recorded).

Unless you can site a case or reference this, how is this valid?

Through out your entire 5 page paper, it amazes me that you think the entire world history of flight recorders and every crash investigation for the past 40 years hasn't already engineered solutions to this problems you attempt to create. And that somehow, you have discovered the errors which they have overlooked through every paper, every report, and every scientific study done.

By the way, in 1971, NASA and Boeing research into supersonic transport and barometer/alitmeter performance revealed that sea level barometer lag (for existing subsonic transports) is on the order of 0.1-0.2 seconds. While at Mach3+ and 77,800ft it's between 5-10 seconds.
(Refernce: NASA_CR1770_1971)

[Anti-sophist]

Originally Posted by UnderTow

You paper is full of assumptions, you don't reference a single standard for your error assumptions.

That's because there is no standard for how the CSV file should be. Are you dense? Show me what standard the CSV file adheres to. It is a derived work from STANDARD FDR data, but the CSV file, itself, conforms to NO standard. It's easy for someone, like me, to figure out what it means because I understand the standard of the data it was based upon. For you, however....

Quote:

You state the the CSV file is not FDR data, when in fact, it is derived from it

That is a blatant lie. That is EXACTLY what I say.

Quote:

and through some poor software engineering your +-2 seconds and +-1.5 seconds assumptions are aboslutely ridiculous.

Engineering you can find absolutely no mistake in, mostly because you can't understand it. And they aren't assumptions. I calculate them based on very simple digital signal processing methods. Do you know what a Nyquist Criterion is?

Quote:

Of course, if it was up to you, I'm sure you would work on removing all these errors you have created from scratch in the design of your flight recording system. After all, it would have to be certified by several angecies before even being installed in the airframe.

Are you still repeating this strawman nonsense? I've stated, over and over and over, that the system on the aircraft doesn't contain these errors. THE CSV FILE CONTAINS THESE ERRORS, NOT THE FDR. THIS IS NOT A HARD CONCEPT TO COMPREHEND. YOU HAVE MISUNDERSTOOD IT CONTINUOUSLY.

Quote:

Through out your entire 5 page paper, it amazes me that you think the entire world history of flight recorders and every crash investigation for the past 40 years hasn't already engineered solutions to this problems you attempt to create.

Read the statement above. These problems _ARE_ solved, but the answers are _NOT_ in the CSV file. Your amatuer analysis is based on the CSV file, which conforms to NO standard. If you based your analysis on the FDR data, it wouldn't have these errors, but you didn't. THE FLAW IN YOUR ANALYSIS IS THAT IT IS BASED ON THE CSV FILE, NOT THE RAW FDR DATA. Real engineers aren't basing their calculations on CSV files that were generated to plot data. They use the real data. You aren't.

Quote:

And that somehow, you have discovered the errors which they have overlooked through every paper, every report, and every scientific study done.

Find me one real world example of a scientific study based on a CSV file that is based on a standard that doesn't exist.

Quote:

By the way, in 1971, NASA and Boeing research into supersonic transport and barometer/alitmeter performance revealed that sea level barometer lag (for existing subsonic transports) is on the order of 0.1-0.2 seconds. While at Mach3+ and 77,800ft it's between 5-10 seconds.

Strawman. Has nothing to do with FDR time-slip errors in the CSV file.

Next.

[UnderTow]

Originally Posted by AntiS

Please keep in mind the CSV file is not raw FDR data, and it was not meant to be used forensically.

What is your basis for this falacy?
When every case I have seen begins with the tabular readout of the raw data. The tabular readout is where the investigation begins. Or do you propose they convert from binary to engineer units every time they look at a different parameter. And you are proposing that every time they make a tabular readout, they won't know if that roll actually occurred 3 seconds ago compared to a pitch on the same tabular row?

Your entire myopic argument is based off you being the sole creator of this wonderful paradigm of miraculous appearing offsites, errors, and assumptions.

Despite all the world's government agnecies, regulartory bodies, and investigative resources somehow overlooking the that thier plots and tabular readouts are actually completely worthless based on your scientific analysis.

There is no standard for a CVS tabular plot becuase it is a direct text based represntation of the engineering computations and calcuations done on the Standards in place over the past 40 years. It is the result of the calculations, engineering, certification, and requirments that made the FDR data file in the first place. When you plug that raw file into a ground station, and examine the parameter history in an table on screen, are these errors you have created there then? And when you print that table out on the printer, where did your errors come from?

Are you so pompous as to propose that the world history of investigative reports is based on faulty use of tabular read outs? And that by plotting thier FDR data into a multi-line chart is in error because when they read out that FDR data to a timeline plot they are introducing all these errors you somehow managed to create out of thin air?

[Anti-sophist]

ack, double post

[Anti-sophist]

Originally Posted by UnderTow

What is your basis for this falacy?

Originally Posted by Me, wasting my time

The flawed interpretation is quickly disposed of by realizing a few key pieces of evidence. (EDIT: Feel free to consult the CVS file for this example) 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.

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.

Originally Posted by UnderTow

Despite all the world's government agnecies, regulartory bodies, and investigative resources somehow overlooking the that thier plots and tabular readouts are actually completely worthless based on your scientific analysis.

Originally Posted by Me, still wasting my time

Are you still repeating this strawman nonsense? I've stated, over and over and over, that the system on the aircraft doesn't contain these errors. THE CSV FILE CONTAINS THESE ERRORS, NOT THE FDR. THIS IS NOT A HARD CONCEPT TO COMPREHEND. YOU HAVE MISUNDERSTOOD IT CONTINUOUSLY.

Read the statement above. These problems _ARE_ solved, but the answers are _NOT_ in the CSV file. Your amatuer analysis is based on the CSV file, which conforms to NO standard. If you based your analysis on the FDR data, it wouldn't have these errors, but you didn't. THE FLAW IN YOUR ANALYSIS IS THAT IT IS BASED ON THE CSV FILE, NOT THE RAW FDR DATA. Real engineers aren't basing their calculations on CSV files that were generated to plot data. They use the real data. You aren't.

I'm always up for repeating myself.

Quote:

There is no standard for a CVS tabular plot becuase it is a direct text based represntation of the engineering computations and calcuations done on the Standards in place over the past 40 years.

False. Evidence for this atrocity to human reason, please. Engineers base their calculations on the FDR data. Not CVS files generated to plot graphs.

Quote:

When every case I have seen begins with the tabular readout of the raw data.

Oh, and what forensic analysis have you done?

[UnderTow]

That is not it. The data is in the frame in the raw fdr file. It has already been placed there.
You can't post an image of this table so your refernce is incomplete.
Which 4 rows are you talking about?
There is ZERO dsp occuring when you compute the fdr frames to a tabular plot? Where is your error coming from.

You have said yourself, the FDR data Does Not contain this error. So how in the world can you possible insert this error into your tabular readout?

Let's theorize what your are referring to in the quote block of yours.
If you have 2 columns in a table. 8 rows of data.
Column A has 8 values, and Column B has 4, how many blank spaces do you get below Column B?

[Anti-sophist]

Let's play a new game, shall we, UnderTow.

Since I am a complete idiot and have no idea what I am talking about, please feel free to explain the following questions I have about this footnote in your graphic:

(original: http://www.aa77fdr.com/misc/Fig1_A717FrameFormat.jpg)

Quote:

The age of the NZ sample depends on how old it was when it arrived in the pool and how long it sat in the pool before time T-1. The source latency and transmit delay determine the age on arrival. The update rate determines the time spent in the pool before being used.
It appears that the Nz is 2/64 second older than Radalt because of its implied timetag, but it could actually be much newer.

1) Explain to me the difference between source latency, transmit delay, and how they effect the data "age".
2) How does "update rate" effect "time before use", and what effect does this have on the data?
3) How are these "delays" corrected?
4) Explain to me how you calculate the "age of a sample".
5) Explain to me how Nz "appears" older than Radalt.
6) Explain what an "implied timetag" is.
7) Explain how the Nz "could actually be much newer" even though it "appears" older.

If you don't have time to make up answers to all of it, just stick to #7.

[Anti-sophist]

Originally Posted by UnderTow

You can't post an image of this table so your refernce is incomplete.
Which 4 rows are you talking about?

Look in the CVS data for an example of a parameter (like longitudnal acceleration) that has 4 samples per frame. That's exactly what the table looks like in my document. Pick any frame.

Quote:

You have said yourself, the FDR data Does Not contain this error. So how in the world can you possible insert this error into your tabular readout?

Because this not a "tabular readout" of the FDR data. It was generated from the FDR data to be plotted. It is _not_ identical to the FDR data. And before you ask how I know, realize that the answer is in my two pieces of evidence already explained. It _cannot_ be the raw FDR for two simple reasons: (1) the samples are out of phase (see long. accel, or any other 4 Hz sampled datapoint in the CVS file) (2) the "bitrate" of the CVS file is non-constant (different amounts of data per row).

Raw FDR data would have a constant bitrate (ie, equal amounts of data per row, in a tabular printout), and all samples would be in phase (equally spaced out).

[UnderTow]

Who will grade this test? Your past employer?
Would you like an example picture to represent the delays and source code for the 429 card that calculates the sample before assembling this 717 frame?
Should I get my ARINC references out since you have failed to account for them in your great work of smarts?

If this frame is already compiled, and the time Parameter is syncrohnized in the FDAU prior to assembly, and the FDR Raw data does Not contain the errors you speak of in your report. Where do your errors come from?

Do you claim that every tabular readout and plot graphic is flawed and inaccurate?
If so, your claim as nothing to do with any conspriacy and you should petition the FAA to rewrite thier standards.

[UnderTow]

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.

[UnderTow]

There is no Phase or bitrate in a CSV file. It is TEXT in Table form.

The Plot is not made FROM the CSV. The RAPS system (and any FDR analysis software) uses the raw FDR file to make BOTH the Table and the Plot. They are BOTH based of the direct calculation of the FDR Data.

[Anti-sophist]

Originally Posted by UnderTow

Who will grade this test?

I have explained to you how this system works, in reality. You have claimed I'm an idiot. Therefore, you obvoiusly believe you know more than me. It is not a "test". I want to see how your interpretation of those comments is different then mine.

I can answer all 7 of those questions given my knowledge (that you claim is wrong)... let me see your explaination of those 7 questions raised from the footnote.

Once we've established your interpretation of these issues, we can move on to the more abstract issues you raise above.

[Anti-sophist]

Originally Posted by UnderTow

There is no Phase or bitrate in a CSV file. It is TEXT in Table form.

That's what I've been saying! You and JDX's dopey analysis is based on a misintrepretation of the CSV file.. that dopey intrepretation DOES assume bitrate and phase, inadvertently, by consequence of the way you are reading the file. The _full_ FDR data does contain that information (as in, it can be extracted entirely from the raw FDR data, given the descriptor)... and yet it's missing in the CSV file... where did it go?

This is exactly my point. Treating the CSV file as just true "tabular" FDR data is false. Tabular FDR data, like any serial framed data, is organized obviously in frames, with each row and column equaling a fixed amount of time. Every cell would define a unique period of time which is when the sample was RECORDED. Not measured. Each cell would represent a the same fixed amount of time, and they would all be full. That is what _raw_ tabular FDR data looks like. That is _not_ what the CSV file looks like.

Probability of this post being understood is frighteningly low, I'm afraid.

(Still waiting on your interpretation of the 7 issues raised in regards to the footnore)

[apathoid]

I see that you've mentioned ARINC numerous times, UT, as if to say that everything A-S has written can be dismissed if only he knew what the ARINC standards were.

This tells me one of two things. Either you still havent read A-S' orginal post or follow-ons(I mean actually read them - not scan them to see what you can cherry-pick), or you've no idea what ARINC is and how it pertains to the operation on the FDR/DFDAU.

ARINC is merely a transfer system, a means for communicating. All avionics on Boeings and Airbus use a Digital Information Transfer System (DITS), namely ARINC 429/629 - and in the case of the Loral Fairchild 2100, ARINC 717, 573, or 747 - to communicate. The front end of ARINC capable LRUs eventually strip away all of the ARINC formatting and convert the data(via signal condtioning) to something the on board circuit cards can use. This can be analog error signals for the Flight Control Computers to send to the autopilot servos during an ILS approach, or it can be TTL for data storage and processing.

You see, while the ARINC standards may indeed be very tight for accuracy and snycing of data between LRUs - it doesnt really pertain to how data gets acquired, buffered, compressed, multiplexed, stored, demuxed, decompresed, written or erased in the DFDR. All that happens behind the signal conditioners. Not to mention the fact that the DFDAU has similar things happening and its really the more pertinent LRU to A-S' essay on data aquisition.

I dont pretend to really grasp how these systems are designed or how they operate in detail, very few people do. But I can at least understand the point of A-S' original post. It seems you, UnderTow, still dont.

[Anti-sophist]

My explaination isn't complete. His notion that that was my intention is clearly misfounded. My intention was to provide exactly enough background to understand their flawed assumptions. If I wanted to add unnecessary complication, it would be easy.

First we would need to start with the electromagnetics. Ohm, Gauss, Faraday's law, at a minimum.

I'd go into the interconnection, when and why you should use single ended serial communication versus differential. We'd need to talk about coaxial, triaxial, twisted pair wiring, too.

Then we can talk about wire gauges (26, 22, 20...), shielding (especially for those twisted pair!), and terminiation resistors (wouldn't want any reflection, now, would we).

Now we also need to throw in a section about bit synching and under what conditions separate clock signals are approriate

Next, I could recite insane amounts of signal processing theory, error correction theory, and information theory to only explain the technical challenges associated with transfering this information, and provide sufficient motivation to develop a standard.

Once we understand the challenges facing such a system, I could get into the ARINC standad. I could compare and contrast them with MIL-1553 or HOO-9, both used on Boeing military aircraft, to help make the concepts clear. We'd show how each standard meets the technical challenges and solves the most difficult issues.

Once we've established what the standards require, and why they require the things they do, we can talk about the basic fundamentals of the system design, and how these systems meet the standards. We can talk about the necessary support required on the ground in terms of software and hardware. We can talk about the necessary maintence and testing procedures to ensure the standard is met.

And then, once all that is finished, you guys will have to read 400 pages and UnderTow will be complaining I didn't include an IRIG chapter 10 explaination.

[apathoid]

Originally Posted by Anti-sophist

My explaination isn't complete. His notion that that was my intention is clearly misfounded. My intention was to provide exactly enough background to understand their flawed assumptions. If I wanted to add unnecessary complication, it would be easy.

First we would need to start with the electromagnetics. Ohm, Gauss, Faraday's law, at a minimum.

I'd go into the interconnection, when and why you should use single ended serial communication versus differential. We'd need to talk about coaxial, triaxial, twisted pair wiring, too.

Then we can talk about wire gauges (26, 22, 20...), shielding (especially for those twisted pair!), and terminiation resistors (wouldn't want any reflection, now, would we).

Now we also need to throw in a section about bit synching and under what conditions separate clock signals are approriate

Next, I could recite insane amounts of signal processing theory, error correction theory, and information theory to only explain the technical challenges associated with transfering this information, and provide sufficient motivation to develop a standard.

Once we understand the challenges facing such a system, I could get into the ARINC standad. I could compare and contrast them with MIL-1553 or HOO-9, both used on Boeing military aircraft, to help make the concepts clear.

Once we've established what the standards require, and why they require the things they do, we can talk about the basic fundamentals of the system design, and how these systems meet the standards. We can talk about the necessary support required on the ground in terms of software and hardware. We can talk about the necessary maintence and testing procedures to ensure the standard is met.

And then, once all that is finished, UnderTow will be complaining I didn't include an IRIG chapter 10 explaination.

You forgot DC theory, solid state, transistor theory, digital theory and numbering systems(binary, octal, hexadecimal), logic gates, etc..

[Anti-sophist]

Originally Posted by apathoid

You forgot DC theory, solid state, transistor theory, digital theory and numbering systems(binary, octal, hexadecimal), logic gates, etc..

Digital encoding (floating point, fixed point, integer, big/little endian), too. It mixes in with the information theory, along with shannon entropy. Those two topics would be big.

Oh, and I'd need a section for a quick refresher on calculus 1, 2, and 3 so we could prove the characteristics of all our wire-types using Maxwell's Equations. I'd need to include data sheets of all the wires and signal conditioners, so we could properly prove that what goes in one side comes out the other. This goes back to the signal processing knowledge, you know.. nyquist criteria, fourier transforms, frequency responses, and the like.

[Qubit]

Originally Posted by Anti-sophist

Digital encoding (floating point, fixed point, integer, big/little endian), too. It mixes in with the information theory, along with shannon entropy. Those two topics would be big.

Oh, and I'd need a section for a quick refresher on calculus 1, 2, and 3 so we could prove the characteristics of all our wire-types using Maxwell's Equations. I'd need to include data sheets of all the wires and signal conditioners, so we could properly prove that what goes in one side comes out the other. This goes back to the signal processing knowledge, you know.. nyquist criteria, fourier transforms, frequency responses, and the like.

Don't forget VLSI concepts:
- Wiring and Interconnect: Elmore Delay, capacitance (fringing, interwire, cross-talk), low-k dielectrics, reduced swing, resistance, electromigration, inductance
- Gates: nmos, pmos, transient response, propagation delay, sizing, fan-in/out, subthreshold leakage
- combinational logic: logical effort, ratioed logic, pseudo-nmos, DCVSL, pass-transistors
- dynamic logic: charge sharing, backgate coupling, domino logic, differential domino logic
- sequential logic: latches, (positive/negative) edge triggered registers, C2MOS, TSPC, Schmitt Trigger, VCO

Etc, etc...just for starters