AA77 FDR Data, Explained

[beachnut]

docker stop messing up the tread

[WildCat]

Originally Posted by jessicarabbit

It proves popular mechanics lie, hence they are discredited.

Keep up the sarcasm gravy.

I like that line of thinking! So it's safe to say that the entire TRUTH movement is discredited.

[jessicarabbit]

Why are you building strawmen gravy? Please show me a post where I have mentioned the illuminati or lizard people.

[jessicarabbit]

Originally Posted by WildCat

I like that line of thinking! So it's safe to say that the entire TRUTH movement is discredited.

No the entire truth movement don't represent each other. James Meigs is the editor of popular mechanics and was caught lying. Hence PM is now discredited.

[WildCat]

Originally Posted by jessicarabbit

No the entire truth movement don't represent each other. James Meigs is the editor of popular mechanics and was caught lying. Hence PM is now discredited.

What did he lie about?

[beachnut]

Originally Posted by jessicarabbit

Why are you building strawmen gravy? Please show me a post where I have mentioned the illuminati or lizard people.

- jessicarabbit/docker either bring something to the thread or go away

we need some help on some issues, this would be the first time you have really read a thread, you could, and you could help

your read all 10,000 pages of the NIST report, this thread should be a piece of cake

[jessicarabbit]

Originally Posted by WildCat

What did he lie about?

When asked about Chertoff being connected to the head of homeland security, Meigs claimed that Chertoff could not influence the project since he was a junior researcher. So Jeff rang and discovered that in fact Chertoff was the senior researcher.

[beachnut]

jessica try to help on the FDR or go start your own thread

[jessicarabbit]

Originally Posted by WildCat

What did he lie about?

Just told you.

[bob_kark]

Originally Posted by jessicarabbit

The point of the call was that James Meigs had pretended Chertoff was a junior researcher on the 911 project. During the call he admitted he was in fact a senior researcher.

The call did its job beautifully.

What does it matter, he's not related to Michael Chertoff. Get over it. Any other useless accusations?

[beachnut]

Please jessica try to help on the FDR or go start your own thread

[beachnut]

Originally Posted by jessicarabbit

Just told you.

are you docker

what do you have on the FDR, anything

[CurtC]

Originally Posted by jessicarabbit

When asked about Chertoff being connected to the head of homeland security, Meigs claimed that Chertoff could not influence the project since he was a junior researcher. So Jeff rang and discovered that in fact Chertoff was the senior researcher.

Bulldung. The moniker of "senior researcher" was pinned on Chertoff by Christopher Bollyn, who called him, asked if he worked on the story, then asked him whether he was the "senior researcher." That title doesn't exist at Popular Mechanics, but Chertoff had been there longer than some of the others, and said something like "sure."

Meigs wouldn't have excused Chertoff's role as insignificant, especially not by implying that he is really related to the head of Homeland Security. I think you're simply lying here, but you're invited to prove me wrong.

ETA: the prank phone call was made well after Bollyn's article which called Chertoff "senior researcher."

[Anti-sophist]

Originally Posted by UnderTow

I don't know where this claim comes from and I have never stated such. But this paper is directed at 'them' and not 'me' so who knows. This Time value is there, therfore it was recorded. It's relation to real-world time before it was sync'd during the investigation is up for grabs.

Correlating time between the FDR stamps and the "real world" is not easy. There is a specific error margin that this was done with, and that number is not in the public domain as best as I can tell. From my perspective, the number +/- 2 seconds I would say is an extremely safe guess, but the actual margin error is probably smaller.

Quote:

Time sync within the plane is most definately very strict (microseconds?).

Potentially nanoseconds. Hard to say w/o the datasheets of the components, though. It's fairly safe to say though that any time-error "within" the plane is insignificant compared with the rest. If the plane says two samples happened 1 seconds apart, that's good to alot of decimal places.

Quote:

I don't know what claim is being referenced here either. But I find fault in suggesting that a parameter 'recorded' during one second (after Time.00) would be a value from Time-1.5 seconds.

