AA77 FDR Data, Explained

[Anti-sophist]

I gathered up all the publically available flight-data-recorder information, looked at it closely. My initial intent was to properly analyze the data and debunk the variety of dopey conspiracy theories that abounded. After reading 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 using this data for sub-second accurate reconstruction is completely and utterly baseless. In the words of Pauli, paraphrased, they aren't even wrong.

What follows is a copy/paste of the bulk of a longer doc file I've been writing. 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). I'd really appreciate a proofread and some constructive criticism on any gaps. 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.

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.

The meat of the paper is section 3. Sections 1 and 2 are scientific background and descriptions of the various technical aspects.

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

I. Recorded Flight Data Format

The recorded flight data is serial binary data. 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 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.

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

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.

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.

There are some important issues to note about recorded:

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.

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.


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

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

The vast majority of information about the Flight Data Recorder (FDR) that is found in the public domain is the result of FOIA (Freedom of Information Act) requests to the NTSB. The full versions of all the reports are available here: http://www.ntsb.gov/info/foia_fri.htm

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

Some technical details about the serial data on the FDR:

This output is a continuous sequence of four-second frames. Each frame consists of four subframes of 256 separate 12-bit words, with the first word containing a unique 12-bit synchronization word identifying it as subframe 1,2,3 or 4.

The FDR Raw Data File

A raw data file is only useful if also given the frame description, which describes the synch words, and the location inside of each frame for each recorded value. This frame-description was included in the NTSB report, according to the NTSB Flight 77 FDR report, page 2, footnote 1:

Based on Boeing’s 757-3B data frame. See Attachments IV and V. Boeing Document D226A-101-3, Rev. G, October 27, 1999 (D226A101-3G.pdf); American Airlines database printout (757-3b_1.txt)

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.


The CSV file

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.

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.

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.

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.

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.

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

The Final 1 to 2 Seconds

Given that the data was compressed, and synched, it’s very likely that any frames that were not complete would be difficult to recover, if even recoverable at all. The implication of this is quite simple, and that is the FDR data in the CSV file “runs out” well before the plane actually hits.

This means that 9:37:44 was the last, complete frame, gathered by the recorder. That puts the likely time of impact in the 9:37:45-6 range, and possibly even into the 9:37:46-7 timeframe. The presence of 9:37:46 in this data suggests that its timestamp may have made it onto the tape. How is that possible if 9:37:45 is not a complete frame? That’s a good question, but a reasonable hypothesis has to do with the storage mechanism used. Solid State Recorders, like all medium, are quite unpredictable if they fail during write operations. The actual area being used to record data can very easily be corrupted if power fails while writing. It’s plausible that the crash caused problems in and around this local area of data, causing corruption of the 9:37:45 data frame (again, changing a single bit in a synch word is enough to cause software to completely choke).

The moral of the story here is that the FDR data runs out anywhere from up to 2 seconds before the plane actually crashed into the Pentagon.

Pitfalls Using the CSV File to Reconstruct the Flight of Flight 77

Please keep in mind the CSV file is not raw FDR data, and it was not meant to be used forensically. As such, much information that is present in the raw FDR is lost. Using the CSV file for this purpose is not what it was intended for, however that does not make it impossible. Any analysis done using the file must successfully justify it’s correctness despite the following errors:

0) Absolute Time Error
The times calculated in the file were processed after the fact by the NTSB analysts. This information can be found in the NTSB FDR report, on page 3. We have no idea what the precision or accuracy of the original time stamps is. Any attempt to correlate FDR times to non-FDR (“real world”) times is flawed from the get-go, given this level of uncertainty. It’s probably safe to assume +/-2 seconds of error in the absolute time. This has no effect on relative time (e.g., if it says two frames are 19 seconds apart, chances are good they are exactly 19 seconds apart, to several decimal places).

False Claim: The FDR couldn’t have recorded 9:44:46, the official time of the crash is 9:44:45!

1) Instrument Error
First, and foremost, if the sensor or instrument is giving the recorder a bad number, it’s obviously not going to record the right one. This type of error must be dealt with on an instrument by instrument basis. Any reconstruction should justify the precision used for each value attained. Please keep in mind that all other errors in this document are due to the recording system, and the lost information in the processed version of its data. The uncertainty caused by the data scheduling into a frame, plus the digital buffering, is in addition to any instrument errors.

False Claim: I already debunked the lagging altimeter nonsense!
(The recording-system errors discussed in this document are in addition to, and independent of, any instrument errors.)

2) Intra-frame Time Error
Since we do not have the frame descriptor, all we know is that N samples are taken during a 1 second period. This means that 1/N of a second is the possible error range for a particular data point. With the frame descriptor, this error would be completely removed if using the raw FDR data.

False Claim: The aircraft’s speed at 09:37:14.00 was 305.5 knots!

