AA77 FDR Data, Explained

[wstutt]

Hi Warren, very interesting find. Have you considered going after the raw FDR data and analyzing it?

Thank you for your welcome.

That's what I have been doing. The Hamming codes and page parities are in the raw .FDR file. I also wrote a program that decodes the small portions of the .FDR file that are stored uncompressed. It is also available on my web site warrenstutt dot com. Look for the link to my AAL77 FDR partial decoder program if you are interested in it.

BTW, your post #85 in this thread which I link to in my web page and in my source code has been extremely useful to me. Thanks very much for it.

Warren.

 

[R.Mackey]

I believe the .FDR file basically is a data dump when you remove the text header from the beginning of it. The 64 kilobyte pages are laid out as in figure 4.2-2 of the PDF document on my web page that I referred to in my reply to Myriad. There are two flight data streams in the .FDR file as in the same figure.

It could be -- I have no way to tell. However, if the .FDR is a copy of the flash image, it should also have some other interesting properties, like old flights that are gradually being overwritten. At the end of the record should be a chunk of cleared memory corresponding to the last block erase, followed by remnants of the overwritten data. There may also be EDAC bits in play, i.e. every 16-bit word is actually represented by 20 bits, that kind of thing.

I'm stabbing in the dark, however; I've never worked on an FDR directly and I don't know how it was configured. We would need a system expert and this information is probably proprietary.

When you refer to the file extracted by the NTSB do you mean the .CSV file?

The .FDR file comes from NTSB as well, I think. It also must have some kind of filtering applied, though whether it's heavy filtering or very light I just don't know. It may be close enough to the original image that your analysis is valid.

The NTSB report says that "The remaining parameters either were not recorded properly or were not confirmed to have been recorded properly". I do not interpret this as definitely saying that some parameters were found to not be recorded properly, it could be that the NTSB did not try to confirm that any of the parameters that they did not validate were recorded properly.

That's my reading as well. I think the NTSB simply had some out-of-date packet definitions, or there was some mild configuration management problem at American Airlines that could be rectified without too much effort. I believe with more effort the invalidated parameters could be reconstructed. NTSB may not have bothered -- as I mentioned somewhere in this monster thread, the usual purpose of FDR analysis is to understand why the accident happened, and since the cause in this case is straightforward, they may have done only a cursory data inspection. On other flights, notably AA 587, they worked much harder to extract fragmentary data than they did here, and for good reason.

Incidentally, have you looked at the UA 93 FDR? We see a similar phenomenon there, where the last couple of frames have time markers but no valid data. Here, however, the amount of missing data is thought to be only a second or so, rather than ~6 seconds as we see here, but I think the phenomenology is similar.

 

[beachnut]

There are 187092 flight data pages that are filled (not erased) and that have the correct Hamming code and page parity and 2 such pages that have an incorrect Hamming code and page parity.

I see no evidence of data being corrupted. Does this answer your question? I am not sure I have correctly understood what you meant.

Warren.

The secure chip is constantly being erased and written to; it holds the last 25 hours of data. There are pages being erased and written to all the time; are these those papes you found?

The data rate to the secure chip per second is the same as the data collected in a second. Lost data could be in the buffers waiting to be stored. Think about where the data is encrypted/compressed. Flight 93 had data up-to the last second but that FDR only stored 64 12 bit words per second whereas 77 stored 256 12 bit words per second.

Seconds missing in other FDRs have happened. There is no red flag for Flight 77. The need to speed up data storage while being an issue was OCBE. Regulations were changed to force and eliminate the seconds of buffered data not stored securely in a timely fashion in early digital FDR systems.

No evidence the FDR was tampered with, no anomalies that standout, and the data supports impact at the Pentagon, backed-up with hard evidence. There are only a few fringe groups of who have idiotic ideas on 911 and make-up delusions to include the FDR. Some idiots claim 77 did not impact the Pentagon. I assume you have seen some of the moronic tripe from Balsamo all over the Internet in his standard 11.2G failed physics with flawed logic to match. If this is new FDR information he will twist it to fit his delusional claptrap he sells on DVD.

On the surface it means nothing. ... the final few seconds of data in the FDR being corrupted during the crash. I do not see any evidence of the FDR data having been corrupted.

The "FDR system" was corrupted by the crash. We do not have the data from the buffers destroyed in the crash. There may be limited corruption in the secure chip and/or no sign of the massive data corruption in the "pipeline". The secure chip and recorded data say little about the entire "FDR system" and the status of data to be stored.

