• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

AA77 FDR Data, Explained

I should have done a screen shot of CPT Bob's comments at P4T. This morning they seem to be gone.
 
<snip>

The coding at issue is created by the FDR, not the flight systems. Experience has taught me that when I come across a "00" or "FF" in a raw file, to look at the context because often these are used as default values (much like 0 or 1 can be in binary). In this case, the coding is used to properly extract the original serial bit stream by the software doing the extraction. I find it particularly interesting that the anomaly occurs during the final frames and in the context of having a file myself with a modified date/time before the FDR was actually recovered certainly raises the question in my mind of tampering by the NTSB.

That is purely speculation and I don't have one iota of evidence to back it up. But if I was a conspiracy minded person, it would certainly be within reason to conclude that the 'NWO' was playing games with people like CPT Bob and P4T. Open up the file, replace the code corrections with some 'default' value for the end of flight leading to erroneous CSV outputs, read-outs and 3D animations. Distribute it to the public knowing that some 'tin foil' hat individual will pick up on the irregularities and out of sheer ignorance come up with all kinds of crazy theories about planes flying over the Pentagon, etc.

Regarding FF (hex) being a default value, you are correct. This particular make and model of FDR records its data in flash memory. When blocks in the flash memory are erased, all the bits are set to 1, so if you read a byte that has not been written to since it was erased you will get FF (hex). This erase procedure is necessary since writing to the flash memory can only change bits from 1 to 0, not 0 to 1. The blocks are 64kb in size.

Regarding the possibility that the FDR file had had the last error correction codes erased, one thing I can say for certain, is that the FDR can not write the error correction codes for a page until it knows all of the data that will be in that page so that it can write the correct error correction codes.

Because the memory can only be erased in 64kb blocks and the pages are 128 bytes and bits set to 0 can not be set back to 1 except by erasing, then unlike normal computer memory, it only gets one shot to write the error correction code for that page. i.e. it can't continuously update the error correction code as more data is added to the page.

I have not found evidence in the FDR file one way or the other that the last error correction codes were erased. I do however have some other FDR files from other aircraft which probably didn't crash. I'll search through them for unrecorded error correcting codes. If I can find any, it could help shed some light on this.

<snip>

Again, great job Warren and I for one greatly appreciate your efforts.
Thanks again for your kind words.

Warren.
 
I should have done a screen shot of CPT Bob's comments at P4T. This morning they seem to be gone.
Curious.

I visited the thread without logging in (as a guest) and I could not see Rob's post that you referred to (#189). I then logged in and it appeared. Then I logged out which put me back in to guest mode and I could still see it! Try looking at it again.

Warren.
 
I should have done a screen shot of CPT Bob's comments at P4T. This morning they seem to be gone.

I saw that as well. Cap't Bob is playing with those posts. The few posts in question were definitely not there this morning and now some, if not all, are back up.
 
I saw that as well. Cap't Bob is playing with those posts. The few posts in question were definitely not there this morning and now some, if not all, are back up.

...
97.5/35 = 280% (G Load required to arrest 4480 fpm descent rate within 1.3 seconds and 97.5 feet vertically needs to be increased by 280%.)

280% x 4.0 G's = 11.2 G's needed to arrest descent. ...
Wow, is he as challenged in editing as he is in math. His 11.2g special moron math is still posted for over 2 years.

http://pilotsfor911truth.org/descent_rate031308.html

Balsamo fails at the FDR, Vg diarams, and math.
 
Last edited:
I saw that as well. Cap't Bob is playing with those posts. The few posts in question were definitely not there this morning and now some, if not all, are back up.


He's moved the whole thread from the "AA77" subforum to the "Debate" forum. This effectively hides any updates to that thread from the "Latest News" subforum.

A subtle form of censorship, in effect. I suspect, though, that most guests to that cesspit head straight for the "Debate" subforum in any case for the LOLs :).

I've captured the whole thread, just in case it disappears.
 
<snip>

I have not found evidence in the FDR file one way or the other that the last error correction codes were erased. I do however have some other FDR files from other aircraft which probably didn't crash. I'll search through them for unrecorded error correcting codes. If I can find any, it could help shed some light on this.

<snip>
I had a look through the 4 other FDR files that I have and one of them does have an incorrect Hamming Code and page parity.

However this particular file has 0's starting part way through a page and continuing through to the end of the file. This is about 29% of the file. My source said that he had several files with problems and that file was an example. Since he was working on an FOQA system, I would not expect that his FDR files came from aircraft crashes. I suggested to him that the software used to read the data from the FDRs wasn't working properly.

So, unfortunately, I don't think this particular FDR file gets us any further on answering your question about AAL77's FDR file, John. I'd be interested if you or anyone else finds any evidence either way though.

Warren.
 
So, unfortunately, I don't think this particular FDR file gets us any further on answering your question about AAL77's FDR file, John. I'd be interested if you or anyone else finds any evidence either way though.

Warren.