3) Digital Buffering Latency
One of the most important purposes of the DAU is to buffer digital outputs from things like the ADC (Air Data Computer). It is a reasonably safe assumption that the Air Data Computer updates the DAU at least once per sampling, and more than likely twice. This means that for a 1-Hz sample, recorded into the data stream, the actual measured time could have been anywhere in the entire previous second. This means, combined, 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). More then likely, the raw data stream has embedded the actual measurement times, so this error might be completely removed using the raw FDR data.

False Claim: The worst case scenario for the 9:14:14 frame’s airspeed is 9:14:14.00, then!
(Yes, that is the worst case time it could be recorded… not measured).

4) Simultaneity Issues
You cannot assume any two samples occurred at the same time. Any analysis that combines two columns of numbers is risking using numbers that did not happen at the same moment in time, for a calculation that assumed they did.

False Claim: The altimeter data shows you’d need positive acceleration to hit the light poles, the accelerometer is showing negative acceleration! (Did you account for the +/- 2 seconds, potentially, between those two separate data points?)

The Bottom Line on Error

Two variables sampled at 1Hz will appear on the same line in the CSV file, however they have a total, combined, error range of nearly 3 (or even 4) seconds. How is that possible? Let me walk you through it.

In this example we consider two samples, A and B, both sampled at 1Hz, during the time frame between second 1.0 and 2.0:

Sample A:
Measured at 0.5s ADC->DAU (buffered)
Recorded at 1.0s DAU->REC (recorded)

Sample B
Measured at 1.98s ADC->DAU
Recorded at 1.99s DAU->REC (recorded)

Please note that sample A and Sample B will both appear on the same line in the CSV file, as they are both part of the frame with timestamp 1.0 second. In this example, Sample A and B are on the same line of the CSV file but were measured 1.5 seconds apart. The entire method could be reversed for A and B, giving a total error between the two of +/- 1.5 seconds, for a full error range of 3 seconds.


Summary

1) The FDR did not record the final moments of Flight 77. There is up to 2 seconds missing.
2) The CSV file is not meant to be analyzed forensically, it is meant to be plotted.
3) The CSV data is not raw FDR data. It is not even serial bitstream data.
4) The CSV data is not meant to be broken down into 1/8th seconds and analyzed.
5) The CSV data, properly interpreted, says that there are N samples during this particular frame.
6) Without the frame description, we do not know when in a frame any one sample occurred.
7) Without the frame description, we have lost the measurement timestamps, so the time a particular word was recorded does not necessarily equate with when it was measured.
8) Given these time-shift errors, any mathematics that uses more than one data-point runs the risk of assuming that two numbers occurred at the same time, when they didn’t.
9) Many of these errors can be corrected, greatly, with the frame descriptor.
10) Any analysis must account for (or justify ignoring) these issues in order to draw any valid conclusions.

[kevin]

still reading. minor issues:

Originally Posted by Anti-sophist

Well, the first (and most familiar) is to break up the signal into bytes (8 bytes)

I think you mean: bytes (8 bits)
although I'd probably go with: bytes of data each 8 bits long.

Quote:

, or other units of length (the FDR on flight 77 uses words of 12 bits in length, instead of bytes).

the traditional word is 16 bits but I think this usage is appropriate, although you might explain the difference between the traditional word in computers and how you're using it. Just to avoid accusations you don't know what you're talking about.

[kevin]

Originally Posted by Anti-sophist

Pitfalls Using the CSV File to Reconstruct the Flight of Flight 77

(...snip...)

0) Absolute Time Error

(...snip...)

False Claim: The FDR couldn’t have recorded 9:44:46, the official time of the crash is 9:44:45!

I don't understand these false claims in this section. For example with this one are CTer's claiming the FDR shows data from 9:44:46 which is impossible because of the official time, or are they claiming it didn't record this data because of the official time?

Perhaps breaking this into:
False Claim:
The Truth:

And explicitly detailing what they claim might help clarify those bits for me.

[kevin]

other than those quibbles, excellent work.

[Brainache]

I would love to help you A-S, but my brain hurts. It would be like me offering my crappy '89 model Honda to the F-1 race team as a back-up.

I can only watch in awe.

[mortimer]

Stunning work. WTG A-S!

[ktesibios]

So far, I see one apparent typo:

Quote:

There are some important issues to note about recorded:

I kinda agree with Kevin about explaining word length. I'm not flummoxed by a 12-bit word (quite a few "vintage" digital audio effects devices used 12-bit quantization and thus 12-bit words, due to the lack of good 16-bit A/D converters in the earlies), but people whose only exposure to digital anything is from personal computers might get confused.

I assume that there are going to be illustrations to go with text like

Quote:

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.

since the .csv file itself doesn't have a vertical axis, being just an ordered set of text.

Also, poring over the .csv file, it looks to me like each item is recorded just once in each one-second subframe. In a previous thread you referred to the FDR having a minor frame rate of 8 Hz and a major frame rate of 1 Hz, but here you call them out as 1 Hz and 1/4 Hz respectively, which seems to agree with the NTSB report's reference to a four-second frame containing four one-second subframes.