This topic mean nothing on the surface for 911, and it means nothing under the surface for 911; only in the paranoid minds who make up lies and fantasy like p4t.

The two 128 byte pages of data that show incorrect Hamming codes and page parities start at hex file offsets 38972A and 39952A respectively in the .FDR file

Any ideas if these are the page being erased so the new data can be stored? The data is being erased as new data comes in so 25 current hours are in the FDR?

There is no exact answer to this question since the frames which each contain four seconds of data are compressed using Huffman coding so the number of bits used to store each frame varies from frame to frame. Averaging from the last ten complete looking frames from each flight data stream, I get a figure of approximately 0.5 seconds of data per full page.

That sounds reasonable. Where is the data compressed? In the secure chip or outside of the chip? 4 seconds compressed together? Inside, or outside of the secure area in the FDR system? Any insight for this?

Welcome to the forum.

 

[T.A.M.]

Yes, a real conspiracy would have surely faked such evidence.

Yah as far as conspirators go, the NWO sucks. I mean with all their power and money, they couldn't manage to forge a few plane parts, fake a couple of videos...I want my NWO contributions back on that one.

TAM

 

[twinstead]

Its just too bad we do not have any hard evidence like the following.

Actual photo or video of AA77 hitting the Pentagon.

Reports matching parts found to the plane.

Yea, because ALL crimes have the perfect evidence to support them.

You have enough compelling evidence to hand wave away as it is. I can only imagine the mental gymnastics you folks would be having to perform if evidence like that actually DID exist.

Oh, you don't think that for a moment I believe that evidence you suggest, if it existed, would actually sway the majority of those in your delightful little movement, do you?

 

[wstutt]

Would the software skip over the corrupted bytes and use a default value which caused the Hamming and parity errors?

Yes, the software would in effect use a default value as the recorded value for pages which have some data in them, but for which the Hamming code and page parity were not recorded. The part of the page where the Hamming code and page parity are stored would still have all bits set to 1 from when the page was erased. The calculated Hamming code and page parity from the rest of the page would most likely not match the default value (there is a 1 in 2048 chance)


Warren.

 

[wstutt]

Well, one obvious possibility is if the overall data acquisition rate were about twice what a single flash ram bank would be able to keep up with. But that's just speculation on my part.

There are uncompressed portions of up to 4 seconds of data that are each stored completely within one flash memory bank or the other, so it appears to me that the flash memory banks can cope with the data rate. The uncompressed data would only need to be stored at the rate of not much over 3000 bits per second, the compressed data would have an even lower bit rate. I have not checked the specifications of the EEPROM chips, but I would have thought that such data rates would be well within their capability. There must be some other reason as to why there are two flight data streams.

Thanks for the answers. I hate to stack up questions while you're still working on others, but it appears you're saying that the NTSB file really does resolve into a complete bit image of the contents of the FDR's memory, not just a decoding or translation of it. Am I reading that correctly?

Yes that's correct. The NTSB released both a .FDR file and a .CSV file. The .FDR file is a binary file and is essentially an image of the contents of the FDR's memory as you said. The .CSV file is a decoding of the .FDR file and consists of columns of data that can be viewed in Microsoft Excel and other software. Both files are available online.

Respectfully,
Myriad

Warren.

 

[beachnut]

Its just too bad we do not have any hard evidence like the following.

Actual photo or video of AA77 hitting the Pentagon.

Reports matching parts found to the plane.

The FDR shows all 25 hours of previous flight verified by 911Truth! So as an analyst that means the FDR shows exactly all the flights done by the aircraft found in the Pentagon which proves 77 is in the Pentagon with DNA to make your failed lie a pathetic disrespect based on your failed opinions, hearsay, delusions, and other false ideas by you and 911Truth.

Do you have something to add on the FDR or will you report yourself for making off topic posts and slander against the FBI, DoD, FAA, me, all my fellow soldiers and those who were killed on 911.

"Be all you can be" post delusions and claim you are a NSA analyst; that make me cringe if you are a delusional 911Truth follower and you work to protect us against foreign technology surprises. Looks like you failed to take action and prevent 911 since you worked for the NSA and messed up the analysis so now all you can do is fail at apologizing for murderers, the terrorists.

Your ignorance on FDR and lack of knowledge is showing as you say there are no parts showing 77 at the Pentagon; The FDR is the biggest and it is public record and many of us have the readouts from the NTSB. Better accuse the NTSB of being traitors too; add me to your list of enemies and go join the terrorists you apologize for.
Irony, the FDR proves it is 77!

 