This is not one that will be solved Warren, although I know you will not give up on trying. I think you misunderstood my 'hypothetical'. That scenario involves taking the raw dump file (*.fdr), loading it on a computer, opening it just like you have, changing a few values, then saving it. The only thing that 'supports' that hypothesis is the conflicting file creation dates for versions of the file sent out by the NTSB.

You or I can neither 'prove' nor 'disprove' the 'hypothesis', so it is simply speculation. In other words, my little 'hypothesis' does not amount to a hill-of-beans in the real world (kinda like cuckoo-flew-over-the-cuckoo-nest 'hypothesis'). What matters is, you managed to find the problem and work around it to recover the data.

I make no secret that I personally am convinced that the NTSB data release was 'disinformation' designed to inspire some of the wacky stuff we have seen from groups like CIT and P4T. I said that back in 2007 and I remain convinced of it. It is a personal opinion based entirely on circumstantial evidence, NOT hard data. Discoverys such as yours only serve to reinforce that opinion. The oddity of the VDOT/VSP bent antenna, the 'missing' Sheraton, Navy Annex and Pentagon videos, all intentional diversions to inspire the conspiracy mongering in regards to AAL77. But again, I repeat that is purely conjecture and opinion on my part.

However, it begs the question that if the 'disinformation' is intended as a diversion, then a diversion from what? Darn if I know :)
 
This is not one that will be solved Warren, although I know you will not give up on trying. I think you misunderstood my 'hypothetical'. That scenario involves taking the raw dump file (*.fdr), loading it on a computer, opening it just like you have, changing a few values, then saving it. The only thing that 'supports' that hypothesis is the conflicting file creation dates for versions of the file sent out by the NTSB.

You or I can neither 'prove' nor 'disprove' the 'hypothesis', so it is simply speculation. In other words, my little 'hypothesis' does not amount to a hill-of-beans in the real world (kinda like cuckoo-flew-over-the-cuckoo-nest 'hypothesis'). What matters is, you managed to find the problem and work around it to recover the data.

I make no secret that I personally am convinced that the NTSB data release was 'disinformation' designed to inspire some of the wacky stuff we have seen from groups like CIT and P4T. I said that back in 2007 and I remain convinced of it. It is a personal opinion based entirely on circumstantial evidence, NOT hard data. Discoverys such as yours only serve to reinforce that opinion. The oddity of the VDOT/VSP bent antenna, the 'missing' Sheraton, Navy Annex and Pentagon videos, all intentional diversions to inspire the conspiracy mongering in regards to AAL77. But again, I repeat that is purely conjecture and opinion on my part.

However, it begs the question that if the 'disinformation' is intended as a diversion, then a diversion from what? Darn if I know :)

The NTSB data has to be disinformation, we know with computer programs and computer things they are perfect and never malfunction.

1bluescreendeath.jpg
 
However, it begs the question that if the 'disinformation' is intended as a diversion, then a diversion from what? Darn if I know


You have not shown that in fact there is any disinformation. Until you do that you are just building a strawman.
 
You have not shown that in fact there is any disinformation. Until you do that you are just building a strawman.
You must have missed these parts:

You or I can neither 'prove' nor 'disprove' the 'hypothesis', so it is simply speculation.
[...]

I make no secret that I personally am convinced that the NTSB data release was 'disinformation' designed to inspire some of the wacky stuff we have seen from groups like CIT and P4T. I said that back in 2007 and I remain convinced of it. It is a personal opinion based entirely on circumstantial evidence, NOT hard data.

I didn't.
 
Hey, I said it was personal opinion based on circumstantial evidence (speculation). Like I said, the most important thing is that we have the data now. If Beach and others want to believe the FDR just happened to stop recording the correction codes during the last two pages, then hey, their opinion is just about as good as mine. Neither has any hard evidence to back it up. Just speculation .... kinda like that wacky 'cuckoo flew over the cuckoo's nest' theory :)
 
I'm perfectly OK with you having that opinion. Personally, I'm pretty convinced of the accuracy of Warren's assessment that the error correcting codes (ECCs) must be written after writing the rest of the data, because you can only write zeros into the data, not ones, and since the ECCs have to cover the whole frame, it's not possible to update an ECC once written, so its writing has to be delayed until the frame is completed, because its value depends on every bit of the data. That's indeed how Flash memories and ECCs work, and I expect that any incompletely written block lacks the ECCs, and conversely, that any completely written one has them (except in the unlikely case of software error or hardware failure). But failure of the recording system is hard to find except in the case of plane crashes, so the one failure that Warren found is probably a different kind of error.

The only slightly puzzling matter is that there's two, and not one, frames lacking ECCs, but since we know so little about the way the recorder works, advancing manipulation as an explanation is putting the cart before the horse. I believe that it's easier to just recreate a modified ECC (as Warren easily did) to cover up the tampering; therefore, I conjecture that it's more likely that there is an explanation related to the way the recording works. A possible one, for example, is that ECCs are calculated in larger blocks which comprehend more than 1 frame, and saved all together. Maybe Warren can tell us what offset the first block starts at, to add some degree of confirmation to that hypothesis. My prediction is that if the ECCs are saved in pairs of frames at a minimum, then it's not possible that the first ECC-failing frame is in an odd-numbered frame position and the second is in an even-numbered one, because the first one has to begin at an even-numbered position always. There's an 1/2 chance that my prediction is met just by luck, so it's not a big confirmation anyway.