I've sat and counted fields in the .csv file until my brain hurt, but bless me if I can see an easily identifiable quantity, like vertical, longitudinal and lateral accelerations, which are recorded at the top of each subframe, being recorded more often than once per second. That has me kind of confused; even if I were a CTer I can't see how I would get to claiming 1/8 second precision.

Otherwise, I think you've done a darned good job of popularizing a technical subject. The explanations of where the timing uncertainties that CTer "analysts" ignore arise are nice and clear. It should be accessible to anyone who has enough of an electronics background to know what a sampled-data system is.

[qarnos]

Originally Posted by kevin

still reading. minor issues:



I think you mean: bytes (8 bits)
although I'd probably go with: bytes of data each 8 bits long.



the traditional word is 16 bits but I think this usage is appropriate, although you might explain the difference between the traditional word in computers and how you're using it. Just to avoid accusations you don't know what you're talking about.

Actually, the "traditional" meaning of "word" is the data size that a system was designed to handle natively. It is only more recently that "word" has come to commonly mean 16-bits, thanks largely to IBM, who made some popular 16-bit processors some time ago.

These days, for some reason, "word" also seems to mean "I agree".

In this case, "word" is correct terminology.

[weedwacker]

If the csv file is off, the animation produced by the NTSB must be off as well.

Why would the NTSB provide an animation of the flight in error?

http://www.youtube.com/watch?v=DzR-q0ijbV0

The above is just the final portion of the flight. The entire animation is available from taxi out of Dulles to take off to end of data. It matches perfectly with the CSV file time stamps, engine parameters, headings, airspeeds, ATC instructions for altitudes, headings, navigation, etc.

I guess the NTSB went through all the trouble to make an animation in error along with the csv?

Also, JDX has provided these questions for anyone willing to answer.

1. What is the True Altitude at end of data recording :44. How did you come to your conclusion.
2. What is the vertical speed at end of data recording :44. How did you come to your conclusion.
3. What is the Absolute Altitude and end of data recording? How did you come to your conclusion.
4. Why does the csv file show the altimeter being set in the baro cor column on the descent through FL180, but the animation altimeter does not show it being set?
5. Why do the current G Forces for the last minute of data correspond to the changes in vertical speed, yet at end of data :44-:45 it shows an increase in vertical speed never accounting for any type of level off to be level with the lawn as shown in the DoD video?
6. Do you have any video showing a clear impact and/or of the plane on its approach to impact?
7. Why does your animation show a flight path north of the reported flight path?
8. Why are there no system indication of any impact with any object up to and after :44?
9. Why does the csv file and animation show a right bank when the official report requires a left bank to be consistent with physical damage to the generator?
10. How did you come to the conclusion of 09:37:45 as the official impact time?
11. What is the exact chain of custody of the FDR? What date/time was it found? Where exactly was it found? Please provide documentation and names.
12. Why does the hijack timeline show a 3 min interval for hijacking to take place? Why did Capt Burlingame not follow protocol for the Common Strategy prior to 9/11?


Good day!

[qarnos]

I am the only one getting really sick of this guy talking about JDX in the third person?

[Gravy]

Excellent work, A-S. Very clear. Thank you.

[Gravy]

Originally Posted by weedwacker

If the csv file is off, the animation produced by the NTSB must be off as well.

Why would the NTSB provide an animation of the flight in error?

http://www.youtube.com/watch?v=DzR-q0ijbV0

The above is just the final portion of the flight. The entire animation is available from taxi out of Dulles to take off to end of data. It matches perfectly with the CSV file time stamps, engine parameters, headings, airspeeds, ATC instructions for altitudes, headings, navigation, etc.

I guess the NTSB went through all the trouble to make an animation in error along with the csv?

Also, JDX has provided these questions for anyone willing to answer.

1. What is the True Altitude at end of data recording :44. How did you come to your conclusion.
2. What is the vertical speed at end of data recording :44. How did you come to your conclusion.
3. What is the Absolute Altitude and end of data recording? How did you come to your conclusion.
4. Why does the csv file show the altimeter being set in the baro cor column on the descent through FL180, but the animation altimeter does not show it being set?
5. Why do the current G Forces for the last minute of data correspond to the changes in vertical speed, yet at end of data :44-:45 it shows an increase in vertical speed never accounting for any type of level off to be level with the lawn as shown in the DoD video?
6. Do you have any video showing a clear impact and/or of the plane on its approach to impact?
7. Why does your animation show a flight path north of the reported flight path?
8. Why are there no system indication of any impact with any object up to and after :44?
9. Why does the csv file and animation show a right bank when the official report requires a left bank to be consistent with physical damage to the generator?
10. How did you come to the conclusion of 09:37:45 as the official impact time?
11. What is the exact chain of custody of the FDR? What date/time was it found? Where exactly was it found? Please provide documentation and names.
12. Why does the hijack timeline show a 3 min interval for hijacking to take place? Why did Capt Burlingame not follow protocol for the Common Strategy prior to 9/11?


Good day!

