AA77 FDR Data, Explained

[dtugg]

Just wondering, are there any real FDR experts that agree with the morons at PfffffffffT? You know somebody at the company that made the FDR, Boeing, American Airlines, the NSTB, FBI, ect. If not, how come? Are they all in on it? Hey, I am just asking questions.

 

[Turbofan]

What you mean by "overwritten data" is unclear to me.

Old data (the oldest) which already exists(ed).

Although the only way to reset a memory location is to reset the entire block in which it reseides, flash memory can write to individual cells.

You better read up on Flash memory and study MacGuyvers posts again.

I see no reason why the designers would want to have an entire block's data held in a buffer in order to write an entire block at once.It would seem counterproductive in the application of an FDR.

See above.

That is the design, that is the way things are supposed to work, and the designers did as much as possible to mitigate the effects of non-standard signals and violent forces on the FDR but any engineer will tell you that things never, ever work exactly as designed when things are at their worst.

Ask any engineer if a signal can find a way to a circuit that is not connected,
or how a transient of short duration can 'bias' a circuit which is supposed to
operate on stable, filtered DC.

 

[bje]

Hey Turbofan, quick question:

How many people do you and more moron friends have that say a big plane pulled up and over the Pentagon at the last second rather than flew into it?

You know, the belief that AA 77 flew over the Pentagon is so strong that even the Pentagon Security Video Camera must have caught it!

 

[beachnut]

All that energy and it couldn't take out a partition.

Sorry netgineer, you don't make sense.

Your lack of sense on my post can be indicative of your abilty to figure out 9/11.

Did I get the energy correct?

 

[jaydeehess]

No, there were none. None with similar cases as the alleged AA77 impact.

SHOW ME.

You have been shown several examples of FDR's with lost data. You wish to move the goalposts so far away as to be unreachable and you know it.

Please point me to the crashes of large aircraft into a concrete structures at high velocity in which the aircraft was not experiencing any structural or systems malfunctions. THAT is where you place the goalposts TF, perhaps you can tell me how far away they are.

I have no doubt whatsoever that IF it can to be that one did discover some other suicidal pilot who crashed his jet into a concrete structure and it was shown to you that the FDR was missing several seconds of data that you would again move the goalposts, pooh-poohing the idea that this was close enough to the flight of #77.


I also remind you that it is well known among us not-technical-enough-uneducated-duhbunkers that;

Your group has absolutly no support among any recognized FDR expert organization, including L3, the manufacturer of the FDR in question. This despite your group often citing L3 as supporting its claims.

The only 'experts' that do support your group are self taught persons within your own group.

Your group steadfastly refuses to write up a purely technical paper outlining the work you have already done showing that the FDR that the NTSB had could not have been on a flight that impacted the Pentagon.

Your group steadfastly refuses to write that paper and submit it with no political or accusatory statements attached, to the manufacturer of the FDR, the pilot's unions, ICAO, the FBI, or the NTSB, nor any publication that would have a readership that would be interested in technical aspects of aviation or aviation safety.

Your group refuses to offer any reasoning as to why you will not do this, instead prefering to argue incessently on the internet with persons you claim have not enough technical expertise to have a vaild opinion.

 

[Turbofan]

you have been shown several examples of fdr's with lost data.

show me. Link me. Source me.

 

[jaydeehess]

You better read up on Flash memory and study MacGuyvers posts again.

The particular StrataFlash device I'm looking at has a 32-Word write buffer (each a 32-bit Word), which allows for burst of writes to take place (it's more efficient than writing one Word at a time)... there's no guarantee they use that mode in the FDR, but it's available, and a potential area for losing up to 32 Words (roughly 1 second) of data.

Neglecting the smaller boot bocks, the die consists of multiple 32kWord blocks. To write new data to a specific memory location that was previously populated, the entire block must be erased. Using our frame size numbers from above of 128 Words, this says it is guaranteed that (hopefully old) data is erased in 1024 second bursts (32kW / 128W * 4sec = 1024sec). To put it in perspective, that's a potential loss of over 17 minutes of data should the incorrect block of data be erased.

