• Security incident: ISF was recently accessed by intruders. Please change your password, and change it anywhere else you used it. Read more

AA77 FDR Data, Explained

I am unaware of any claim you've made that is correct. I am quite certain that none of them have been properly supported.

Oh really?

500 msec, no delay, or "old data in buffer" in the system. I corrected you and others on the
transmit and storage time to CPM. These facts are supported and have
been echoed by Ed Satana of L3 Comm., and EUROCAE specs.

I had to point Beachnut to the NTSB released data to prove x.7 exists and
works. I've also linked him directly to MFG sites to show the accuracy of
the DME receiver to be +/- 0.1 nm making his claim about the position of
the aircraft false.

PFT has done an outstanding job of scaling the terrain and using correct
equations to solve flight paths unlike some squares and sticks.

My best guess about the NTSB report is that they didn't care.

My best guess is it never happened. I don't see how any professional
FDR analyst could miss, or let slide several thousand reset bits?

Not only would it be odd, it would stick out like a red headed step child.
Let me show you a small sample of what it would yield. This is half a frame
uncompressed:
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_
1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_1111_


Multiply that by two, and then repeat for any additional frame.
Pretty hard to miss huh? Maybe it's even inverted through some
sort of digital logic and could appear as zeros when read out!

Now, again, if you wish to respond further, your options are to present a better theory, or else let it go. We've seen the depth of your technical expertise, and collectively found it insufficient. No further discussion down that path is recommended.

Like I said before, this was just a little side discussion between you and I.
It has nothing to do with the data that the NTSB presented under FOIA.
I'm more than capable about discussing this topic. Equal to, or better
than those who can't understand certifications and specs. that is for sure.

You still have to deal with all of the other parameters, flight study and
obstacles. The FOIA released data for "AA77" still stands as suspect.
 
Originally Posted by Turbofan

Original news coverage banned from TV

That is a lie.

Then in response to Johnny you say:

retracted, omitted. Some shown once.

Well which one was it?

None of it was retracted, banned, or omitted. It is ALL available with a point and a click:

http://www.archive.org/details/sept_11_tv_archive

CBS, NBC, ABC, FOX, BBC, CNN ... the are all there. From September 11th at 8:30 am...on.
 
Yeah i'd be pretty concerned too if there were underscores in my Binary.
 
PFT has done an outstanding job of scaling the terrain and using correct
equations to solve flight paths unlike some squares and sticks.

While Balsamo's eyewitnesses all say AA77 hit the Pentagon. See my sig for the whole story.
 
Oh really?

500 msec, no delay, or "old data in buffer" in the system. I corrected you and others on the transmit and storage time to CPM. These facts are supported and have been echoed by Ed Satana of L3 Comm., and EUROCAE specs.

I had to point Beachnut to the NTSB released data to prove x.7 exists and
works. I've also linked him directly to MFG sites to show the accuracy of
the DME receiver to be +/- 0.1 nm making his claim about the position of
the aircraft false.
Please post that Eurocare spec in effect for Flight 77 first flight. Please show where the FDR had to conform to a spec created after 77 was built. BTW, the 500 ms has nothing to do with data missing.

There are no x.7 DME in the NTSB decode, only x.8. I explained in the error filled decode by p4t they have DME every second, the NTSB has it every 4 seconds but it is not updated every four seconds due to the resolution issue most likely.

What is the resolution DME is stored in the FDR? Turbofan, please give a number.

Please prove the DME equipment you posted was in 77. Show me.

Then explain why planes with the DME equipment of the time 77 was built only had 0.23 NM accuracy in the terminal area. But I have used your accuracy of 0.1 NM to prove you have no clue where 77 is but you ignore much more.

I have shown the 1.5 DME can be off with accuracy and resolution. When 77 is at 1.724 NM from DCA, that value can be stored as 1.5 DME. A grade school kid understands this, why does Turbofan ignore the fact Balsamo ignore rational ideas and pushes his lies.

77 is near the Blue Pin when the altitude is about 400 feet, with 6 seconds to go. Hani was making good at up to 90 feet per second down! Questions?

Turbofan has been doing pure talk, most likely posting for Balsamo, he sounds just like Balsamo, making up ideas and not backing them up.


Turbofan, you have no clue how accuracy and resolution work and you can’t use 1.5 DME as an absolute value after you give me a 0.1 NM accuracy and ignore the 0.25 resolution storage issue. Stop letting Balsamo read these posts and coach you to make stupid uniformed statements.

A RADAR fix confirms 77 was at or over 1.724 DME from DCA and 6 seconds from impact at :43. Got math?
1724DME6secondsToGo.jpg



