AA77 FDR Data, Explained
- Thread starter Anti-sophist
- Start date
-
- Tags
- aa77 flight data recorder
Anti-sophist
Graduate Poster
- Joined
- Sep 15, 2006
- Messages
- 1,542
Well, after a quick look at it, the graphic appears to be quite accurate. It's plenty sufficiently accurate, anyway, to debunk most of the claims made by CTers with only a reasonable bit of extra knowledge.
I wonder if they even understand the full implications of what the graphic is telling them. Ie, that the CSV file cannot be raw bit data and the implied time stamps are not to be trusted.
Seems odd that he'd post it if he actually understood it, as it tends to submarine alot of the assumptions made in analysis based on the CSV file.
It would be interesting to know how much time is missing due to FDR destruction and data storing parameters.
But with the video and data as is. The plane is only seconds from crashing into the ground and even if he points flight 77 into the pentagon as is and the approximate slope is 6 degrees, the altitude of flight 77 as it passes over the light posts, is only 90 to 120 feet above the base of the pentagon.
Knowing how many seconds are missing from the final altitude would help, but flight 77 was in the door for hitting the pentagon as seen by the visual data from the NTSB of the FDR.
It appears it was matched with the ground by approximation with other data. not sure how the ground was synchronized with the FDR data.
They referenced the the FDR times to the ATC clocks. This was snipped from the "Radar Study From All 4 Flights - Time Correlation"
http://www.ntsb.gov/info/Rec_Radar_ Data_ Study_all _aircraft.pdf
In case anyone is wondering, the onboard aircraft clock is handset, that is - it's not snyced to UTC. The DFDAU does indeed sample the clock, but I dont think its for event marking.
There are also some parameters that weren't released in the CSV that might help, namely Radar Altimeter. Does anyone know if the raw file does have the RADALT data? I've seen people mentioning this file, but have not seen it linked yet.
the excel file from NTSB does not have RADALT or other altitude besides PA I could find.
I searched ALT and RADALT no joy.
But the plane is only seconds away from impact, and if you back off at 6 degrees from the pentagon, it give you 6000 feet per minute, and it is only 90 to 120 feet above the base of the pentagon as it crosses the road.
Gravy
Downsitting Citizen
- Joined
- Mar 27, 2006
- Messages
- 17,078
My apology for not noticing your explanation. I do hope we keep in mind that the "cargo" aboard flight 77 was priceless.
The raw file was posted at JohnDoh's forum, but it's not exactly plain text. I believe the radar altimeter was listed under "parameters not working or unconfirmed" in the NTSB report (AAL77_fdr.pdf.) What they mean by that I do not know.
http://z9.invisionfree.com/Pilots_For_Truth/index.php?showtopic=64&st=0#entry2896395
Anti-sophist
Graduate Poster
- Joined
- Sep 15, 2006
- Messages
- 1,542
Right, the CSV is an extraction from the raw FDR data, which was also released. The problem is the raw FDR data is useless w/o the frame-descriptor to describe how to decode it. I'm also growing more convinced that the raw FDR file is also compressed by a propriety system, which would make reverse engineering the frame descriptor impossible.
Many of the parameters were "not working or unconfirmed". I should probably add up how many samples, total, occur during each frame in the CSV file and see how that total compares with the total bitrate, to see how much data got thrown out.
The RADALT data wasn't included in the CSV file. This is because the government knows it will bust the case wide open if they release it! (oh wait.. that's JDX's line).
LashL
Goddess of Legaltainment™
- Joined
- Aug 12, 2006
- Messages
- 36,711
No, sorry, I disagree with this assertion.
Having worked in aviation for several years in "the old days", and having flown all over the world in the process, specifically with regard to shipping cargo, I do not accept this assertion. There was always a distinction made between shipping cargo and shipping pax. Granted, when talking about total weight on a particular flight, it might all be referred to as "cargo" but Under_Tow is over-simplifying if he wants you to believe that there was no distinction made between the two. Sheesh, the paperwork and manifests for cargo, particularly live cargo, were much more complicated and difficult than those for pax, in fact.
(for clarity, pax=passengers)
Last edited:
Gravy
Downsitting Citizen
- Joined
- Mar 27, 2006
- Messages
- 17,078
The Complete Works of UnderTow
Hey Hey, I made it on board here
/yippe
I'll get to the OP (Orignial Post) here shortly(or at least over the next few days I hope)
I'll try not to let you down
No, I don't mind.
Well, I want to be complete and don't want to just post some 'I know' statement. And, I'm not working on this full time. You know. I get on when I can and what not. And your post is a 5 page wall of text.
Plus, I'd like to give people a chance to to self-correct first
'cargo plane' is just jargon in certain circles for any aircraft carrying over X gross weight. Whether it's bodies, boxes, or booty doesn't make a difference. It's all cargo.
HAHa, I could say the same thing about your "report".
And I'm not making anything of great length, just making sure I only use source and not opinions. Also, I can't post links yet so that makes it kind of limited.
I like this smilely jaw-dropping.gif but I can't use it b/c I don't have 50 posts yet.
Hm. Maybe I post links withCode:. Nope that didn't work. Oh well that's just randy.[/quote][QUOTE="UnderTow, post: 2021155, member: 12435"]And your referring to what?[/quote][QUOTE="UnderTow, post: 2021311, member: 12435"]I need to work on my post count here. :) You report is tripe. It is so full of misunderstandings, misintterputations, and is total bloat. I can't believe your "waving it about as proof".[/quote][QUOTE="UnderTow, post: 2021351, member: 12435"]I don't know why. The term 'computer expert' certainly could mean just about anything these days. Most likely because through my other work he's found me to be very adept with technology. In like terms, I don't care about your credentials much either, and I don't see why you even put them in your report, since they are pretty loose and easily typed by anyone. Perhaps to add a bit of extra fluff to the report maybe. And since you won't judge me by mine, I feel no reason to state them.[/quote][QUOTE="UnderTow, post: 2021442, member: 12435"]I guess I have to get a couple hundred posts in before I can start acting like other Randi posters hey? Thanks for you comment anyway I guess /sigh[/quote][QUOTE="UnderTow, post: 2021471, member: 12435"]I'm getting there :) /thanks 14 and slacking[/quote][QUOTE="UnderTow, post: 2021631, member: 12435"]I'd post the specific link. But I'm not allowed. But it is right below your question. /whistle[/quote][QUOTE="UnderTow, post: 2021734, member: 12435"]I only said that b/c Gravy posted a link to his post which is on this very same page, and my reply was the post directly below his. So in like I would've post the link directly to my post like he did. But instead I jabbed at my post limitation again and simple quoted myself. See :) /post 17[/quote][QUOTE="UnderTow, post: 2021774, member: 12435"]For real!! :D [URL]http://www.aa77fdr.com/misc/Figure2.1_1.jpg[/URL] [URL]http://www.aa77fdr.com/misc/Fig1_A717FrameFormat.jpg[/URL] Damn, and right at the end of the day. I'll let you all sauce on that. Gotta run. /thanks Admins :)[/quote]That was it? He didn't seem to be having fun at all.
Anti-sophist
Graduate Poster
- Joined
- Sep 15, 2006
- Messages
- 1,542
I'm still waiting anxiously to see how he's going to use those graphics whose footnotes literally validate everything I've said.
It is my current belief that the basic issues I bring up are yet to be understood by any of the "believers". I truly hope that is not true, because it will have meant I have wasted my time. They are going to attack a bunch of arguments that I'm not making (ie, quote that same line I've seen 5 times already about "perfect" data recovery), and declare victory.
It's easier, I suppose, then having to learn how a complicated system works. The whole concept that the CSV file isn't the same as the raw FDR data completely escapes them, I think.
It is my current belief that the basic issues I bring up are yet to be understood by any of the "believers". I truly hope that is not true, because it will have meant I have wasted my time. They are going to attack a bunch of arguments that I'm not making (ie, quote that same line I've seen 5 times already about "perfect" data recovery), and declare victory.
It's easier, I suppose, then having to learn how a complicated system works. The whole concept that the CSV file isn't the same as the raw FDR data completely escapes them, I think.
What was that all about Gravy? Anyone can read through this thread for the progression of what I have (or haven't) done so far here. What are you trying to represent by just posting all my quotes completely out of refernece to everything around them? (the time I posted them, the comments before and after them, etc).
Don't worry AntiS. You status and prestige with the JRandi site is not my concern. Niether is whatever battle you think your in.
However, you may have more work to do editing your posts with the information I will provide you, since you failed to find it on your own.
So on with the show. I will post my comments to your wall of text in sections, so it will be somewhat more readable. This is primarily my critque and not an alternative analysis (in which case I'm not going to be using any of your text anyway).
Don't worry AntiS. You status and prestige with the JRandi site is not my concern. Niether is whatever battle you think your in.
However, you may have more work to do editing your posts with the information I will provide you, since you failed to find it on your own.
So on with the show. I will post my comments to your wall of text in sections, so it will be somewhat more readable. This is primarily my critque and not an alternative analysis (in which case I'm not going to be using any of your text anyway).
The Intro.
------------------------
I gathered up 1a all the publically available flight-data-recorder information, My initial intent was to 2a properly analyze the data and debunk the variety of 2b dopey conspiracy theories After reading 1b all of the NTSB reports, looking carefully at the data provided about the hardware, and the CSV file, I realized that virtually all conspiracy theorist attempts at 3 using this data for sub-second accurate reconstruction is completely and utterly baseless.
4 In the words of Pauli, paraphrased, they aren't even wrong.
1a. This is false, otherwise you would have used the Standards and Requirements that have been in place for years and decades
1b. This is false, otherwise you would seen exactly the type of analysis which was your intial intent
2ab. I'm not sure if you ever got to the first part and the second part seems uncivil and unscientific. Trying to score points with humor is not needed
3. Ambiguous use of the word 'data' and if 1a,1b were true, you would see that sub-second accuracy is easily obtain through FDR analysis. Or maybe this Topic should be AA77 CSV Tabular Hypothesis
4. Cute, but again not neeed
This details, specifically, what flight data recorder data looks like, how it is recorded, how it is decoded, and what the CSV file flying around actually is (and how it was made).
But you failed to reference any of the ARINC, IEEE, Boeing, or other industry standards. I think you would find that they have done all of this work already and it is has been in service for several decades
Contained in this document is a pretty thorough description of all the sources for error that pop up when using the CSV file as a "raw" fdr data output, and I explain how the real "fdr" data has few of these problems. I don't actually debunk any specific claims (ie, JDXs), entirely because almost all of the flaws in the analysis are simple and trivial to point out given a thorough understanding of what the CVS file is.
Using the world 'all' seems to be an error you are prone to. The CSV file is a result of Engineering Computation of the raw FDR data. It surely does contain some problems in presentation, but I don't know where you get this statement "using" from, perhaps a reference to some specifics would be in order instead of using 'all' so much. Again, you should replace FDR with CSV in your Title
----
About Me:
MS Electrical Engineering, worked with the USAF (as a civilian) on F15s doing data recording and telemetry. I've designed, built, tested, installed, and maintained flight data acquisition systems, of which the FDR is a very low-bit-rate version. It also has the unique characteristic, among data recorders, of being crash survivable.
-------------
Why bother putting this in here. Based on your other comments in this thread, the body of your text should stand on it's own. Perhaps to add weight and an air of authority? Since you don't actually reference any industry standards and prior work, this must be your personal opinion.
One of the problems with this report is that you seem to be doing a lot of work and effort despite the fact that the major companies and bodies in this industry have already done all this work and that's why we have Standards, References, and Requirments in place since the mid 1900's. You appear to propose some industry breaking theory of error finding that all these thousands of people and billions of dollars have overlooked or not thought of themselves. Not NASA, Boeing, L-3, AA, FAA, NTSB, ARINC, IEEE, FlightScape, and the list goes on and on.
Now, not everything is wrong in here, but why you didn't just take the Crash Investitgations, Enginerring Standards, and Industry Requirments already in place for the past 40 Years and shoot holes in that.
------------------------
I gathered up 1a all the publically available flight-data-recorder information, My initial intent was to 2a properly analyze the data and debunk the variety of 2b dopey conspiracy theories After reading 1b all of the NTSB reports, looking carefully at the data provided about the hardware, and the CSV file, I realized that virtually all conspiracy theorist attempts at 3 using this data for sub-second accurate reconstruction is completely and utterly baseless.
4 In the words of Pauli, paraphrased, they aren't even wrong.
1a. This is false, otherwise you would have used the Standards and Requirements that have been in place for years and decades
1b. This is false, otherwise you would seen exactly the type of analysis which was your intial intent
2ab. I'm not sure if you ever got to the first part and the second part seems uncivil and unscientific. Trying to score points with humor is not needed
3. Ambiguous use of the word 'data' and if 1a,1b were true, you would see that sub-second accuracy is easily obtain through FDR analysis. Or maybe this Topic should be AA77 CSV Tabular Hypothesis
4. Cute, but again not neeed
This details, specifically, what flight data recorder data looks like, how it is recorded, how it is decoded, and what the CSV file flying around actually is (and how it was made).
But you failed to reference any of the ARINC, IEEE, Boeing, or other industry standards. I think you would find that they have done all of this work already and it is has been in service for several decades
Contained in this document is a pretty thorough description of all the sources for error that pop up when using the CSV file as a "raw" fdr data output, and I explain how the real "fdr" data has few of these problems. I don't actually debunk any specific claims (ie, JDXs), entirely because almost all of the flaws in the analysis are simple and trivial to point out given a thorough understanding of what the CVS file is.
Using the world 'all' seems to be an error you are prone to. The CSV file is a result of Engineering Computation of the raw FDR data. It surely does contain some problems in presentation, but I don't know where you get this statement "using" from, perhaps a reference to some specifics would be in order instead of using 'all' so much. Again, you should replace FDR with CSV in your Title
----
About Me:
MS Electrical Engineering, worked with the USAF (as a civilian) on F15s doing data recording and telemetry. I've designed, built, tested, installed, and maintained flight data acquisition systems, of which the FDR is a very low-bit-rate version. It also has the unique characteristic, among data recorders, of being crash survivable.
-------------
Why bother putting this in here. Based on your other comments in this thread, the body of your text should stand on it's own. Perhaps to add weight and an air of authority? Since you don't actually reference any industry standards and prior work, this must be your personal opinion.
One of the problems with this report is that you seem to be doing a lot of work and effort despite the fact that the major companies and bodies in this industry have already done all this work and that's why we have Standards, References, and Requirments in place since the mid 1900's. You appear to propose some industry breaking theory of error finding that all these thousands of people and billions of dollars have overlooked or not thought of themselves. Not NASA, Boeing, L-3, AA, FAA, NTSB, ARINC, IEEE, FlightScape, and the list goes on and on.
Now, not everything is wrong in here, but why you didn't just take the Crash Investitgations, Enginerring Standards, and Industry Requirments already in place for the past 40 Years and shoot holes in that.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I. Recorded Flight Data Format
The recorded flight data is serial binary data. 1 So that means the guy who sat down with Flight 77s data recorder, put the tape into a computer, a single wire as the input, and across that wire comes a series of bits: 1,1,1,0,0,1,0,1,1,0,0,1.
When you 2 consider the problem of sitting at a computer, and seeing a serial stream of 1s and 0s come in, and trying to make sense of it, you will begin to realize the engineering difficulties in making this process work well. Well, the first (and most familiar) is to break up the signal into bytes (8 bytes), or other units of length (the FDR on flight 77 uses words of 12 bits in length, instead of bytes). Throughout the document, I will refer to “words” which simply means a predefined number of bits. For Flight 77, specifically, it means 12 bits, however the logic below will apply to any number of bits per word.
1,2 This is completely disengenous and is a personal attack to the people and companies that actually perform this work. Being an Engineer yourself I would think you would have more respect for the fellows that perform in this field of work. The "problem" you attempt to create is something that these companies and people have been working with for several decades. No one "sees" a stream of bits and attempts to "make sense of it". That is nonsense and for the people that actually work on this for a living it's an offense to thier efforts and achievments. You continue this for the next several paragraphs which I won't bother hashing apart for more "dopey" comments except to note some special cases.
The next major abstraction is to frames. A frame is a specific group of words. On Flight 77, the frame length was 256 words. In order to correct for errors, each frame has specific “synch” words that are used to keep the data-processing software “in synch”. Every 256 words, the recorded inserted a known “synch” word. This synch word, literally, is used to keep the data-processing in synch, and help correct for errors.
All frames are exactly the same length, with the known synch words in the exact same places. For this reason, when you are receiving data from a data recorder, you would know there is supposed to be 2000 bits between synch words, and so if the current frame you’ve received only has 1999 bits between synch words, you would know that a bit has been dropped (this happens more often than you’d think).
3 The question becomes: “Ok, we dropped a bit… but from where?” Chances are high only one of your words is corrupted (11 bits instead of 12), but 4 it’s impossible to know which one, so you are forced to throw out the entire frame. (Please keep that thought in mind when conspiracy theorists talk about “partial frames”).
3. This question does arrive, but it's easily answered by the companies that specialize in this field and specifically Boeing and American Airlines. You would be better off explaining right here about the data frame layout which would tell you exactly what is missing instead of injecting more nonsense about impossiblities. Remember, we haven't even got to the Engineering Computations yet which occur prior to a CSV or Tabular read out.
Often times, frames of serial data are structured even further into “major frames” and “minor frames”. A major frame is simply a collection of minor frames, and it’s done almost always for convenience. Flight 77 has major frames that are 4 seconds long, and it is broken down into four 1-second minor frames, each consisting of 256 12-bit words.
4 All frames have time stamps. Since each frame represents an exact amount of time, the recorded time of any single word can be calculated by its position in the frame and the time-stamp of the frame. If a word is exactly half way into a frame, it’s time of recording was exactly halfway between this frame’s timestamp and the next one.
4. And right here is your * great mistake. You cojoin different definitions of time in the same reference. A Time Stamp is entirely different from a Time Slot. Later on you change "word" to "data" which further the mistake. This is my critique and not my alternate presentation so I will not create another wall of text on details here. Perhaps you mean something different here, in which case you should reword it to be clearer.
There are some important issues to note about recorded: You need to fix this statement, it seems incomplete
1)The amount of data flowing is always constant. There are exactly N bits in T time, never more, never less (if you were designing a system, you’d put filler words in to make sure of this).
2)If there are too many, or too few bits, between a pair of synch words, it’s virtually impossible to tell which data is corrupt, and almost always all of this data is thrown out.
Another false use of "impossible" to add weight to your argument. It is not impossible and "all" of this data is never "thrown out". We are talking about the FDR here correct?
3)Data, relative to the frame, is always recorded at the same time. If your frame period is 1 second and you set it to record the altimeter at 0.3 seconds, it’s going to be in the data stream at 0.3, 1.3, 2.3, 3.3, 4.3, etc. Each piece of data gets his one shining moment specially reserved for him, so he had better be ready to go at that moment.
Adding more wieght by not fully explaining the Frame and injected seconds for your false computations later. You continue the mistake of earlier by linking a "word" which a value for Alititude and that you can add the Time Slot to the Time Stamp for the Real World Time of the Data Event as it happened.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I. Recorded Flight Data Format
The recorded flight data is serial binary data. 1 So that means the guy who sat down with Flight 77s data recorder, put the tape into a computer, a single wire as the input, and across that wire comes a series of bits: 1,1,1,0,0,1,0,1,1,0,0,1.
When you 2 consider the problem of sitting at a computer, and seeing a serial stream of 1s and 0s come in, and trying to make sense of it, you will begin to realize the engineering difficulties in making this process work well. Well, the first (and most familiar) is to break up the signal into bytes (8 bytes), or other units of length (the FDR on flight 77 uses words of 12 bits in length, instead of bytes). Throughout the document, I will refer to “words” which simply means a predefined number of bits. For Flight 77, specifically, it means 12 bits, however the logic below will apply to any number of bits per word.
1,2 This is completely disengenous and is a personal attack to the people and companies that actually perform this work. Being an Engineer yourself I would think you would have more respect for the fellows that perform in this field of work. The "problem" you attempt to create is something that these companies and people have been working with for several decades. No one "sees" a stream of bits and attempts to "make sense of it". That is nonsense and for the people that actually work on this for a living it's an offense to thier efforts and achievments. You continue this for the next several paragraphs which I won't bother hashing apart for more "dopey" comments except to note some special cases.
The next major abstraction is to frames. A frame is a specific group of words. On Flight 77, the frame length was 256 words. In order to correct for errors, each frame has specific “synch” words that are used to keep the data-processing software “in synch”. Every 256 words, the recorded inserted a known “synch” word. This synch word, literally, is used to keep the data-processing in synch, and help correct for errors.
All frames are exactly the same length, with the known synch words in the exact same places. For this reason, when you are receiving data from a data recorder, you would know there is supposed to be 2000 bits between synch words, and so if the current frame you’ve received only has 1999 bits between synch words, you would know that a bit has been dropped (this happens more often than you’d think).
3 The question becomes: “Ok, we dropped a bit… but from where?” Chances are high only one of your words is corrupted (11 bits instead of 12), but 4 it’s impossible to know which one, so you are forced to throw out the entire frame. (Please keep that thought in mind when conspiracy theorists talk about “partial frames”).
3. This question does arrive, but it's easily answered by the companies that specialize in this field and specifically Boeing and American Airlines. You would be better off explaining right here about the data frame layout which would tell you exactly what is missing instead of injecting more nonsense about impossiblities. Remember, we haven't even got to the Engineering Computations yet which occur prior to a CSV or Tabular read out.
Often times, frames of serial data are structured even further into “major frames” and “minor frames”. A major frame is simply a collection of minor frames, and it’s done almost always for convenience. Flight 77 has major frames that are 4 seconds long, and it is broken down into four 1-second minor frames, each consisting of 256 12-bit words.
4 All frames have time stamps. Since each frame represents an exact amount of time, the recorded time of any single word can be calculated by its position in the frame and the time-stamp of the frame. If a word is exactly half way into a frame, it’s time of recording was exactly halfway between this frame’s timestamp and the next one.
4. And right here is your * great mistake. You cojoin different definitions of time in the same reference. A Time Stamp is entirely different from a Time Slot. Later on you change "word" to "data" which further the mistake. This is my critique and not my alternate presentation so I will not create another wall of text on details here. Perhaps you mean something different here, in which case you should reword it to be clearer.
There are some important issues to note about recorded: You need to fix this statement, it seems incomplete
1)The amount of data flowing is always constant. There are exactly N bits in T time, never more, never less (if you were designing a system, you’d put filler words in to make sure of this).
2)If there are too many, or too few bits, between a pair of synch words, it’s virtually impossible to tell which data is corrupt, and almost always all of this data is thrown out.
Another false use of "impossible" to add weight to your argument. It is not impossible and "all" of this data is never "thrown out". We are talking about the FDR here correct?
3)Data, relative to the frame, is always recorded at the same time. If your frame period is 1 second and you set it to record the altimeter at 0.3 seconds, it’s going to be in the data stream at 0.3, 1.3, 2.3, 3.3, 4.3, etc. Each piece of data gets his one shining moment specially reserved for him, so he had better be ready to go at that moment.
Adding more wieght by not fully explaining the Frame and injected seconds for your false computations later. You continue the mistake of earlier by linking a "word" which a value for Alititude and that you can add the Time Slot to the Time Stamp for the Real World Time of the Data Event as it happened.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:
1)Data the recorder can access at any time (almost always analog sensors)
2)Data that the recorder is told, at certain, unpredictable, times (almost always digital information from a computer).
An accelerometer is an analog sensor. The recorder can read the accelerometer at any time. So if the accelerometer data is programmed to be recorded at 19.723 seconds, the recorder can read the accelerometer at 19.721 seconds, get the answer, and store it. This means, for data of type I, the time the data is recorded is virtually identical to the time it is measured. This is the key distinction between the two types of data.
This time the data will come from a digital source like, for example, an Air Data Computer (ADC). The ADC might compute the air speed 5 times per second, along with helping the pilot fly the plane. It’s much smarter (and safer) to let the ADC say to the recorder “Here is the computed airspeed” when it isn’t busy. The opposite approach would be to let recording system interrupt the ADC and say “Give me the airspeed”. The ADC might be doing more important things during this time, and giving out data to the recorder might not be the highest priority. In almost all situations, the first method is preferred: The device, when it’s ready, sends the data to the recording system.
This fundamental design decision has serious implications. The airspeed data might not be programmed to go out in the serial data stream until 0.75s (remember, this data is stored at a specific time), but the ADC has informed the recorder at 0.3s of his airspeed. The recorder unit must be able to receive this information from the ADC or other digital sources, and store it, until it is time to record it. Recording systems all employ some type of digital buffering, so that they can receive and hold information until that particular piece of data gets his turn to be recorded.
Be mindful, that this introduces an error. If the data was measured at 0.3s, and recorded at 0.75s,
our poor software engineer
OMG!! I Can Not believe this is really your point of view here!!
who is decoding it later will think it was measured at 0.75s. This problem is generally solved by reserving space in the data-stream for time-stamps of the data. In other words, word 3 might be for the computed airspeed, and word 4 might be for the time-stamp that the computed airspeed was measured. In this way, the actual altitude signal might be recorded at time 1.7, but the timestamp will tell us it was measured at 1.3. It’s very important to understand that when this type of data was recorded does not indicate when it was measured. You need this timestamp information to do know when it was measured. Flight 77 raw's FDR data probably has these timestamps, but the CSV file does not.
You continue the great mistake right here again. The Time Stamp recorded in the Data Frame is exactly what it is. A Time Stamp for ALL records recorded in that Frame. I'm sure you'll be upset about me saying this here, but I'm just critique. I'll give source references and factual data later.
YOU SHOULD DELETE THIS ENTIRE FOLLOWING SECTION
Hardware and Terminology
All flight data recording is split into 3 distinct, logical, components. Modern recorders contain all 3 modules in a single box, but if you were to crack it open, and look at the design, you’d see three very distinct components:
1)DAU: Data Acquisition Unit: The DAU is responsible for buffering all digital data (and timestamps of when it was measured), and having all analog data sampled and ready to go. Basically, you can think of the DAU as the RAM or memory of the recording system.
2)Controller: The controller is responsible for executing the program (the frame). Basically he follows the tabular chart. If we are at word 1, we tell the DAU “Send Major Synch to the Recorder”. Wait for the word to finish sending, and then tell the DAU “Send the Time Stamp to the Recorder”, and so on.
3)Recorder: Obviously receives a stream of data and stores it to some medium. The actual recording medium used in the FDR of Flight 77 was “solid-state”. It’s a fairly new recording technology and a large improvement over the older methods (magnetic tapes).
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:
1)Data the recorder can access at any time (almost always analog sensors)
2)Data that the recorder is told, at certain, unpredictable, times (almost always digital information from a computer).
An accelerometer is an analog sensor. The recorder can read the accelerometer at any time. So if the accelerometer data is programmed to be recorded at 19.723 seconds, the recorder can read the accelerometer at 19.721 seconds, get the answer, and store it. This means, for data of type I, the time the data is recorded is virtually identical to the time it is measured. This is the key distinction between the two types of data.
This time the data will come from a digital source like, for example, an Air Data Computer (ADC). The ADC might compute the air speed 5 times per second, along with helping the pilot fly the plane. It’s much smarter (and safer) to let the ADC say to the recorder “Here is the computed airspeed” when it isn’t busy. The opposite approach would be to let recording system interrupt the ADC and say “Give me the airspeed”. The ADC might be doing more important things during this time, and giving out data to the recorder might not be the highest priority. In almost all situations, the first method is preferred: The device, when it’s ready, sends the data to the recording system.
This fundamental design decision has serious implications. The airspeed data might not be programmed to go out in the serial data stream until 0.75s (remember, this data is stored at a specific time), but the ADC has informed the recorder at 0.3s of his airspeed. The recorder unit must be able to receive this information from the ADC or other digital sources, and store it, until it is time to record it. Recording systems all employ some type of digital buffering, so that they can receive and hold information until that particular piece of data gets his turn to be recorded.
Be mindful, that this introduces an error. If the data was measured at 0.3s, and recorded at 0.75s,
our poor software engineer
OMG!! I Can Not believe this is really your point of view here!!
who is decoding it later will think it was measured at 0.75s. This problem is generally solved by reserving space in the data-stream for time-stamps of the data. In other words, word 3 might be for the computed airspeed, and word 4 might be for the time-stamp that the computed airspeed was measured. In this way, the actual altitude signal might be recorded at time 1.7, but the timestamp will tell us it was measured at 1.3. It’s very important to understand that when this type of data was recorded does not indicate when it was measured. You need this timestamp information to do know when it was measured. Flight 77 raw's FDR data probably has these timestamps, but the CSV file does not.
You continue the great mistake right here again. The Time Stamp recorded in the Data Frame is exactly what it is. A Time Stamp for ALL records recorded in that Frame. I'm sure you'll be upset about me saying this here, but I'm just critique. I'll give source references and factual data later.
YOU SHOULD DELETE THIS ENTIRE FOLLOWING SECTION
Hardware and Terminology
All flight data recording is split into 3 distinct, logical, components. Modern recorders contain all 3 modules in a single box, but if you were to crack it open, and look at the design, you’d see three very distinct components:
1)DAU: Data Acquisition Unit: The DAU is responsible for buffering all digital data (and timestamps of when it was measured), and having all analog data sampled and ready to go. Basically, you can think of the DAU as the RAM or memory of the recording system.
2)Controller: The controller is responsible for executing the program (the frame). Basically he follows the tabular chart. If we are at word 1, we tell the DAU “Send Major Synch to the Recorder”. Wait for the word to finish sending, and then tell the DAU “Send the Time Stamp to the Recorder”, and so on.
3)Recorder: Obviously receives a stream of data and stores it to some medium. The actual recording medium used in the FDR of Flight 77 was “solid-state”. It’s a fairly new recording technology and a large improvement over the older methods (magnetic tapes).
III. Flight 77s Flight Data Recorder
I'm only go to note some special cases in this section
The vast majority of information "vast majority" oh my...*cough*
Beyond the FDR report, from the NTSB, there are two released attachments:
1)The .fdr file which contains the actual data-dump from the FDR
2)A CSV file which contains processed FDR data
You should just go ahead and link them and give credit where it's due. "poor software engineer" omg...
The FDR Raw Data File
To the best of my knowledge, none of these documents exist in the public domain, and were not released with the FOIA request. Without the frame description information, the raw data is almost entirely useless.
The only issue is to what extent can this file be reverse engineered, and what useful data can come from it. First, and most importantly, I am not sure if this data file has been uncompressed. The Flight 77 FDR report mentions (page 3) that specific software is necessary to uncompress the data. If the data in this file is compressed, then there is virtually nothing useful to be gained, without first uncompressing it. Given a brief look at the header of the raw file, it appears to contain plain-text, which would imply it was not compressed data.
Under the assumption it is uncompressed, already, I will speculate, briefly, on the potential gain from reverse engineering it. First, it’s very likely that someone with minor amounts of effort could figure out the synch words, and extract the major and minor frames in raw format. In this sense, you could get “frame lock”. You’d be able to align all the data between frames. This may be useful in determining the number of frames, or the state of the final few frames. Extracting any information, beyond that, would be incredibly difficult to pull off successfully.
Perhaps another one of those "poor software engineers" like yourself (given your "credentials") would not need to assume such things and give details and credit where it is due for things that others have already done publicly. I'm getting quite tired at this point of reading this "dopey" work. I know I should refrain from being uncilvil and unpolite but whatever.
~~~~~~~~~~~~~~~~~~~~~~~~~~
I'm only go to note some special cases in this section
The vast majority of information "vast majority" oh my...*cough*
Beyond the FDR report, from the NTSB, there are two released attachments:
1)The .fdr file which contains the actual data-dump from the FDR
2)A CSV file which contains processed FDR data
You should just go ahead and link them and give credit where it's due. "poor software engineer" omg...
The FDR Raw Data File
To the best of my knowledge, none of these documents exist in the public domain, and were not released with the FOIA request. Without the frame description information, the raw data is almost entirely useless.
The only issue is to what extent can this file be reverse engineered, and what useful data can come from it. First, and most importantly, I am not sure if this data file has been uncompressed. The Flight 77 FDR report mentions (page 3) that specific software is necessary to uncompress the data. If the data in this file is compressed, then there is virtually nothing useful to be gained, without first uncompressing it. Given a brief look at the header of the raw file, it appears to contain plain-text, which would imply it was not compressed data.
Under the assumption it is uncompressed, already, I will speculate, briefly, on the potential gain from reverse engineering it. First, it’s very likely that someone with minor amounts of effort could figure out the synch words, and extract the major and minor frames in raw format. In this sense, you could get “frame lock”. You’d be able to align all the data between frames. This may be useful in determining the number of frames, or the state of the final few frames. Extracting any information, beyond that, would be incredibly difficult to pull off successfully.
Perhaps another one of those "poor software engineers" like yourself (given your "credentials") would not need to assume such things and give details and credit where it is due for things that others have already done publicly. I'm getting quite tired at this point of reading this "dopey" work. I know I should refrain from being uncilvil and unpolite but whatever.
~~~~~~~~~~~~~~~~~~~~~~~~~~
So after what ever you are doing!?
Is the final attitude on the CT idiot smart-remarks video of the NTSB, the final altitude or are 3 seconds of altitudes missing?
Did the aircraft hit at 5 degrees or 6 degrees, or 4 degrees.
Cause at this altitude there are only a few seconds left before it hits the ground. And it does hit the pentagon.
Question you could work on is how they fit the FDR to the ground? How accurate is it?
And you can not use a flat on the grass attitude, the security camera is a one second camera, the plane is doing 771 plus feet per second, you will never see it on the one second parking lot camera. So there is no video proof of the angle of final hit on the pentagon.
But a 4 to 6 degree impact, which the terrorist is doing, will hit the light post and hit the pentagon.
No the Pentagon does not have millions of cameras, we do not pay enough taxes!
did the terrorist push the nose over to 10 degrees then settle on 4 degrees into the pentagon on the final second?
The main point is understanding the FDR. Just for normal people.
I look at the FDR data and it supports all the other information you can gather on 9/11. Since the FDR was found in the pentagon, it now only becomes a point to argue with not so smart CT dolts who now say the planed did not crash into the Pentagon.
The fact is, flight 77 did crash into the pentagon and the FDR backs up the facts.
The only point for the CT movement of non truth is to find proof it did not happen. Else they need to move to fiction land.
Darth Rotor
Salted Sith Cynic
- Joined
- Aug 4, 2006
- Messages
- 38,527
Among military aviators, the difference between Pax(passengers) and Cargo is not blurred. I wonder what circles he travels in. I have carried both.
DR
Gravy
Downsitting Citizen
- Joined
- Mar 27, 2006
- Messages
- 17,078
It was about getting you to come back to finish what you started but chose not to continue. Looks like I was successful.