Erasing a block consist of issuing two specific command codes to a memory location within the block to be erased before the actual erase operation will occur. This is obviously to prevent accidental erasures from rogue/buggy programs and the like, but it's not infallible. The memory location, however, is not specific (e.g., it doesn't have to be just the first element in the block), and any valid location within a block will start the erase sequence. For example, suppose the proper sequence for block erasure is entered, but one of the address lines is damaged due to a voltage transient... the command sequence is correct, but you're pointing at an incorrect location in memory. The result? You just toasted 17 minutes of flight data from the wrong block, and there's nothing that says it couldn't be the block you just started filling up 4 seconds ago.

This is only one example of many I could come up with that are likely to cause a loss of previously valid data in flash.

Now, I can certainly come up with more scenarios where the flash would lose data (both physcial and electrical causes), but I hope these few are wide enough to show that it can happen. I did not get into how smaller portions of data may get toasted as I figure these scenarios alone would prove that it is at least possible to lose data.

Ask any engineer if a signal can find a way to a circuit that is not connected,
or how a transient of short duration can 'bias' a circuit which is supposed to
operate on stable, filtered DC.

In fact due to large unwanted transients I have personally repaired or replaced electronic devices that operated with not only on board filtered power supplies but were supplied their ac by battery back up UPS power supplies.

I have cleaned up the debris from exploded capacitors, toasted power supply boards and pcboards with dead IC's all in the same piece of equipment.

show me. Link me. Source me.

This thread or the split thread from this one. You responded to the post in which they were given so you obviously saw them.

Now link me to any crash that you believe is equivalent to the crash of Flight 77 into the Pentagon. I wish to know exactly where your goalposts are placed. Not that any goalposts set by Pft would not be attached to a truckbed in order to get them moved to a safer position if need be.


I also remind you that it is well known among us not-technical-enough-uneducated-duhbunkers that;

Your group has absolutly no support among any recognized FDR expert organization, including L3, the manufacturer of the FDR in question. This despite your group often citing L3 as supporting its claims.

The only 'experts' that do support your group are self taught persons within your own group.

Your group steadfastly refuses to write up a purely technical paper outlining the work you have already done showing that the FDR that the NTSB had could not have been on a flight that impacted the Pentagon.

Your group steadfastly refuses to write that paper and submit it with no political or accusatory statements attached, to the manufacturer of the FDR, the pilot's unions, ICAO, the FBI, or the NTSB, nor any publication that would have a readership that would be interested in technical aspects of aviation or aviation safety.

Your group refuses to offer any reasoning as to why you will not do this, instead prefering to argue incessently on the internet with persons you claim have not enough technical expertise to have a vaild opinion.

 

[jaydeehess]

You better read up on Flash memory and study MacGuyvers posts again.

how about some more then.

So, it's safe to say from your expert analysis that single bits adjacent to
the bits written cannot be altered; but rather blocks of data would be lost?

Originally Posted by Macgyvers2000 It would not be safe to say that, as doing so would be akin to saying all vehicles have four wheels because they're the color green... one statement has no bearing on the other.

My previous examples merely showed several different logical ways in which a block of data could be lost. The loss of individual bits was never mentioned in those examples, and therefore it should not be inferred the possibility of that happening is zero. Individual bits / bytes / words can be invalidated under the proper conditions.

My quick review of the report (and I admit it was not in-depth by any sense of the word) says the time mentioned (xx:45) is not necessarily a true impact time, but simple termed "impact" for lack of valid and/or readable/recoverable data after that time stamp. As has been mentioned already by others, a bit of reason has to be applied to reports, so if a plane is sitting in pieces on the lawn of the Pentagon, one has to assume the plane made impact, even if the time stamps are off by a few seconds... if it walks like a duck and quacks like a duck...

 

[beachnut]

show me. Link me. Source me.

You missed them? They are there. Use the search function to find them.

Use a page out of your own book; prove there are not examples of lost data, missing data, etc. Use the truther method in reverse.