Now you go back to 500msec to have a signal from any particular sensor go from that sensor, to the DFDAU, be compiled to its subframe and fill the buffer to a full frame (this is what you have stated in the past) at which point the frame is sent to the flash memory. However the data rate is 256 words per second meaning it will take at least one second for a frame to be inputted to the DFDAU before the DFDAU outputs it at the same rate to the flash memory.

No, that is totally incorrect. It will not take at least one second. If that
were true, the system would have constant delay and crash.

You still do not understand.

All you need to remember is MAX time for data to store itself into CPM is
500 msec from the sensor.

Not OK. It can't erase JUST the last few seconds. It must take out the
entire block as per design.
http://i286.photobucket.com/albums/ll116/tjkb/datarate1.jpg
datarate1.jpg

Explain this Turbofan. The time it takes to store one second of data, is one second. Must be an early system. I know the new FDR are faster and will have to have faster pipe lines but there is a reason for slower pipelines when 77 was first flown.

I know Balsamo can help you on heavy jets. Oops, no he has no experience in the left seat of heavy jets. Darn, no wonder he doesn’t know standard stuff like feet in a NM, frequency range of RADALT, math to do slant range before saying people have something wrong. The rest of p4t pilots have a very shallow understanding of 9/11 and flight systems to be signed up with the dumbest ideas on 9/11 group p4t. What a failure.
lol, p4t are good at bad math.

Letting Balsamo have his absolute position at 1.5 NM from DCA, a plane can hit the Pentagon. Ironically, Hani makes the biggest down stick input of the entire flight as the data ends. Witnesses saw 77 at 50 feet above the FOB, and other saw 77 just missing hitting the cars on the highway. 77 was seen hitting the lampposts. This alone proves p4t and Turbofan have no idea how to understand the FDR information in a real world. Of course p4t and Turbofan can’t explain why people saw 77 impact the Pentagon, they have to call them liars or government agents. How paranoid can you get, and is that anti-government stand due to being bad at math and physics or due to the ability to foster dumber than dirt ideas, analysis and fantasy.
 
Last edited:
Has anybody posted the part of the ED-55 spec that covers the <500ms sensor to CPM claim?
 
"PFT has done an outstanding job of scaling the terrain and using correct
equations to solve flight paths unlike some squares and sticks."

Is that a joke?
 
I take as much time as needed to get the facts. I don't sit behind a screen
and do research, I call manufacturers and research.
blah,,, blah ,,, blah


Still argueing with the incompetant, anonymous JREF members sitting behind their screens, rather than putting all that extensive research to good use by compiling a consise technical paper outlining how you and PfT arrive at the conclusion that the FDR data indicates a flight path that is grossly different than the one illustrated by the downed lamp posts and accepted as the flight path of AA77.
Rob Balsamo states that this is an extremly important issue even going so far as to look forward to the day of the extra-judicial executions of those deemed responsible for the faked attacks of 9/11/01, and of those who chose to cover up for them. I would think therefore, that getting the story out to the widest audience possible would be of the utmost importance to the PfT. However, they, and you, are insteda content to spin your wheels argueing on the internet because, according to you, its "fun".

,,,,, and you wonder why PfT does not get taken seriously? Go figure!:rolleyes:
 
Oh really?

500 msec, no delay, or "old data in buffer" in the system. I corrected you and others on the
transmit and storage time to CPM. These facts are supported and have
been echoed by Ed Satana of L3 Comm., and EUROCAE specs.

Does it take 1 second to collect and compile one frame of data or not?
Does the buffer collect and compile an entire 256 word frame before sending that frame to flash memory or not?
Is the data rate from buffer to memory 256 words per second or not?

PFT has done an outstanding job of scaling the terrain and using correct
equations to solve flight paths unlike some squares and sticks.

PfT did some arithmetic after drawing some pictures. There is no explanation as to how they decided on the radial lines they drew, other than that, "it looks like that is where we should put them".



My best guess is it never happened. I don't see how any professional
FDR analyst could miss, or let slide several thousand reset bits?

Once again you seem to willfully ignore some of what has been stated about flash memory erasure and what oddities transients would introduce to it.
If you search back not that far you will discover that such an erasure error might well not reset the entire block and that it might not even cause a reset to consecutive gates resulting in some data being corrupted but not reset to all 1's.

Furthermore, given that an proper block erase would indeed reset an entire block and that in any crash this would mean that it is likely that the memory locations in the same block as the last new data would be all 1's. This would therefore be a very UNNOTABLE condition for the NTSB now wouldn't it?

To illustrate, in a crash for which the FDR records everything up to final power down;
-FDR running smoothly and an erase command resets enough memory for 40 seconds of data
-plane crashes 15 seconds after the FDR starts writing to that reset block
-the NTSB download the data from the memory and it contains a block of all 1's , after the last recorded data, that would be large enough to store 25 seconds worth of data.
 