Um, Weedwacker, you said that YOU were investigating many of these issues.

So what have you found?

[apathoid]

Originally Posted by Gravy

Um, Weedwacker, you said that YOU were investigating many of these issues.

So what have you found?

Whatever D'oh says is good enough for him. Why is that not suprising..

BTW - Great work A-S!

[T.A.M.]

Weedwacker;

While I appreciate the "mystique" being created by JDX sending a messenger with his "comments", I also find it a little cowardice. Why don't you stop being his gopher, and get him to come over here himself and start posting.

A-S:
Absolutely top notch post. Hard to argue with the guy who puts these things together...lol, but I am sure they will try.

TAM

[apathoid]

Originally Posted by weedwacker

Also, JDX, I have provided these questions for anyone willing to answer.

1. What is the True Altitude at end of data recording :44. How did you come to your conclusion.
2. What is the vertical speed at end of data recording :44. How did you come to your conclusion.
3. What is the Absolute Altitude and end of data recording? How did you come to your conclusion.
4. Why does the csv file show the altimeter being set in the baro cor column on the descent through FL180, but the animation altimeter does not show it being set?
5. Why do the current G Forces for the last minute of data correspond to the changes in vertical speed, yet at end of data :44-:45 it shows an increase in vertical speed never accounting for any type of level off to be level with the lawn as shown in the DoD video?
6. Do you have any video showing a clear impact and/or of the plane on its approach to impact?
7. Why does your animation show a flight path north of the reported flight path?
8. Why are there no system indication of any impact with any object up to and after :44?
9. Why does the csv file and animation show a right bank when the official report requires a left bank to be consistent with physical damage to the generator?
10. How did you come to the conclusion of 09:37:45 as the official impact time?
11. What is the exact chain of custody of the FDR? What date/time was it found? Where exactly was it found? Please provide documentation and names.
12. Why does the hijack timeline show a 3 min interval for hijacking to take place? Why did Capt Burlingame not follow protocol for the Common Strategy prior to 9/11?


Good day!

Morning "weedwacker". Your boy Jonny D'oh D'oh-brain finally got de-admined at LC for being a wanker. I have it from a good source that it was the will of Mr. Avery himself......

1. Less than 10' AGL/ 47' MSL, 'cause the friggin plane impacted the building.
2. If you had the capacity to understand any of what A-S has written you'd understand why its irrelevant.
3. If you had the capacity to understand any of what A-S has written you'd understand why its irrelevant.
4. Relevant how?
5. If you had the capacity to understand any of what A-S has written you'd understand why its irrelevant. You can tell AA77 levelled off from a single frame of security camera footage?
6. Do you have a video of a cruise missile/MOAB/flyover? Absence of video means absence of possibility? Interesting. Anyhow, you just might get your wish when the Doubletree video is released.
7. Reported by whom? Witnesses who saw AA77 hit the Pentagon? Hello?!
8. Eh?
9. If you had the capacity to understand any of what A-S has written you'd understand why its irrelevant.
10. The raw file(not the CSV), maybe? If could've even been....gasp....0937:46.542787499911 seconds. No way to know for sure. Oh and: If you had the capacity to understand any of what A-S has written you'd understand why there is no way to know the exact time.
11. It was found at the Pentagon, probably on 9/11.
12. Eh? What common strategy was that? To bludgeon the hijacker with a crashaxe whilst throwing fire extinguishers to pax?

Please re-read what A-S has written and thank him if it decides to sink in..

[Shrinker]

Cheney: Mr President, we've got a problem, some boob on the internet has filed an FOIA request for the flight 77 FDR! What will we do?!

Bush: We can't send them the FDR data?

Cheney: No, the plane's still in service!

Bush: Okay, let's fake one. Double-click notepad.exe and start typing some numbers.

Cheney: No, it's too hard. I can't work out how high the plane should be just before impact! Is it 480 feet, or 10 feet, or maybe minus 200 feet?

Bush: Hmm, I don't know. Okay, forget that. What about that plane we had fly 100ft over the Pentagon, and drop a MOAB on the lawn? Do we have an FDR from that?

Cheney: Yes we do! We can just delete the last entries and make it look like it crashed! Genius!

Bush: Wait a minute, how have we got FDR data from a plane that never crashed?

Cheney: We pulled it out of the wreckage after the MOAB shockwave took off the plane's tail and it crashed into downtown Washington.

Bush: What? I never heard about that.

Cheney: We are very good at this Mr. President.

[eeyore1954]

Weedwacker

What happened to Anti sophist when he tried to discuss the FDR with JohnDoe on the Loose change board. He was banned for no reason other than stating at the onset ( i would call that honesty) that he was from the JREF board. Why didn't Mr Doe step up and ask he be allowed to discuss with him if he is so sure he is correct and more importantly is interested in the truth.

[T.A.M.]

Has JDX ever shown anything but cowardice when it come to debating with JREFers. Look, he has his pool boy deliver his messages.

TAM

[Brainache]

Originally Posted by T.A.M.