[wstutt]

It could be -- I have no way to tell. However, if the .FDR is a copy of the flash image, it should also have some other interesting properties, like old flights that are gradually being overwritten.

It does have old flights. My partial decoder program for the .FDR file shows airports where the plane took off from on previous flights. These match up with official records of the previous flights. Follow the AAL77 FDR Partial Decoder program link and the download output files link from that if you are interested.

At the end of the record should be a chunk of cleared memory corresponding to the last block erase, followed by remnants of the overwritten data.

There are two 64 kilobyte erased blocks, one for each flight data stream starting at file offsets 3A00AA and 3B00AA. The remnants of the overwritten data start after that from file offset 3C00AA.

There may also be EDAC bits in play, i.e. every 16-bit word is actually represented by 20 bits, that kind of thing.

The only EDAC bits I am aware of in the .FDR file are the Hamming code and page parity.

I'm stabbing in the dark, however; I've never worked on an FDR directly and I don't know how it was configured. We would need a system expert and this information is probably proprietary.

I agree the information is probably proprietary to L3 Communications. However I did find that PDF document containing figure 4.2-2 on the web using Google. Perhaps the person who posted it was not authorised to do so, but it has been there for at least a year now. If I had the Huffman tree which is probably proprietary, I could decompress the .FDR file and decode it now that the NTSB gave me the data frame layout through a FOIA request.

The .FDR file comes from NTSB as well, I think. It also must have some kind of filtering applied, though whether it's heavy filtering or very light I just don't know. It may be close enough to the original image that your analysis is valid.

Copies of the .FDR file were received by myself and others through FOIA requests to the NTSB. The only changes I am aware of in the .FDR file from what I would expect from a pure dump of the EEPROM contents is that the .FDR file consists of 64 kilobyte blocks alternately from the different chips for the different flight data streams rather than the whole contents of one chip followed by the whole contents of the next one, and that a text header was added at the beginning of the .FDR file, otherwise the layout of the file matches Figure 4.2-2 of the document I previously mentioned. There is no filtering applied that I am aware of. What sort of filtering would you expect to have been applied?

<snip>

Incidentally, have you looked at the UA 93 FDR? We see a similar phenomenon there, where the last couple of frames have time markers but no valid data. Here, however, the amount of missing data is thought to be only a second or so, rather than ~6 seconds as we see here, but I think the phenomenology is similar.

Yes I have. The .FDR file for UAL93 is named UAL93.DLU and is not compressed. I wrote a decoder for the file. Follow the UAL93 FDR decoder program link on my web site if you are interested. It decodes every subframe in the file but not every parameter within each subframe. There is a partial subframe at the end of the data with the contents as described in the NTSB report. The second additional subframe that the NTSB report mentions does not appear after the partial subframe in the file.

Warren.

 

[wstutt]

The secure chip is constantly being erased and written to; it holds the last 25 hours of data. There are pages being erased and written to all the time; are these those papes you found?

Yes, I believe the two pages I referred to are the ones that were being written to and were not yet full. There are two completely erased 64 kilobyte blocks, which leads me to believe that at the point in time when the last data was written, there was no erase process that was interrupted.

<snip>
... I assume you have seen some of the moronic tripe from Balsamo all over the Internet in his standard 11.2G failed physics with flawed logic to match. If this is new FDR information he will twist it to fit his delusional claptrap he sells on DVD.

I have posted on the Pilots for 9/11 Truth forums and have watched their DVDs, however I am not a member of Pilots for 9/11 Truth.

The "FDR system" was corrupted by the crash. We do not have the data from the buffers destroyed in the crash. There may be limited corruption in the secure chip and/or no sign of the massive data corruption in the "pipeline". The secure chip and recorded data say little about the entire "FDR system" and the status of data to be stored.

When I said "FDR data", what I meant was the data as it was recorded in the secure memory of the FDR. The Hamming code and page parity is only designed to detect corruption of data in the secure memory of the FDR after (not before) it was recorded. I see no evidence that any data in the secure memory was corrupted after it was recorded. As to whether or not data was corrupted or otherwise lost before it was recorded, I have no evidence to add to what others have already presented.

<snip>

Any ideas if these are the page being erased so the new data can be stored?

No, these two pages are separate from and in the preceding two 64 kilobyte blocks to the two 64 kilobyte blocks that are erased.