Last edited:
Does it take 1 second to collect and compile one frame of data or not?
Does the buffer collect and compile an entire 256 word frame before sending that frame to flash memory or not?
Is the data rate from buffer to memory 256 words per second or not?



PfT did some arithmetic after drawing some pictures. There is no explanation as to how they decided on the radial lines they drew, other than that, "it looks like that is where we should put them".





Once again you seem to willfully ignore some of what has been stated about flash memory erasure and what oddities transients would introduce to it.
If you search back not that far you will discover that such an erasure error might well not reset the entire block and that it might not even cause a reset to consecutive gates resulting in some data being corrupted but not reset to all 1's.

Furthermore, given that an proper block erase would indeed reset an entire block and that in any crash this would mean that it is likely that the memory locations in the same block as the last new data would be all 1's. This would therefore be a very UNNOTABLE condition for the NTSB now wouldn't it?
but but but, that goes against the design :rolleyes:
It can't erase JUST the last few seconds. It must take out the entire block as per design.
Seriously, is TF that dumb or is he playing games? Note, I don't think that is necessarily an either/or question.
 
Let's recap then using what various posters have stated including TF

- Devices on the aircraft produce signals and place them at their o/p
- The DFDAU polls thise devices one at a time
- The DFDAU polls some of those devices more than once per frame
- The DFDAU compiles this data into a 256 word frame
- Once a full frame is compiled it is sent onto the protected flash memory in write blocks of (for the sake of arguement) 32 words each at a rate of 256 words/second
- The memory controller anticipated the requirement for reset locations in the flash memory and ahead of the write commands it reset a large block of memory, approx 40 times larger than an FDR 256 word frame.

The erase operation takes up to several seconds to complete but this does not matter since it resets a block that will take about 40 seconds to refil.
Given that it would be co-incidental for data recorded to the FDR to end at the last location in an erase block the NTSB in all likelihood always sees many words containing al 1's beyond the end of flight data.( in fact there will have to be a large number of all 1's beyond the last recorded data as the memory controller will have made sure that the write operation does not catch up to the erased blocks. The block erase command will begin resetting another block sometime between the initial writing to a newly reset block and the system writing to the last locations in that block.)

The erase command would go to specific addresses, the next addresses to be erased would differ, in binary number, incrementally from those just reset. We do not know when the flash controller updates the addresses to be erased next.

One example of how data gets lost/corrupted is:
If that block address is still present and an erase command is implemented by a transient it will go to the same block that was last reset.
However in a wildly non-standard condition the erase signal to the gates is not likely to be spot on within tolerance or present long enough to reset all gates. Some gates will be more susceptible to being reset than others. It depends on how often they have been flipped during their lifetime. (Eventually a gate will be stuck at one level due to build up of charge over time). Thus the data recorded in that block is corrupted, some words being reset to all 1's while others simply being corrupted by having some bits reset to 1
However, the data locations beyond the last recorded data, to the last location within that erase block will already be at a 1 state, thus all 1's in a large part of that block.

Clear now?
 
Last edited:
There are 2 things I'm waiting to see. First is the part of the ED-55 spec that specifies that the time from sensor to CPM has to be <500ms. Second, where does it say that the raw file is a memory dumb of the entire contents of the CPM. Isn't the raw file in time-stamp order covering just the 25 hours?
 
Can you read English? Are you on medication? I already posted a portion
of the ARINC document which states the data rate at 64 words per second!

Here it is again!

911_FDR_data_rate.jpg


Look at this JREF, Beachnut cannot even come to terms with black and white
FACTS! :D
You blindly posted 64 words per second! Like now you were wrong.
Turbofan, in the past you were off by a factor of 4 and I tried to talk you back to reality. It finally worked.

Your current error; not understanding the FDR, the accuracy of DME, and the DME resolution stored in the FDR. People try to help you but you insist on using Balsamo inputs of bad math, bad physics, and dumb conclusions.
 
I wonder if TF would post "Attachment 10-4" which I assume illustrates Harvard Bi-phase modulation.
That does not sound like a stream of 1's and 0's. It sounds like a signal that is capable of transmitiing the intelligence of 4 streams of digital data at once. I am familiar with quadrature amplitude modulation (QAM, is how digital TV on cable and most cable internet is transmitted)which seems is similar.

It would require that the FDR have a demodulator to change this into a stream of electronic high and low voltages. this would require that either the flash memory have 4 input streams (unlikely) or that there is a controller that arranges the data in a single serial stream.

If the DFDAU has a four lane info highway leaving it and the flash memory has a single lane entering it then there has to be a cop on duty telling when the data in each of the four lanes should merge.