First, I've never said that, exactly. I state that if the frame starts at t=0, then the parameter is recorded some time between t=0 and t=1, and it was measured some time between t=-1 and t=1. (I also use the more conservative estimate of t=-0.5 to t=1, which would correspond to a "measurement" rate of twice the "recorded" rate.)

I don't see why you would disagree with this, unless you still deny the existance of the digital buffer (the so called parameter pool), and/or the reality that measured time does not equal recorded time. There is a 1 second window error (for 1Hz signals) in the recorded time. Furthermore, there is some delay between measurement and recording. For some samples (like reading an analog accelerometer), the second delay may be insignificant. For others, like computer airspeed, it is likely very significant.

Quote:

The +-2seconds is also false for parameters that appear within the same frame/row of the CSV.

It's not false when you take into account the digitial buffering error combined with the intraframe error of 1 second.

Quote:

I still find this ridiculous within the scope of the parameters most concerned. Time,Accleration(s),Speed,Alititude, etc. If we are talking about unimportant parameters like a Seat Belt Light, well who cares. Every instance I have seen of Word location for the most crucial required parameters places them within the first 50 words. In our subject's 256wps frame this means these crucial mandatory parameters are recorded to FDR within .2 seconds of our .00 Time Stamp. For instance, TWA800's AirSpeed was located in Word 38. If this placement is similiar in AA77's Frame, AirSpeed would be recorded at +00.15 seconds.
But again, we don't know 'exactly' so there can be no real conclusion to any argument over this I suppose.

You seem to be misunderstanding what "error range" is. Since you already agree that we don't know when a parameter is recorded inside of the 1 second frame, that means the error range between two parameters is 2 seconds. Altitude could be +0.0 and speed could be +1.0, or Alt. could be +1.0, and speed could be +0.0. Both are recorded in the same frame, and occur on the same line in the CSV file. The total difference is 2 seconds. That is _just_ using the recording time error. When combined with the digital buffering, that can be 3 seconds, or even 4 seconds in some cases.

Quote:

1) The FDR will record data (or 'something') up until it is detached from all power. The CSV does not show the final 2 seconds other then a Time value. Whether partial data or no data occurs in the FDR we can't say. To say that the FDR stopped recording 2 seconds Before impact, error.

This is mostly correct, and I thank you for pointing it out. Both you and I are using insufficiently precise language to describe what is happening. Frame :45 and :46 were partial frames, so for some parameters, the last recording happened in the :44 frame. That means that up to 2 full seconds for some parameters _is_ missing from the FDR. That was what I meant.

You are correct, however, when you state that the FDR itself was recording until the time of the crash. The data, however, wasn't necessarily valid up to that point, and for some parameters, up to 2 seconds of valid data is missing.

This is complicated by the fact that you need to add in the measurement-to-recording delay, to find the "age" of the final sample of any parameter.

Quote:

2) Agreed on the first part in regards to the extreme hundreths of a second we keep talking about. The 2nd part I don't agree with but if he wants to say that s'okay I guess.

There is no other reason to make this CSV file, other than to make it easy to plot in a program like gnuplot or excel. The actual FDR data with the frame descriptor is far more useful for any forsenic purpose. The FDR report mentions, specifically, that the CSV file is the source of the plots.

Quote:

4) Except for those parameters which are recorded N per second.

Well, again, we are both being too imprecise in our wording, but you are on the right track.

Quote:

8) I only assume they're recorded during the same second. But to think that the Altitude and Speed Measument could differ by 2 seconds in plane time, I don't think so.

Again, this is +1 second for frame haziness and +1 second for digital buffering. That provides a maximum upperbound of +2 seconds (and vice versa, giving a full error of +/-2 seconds, or a 4 second error range). Keep in mind this has to do with _two_ parameters in relation to each other. One might be 2 seconds ahead, or 2 seconds behind. Both would appear in the same line of the CSV file.