The data is being erased as new data comes in so 25 current hours are in the FDR?

I have found 38670 frame markers in the file. At 4 seconds per frame, this would be more than 42 hours of data.

That sounds reasonable. Where is the data compressed? In the secure chip or outside of the chip? 4 seconds compressed together? Inside, or outside of the secure area in the FDR system? Any insight for this?

I don't know whether the data is compressed by the Crash Survivable Memory Unit (CSMU) or not.

4 seconds compressed together?

If you mean does the compression algorithm need to wait for a whole frame to become available before it can compress any of it, then I don't believe so. According to post #85 of this thread, compression is done word by word.

Welcome to the forum.

Thank you.

Warren.

 

[jaydeehess]

Warren, the crux of the matter is that there seems to be no more data after about 4-6 seconds prior to impact.
One suggestion was that the erase command had been re-instituted for the frame being written to. Your work suggests that this did not occur.
As I said that was one suggestion, although PfT seems to ignore that and assume that it is the only way data could be lost.
It still leaves us with missing data. The data must, IIRC, be stored in a buffer prior to being written to flash, and the poster Turbofan has said that the system writes a full frame at a time to flash memory. Data still in the buffer could certainly be lost on impact.

Also , does the incorrect Hamming code give any clue as to what caused the data for the last few seconds of flight to not be recorded?

 

[R.Mackey]

It does have old flights. My partial decoder program for the .FDR file shows airports where the plane took off from on previous flights. These match up with official records of the previous flights. Follow the AAL77 FDR Partial Decoder program link and the download output files link from that if you are interested.

Got it, thanks for your reply. In that case, it does support the notion that your analysis is valid.

I agree the information is probably proprietary to L3 Communications. However I did find that PDF document containing figure 4.2-2 on the web using Google. Perhaps the person who posted it was not authorised to do so, but it has been there for at least a year now. If I had the Huffman tree which is probably proprietary, I could decompress the .FDR file and decode it now that the NTSB gave me the data frame layout through a FOIA request.

I was mainly thinking of the Huffman schema and the frame markers with respect to filtering. If you've got data from before applying the Huffman symbols, then you may indeed be quite close to the original data.

I'm also a little surprised there doesn't seem to be more EDAC, particularly with an irregular compression scheme, but maybe that's just how it is.

Well, given these results, we should start looking harder at the DFDAU rather than the recording module as the next candidate for causing the data outage. Just for full disclosure, I don't think this is in any way going to change our thoughts on what happened at the Pentagon -- the radar data pretty much ices any alternative narrative -- but the missing few seconds could be indicative of a design flaw in the FDR system itself. I say this becase there are similar episodes, like AA 587, so the fact that the last few seconds are missing may not be a random event.

This obviously doesn't matter for purposes of reconstructing September 11^th, but it could matter if, for instance, there was a mid-air collision event, and the last few seconds were essential in determining how it had happened. If there is a system vulnerability, we should take steps to address it.

 

[Norseman]

Here is the NTSB report on the FA2100 FDR from Flight 1400 that made an emergency landing due to fire in one engine, no injuries fortunately. But the FDR lost power twice and stopped recording during flight, loosing large amounts of data, before it regained power and continued to record. The document also lists the conditions necessary to keep the FDR powered. It could be of interest.

http://www.ntsb.gov/Dockets/Aviation/DCA07MA310/394887.pdf

 

[apathoid]

Here is the NTSB report on the FA2100 FDR from Flight 1400 that made an emergency landing due to fire in one engine, no injuries fortunately. But the FDR lost power twice and stopped recording during flight, loosing large amounts of data, before it regained power and continued to record. The document also lists the conditions necessary to keep the FDR powered. It could be of interest.

http://www.ntsb.gov/Dockets/Aviation/DCA07MA310/394887.pdf

Interesting find. Somewhere in one of these threads someone asked what are some possible ways the FDR/FDAU could lose power besides a fault in the "black box" itself. Well there are many ways.