Has JDX ever shown anything but cowardice when it come to debating with JREFers. Look, he has his pool boy deliver his messages.

TAM

I would assume that WeedWacker was the gardener. The pool boy would be HoseWacker.

[thinkingcat]

Wow, A-S. You took a very complicated process and explained it sensibly and logically. Thank you for the effort.

Even the CT'ers should be able to follow this and understand why their so-called 'analysis' has gone awry.

[T.A.M.]

Originally Posted by Brainache

I would assume that WeedWacker was the gardener. The pool boy would be HoseWacker.

LOL, I am a little slow on the insults this morning...thanks for the correction.

thinkingcat:

Welcome to the JREF Forum on Conspiracy theories. All opinions are allowed, if not accepted. Debating in here can be intense at times, but all is fair in...you know the rest.

TAM

[bob_kark]

Hey Weedwacker,

President Bush told me to tell you to tell JDX to stop digging for answers or else! That's right, he'll totally stop being his friend on Myspace.com!

[kevin]

Originally Posted by qarnos

Actually, the "traditional" meaning of "word" is the data size that a system was designed to handle natively.

Yeah, i just reread my message and noticed that too. I think really meant "common usage". or maybe current usage.

Also I agree this is correct usage, however a common CT tactic is to use one definition of a term in the dictionary as the only possible definition and if you don't conform to that you're wrong. To nip the argument "this guy doesn't even know what a word is, therefore his whole paper is wrong" I think an explanation that you know the common usage but are using this definition because would shut that down.

[kevin]

Originally Posted by qarnos

I am the only one getting really sick of this guy talking about JDX in the third person?

yes, we are not amused.

[Dog Town]

Quote:

I am the only one getting really sick of this guy talking about JDX in the third person?

I am! I have sent a PM to WW asking him to provide the link from Flightinfo's board. The one that started his brush w/JDX. He keeps avoiding this. Hmmmm!
I smell feet!

[apathoid]

Originally Posted by D'ohs Errand Boy

11. What is the exact chain of custody of the FDR? What date/time was it found? Where exactly was it found? Please provide documentation and names.

Found the following at pentagonresearch.com.

Originally Posted by Pentagonresearch

"Somewhere in that massive pile of rubble lay two mangled metal containers that might reveal what happened aboard American Airlines Flight 77 in the minutes before terrorists crashed it into America's military headquarters. As a cockpit voice recorder analyst for the National Transportation Safety Board (NTSB), it was Cushman's job to help locate the airplane's black boxes, as the voice and data recorders that all airliners carry are known informally. It was the first crash site she'd visited.

"Over the next few days, working the 3 p.m. to morning shift, she and several other NTSB experts struggled to separate airplane parts from office parts. Early on the morning of Sept.14, while Cushman was at the site, the cockpit voice recorder, or CVR, was found. It was quickly transported across the Potomac to the NTSB lab in Washington, D.C., where Cushman works with three other analysts, and its data was downloaded.

"Ordinarily, that would have been just the start of Cushman's association with the device, but this time, it was the end. The events of Sept. 11 had already been classified as criminal acts, rather than accidents, so the FBI, which has its own forensic audio lab, took charge of the box and its data.

That's also why Cushman can't say much more about her role in that investigation, or about the work she did on the recorders recovered from Flight 93, which plowed into a field in Pennsylvania after passengers apparently thwarted another hijacking. Like the Pentagon CVR, the black box from that plane came to NTSB only for the extraction of its data before being turned over to the FBI". http://www.wpi.edu/News/Transformati...ring/hear.html

"FBI Director Robert Mueller said Friday that the agency has gotten information from the flight data recorder recovered in the crash of American Airlines Flight 77, which slammed into the Pentagon. He declined to say what information the FBI received from the recorder, which tracks an airplane's flight movements for the last 25 hours. He said the agency had not gotten any information from the voice data recorder from Flight 77". http://www.sptimes.com/News/091501/W..._voice__.shtml

"Early Friday morning, shortly before 4 a.m., Burkhammer and another firefighter, Brian Moravitz were combing through debris near the impact site. Peering at the wreckage with their helmet lights, the two spotted an intact seat from the plane's cockpit with a chunk of the floor still attached. Then they saw two odd-shaped dark boxes, about 1.5 by 2 feet long. They'd been told the plane's "black boxes" would in fact be bright orange, but these were charred black. The boxes had handles on one end and one was torn open. They cordoned off the area and called for an FBI agent, who in turn called for someone from the National Transportation Safety Board (NTSB) who confirmed the find: the black boxes from AA Flight 77." http://msnbc.msn.com/id/3069699/

"Pentagon officials said the recorders, also called "black boxes" were found around 3:40 a.m. under mounds of wreckage in the collapsed part of the building, where only a few pieces of the plane remain."
(The Washington Times September 15, 2001, Saturday, Final Edition Section: Part C; Metropolitan Pg. C1)

[R.Mackey]