Overall, you seem to be 90% of the way there. The last 10% seems to be the fact that you refuse to believe that recorded time does not equal measured time. You seem to think that the delay between being measured and being recorded is safe to ignore. It's not. Once you accept the existance of this delay, and you go back and reread the footnote I keep bringing up, you will see how easy it is to explain how one parameter can "appear" to be older, but actually be much newer. That's because it was measured much closer to when it was recorded.

Finally, given your understanding as it is now, you can already debunk both of JDX's "lightpole" analyses on your own. He seems to think you are going to support his position. If you don't, then what do you support?

[uk_dave]

I always liked this thread (not that I understand a word of it) because AS did such a fantastic job of presenting his evidence.

But what annoys me immensely is that Undertow (listed as a 'researcher' on the pilots for truth site) didn't have the common decency to concede or apologise to AS for all his bluster and arrogance at the start when he was subsequently found to be talking crap.

[beachnut]

I was trying to ask some accident guys what the possible data missing was in seconds in a massive impact like flight 77. The data not recorded on the chip. The guy I am trying to ask would have some connections to Boeing. He never reads my email. He post tons to me, but I think his receipts are wholesale deleted with my requests.

Any updates from AS?

[Anti-sophist]

I think it's impossible for anyone to say with certainty how much data is missing except the people who actually looked at the recorder. I think the estimate in the 1-2 seconds range is probably accurate, though.

[beachnut]

Originally Posted by Anti-sophist

I think it's impossible for anyone to say with certainty how much data is missing except the people who actually looked at the recorder. I think the estimate in the 1-2 seconds range is probably accurate, though.

I was looking for more to match the descent rate into the Pentagon. But if you mean 2 seconds past the time stamps; that gets real close to make me happy.

Dam CT guys drive me nuts.

[Anti-sophist]

Originally Posted by beachnut

I was looking for more to match the descent rate into the Pentagon. But if you mean 2 seconds past the time stamps; that gets real close to make me happy.

Dam CT guys drive me nuts.

I'm not sure what that mean, exactly. Are you talking about the absolute altimeter reading, or the descent rate in regards to the lightpoles?

In the first case, the speed + pressure is outside of the calibrated operating point of the altimeter. Those readings can't be trusted because they aren't calibrated for those conditions. In the second case, yes, the FDR is incapable of telling us with any precision where the plane was or how high it was relative to the impact point when it crossed over the lightpoles.

[beachnut]

Originally Posted by Anti-sophist

I'm not sure what that mean, exactly. Are you talking about the absolute altimeter reading, or the descent rate in regards to the lightpoles?

In the first case, the speed + pressure is outside of the calibrated operating point of the altimeter. Those readings can't be trusted because they aren't calibrated for those conditions. In the second case, yes, the FDR is incapable of telling us with any precision where the plane was or how high it was relative to the impact point when it crossed over the lightpoles.

I was talking about how many data points are missing from the last altitude taken to the impact point.

If you assume the altitude is correct on the FDR. You can back off from the impact to that altitude. That could be 7 seconds back away from the Pentagon. Or about 4 seconds if you take the standard rate of descent the terrorist was getting during his final run.

I am still thinking about compressibitiy and the error on the altitude and airspeed. This guy is past the 350 KCAS limit on the airframe (or what ever the 757 limit is this is close).

Give me 4 plus missing seconds of altitude data to shut up the CT idiots; I will go look up compressabilty errors and see what the book answer is.

I know 77 hit the Pentagon; I am just pissed the CT guys keep adding 10 seconds to the clock!

[Anti-sophist]

I don't think there is that many data points missing. My best guess is 1-2, so 2 at the most. The problem, of course, is the altimeter is not correct because it's not calibrated for those speeds and pressures.

If you have a way of quantifying the altimeter error given the airspeed, I'd love to see it. From my initial research on the issue, I thought that question was a non-starter.

[beachnut]

Originally Posted by Anti-sophist