Have we gone through that yet?

I said
- Once a full frame is compiled it is sent onto the protected flash memory in write blocks of (for the sake of arguement) 32 words each at a rate of 256 words/second

But if the data is in 4 streams then the 32 word write blocks are compiled by the memory controller out of the 256 word/second four lane info highway.
 
Last edited:
Why do I get the feeling that TF will now be telling us that the NTSB did not notice that the last valid data is at the back end of an erase block.

as if that would be;
a ) useful information that the NTSB would even care about
b ) something that would be easily determined in the first place

As for the DME, I just checked for myself on Google earth and if the VOR/DME site is where I see the building that looks very much like a VOR/DME site to me a 1.5 NM arc would easily put the aircraft over Columbia Pike in front of the Navy Annex, and 2600 feet from the Pentagon (about 3.5 seconds at 740 f/s max)
where's the beef again?
 
Last edited:
Why do I get the feeling that TF will now be telling us that the NTSB did not notice that the last valid data is at the back end of an erase block.

as if that would be;
a ) useful information that the NTSB would even care about
b ) something that would be easily determined in the first place

Don't get that feeling, because I'm not going to pay much attention as it
does not effect the FOIA presented data alleged to be from AA77.

You guys have your theories about what might have happened to this
missing data, and it's 1/10000000000 that everything seems to go just
they way you need it in order to make your theories work. Everything
has to be maxed to the extreme and out of tolerance on 9/11 just like
fire and column # 79.

I'll post up the Harvard Bi-phase modulation as you requested when I get
home this weekend.
 
Don't get that feeling, because I'm not going to pay much attention as it
does not effect the FOIA presented data alleged to be from AA77.

My bad then. I had thought that since you were so perplexed at why the NTSB had not noted all the 1's after the last valid data that you might also be perplexed that they did not note where the data was located wrt to erase blocks.

You guys have your theories about what might have happened to this
missing data, and it's 1/10000000000 that everything seems to go just
they way you need it in order to make your theories work.

Well we did have an accepted expert on flasj memory state unequivocably that there are multiple ways for flash to lose data. Your problem is that because a few were given you therefore assume that we are stating that it had to lose or corrupt data exactly in that fashion. Fact is of course we do not know the exact fashion by which this particular flash lost/corrupted data. The very FACT that data can be lost/corrupted in flash, and in other examples, FDR's specifically, indicates beyond any reasonable doubt that it occured the the FDR in AA77.

Everything has to be maxed to the extreme and out of tolerance on 9/11 just like
fire and column # 79.

As I said, I use Google Earth and 1.5NM from the DME puts the a/c in front of the Navy Annex, 2600+ feet (3.5 to 4 seconds away) from the Pentagon.

I'll post up the Harvard Bi-phase modulation as you requested when I get
home this weekend.

Good, while you're at it how does the FDR demodulate it to a simple serial stream for the write function of the flash?
 
big smoking gun 500 ms junk; makes 77 FDR invincible,. This is it?

Don't get that feeling, because I'm not going to pay much attention as it
does not effect the FOIA presented data alleged to be from AA77.

You guys have your theories about what might have happened to this
missing data, and it's 1/10000000000 that everything seems to go just
they way you need it in order to make your theories work. Everything
has to be maxed to the extreme and out of tolerance on 9/11 just like
fire and column # 79.

I'll post up the Harvard Bi-phase modulation as you requested when I get
home this weekend.
11. Recording shall commence in the crash protected memory within 250 milliseconds for audio and 500 milliseconds for flight data after power is applied and the start criteria are satisfied. After power interruptions greater than 5 minutes, up to 10 seconds are allowed for flight data sensor initialization and calibration.
This is the standard for normal operations, but it does not say what happens in a crash at 535 mph into a hard concrete building. Not a thing about what happen on 9/11. This standard was set in 1996 for US carriers. When was 77's first flight?


This is not helping missing data! If no FDR could have missing data, we would not have examples of missing data.


... funny; After Turbofan posted this ED55 stuff, he posts a requirement from 2003! He post a spec from 2003, 2 years too late for FDRs made after 77 crashes.
"3.3 Continuity of Recording – the loss of information shall not exceed 200 milliseconds per event and the cumulative loss shall not exceed 500 milliseconds per hour. It is accepted that power interruption may affect the simple retrieval of whole subframes of data due to loss of synchronisation. (as defined in ED112 paragraph II-3.2.1)"

Oops, from ED-112, Minimum Operational Performance
Specification for Crash Protected Airborne Recorder Systems, dated March 2003.
 
Last edited:

ISF - Join now!

Every member here is approved by hand. No bots, no spam, just people who care about evidence and honest debate.

Membership is free!

Create your free account

Back
Top Bottom