For weedwacker, you may kindly inform your bosom buddy JDX that his questions are out of order. We've shown his computation to be in error. Thus far, it is plausible for the FDR to be consistent with the witness statements, debris, and official theory. His questions can be answered thusly, unless he can show otherwise. In short, he needs to fix his theory.

For Anti-sophist, nice job. Right on the mark. One thing you might want to look into as well, I don't know this for sure, but I have read that crash FDR's deliberately withhold the last couple seconds of data in an effort to avoid corrupting the record with an incomplete write cycle. Not sure how that works, I haven't worked with crash FDR's either, but maybe you can find something.

[Anti-sophist]

First, thanks for all the typo gets, and pedalogical weaknesses. I'll fix them.

Originally Posted by ktesibios

Also, poring over the .csv file, it looks to me like each item is recorded just once in each one-second subframe. In a previous thread you referred to the FDR having a minor frame rate of 8 Hz and a major frame rate of 1 Hz, but here you call them out as 1 Hz and 1/4 Hz respectively, which seems to agree with the NTSB report's reference to a four-second frame containing four one-second subframes.

Well, my original guess was 1 second major frames, and 1/8 second minor frames. That was due to the fact that 1 second was the lowest period of sampling, and 1/8 was the highest. After looking at the file more carefully, some values are, in fact, sampled as low as 1/4 HZ (or once every 4 seconds), so 4 second major frame seems plausible.

Minor frames, strictly speaking, are just the distance of synch words in your data. Effectively, it is the "quantum" or error-checkable data. If a single bit goes, the most data you will lose is a minor frame. I guessed they would do it at 8hz due to 8hz sampling, but I was wrong. They only do it at 1hz.

Quote:

I've sat and counted fields in the .csv file until my brain hurt, but bless me if I can see an easily identifiable quantity, like vertical, longitudinal and lateral accelerations, which are recorded at the top of each subframe, being recorded more often than once per second. That has me kind of confused; even if I were a CTer I can't see how I would get to claiming 1/8 second precision.

V.Acc is sampled 8 times per second according to the CSV file I have. It's in the first column. Maybe we have different ones?


Weedwacker--

Quote:

I guess the NTSB went through all the trouble to make an animation in error along with the csv?

Short answer:
To show laypeople what the flight looked like within 99.9% accuracy? Why do you demand 99.9999% accuracy?

Long answer:
What's the data source? You seem to think it was the CSV file. If that' sso, it is already flawed in terms of to-the-millisecond-and-foot accuracy. Maybe it was done that way for expediency? Maybe 99.9% is good enough? What's the precision of this animation? What are the error thresholds? What was the metholdolgy?

The animation is a reconstruction done by an engineer. He made an animation that was reasonably accurate to show the big picture, not be precise down to the millisecond or the foot. If he wanted to make a foot-and-millisecond precise animation, he'd need to correct for ALL the errors I've explained, and that would be virtually impossible for someone to do without a massive scientific effort justifying all sorts of assumptions, and even then, it would be assailable on a number of scientific fronts.

As far as I'm concerned, the animation is of little value beyond the actual data given, because it's non-repeatable. I don't know any of the parameters it was constructed with. It has built-in assumptions that aren't stated. I've already pointed out a number of errors in the underlying data for to-the-millisecond-and-foot precision, so I see no reason to expect that the animation, based on that data, would be any more precise.

Quote:

1. What is the True Altitude at end of data recording :44. How did you come to your conclusion.

What does "end of data recording :44" mean? What time, specifically? The end of the 44th second? What was the pressure altitude at :45.00? Is that the question? Let me ask a different question? Why is that important? Are you assuming that's the time of the crash? That would be a mistake.

I'll answer, anyway...

The presssure altitiude recorded during the :44 frame is 173. In the worst case, this was measured at around :43.50 or :43.00 (depending on the sampling rate from the ADC to DAU). In the best case, this was measured at :44.99.

That gives us a measured pressure altitude somehwere between 173 and 173 - 2seconds * descent rate (in foot per second). JDX likes to quote '66 feet per second' as the descent rate. He gets this by subtracted the pressure altitude from the :43 and :44 frames. Using the same logic, in the worst case, these were actually measured at :42.00 and :43.00. We cannot use this as the average descent rate between :44.00 and :45.00 for obvious reasons, unless we assume no acceleration (a false assumption). The moment you try to introduce V.Acc to compensate, you need to now account for simultaenity errors to over come this.

This answer is intractably difficult to answer to with any certainty given the time-error introduced by basing our calculations on the CSV file. The only definitive answer to this questions is that, given only the CSV data, it's intractibly difficult to answer this question definitively.

Once you've made all your assumptions about simultaenity and acceleration, and come up with a calculation, you can then begin to think about correcting your answer for instrument error in the altimeter, due to lagging because pressure differentials and all that.

Quote:

2. What is the vertical speed at end of data recording :44. How did you come to your conclusion.
3. What is the Absolute Altitude and end of data recording? How did you come to your conclusion.