I don't think there is that many data points missing. My best guess is 1-2, so 2 at the most. The problem, of course, is the altimeter is not correct because it's not calibrated for those speeds and pressures.

If you have a way of quantifying the altimeter error given the airspeed, I'd love to see it. From my initial research on the issue, I thought that question was a non-starter.

I think I can find the general trend of errors based on speed in my books. I still have computer runs from 1970. I have punch card to program in fortran from 70-74. I must have my UPT books some where.

I have KC-135 dash-1 some where in the house.

I will search for the stuff.

[GlennB]

Originally Posted by Anti-sophist

...

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.

...

You might be interested to know that "Snowygrouch" of the UK forum claims to have the raw data file *with data frame layouts* and is a few days work away from decoding it (allegedly)

http://www.nineeleven.co.uk/board/viewtopic.php?t=6242

(hope this isn't old news - I haven't read this entire thread)

[Anti-sophist]

That is news. I'm impressed that someone is actually making forward progress on the issue.

The data frame layout is only half the battle. They also need the conversion information to get engineering units. I imagine an "insider", as they claim, would have both of these pieces of information in a reasonably succinct form.

I'll await their results.

[Anti-sophist]

Originally Posted by Anti-sophist

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

Erm. I forgot to mention my degree is from the University of Florida. I just got the overwhelming sense that this information is appropriate.

I'm not sure why....

[apathoid]

Originally Posted by Anti-sophist

Erm. I forgot to mention my degree is from the University of Florida. I just got the overwhelming sense that this information is appropriate.

I'm not sure why....

Jeb Bush is the governor of Florida. Florida miraculously "pulled" ahead of Michigan for the #2 BCS spot. Florida has won the basketball and football national chamionships for 2006. I smell a conspiracy....

eta: Oh and the Buckeyes didnt even get a 100 total yards of offense - they were gotten to...wake up sheeple.

[Anti-sophist]

Originally Posted by apathoid

Jeb Bush is the governor of Florida. Florida miraculously "pulled" ahead of Michigan for the #2 BCS spot. Florida has won the basketball and football national chamionships for 2006. I smell a conspiracy....

eta: Oh and the Buckeyes didnt even get a 100 total yards of offense - they were gotten to...wake up sheeple.

Ahem, and the Heat won the NBA title. Marlins and Tampa Bay have also won within the last 4 years.


(And technically Jeb isn't govenror anymore.. but who's counting)

[apathoid]

Originally Posted by Anti-sophist

Ahem, and the Heat won the NBA title. Marlins and Tampa Bay have also won within the last 4 years.

See! Its TEH CONSPEERICY!! Its common sense!

Quote:

(And technically Jeb isn't govenror anymore.. but who's counting)

Oh. Still a good conspiracy theory though.

[Anti-sophist]

Silly technicalities like that have never stopped them before. I mean if Marvin Bush is "in charge of security" of the WTC, then Jeb is definitately still governor.

[Dog Town]

Originally Posted by Anti-sophist

I'm not sure why....

TGjr, and celebration, six weeks since last game? Great win, atleast it wasn't Spurrier.

[Snowygrouch]

All,
I have complete data frame layouts for virtually every 757 variant from my source whom I`ve been talking to for several months. I have amassed a great deal of information from her.

The conversion is not yet done, its not an easy process but it will be done. Make no mistake; I have obtained ALL the data nessesary to complely dismember the origional .fdr file which I have in both compressed and uncompressed format.

I will of course share the results (whatever they show) here when that is done. For obvious reasons I cannot provide any further information on where I got the frame layouts or who is doing the computer work.

It was I who origionally got the animation from the NTSB. The animation is not for "illustrative purposes" but is constructed by purpose made software direct from the origional source data with a program such as Insight.

Cant post the address as the server wont let me post a url as I`m a new poster. But the company is Flightscape.

However as has been stated we need to get to the binary data to be absolutely sure about the results.

The heading vector is by digital ring laser gyro accurate to several decimal places; the radio altitude should be accurate to within a few feet.