Where did 77 go after it impacted the Pentagon at 61.2 degree true course?
Why was 77 and the FDR not on the video from the hotel which clearly shows ZERO fly over where CIT, p4t endorsed bad researchers, show the 81 degree bank turn of over 7 Gs! Where is d plane? Lol

How do you wave your hands and dismiss the FDR found in the Pentagon right next to the dead passengers on flight 77?

Use the search function Luke.
Can you find any real evidence yourself?

 

[beachnut]

All that energy and it couldn't take out a partition.

Sorry netgineer, you don't make sense.

What is a netgineer?

Ask a few trained aircraft accident investigators what a 757 going over 535 mph would look like, or if the Pentagon damage is indicative of a 757 impact. They will confirm the damage at the Pentagon is what a 757 would do at high speeds. The p4t has no trained aircraft accident investigators. Why? In 7 years they could have attended the school a few times and repeated it enough to understand 9/11.

You have no real help from p4t on the FDR, you keep saying you have experts but can't produce one who really works with FDRs. You also say the NTSB made errors in the FDR but you can't produce the work to show it.

 

[bje]

I've seen enough from this crowd for a while.

I can understand why you are running away this time, Turbofan.

You've got this crisis on your hands that you have to figure a way to weasel out of.

 

[Tricky]

Several posts moved to AAH. Please keep posts on topic and do not use personal attacks.

Replying to this modbox in thread will be off topic  Posted By: Tricky

 

[R.Mackey]

You have been shown several examples of FDR's with lost data.

show me. Link me. Source me.

Here's an example: American Airlines 587, Belle Harbor, 12 November 2001. Aircraft was an Airbus A300, carrying a Fairchild FA-2100 digital FDR manufactured by L-3, very similar or identical to the type carried by AA 77.

The report clearly describes the last ~ 4 seconds of data missing prior to impact, and also discusses the flaky behavior of the DFDR shortly before the end of the data record:

The last recorded FDR data was evaluated using L-3 Communication's FA2100 standalone software. The last recorded synchronized and correlated data was recorded at 9:16:01.23. Following this data was a Data Interruption Marker which was inserted into the memory to indicate that the recorder stopped receiving data from the DFDAU. Within 4 seconds, the recorder received less than a second of unsynchronized data followed by another Data Interruption Marker. Safety Board staff attempted to decode the unsynchronized data but was unsuccessful.

During the end of the recording, the recorder did not record a Power Up Marker which would indicate when power had been applied to the recorder. Therefore, it can be assumed that the recorder was powered until after the last Data Interruption Marker. Also, because the recorder recorded the last Data Interruption Marker, it can be assumed that the recorder stopped receiving data before it lost power. Lastly, since a Timing Marker was not recorded after the last Data Interruption Marker, it can be assumed that the recorder lost power within 4 seconds of the last Data Interruption Marker.

Now, some fine points: We do not have enough information to disambiguate the DFDAU failure from a failure inside the DFDR when the data interruptions occurred. A failure in either box could cause these symptoms, or slightly different ones. Could have been a failure in both boxes. Could also have been a fault that affected both boxes, such as noise on the power or data bus.

Nonetheless, this is a clear case of data being lost upon impact. The amount of data lost, and which data it was, is eerily similar to AA 77. Therefore, it can and does happen.

It would be instructive if we had more insight into AA 77, to see if there were similar indications of data or power failure inserted into the record. The NTSB report on AA 77 doesn't say one way or the other, and indeed does not seem too concerned about the very last bits of data. This is natural. They were looking at the FDR to understand when and how the flight was hijacked, not nitpick the exact speed and heading a moment before impact, which is only of interest to the most extreme of conspiracy theorists.

Bottom line, this is a plausible case that verifies AA 77's FDR behavior is not unique. There are probably several others.

Also, to Turbofan: Many of your recent posts have been rather rude and unproductive. My Ignore list is on a hair-trigger these days. Please discuss these matters respectfully. Thank you.

 

[twinstead]

You'd think just ONE other example of a FDR loosing data upon impact would render much of this thread moot.

 

[MacGyverS2000]