See #1. I need the answer to #2 to be able to figure out #1, anyway. I have too many variables, and not enough data, to answer these questions definitely.

Quote:

4. Why does the csv file show the altimeter being set in the baro cor column on the descent through FL180, but the animation altimeter does not show it being set?

"Appeal to animation" fallacy.

Quote:

5. Why do the current G Forces for the last minute of data correspond to the changes in vertical speed...

First of all, they don't. I've already provided the graph to show that the two pieces of data ARE NOT simultaenous as shown in the file.
http://img134.imageshack.us/my.php?i...dxdelayfn9.png

Therefore, the premise of your question is already false, but I shall proceed anyway...

Quote:

yet at end of data :44-:45 it shows an increase in vertical speed never accounting for any type of level off to be level with the lawn as shown in the DoD video?

Your assumption that the time frame :44-:45 represents the final second of flight 77 is false. :44-:45 represents the last completed frame in the data. The G forces on the plane during the trip across the lawn are most certainly not the ones shown in the CSV final's data frame.

Quote:

6. Do you have any video showing a clear impact and/or of the plane on its approach to impact?

Nope.

Quote:

7. Why does your animation show a flight path north of the reported flight path?

My animation? I assume you mean NTSB's animation. I can't answer that question, you should ask them.

Quote:

8. Why are there no system indication of any impact with any object up to and after :44?

Since the :44 frame is the last completed frame, the CSV data "runs out" before the plane actually hits the pentagon. We don't know how many more frames (and partial frames) were recorded, but at least 1 partial frame was. Therefore, the data you are looking for didn't happen in the time range of the data given.

Quote:

9. Why does the csv file and animation show a right bank when the official report requires a left bank to be consistent with physical damage to the generator?

You are assuming an impact time and simulatenity issues that you have no justification to be assuming. The data you are looking for isn't in the CSV file, to the best of estimatation. The CSV file ends before this data would have been there.

Quote:

10. How did you come to the conclusion of 09:37:45 as the official impact time?

09:37:45 to what precision... 09:37:45 in reference to whom? The onflight data recorder? Was it GPS synched? When was the last GPS synch? If so, which IRIG GPS time was it synching to? IRIG-B? H? G? (look em up) If it wasn't GPS synced, then in reference to who? The FDR? Greenich Mean Time? The Naval Observatory?

In fact, I'd say it's highly unlike that 09:37:45.00 is even close to the impact time, according to the FDRs clock. More than likely the actual impact time was at some point in the next two seconds.

The NTSB set the time of impact to 09:37:45.00 because within a second or two, it's correct. I doubt very seriously they spent time trying to properly synch the FDR ex post facto with the Naval Observatory, in order to give an exact time so that amatuer forsensic analysis of the FDR could be successful.

Quote:

11. What is the exact chain of custody of the FDR? What date/time was it found? Where exactly was it found? Please provide documentation and names.

Answered above.

Quote:

12. Why does the hijack timeline show a 3 min interval for hijacking to take place? Why did Capt Burlingame not follow protocol for the Common Strategy prior to 9/11?

Outside of my expertise and knowledge. I can't answer that.

[DavidJames]

Originally Posted by Anti-sophist

...removed all the intelligent analysis that zoomed right over JDX's head...

Very nice work AS. I can see JDX congratulating himself and wiping his brow of sweat for having you banned at LC in the nick of time, cause he's clearly shot his wad as it relates to this analysis and is once again reduced to JAQs.