I have had to troubleshoot FDR failures in the past and had one instance quite recently with an intermittent FDR failure had to be repaired prior to further flight. All aircraft are different, but typically the FDR and FDAU are powered from the Left 115 AC Bus(which is typically supplied from the #1 engine generator) through flight deck switchology(parking brake handle, fuel switches, FDR control switch), through one or more flight recorder related relays onto a bunch of terminal blocks and associated wiring, to the boxes themselves. Now when power to the left AC bus is lost(as would happen when the #1 engine fails or generator goes offline), one or more things will happen. The Right 115 AC Bus will supply the entire aircraft through the now energized bus isolation relays, causing a high load condition. And all the electronics folks here know what that means: load shedding. The engine generator may be brought back online, or the APU may be started and its generator switched on to aleviate the load shed condition. But that would take some time. It's also worth noting that the FDR will work off of DC power, but only when all AC is lost and when the aircraft is in the air(through the air/ground relays).

I'm not saying the FDR in the example above(I didn't read much further than the introduction) was load shed, apparently several times, after the #1 engine was lost - but its a possibility. Something similar could have happened on AA77 as well. I don't know, but I'm throwing it out there.

On edit: In case anyone was wondering what the problem I alluded to earlier ending up being - apparently maintenance miswired a terminal strip by putting a 28VDC wire into a data bus(ARINC) AC return terminal block. This 28 volts wasnt always present, so the FDAU worked most of the time.
Not the first time I've seen something like that and it wont be the last!

BTW, your post #85 in this thread which I link to in my web page and in my source code has been extremely useful to me. Thanks very much for it.

Good to know.

 

[BCR]

Earlier on this thread there was debate as to whether the data recorded by the flash memory of the FDR may have become corrupted during the crash.

I have written a program to check the Hamming codes and page parities in the AAL77 FDR file. There are only two pages where the Hamming code and page parity shows as being incorrect. It appears to me that this is because these pages were not completely recorded. You can read about it at my web site at warrenstutt dot com. Follow the AAL77 Hamming code and page parity checker link.

I see no evidence that any of the data was corrupted after being recorded.

Warren.

Warren, I just noticed that you are posting here now. Welcome and might I add how impressed I am with your work on the FDR. Just an FYI for JREF'rs, Warren and I compared notes on the AAL77 FDR around a year ago and he was kind enough to provide me with some of his early C# code that helped me in putting together my own VB code for working with the raw FDR file.

We both reached something of a dead end with the Hoffmann encryption, but got far enough I think to verify the frame structure. Warren, have you found anything since we last communicated to explain the 4-6 seconds of missing data in the published NTSB CSV file?

 

[R.Mackey]