Turbo, I was going to quote all of your most recent posts on the FDR data into one thread, but I'm feeling a bit lazy (a touch under the weather so the fight has gone out of me for the day), so I'll simply quote this one post and work from memory on the rest. Jay has already done a fine job of bringing up my earlier (relevant) posts.

- There is no connection to the erase enable when the CPM resides in the flight data recorder. In order to access this function, the module must be physically removed from the container and placed in a test jig.

A jumper must be physically moved to enable the erase line, followed by a DC voltage application and a step through menu using software.

While I cannot speak with any certainty what this supposed jumper does (having never seen or played with the FDR), I'm willing to bet it is used to change boot modes during initial bench testing, calibrations, etc. It may or may not allow for complete erasure of flash.

That said, I guarantee it is not the only way in which flash blocks can be erased. To make such a system would mean the FDR would have to be removed from the plane after every few flights just to be blanked. The block clear function is an integral part of the recording process.

- RE: transients and bit flipping. If the bits were flipped, they would stll reside in memory.

The last sync word and frame are intact, however the raw file shows no additional bits after the last sync word therefore a change of state did not occur.

Yes, flipped bits would still reside in memory... I didn't realize there was any confusion about this (seemingly obvious) fact. Your example a number of posts back was incorrect, however... you showed corrupted zero bits changed into ones, something that is not possible. If you reread my posts in the other FDR thread, I gave an example that showed what bit corruption would look like, as well as giving a detailed explanation as to why any corrupted bits must be converted to zeros and not ones.

I believe I have already offered several possible explanations as to why data may be missing, as well as several real-world examples of how it can be corrupted or lost. I will simply point you back to my earlier posts rather than rehashing them here...



As I said from the get-go, I don't mind a scientific discussion, but I do mind when my words are taken out of context or used in an improper manner. It is wrong to tell others their conclusions are incorrect and that proof can be had by rereading my posts... truth in point, you seem to be misreading (or conveniently forgetting) what's in my posts. I try to be quite careful in my wording, and your posts (such as the one above) are starting to show a level of desperateness seen only when the facts do not support the argument.

So far, few (if any) of my posts have supported any of your claims. In case I'm not being clear enough... Until at least one of your claims is proven correct by the statements I'm making (which has not happened yet), please do not, in any way, shape, or form, point towards my statements as being in support of your claims.

 

[Turbofan]

Nonetheless, this is a clear case of data being lost upon impact. The amount of data lost, and which data it was, is eerily similar to AA 77. Therefore, it can and does happen.

I beg to differ:

During the end of the recording, the recorder did not record a “Power Up Marker” which
would indicate when power9 had been applied to the recorder. Therefore, it can be assumed
that the recorder was powered until after the last “Data Interruption Marker”.

Also, because
the recorder recorded the last “Data Interruption Marker”, it can be assumed that the recorder
stopped receiving data before it lost power

. Lastly, since a “Timing Marker” was not
recorded after the last “Data Interruption Marker”, it can be assumed that the recorder lost
power within 4 seconds of the last “Data Interruption Marker”.

It seems apparent from the report that the FDR stopped receiving data,
and recorded Data Interrupt Markers to highlight this issue.

This is not the same as having data written to the memory, and then wiped
out.

I will bring this up with my circle of researchers and get their thoughts on
the report however.

 

[Turbofan]

That said, I guarantee it is not the only way in which flash blocks can be erased. To make such a system would mean the FDR would have to be removed from the plane after every few flights just to be blanked. The block clear function is an integral part of the recording process.

We have discussed the possibility that a transient could erase a block of memory.
That is what the reply disproves. We are not referring to single bit flipping.

We understand that a data block must be erased before it is overwritten,
that is not the basis of this particular argument. We are talking about a
transient initiating a block erase for the purpose of wiping out a block entirely.

Yes, flipped bits would still reside in memory... I didn't realize there was any confusion about this (seemingly obvious) fact. Your example a number of posts back was incorrect, however... you showed corrupted zero bits changed into ones, something that is not possible.

If you are referring to the post about clarifying the difference between what
an erased flash block would look like compared to an overwritten block,
the example is spot on.

I was not trying to show corrupted bits.