JDX is rapidly self destructing. I expect the next squib we see in the NYC area will be his head exploding. (Note to JDX, that wasn't a threat, it was a figure of speech).

[Qubit]

As someone who is near completion of their M.S. in Electrical Engineering, I don't think anyone could have made a better explanation. Very well done.

I usually don't like to make assumptions, but I think people here who relate weedwacker to JDX are spot on. I have read alot of posts by JDX and the posting style between the two is eerily similar. JDX likes to post and repost his "findings" in every forum at LC wherever he gets the chance. If you look at the post made by "weedwacker" shown (partially) below (posted above).

Quote:

If the csv file is off, the animation produced by the NTSB must be off as well.

Why would the NTSB provide an animation of the flight in error?

...
...

You can see this was actually posted in numerous places on LC.

s15.invisionfree.com/Loose_Change_Forum/index.php?showtopic=12995
s15.invisionfree.com/Loose_Change_Forum/index.php?showtopic=16778

I am sure you will see this same post 100 more times as time passes.

Anyway, I just wanted to express my appreciation for your time and effort.

[T.A.M.]

Qubit:

I am the UNOFFICIAL welcoming party (no wisecracks Dog Town), so welcome to the JREF Forum on Conspiracy Theories. All opinions here are allowed, but no necessarily accepted. If your gonna bring your views, better be prepared to back it up with evidence, as the guys here will call you (and anyone for that matter) on it.

TAM

[Qubit]

Originally Posted by T.A.M.

Qubit:

I am the UNOFFICIAL welcoming party (no wisecracks Dog Town), so welcome to the JREF Forum on Conspiracy Theories. All opinions here are allowed, but no necessarily accepted. If your gonna bring your views, better be prepared to back it up with evidence, as the guys here will call you (and anyone for that matter) on it.

TAM

Hi TAM! Thanks alot! I lurk here alot and love all the work you and others do (Gravy, AS, Chipmunk Stew, etc). I hope I can add knowledge to the site and learn from each of you in turn. Thanks again!

[Dog Town]

Quote:

no wisecracks Dog Town

Pardon?
Welcome Q, and I hear ya...boy do I hear ya. I smell feet, when WW is around!
Smelly, wet nasty feet!

[T.A.M.]

only love man...only love...lol

TAM

Edit: sorry, but that was my best at urbanspeak...lol

[Dog Town]

Originally Posted by T.A.M.

only love man...only love...lol

TAM

Edit: sorry, but that was my best at urbanspeak...lol

Allow me to translate: Nut'n but luv bruddah...nut'n but luv!

[apathoid]

Originally Posted by Dog Town

Allow me to translate: Nut'n but luv bruddah...nut'n but luv!

And a good alternate spelling for bruddah is bruvva. And it doesnt hurt to add a "yo" at the end of a sentence every now and again.

[Dog Town]

Originally Posted by apathoid

And a good alternate spelling for bruddah is bruvva. And it doesnt hurt to add a "yo" at the end of a sentence every now and again.

Yes bruudah is more Hawiian slang, pidgeon! But there was no hi, in the sentence, hence no yo!

[Gravy]

Originally Posted by weedwacker

Why did Capt Burlingame not follow protocol for the Common Strategy prior to 9/11?

You mean like this?

Originally Posted by JohnDoeX on LC Forum

If hes trying to take over my ship. .and all he has is a boxcutter? Im gonna grab my crash axe and chop him up... while tossing fire extingushers to passengers. .you? Or do you cower and say.. "Please dont cut me Mr. Big Bad Terrorist"

[bignickel]

Quote:

Weedwacker posted in other threads
To be honest, I'd have to check all the math, but these wacky conspiracy theories are getting pretty wild. Some say that no planes hit the buildings in NY? I know crews that watched it!
...
Everyone knows American 77 hit the Pentagon. Thousands of people saw it. But, I guess this is America and they can do what they want I guess. I still need to look over that site thoroughly.
...
Hope his numbers are accurate, cause I'm ready to go over it with a fine toothed comb.
...
I'll see what I can do.
...
Still looking over the work.
...
Still researching.
...
In the meantime, I'll keep looking over his work.
...
I'm still checking on it.
...
I really have to look into this further. Thanks for all the help everyone.
I'll continue to post so observations.
...
I'm still highly skeptical of JDX's claims of 480MSL. It appears he went to Boeing and a few other companies to get some answers, but was refused. I'm also trying to work some of my channels.
...
Still researching.

Weedwacker, after all the time you've spent looking over JDX' site and math, we'd all REALLY like to see that critique you promised. It'd be a shame for you not to post it, after all the work you've done looking over his site and 'researching'. If you'd like, why don't you PM it to me? I haven't seen your PM yet in my mailbox; I'd really like to see the fruits of your labors.

[DavidJames]

I'm not weedwacker, but I'll channell JDX for now: Found this on the "Fdr Vertical Speed, Altimeter lag issues addressed as well" thread in the Pentagon forum at LC

Quote:

Anit-Sophist is holding onto fractions of a second within 1 frame.

The True Altitude of the aircraft at the ":44 Frame" was 480MSL. At 66ft/sec it would take 7.2 seconds longer to hit the pentagon. At this rate if it were low enough to hit the poles, it would have plowed into the ground prior to hitting the pentagon. If it increased its rate (which the accelerometer shows), it would have plowed into the ground sooner.

So, in order for Anti-Sophist to have his way.. he needs to get the NTSB to admit the aircraft struck the pentagon at 09:37:51. Or during the :51 "frame".

He makes a nice attempt to show confusion and chaos as most JREFers do, but the fact remains that using his logic, the FDR still conflicts with the official story. It doesnt matter what "fraction of the :44 second" the altitude was recorded as it will still need 7 seconds from there for impact.

Unfortunately.. the NTSB reports the impact time at 09:37:45

http://www.ntsb.gov/info/Flight_%20P...Study_AA77.pdf
Bottom of page 2.

The NTSB used ATC transmissions, Radar data and the FDR to reconstruct the animation. Its in real time. The csv file matches the animation exactly (except for the cover-up of the altimeter being set on descent in the animation as it would have shown too high.. couldnt have that..lol). However, im not surprised you JREFers are unable to grasp that fact. Perhaps you think the ATC instructions, Radar and FDR are all in error by the same amount?


As for ground elevation errors. I have shown the factor for errors with the original use of Google Earth cross checked with the Jeppessen Airway Manuals. It is +/- 5 feet in error in the DCA area. The USGS is more accurate. It has been noted, im not surprised you missed it.