And the NTSB had to have a specification of the FDR data in order to tamper it, so they also had to have a specification of the ECCs.

Therefore, your explanation fails to me into the category of the "evil clumsy genius" that conspiracy theorists have us used to. I know I will probably fail to convince you otherwise, and that's just fine.
 
Last edited:
Therefore, your explanation fails to me into the category of the "evil clumsy genius" that conspiracy theorists have us used to. I know I will probably fail to convince you otherwise, and that's just fine.

Why? Warren did exactly what I have described to test his algorithm possibility on the ROSE software. Why is it that he is perfectly able to do it but someone else could not have? A very simple change if you know what you are doing.
 
Why? Warren did exactly what I have described to test his algorithm possibility on the ROSE software. Why is it that he is perfectly able to do it but someone else could not have? A very simple change if you know what you are doing.
My apologies. I misunderstood the problem. I thought that the failed ECCs were the last two frames. Now if I understand it correctly, the problem is in two frames near the end, not in the last two frames.

However, my argument stands, and you seem to not have understood it: Warren has easily produced the ECCs; the NTSB could have done the same if they tampered the file, and could have put the correct ECCs in place.

BTW, I have an idea for a couple possible explanations about the dates, involving an old DOS machine with a messed clock used somewhere in the process, or a messed date/time conversion from a possibly different filesystem. But I'd need to refresh my memory on the details of the issue with the dates. I seem to remember that the times were zeroed or something like that.
 
BTW, I have an idea for a couple possible explanations about the dates, involving an old DOS machine with a messed clock used somewhere in the process, or a messed date/time conversion from a possibly different filesystem. But I'd need to refresh my memory on the details of the issue with the dates. I seem to remember that the times were zeroed or something like that.

I think the official NTSB line was that when they heard the FDR had been located, they started a file on their computers in preparation for downloading it (or something like that).

Like I said, my 'speculation' cannot be proven one way or the other. The only real evidence is circumstantial at best. And of course you are assuming that the values were "FF" in the original dump. I like my idea better, they changed them to play games with folks like CPT Bob. I only bring the idea up because I know CPT Bob is reading this and my theory now has just as much to back it up as his does .... nothing.
 
I think the official NTSB line was that when they heard the FDR had been located, they started a file on their computers in preparation for downloading it (or something like that).

Like I said, my 'speculation' cannot be proven one way or the other. The only real evidence is circumstantial at best. And of course you are assuming that the values were "FF" in the original dump. I like my idea better, they changed them to play games with folks like CPT Bob. I only bring the idea up because I know CPT Bob is reading this and my theory now has just as much to back it up as his does .... nothing.

CPT, Special Moron Math, Bob offers no theory, he is dumber than a box of rocks. Your theory has Balsamo being tricked by the evil NTSB MIB, as they tamper with evidence in an FBI case. Risking their jobs and freedom to fight the jack-of-no-trades-Balsamo idiotic claims he claims he never makes. A much better theory than the nut case claims implied by Balsamo's idiotic delusions. 11.2g still posted, how can he be that bad in math?

Got to thank Warren, for finding the "missing seconds"; the ones Balsamo said never existed. Balsamo does not qualify to be a pet rock.
 
Last edited:
Balsamo is insane, or is this paranoia? At least he starts with a theory that is sound logically, then moves to delusional woo after he has to throw Warren under the bus for proving Balsamo is delusional.

If the FDR data is fake, it is a felony. Tampering with evidence.

If the FDR data is real, it is a felony, as it does not support the 9/11 Commission Report claims in many significant ways including that a standard 757, N644AA, impacted the Pentagon, for either the NTSB decode, or yours.

(Source; Pilots for truth forum were Balsamo, the truthNAZI[1], moved this topic to the Debate section because you can't post the truth in his mad pilot forum sections where delusions can't be questioned.)
Moron mind of Balsamo offers no theory[2] but exposes delusional logic responsible for 11.2g to 34g failed physics. Same logic, or failed thinking must be responsible for making fake Vg diagram.


1. Like the soup NAZI, "no truth for you!" http://en.wikipedia.org/wiki/The_Soup_Nazi
2. Balsamo, leader of failed pilots with nut cased ideas on 911, tag-line offering "no theory" on 911 - http://pilotsfor911truth.org/
 
Last edited:
The NTSB data has to be disinformation, we know with computer programs and computer things they are perfect and never malfunction.

[qimg]http://i286.photobucket.com/albums/ll116/tjkb/1bluescreendeath.jpg[/qimg]

Haven't seen one of them since I installed 7
 

Back
Top Bottom