I have had to troubleshoot FDR failures in the past and had one instance quite recently with an intermittent FDR failure had to be repaired prior to further flight. All aircraft are different, but typically the FDR and FDAU are powered from the Left 115 AC Bus(which is typically supplied from the #1 engine generator) through flight deck switchology(parking brake handle, fuel switches, FDR control switch), through one or more flight recorder related relays onto a bunch of terminal blocks and associated wiring, to the boxes themselves. Now when power to the left AC bus is lost(as would happen when the #1 engine fails or generator goes offline), one or more things will happen. The Right 115 AC Bus will supply the entire aircraft through the now energized bus isolation relays, causing a high load condition. And all the electronics folks here know what that means: load shedding. The engine generator may be brought back online, or the APU may be started and its generator switched on to aleviate the load shed condition. But that would take some time. It's also worth noting that the FDR will work off of DC power, but only when all AC is lost and when the aircraft is in the air(through the air/ground relays).

One idea we considered before is that ingestion of debris from flying at low altitude could have upset power generation. AA 77 possibly ingested bits of metal from the VHP radio tower (this I doubt) but almost surely swallowed the top of a tree (for this there are clear pictures, unless there was some crazed gardener running around the Pentagon).

I had assumed the FDR ran off the emergency power bus. Maybe that's not true. If the above is accurate, then it suggests the FDR cuts out relatively quickly -- and it may do so in order to protect its data. So perhaps the relatively minor issues above, not enough to stop or even cause significant damage the airplane, kicked the FDR offline?

Lots of possibilities...

ETA: Do we have FDR data from a birdstrike available for comparison? She was definitely flying low enough to swallow a pigeon or even a goose, in addition to the solid objects above. Also, recall that in the extremely low-quality parking lot photo of AA 77, there appears to be a smoke trail, which would be further evidence for damaging ingestion of debris.

 

[apathoid]

One idea we considered before is that ingestion of debris from flying at low altitude could have upset power generation. AA 77 possibly ingested bits of metal from the VHP radio tower (this I doubt) but almost surely swallowed the top of a tree (for this there are clear pictures, unless there was some crazed gardener running around the Pentagon).

It also definitely swallowed a light pole, but I'm pretty sure that event happened much closer than 4-6 seconds away....maybe 2-3.

I had assumed the FDR ran off the emergency power bus. Maybe that's not true. If the above is accurate, then it suggests the FDR cuts out relatively quickly -- and it may do so in order to protect its data. So perhaps the relatively minor issues above, not enough to stop or even cause significant damage the airplane, kicked the FDR offline?

Lots of possibilities...

I would need a schematic to be 100% certain, but I'm fairly sure the standard AC Bus is the primary power source for the FDAU/FDR on the 757. Like I said in the other post, the system can be run off of 28VDC which would provide power if AC is lost. That does allow it to operate off of Standby Power(Emergency Power on MDC aircraft). But the power switching isn't seemless on older Boeings(767-400 and 777 notwithstanding), so if the airplane lost #1 - at the very least, the FDR would reboot and run off of DC because of the interruption. Then as the engine is restarted, it would switch back and reboot again, etc.

So it is a possibility that AA77 ingested something as it neared the Pentagon and the FDR was in the process or a power switching and reboot, but I think we would need more evidence for this theory.

ETA: Do we have FDR data from a birdstrike available for comparison? She was definitely flying low enough to swallow a pigeon or even a goose, in addition to the solid objects above. Also, recall that in the extremely low-quality parking lot photo of AA 77, there appears to be a smoke trail, which would be further evidence for damaging ingestion of debris.

Well I read more of that NTSB document on Flight 1400 as well as other news articles and it would seem that the Left engine shutdown and first FDR powerdown happened probably within 1 minute each other, but after the first reboot, it did it again shorthly after. I'll look for some birdstrike examples, but a birdstrike that causes an engine shutdown are fairly rare I would think.

 

[R.Mackey]

So it is a possibility that AA77 ingested something as it neared the Pentagon and the FDR was in the process or a power switching and reboot, but I think we would need more evidence for this theory.

Well I read more of that NTSB document on Flight 1400 as well as other news articles and it would seem that the Left engine shutdown and first FDR powerdown happened probably within 1 minute each other, but after the first reboot, it did it again shorthly after. I'll look for some birdstrike examples, but a birdstrike that causes an engine shutdown are fairly rare I would think.

Wouldn't need to be one bad enough to shut down the engine, just enough to cause a significant spike on the power bus.

I agree we would need a lot more evidence before this hypothesis graduates to "theory," but it would explain AA 77 and AA 587's behavior, maybe others.

 

[wstutt]

Warren, the crux of the matter is that there seems to be no more data after about 4-6 seconds prior to impact.
One suggestion was that the erase command had been re-instituted for the frame being written to. Your work suggests that this did not occur.
As I said that was one suggestion, although PfT seems to ignore that and assume that it is the only way data could be lost.

I believe PfT's position is that no data was lost since the last data in the NTSB .CSV file has a time of 9:37:44 and one of the NTSB reports gives an impact time of 9:37:45. That leaves them in the position of refuting any claims and explanations of lost data. If I am wrong, anyone reading this can feel free to reply or PM me through either this or the Pft forums or send an email to me at [email protected].

It still leaves us with missing data. The data must, IIRC, be stored in a buffer prior to being written to flash, and the poster Turbofan has said that the system writes a full frame at a time to flash memory. Data still in the buffer could certainly be lost on impact.

I don't believe full frames are written all at once to the flash memory, but word by word as the individual words in the frame become available. See post #85 on this thread. Does anyone have any documentation for the FDR on how much data resides in buffers before it is written to the flash EEPROMs?

Also , does the incorrect Hamming code give any clue as to what caused the data for the last few seconds of flight to not be recorded

The Hamming code and page parity is only designed to check if data was corrupted after it was recorded in the flash memory. Unfortuantely, if for some reason, some data was not recorded, the Hamming code and page parity will not tell you that nor tell you why.

Warren.

 

[BCR]

I believe PfT's position is that no data was lost since the last data in the NTSB .CSV file has a time of 9:37:44 and one of the NTSB reports gives an impact time of 9:37:45.

Too bad the evidence is clearly to the contrary. At 9:37:45, the plane was still in the air according to DCA TRACON radar data. The RO2 position data also corresponds to all of the radar (RADES and FAA) positional data clearly demonstrating that the SSFDR stopped recording at a point west of the Sheraton Hotel. All video evidence (Citgo and Doubletree) when correlated to other airborne craft (helicopters), confirm the time gap between the RO2 and CSV files.

There is 4-6 seconds of missing data and that should not even be a matter of debate anymore. So the question is why the data gap in the record?