So we shall see exactly what happened soon enough.
Regards

C.

[Firestone]

I know absolutely nothing about how FDRs work.

But common sense () tells me that the data of the FDR of Flight 77 (found at the Pentagon) will confirm that Flight 77 crashed into the Pentagon.

[beachnut]

Originally Posted by Snowygrouch

All,
I have complete data frame layouts for virtually every 757 variant from my source whom I`ve been talking to for several months. I have amassed a great deal of information from her.

The conversion is not yet done, its not an easy process but it will be done. Make no mistake; I have obtained ALL the data nessesary to complely dismember the origional .fdr file which I have in both compressed and uncompressed format.

I will of course share the results (whatever they show) here when that is done. For obvious reasons I cannot provide any further information on where I got the frame layouts or who is doing the computer work.

It was I who origionally got the animation from the NTSB. The animation is not for "illustrative purposes" but is constructed by purpose made software direct from the origional source data with a program such as Insight.

Cant post the address as the server wont let me post a url as I`m a new poster. But the company is Flightscape.

However as has been stated we need to get to the binary data to be absolutely sure about the results.

The heading vector is by digital ring laser gyro accurate to several decimal places; the radio altitude should be accurate to within a few feet.

So we shall see exactly what happened soon enough.
Regards

C.

You have the raw data with the "Parameters Not Working or Unconfirmed" which the NTSB must of run out of money to decode or found it totally superfluous to decode more data from a FDR found in the Pentagon from Flight 77. Are you able to know how many seconds of data never made it to the non-volatile memory? If you can get the raw stuff you should be able to have someone tell you the amount of data in time that was not recorded due to the impact and destruction of 77.

I was looking how 4 second frames are stored; Just knowing where the frames start and end would be interesting. Yet is the final data a complete frame? Is the time stamps from the last frame 2 seconds on the last frame with the last data or the next frame not yet stored?

First of all, it is not important what you find out. I will only sever to prove CT nut cases more wrong.

If you have connections you should be able to explain how much data of flight 77 was lost before being recorded. I need 5 seconds to fit the data into the Pentagon. That is one 4 second frame. There is already enough proof flight 77 did hit the pentagon. Plus the FDR supports what happen on 9/11 when you dovetail it with radar and witness data. I do not like people twisting the data with no facts to support their suppositions.

Unless you have the last data frames you are wasting your time it will still leave the aircraft over 2100 feet away and 300 feet above the impact zone. What do you think?

[uk_dave]

Originally Posted by Firestone

I know absolutely nothing about how FDRs work.

But common sense () tells me that the data of the FDR of Flight 77 (found at the Pentagon) will confirm that Flight 77 crashed into the Pentagon.

Careful now, we're through the looking glass here people.

[GlennB]

Originally Posted by Snowygrouch

All,
I have complete data frame layouts for virtually every 757 variant from my source whom I`ve been talking to for several months. I have amassed a great deal of information from her.
....

Welcome Snowygrouch

All anyone here can ask is that you present your findings without prejudice. I'm sure you'll do just that. There are some here experienced in exactly this field and no doubt they'll be more than willing to advise, if necessary.

Regards

Ign ... (oops) ... Glenn

[jsiv]

Originally Posted by Snowygrouch

All,
I have complete data frame layouts for virtually every 757 variant from my source whom I`ve been talking to for several months. I have amassed a great deal of information from her.

The conversion is not yet done, its not an easy process but it will be done. Make no mistake; I have obtained ALL the data nessesary to complely dismember the origional .fdr file which I have in both compressed and uncompressed format.

I will of course share the results (whatever they show) here when that is done. For obvious reasons I cannot provide any further information on where I got the frame layouts or who is doing the computer work.

It was I who origionally got the animation from the NTSB. The animation is not for "illustrative purposes" but is constructed by purpose made software direct from the origional source data with a program such as Insight.