I believe I have already offered several possible explanations as to why data may be missing, as well as several real-world examples of how it can be corrupted or lost. I will simply point you back to my earlier posts rather than rehashing them here...

Respectfully, you admitted to not having much information about the subject.
Do you still stand behind the claim that a transient could erase 4 seconds
of data?

You have already stated that 4 seconds of corrupted data would still reside
in memory, correct? 3072 bits of information would be considered 'corrupt',
yet retrievable, and present in the raw file after the last successful frame.

There is nothing in the raw file to support corruption of bits, therefore we
must hypothesize about erasure.

In detail please provide an explanation of how 4 seconds (1024 words) can
be erased by a transient(s) upon impact.

We have estimated power decay to be anywhere from 200-400 milliseconds.

 

[applecorped]

show me. Link me. Source me.

ewwwwwww!

Do no disregard previous mod box.

Replying to this modbox in thread will be off topic  Posted By: LibraryLady

 

[MacGyverS2000]

We have discussed the possibility that a transient could erase a block of memory. That is what the reply disproves. We are not referring to single bit flipping.

We understand that a data block must be erased before it is overwritten, that is not the basis of this particular argument. We are talking about a transient initiating a block erase for the purpose of wiping out a block entirely.

At this point, I'm not sure what you are trying to prove/disprove. Quotes are getting cut too short or post snippets are being randomly quoted and muddying the issue. I'll go back to my "Make the question clear and concise" statement to avoid further muddying the waters.

Respectfully, you admitted to not having much information about the subject.

Which subject are you referring to? I believe I have only made the claim that I am typically unfamiliar with the particular piece of hardware being discussed, not about the general subjects of flash, transient failure modes, etc. I'm happy to wager on my information being correct so far as it applies to hardware in general... should the FDR prove to be unconventional in design (doubtful), then my statements should be taken with a grain of salt (not that they should have been taken any other way, mind you, just an experienced and/or educated opinion from a scientific viewpoint).

Do you still stand behind the claim that a transient could erase 4 seconds of data?

It is possible I made that claim earlier, and if I did, I most certainly would have placed a specific set of conditions upon that claim. Feel free to quote me here, including those conditions I stated to support that claim. I cannot say with any certainty I made that claim off of the top of my head... it has been weeks since I last looked at these threads.

You have already stated that 4 seconds of corrupted data would still reside in memory, correct? 3072 bits of information would be considered 'corrupt', yet retrievable, and present in the raw file after the last successful frame.

Again, I'll leave it to you to dig through the old posts and quote the relevant post by me. It is possible I made such a statement, but if memory serves, 4 seconds was a lot of data and therefore I most certainly would have set specific conditions down for such a loss to occur.

There is nothing in the raw file to support corruption of bits, therefore we must hypothesize about erasure.

In detail please provide an explanation of how 4 seconds (1024 words) can be erased by a transient(s) upon impact.

We have estimated power decay to be anywhere from 200-400 milliseconds.

This is vaguely ringing a bell. If my old memory serves, I believe I mentioned the possibility of the write buffer being susceptible to transients (due to it being a slice of RAM, not EEPROM). A transient could erase the buffer to all zeros, all ones, or a random mixture of the two that could even change from one write to the next. If the buffer is set to all zeros and multiple buffer writes are performed to a block, you end up with a long string of zeros after a valid chunk of data. It's not rocket science, just a simple fact of dealing with volatile memory in an electrically unstable environment and is fairly easily repeatable on the bench. In a low-voltage condition, RAM is flaky and
EEPROM writes are undefined... simple physics of semiconductor logic gates.

 

[Turbofan]

In addition to my last post about the FDAU of AA587:

We do not have enough information to disambiguate the DFDAU failure from a failure inside the DFDR when the data interruptions occurred. A failure in either box could cause these symptoms, or slightly different ones. Could have been a failure in both boxes. Could also have been a fault that affected both boxes, such as noise on the power or data bus.

AA 587 experienced in-flight failures and lost both engines prior to crashing.
The FDR continued to record while the DFDAU stopped outputting data as
per report.

This is not a similar case to AA77.