Cant post the address as the server wont let me post a url as I`m a new poster. But the company is Flightscape.

However as has been stated we need to get to the binary data to be absolutely sure about the results.

The heading vector is by digital ring laser gyro accurate to several decimal places; the radio altitude should be accurate to within a few feet.

So we shall see exactly what happened soon enough.
Regards

C.

All this stuff about talking back and forth with this "insider" for months and getting closer and closer to cracking it for every day that passes seems a little laughable.

Surely if you have obtained the description of the FDR file format, it shouldn't take very long at all to write a simple program that just dumps all the parameters frame by frame to a text file. I really do not understand why it would be as hard as you try to make it out.

Why don't you just post the "data frame layouts" for the model of recorder that was in AA77 if you have it? I doubt it contains any identifiable information that could get the source in trouble, and it would allowed others to independently verify your claims. It seems like it would speed things up as well.

At the very least tell us more about these "data frame layouts." Exactly what is it you received from this mysterious source?

[Anti-sophist]

I'm taking the wait-and-see approach. My hypothesis, for now, is the data will be in accordance with the CSV file, and that will be that.

It seems they are still hung on the heading discrepancy in the animation which has been explained dozens of times as being a magnetic declination problem with the map used in the animation.

I hope that's not where they are pinning their hopes, because it's a dead end.


Anyways, I'll wait and see what information they have, what they post, and what they claim it reveals. Maybe something unexpected will turn up.

[Snowygrouch]

Let me clarify a couple of points,
First I`m sorry you feel that the "story with the insider" comes across as laughable. It is what it is..how it appears is superfluous to this investigation.

Second it took months and months because I only GOT the data frames about a week ago.

Third, one week after I spoke to my contact origionally (she HAD agreed to decode the whole file for free before her boss found out which plane it was from) I got a telephone call from the MD of the company which basically said something like:
"can you confirm the flight number of this plane please?..etc etc...in that case we cannot help you with your enquiries goodbye".

My contact ONLY gave me the files on strict condition of absolute anonymity. Her exact words were that her career in the FDR industry would be over if it became industry knowledge that her company tampered with such data. They do work for AAirlines, what do you think would happen to that contract if it became public that they are diddling with AA FDR data for members of the public.....

I`m not for a minuite suggesting its evidence of conspiracy; simply commercial reality in such a niche industry.

Fourth I`m not doing the number crunching so I cannot answer questions relating to the exac procedure followed or the surmountable difficulties we are encountering.

When I`m any the wiser about how many frames we have I`ll post it.

All the engineering units and their accuracies are included in the data frame layout files provided.

As for me "making it out to be harder than it is", well sorry thats because I`m actually trying to do it properly. If it was easy I`d have done it last week. Also if I was so inclined I could just have made up the whole thing and claimed to have done the decode months ago and post any old nonsense. I`m interested in the raw facts of what occured and discussing how easy it OUGHT to be does not accellerate proceedings!

Will I provide the files to anyone else???...

Possibly after we have finished our analysis. Certainly not before.

C.

[Anti-sophist]

Yes, the person who gave you those data frames career is at stake. That is unquestioned. I have no problems with keeping your source secret.

That being said, the experiment must be repeatable for it to have any value. That means you will need to release all the data you have. We will dismiss as nonsense any extraordinary findings that we cannot repeat. In order to repeat them, we will need the full data. I urge you to repackage it as best as possible to obfuscate the source.

I also promise that I will repeat any extraordinary findings you happen to come across to verify them. I don't know if you consider that a good or a bad thing.

I've been promised "reports" from "you guys" (pilotsfor911truth, et al.) before and been dissapointed every time. I tend to get the same repackaged nonsense on youtube with newer spookier music. If you plan on actually bringing something new to the table, I'll be excited. Hopefully you can deliver where UnderTow and JDX have failed.

[Gravy]

Originally Posted by Snowygrouch

So we shall see exactly what happened soon enough.

Many people already saw what happened, Snowy. On September 11, 2001, to be exact, when flight 77 hit the Pentagon, right in front of them. In the real world.