AA77 FDR Data, Explained

[beachnut]

The EGT is at the limit, now I have look up the darn engine again. 800 is okay in the engines I looked up years ago when I first saw the EGT at 800, 710 was our engine is going blow captain in the J-57! But operational EGT was lower. The GE engines can take 800 for some time; the probe must be closer to the core of the engine or GE found some super stuff.

But I found it interesting the EGT was climbing and the RPM is falling as 77 accelerates and I confirmed the throttle angles are full forward since push up.

Found the overspeed bit; it was set for 21 seconds in the FDR column MF. That is ironic. Flight 77. Just as the airspeed shows

 

[apathoid]

Not blown, stalled. Holy cow are those high EGTs.

You'd lose N1 just because of crap efficiency. High EGT means either a fire or (more likely) high inlet temperature, which means less air mass through the core and therefore less thrust and less cooling. Couple that with the high speeds and you are begging for compressor stall.

At those temperatures the engine's control laws would probably try to compensate by running rich, blowing excess fuel to cool off the core, and that could also create a smoke trail. Of course, I don't know exactly how that particular aircraft behaves, so it might not -- you can also cool EGT by leaning out the mixture, but that's a bit more dangerous.

But is this enough to cause havoc on the power bus? Could be...

The fan speed rollback coupled with increased EGT is interesting, especially considering the throttle position remained constant. On a typical GE or PW, there are only a couple of throttle settings where the relationships are inverse(bleed shift/flight to ground idle). Not normal at all otherwise IMO. You're spot on about the control settings. I believe that these motors are fly-by-wire and computer controlled. Even though you may exceed normal operational parameters, the Electronic Engine Control will sequence variable stators and and schedule fuel and air accordingly.

 

[Myriad]

I haven't got any further with decompressing the .FDR file yet to see if any extra data is there or not.

It's interesting that you used the word encryption. Some papers I have read expressed the opinion that data encoded with Huffman coding is as good as encrypted, however I don't think this was the intention of the FDR manufacturer. I'm sure their goal was to compress the data without loss.

Reading the replies here has led me to review some information I previously downloaded, and this has given me some ideas of some new approaches to attempt to decompress the .FDR file. It's still going to require quite a bit of time and effort though. I'll let you know if and when I'm successful.

Unless I'm missing something, in Huffman coding each character in the plaintext is fully represented by some number of contiguous bits in the code, and a given character is always represented by the same string of bits. (There are modified versions where the latter would not be true, but it's unlikely that those would be used in this application as it would prevent any data from being read in the event of recovery of only fragmentary data. Also, given the nature of the data being compressed, the frequency distribution of characters isn't likely to change much over time.)

Those would be fatal flaws in any true encryption system. The compressed data basically amounts to a substitution cypher, with only the added complexity of having a variable number of bits in the cyphertext per plaintext character. (The complexity in Huffman coding is all in arriving at the most efficient mapping of characters to bit strings, but we don't care about that, only about what the mapping actually is in this case.)

As a cypher, it should be vulnerable to the same sorts of frequency analysis that other cyphers are vulnerable to. Especially since you also have a large sample of the decoded data to work with, and you can make educated guesses which characters are most common (e.g. digits 0 and 1, separator characters, digits 2-9, etc.) and would therefore have the shorter bit strings.
Of course, it's still a lot of work (and would be a tremendous achievement) to actually solve the thing.

Respectfully,
Myriad

 

[BCR]

It's interesting that you used the word encryption. Some papers I have read expressed the opinion that data encoded with Huffman coding is as good as encrypted, however I don't think this was the intention of the FDR manufacturer. I'm sure their goal was to compress the data without loss.

You are correct; the proper term would be compression. I use encryption only in the sense of its effect and the obvious absence of the 'key'. When we communicated last year on this subject, I found a number of papers on the subject. The NTSB calls the compression a 'modified Hoffman' encoding, but like you, I assume they are referring to the Huffman algorithm. Use of the term 'modified' leads me to believe that the manufacturer most likely used a custom 'key' suited for the data types recorded (not much use for the alpha characters).

There is no doubt in my mind that the 'key' can be reverse engineered if enough of the known uncompressed values can be compared with the compressed ones. A rather time-consuming task to say the least and one I abandoned for lack of patience

 

[ktesibios]

Not blown, stalled. Holy cow are those high EGTs.

You'd lose N1 just because of crap efficiency. High EGT means either a fire or (more likely) high inlet temperature, which means less air mass through the core and therefore less thrust and less cooling. Couple that with the high speeds and you are begging for compressor stall.

At those temperatures the engine's control laws would probably try to compensate by running rich, blowing excess fuel to cool off the core, and that could also create a smoke trail. Of course, I don't know exactly how that particular aircraft behaves, so it might not -- you can also cool EGT by leaning out the mixture, but that's a bit more dangerous.

But is this enough to cause havoc on the power bus? Could be...

I wonder how much havoc would be required to cause a reset. In this case I'm thinking of a microprocessor-controlled machine I worked on that would intermittently reboot spontaneously while just sitting there powered up. The immediate cause was the power-on-reset circuit generating reset pulses at the wrong time. Replacing the reset generator IC didn't solve the problem.

It turned out that where POC circuits are commonly implemented with a one-shot or an RC network and a couple of gates, this machine used a dedicated reset generator IC that was intended as part of a power monitoring system. These chips are very jumpy and are made that way on purpose- since a CPU attempting to run off a sagging power rail can go bat@#$% in remarkably weird ways, if the power rail went out of tolerance for even a microsecond, the reset chip would trip.

The +5V rail looked clean on a scope, but replacing the voltage regulator which supplied it cleared up the problem. The reset generator was being triggered by noise I couldn't even detect on the rail.

If the FDR had a similarly paranoid power monitoring and reset system, a relatively minor glitch on the power buss might cause a restart and a loss of data for however long it took the system to initialize.

 

[ElMondoHummus]

At those temperatures the engine's control laws would probably try to compensate by running rich, blowing excess fuel to cool off the core, and that could also create a smoke trail.

This is a slight derail, but might this be applicable to the reports of a smoke trail from Flight 93? Did someone take a peek at that flight's FDR data and see if there was similar firewalling of the engines at low altitude? Granted, AA77 flew a longer path over a shorter altitude (IIRC), but it's still a question that sticks in my mind.

Think I'll see what's available on the UA93 FDR data. I've only seen the summaries.

 

[Norseman]

When I scanned through the AA77 FDR file earlier today to look up the engine data beachnut posted, I happened to notice that the last recorded value for the MAIN CARGO DOOR was OPEN. That struck me ass odd since the aircraft still had a few seconds left in the air. After scanning through the file I found that several indicators changed status at 09:37:44 when the last sample was recorded:

• MAIN CARGO DOOR - recorded as CLOSED for the whole flight -but last value recorded was OPEN
• FWD ACCESS DR - recorded as CLOSED for the whole flight - last value recorded was OPEN.
• TCAS FAILURE - recorded as OK for the whole flight - last recorded vaule is FAILURE.
• TCAS SYSTEM STATUS - recorded as OK for the whole flight - last recorded value was FAILURE.
• EICAS COMPUTER - recorded as OPER for the whole flight - last recorded value was INOP.

I assume this could be indicators of a power failure/disturbance if the values are correctly recorded.

ETA
A clarification to avoid misunderstandings. Regarding the doors I was not thinking that they were physically open, but just speculating that the onset of a power failure or power spike could have caused a misreading to be sent to the FDR. For another possible explanation see beachnut's reply below.

 

[beachnut]

This is a slight derail, but might this be applicable to the reports of a smoke trail from Flight 93? Did someone take a peek at that flight's FDR data and see if there was similar firewalling of the engines at low altitude? Granted, AA77 flew a longer path over a shorter altitude (IIRC), but it's still a question that sticks in my mind.

Think I'll see what's available on the UA93 FDR data. I've only seen the summaries.

Quick glance at the FDR and the terrorist pushed up the throttles at the end; but in the last 30 seconds they pulled them back below cruise setting. I used fuel flow. It takes time to find the different columns and I never write it down. Crap!

 

[ElMondoHummus]

When I scanned through the AA77 FDR file earlier today to look up the engine data beachnut posted, I happened to notice that the last recorded value for the MAIN CARGO DOOR was OPEN. That struck me ass odd since the aircraft still had a few seconds left in the air. After scanning through the file I found that several indicators changed status at 09:37:44 when the last sample was recorded:

• MAIN CARGO DOOR - recorded as CLOSED for the whole flight -but last value recorded was OPEN
• FWD ACCESS DR - recorded as CLOSED for the whole flight - last value recorded was OPEN.
• TCAS FAILURE - recorded as OK for the whole flight - last recorded vaule is FAILURE.
• TCAS SYSTEM STATUS - recorded as OK for the whole flight - last recorded value was FAILURE.
• EICAS COMPUTER - recorded as OPER for the whole flight - last recorded value was INOP.

I assume this could be indicators of a power failure/disturbance if the values are correctly recorded.

Uh oh... you realize this opens to door to - who stated it? A-train? - the ridiculous fantasy of Israeli commandos having been the real hijackers, and steering the jet towards its final destination, then parachuting out the bottom.

Yes. That was the proposal. One of the other posters here even had an excerpt of his lunacy as his sig, to highlight the lunacy.

 

[Norseman]

At those temperatures the engine's control laws would probably try to compensate by running rich, blowing excess fuel to cool off the core, and that could also create a smoke trail.

Could this be why the engine fuel flow (ENG FUEL FLOW) continue to increase even though the RPM decreases a bit? The last values are 19 360 lbs/hr and 18656 lbs/hr.

 

[beachnut]

When I scanned through the AA77 FDR file earlier today to look up the engine data beachnut posted, I happened to notice that the last recorded value for the MAIN CARGO DOOR was OPEN. That struck me ass odd since the aircraft still had a few seconds left in the air. After scanning through the file I found that several indicators changed status at 09:37:44 when the last sample was recorded:

• MAIN CARGO DOOR - recorded as CLOSED for the whole flight -but last value recorded was OPEN
• FWD ACCESS DR - recorded as CLOSED for the whole flight - last value recorded was OPEN.
• TCAS FAILURE - recorded as OK for the whole flight - last recorded vaule is FAILURE.
• TCAS SYSTEM STATUS - recorded as OK for the whole flight - last recorded value was FAILURE.
• EICAS COMPUTER - recorded as OPER for the whole flight - last recorded value was INOP.

I assume this could be indicators of a power failure/disturbance if the values are correctly recorded.

Just some BS but it happens. The doors could be having problems due to pressure at high Q; the pressure due to thick air at low altitude and high speed. The kids flying the T-38 were letting down at close to MACH1 and when they got low the air ripped off the T-38 gear door.

A fellow KC-135 pilot was speeding to catch me; I was flying the MAX speed Vmo, and he caught me but his KC-135 had skin de-lamination under the leading edge of the wing.

 

[jaydeehess]

When I scanned through the AA77 FDR file earlier today to look up the engine data beachnut posted, I happened to notice that the last recorded value for the MAIN CARGO DOOR was OPEN. That struck me ass odd since the aircraft still had a few seconds left in the air. After scanning through the file I found that several indicators changed status at 09:37:44 when the last sample was recorded:

• MAIN CARGO DOOR - recorded as CLOSED for the whole flight -but last value recorded was OPEN
• FWD ACCESS DR - recorded as CLOSED for the whole flight - last value recorded was OPEN.
• TCAS FAILURE - recorded as OK for the whole flight - last recorded vaule is FAILURE.
• TCAS SYSTEM STATUS - recorded as OK for the whole flight - last recorded value was FAILURE.
• EICAS COMPUTER - recorded as OPER for the whole flight - last recorded value was INOP.

I assume this could be indicators of a power failure/disturbance if the values are correctly recorded.

I am just guessing here but the door indicators are probably physical switches. The standard would be for an enegized (Hi) as Door closed and de-energized(LO) as door open. This way if anything interferes with the switch , OR the power to the switch, it will indicate door open and have to be checked.
The TCAS and EICAS computer indicators also would likely be on a normally open(de-energized) contact closure which would close(energize) when the system is powered and operable. Remove power from the door switches and the TCAS and EICAS and it generates an alarm condition. This fail-safe arrangement is how everything was used in the ground based Nav-Aids systems I worked on in the past.

It would then bolster the idea that a cct (or ccts)was unpowered at that time.

Now it seems to me that PfT has complained many times that one simply cannot fly a large aircraft like this at such low altitude and high speed because it will damage the aircraft(like a person bent on slamming it into a building would actually care if he dinged it up a bit before he got there). These findings now suggest that Hani was indeed paying little heed to the fact that the aircraft he was piloting was operating in a manner that is highly unreccommened by the manufacturer.

Our bad I suppose for taking PfT at their word that the FDR shows an aircraft in pristine condition right up to the last records on the FDR.

The senario is now that at 4 to 6 seconds from impact the stresses on the aircraft due to bad engine management and operations well outside normal caused power interruption(s) to the FDR and other systems on the a/c resulting in a reset of the FDR and perhaps loss of data in the buffer and that either power was never restored or a reset was not complete before the aircraft was torn apart as it impacted the Pentagon.

Maybe when Pft lets L3 Communications, ICAO and the pilot's unions know that the FDR failed to record the last several seconds of the flight they can include this as a possible reason why it occured.

 

[wstutt]

<snip>

I should have been more clear, my apologies. I meant before the Huffman decode, i.e. I thought you were strictly looking at decoded parameters rather than raw bits. Obviously you can't access data before being encoded and put onto the FDR in the first place.

I now think I understand what you were asking in post #3692. At this point, I don't know the Huffman codes or bit strings so I can still only look at the raw bits in the .FDR file. Does that answer your question?

<snip>

Understand, and it's appreciated.

Thank you.

Whatever the data says, we should try to figure out.

I agree.

Warren.

 

[apathoid]

I am just guessing here but the door indicators are probably physical switches. The standard would be for an enegized (Hi) as Door closed and de-energized(LO) as door open. This way if anything interferes with the switch , OR the power to the switch, it will indicate door open and have to be checked.

The TCAS and EICAS computer indicators also would likely be on a normally open(de-energized) contact closure which would close(energize) when the system is powered and operable. Remove power from the door switches and the TCAS and EICAS and it generates an alarm condition. This fail-safe arrangement is how everything was used in the ground based Nav-Aids systems I worked on in the past.

It would then bolster the idea that a cct (or ccts)was unpowered at that time.

The senario is now that at 4 to 6 seconds from impact the stresses on the aircraft due to bad engine management and operations well outside normal caused power interruption(s) to the FDR and other systems on the a/c resulting in a reset of the FDR and perhaps loss of data in the buffer and that either power was never restored or a reset was not complete before the aircraft was torn apart as it impacted the Pentagon.

(as to the bolded)
The door warning sensors are inductive pickup proximity sensors like this one. This switch is made/closed when a ferrous target is inside a specific distance. So that still supports our budding theory of the 4-6 seconds as all such sensor wiring gets routed to a box called PSEU(Proximity Switch Elex Unit), which won't work without power obviously. You'll probably find similar state changes in the leading edge slats and thrust reverser sleeves, which also use inductive prox switches. The TCAS and EICAS inputs to the FDAU are likely "power ok" type of discretes. Whether they are ground seeking or VDC seeking I'm not sure of. I'd guess the FDAU is looking for a ground and when power is lost, the FDAU sees an open and the state would change from "OK" to "FAIL".

I'd say this looks like a fairly solid theory now. Of course, Sunstrand, or whoever makes the engine integrated drive generators would likely disagree, so might Rolls Royce...but the evidence is definately pointing at the engine.

 

[R.Mackey]

I now think I understand what you were asking in post #3692. At this point, I don't know the Huffman codes or bit strings so I can still only look at the raw bits in the .FDR file. Does that answer your question?

Yup, I read you now.

While it's still possible the .FDR file you have isn't a faithful reproduction of the FDR memory, for now there's no particular reason to think that it isn't. I'm comfortable assuming that it is an accurate copy until we find something that says otherwise.

I don't know how you can get the Huffman tables without going to the airlines direct. You could possibly reverse-engineer them from the .CSV, but it would be painful!

 

[R.Mackey]

The senario is now that at 4 to 6 seconds from impact the stresses on the aircraft due to bad engine management and operations well outside normal caused power interruption(s) to the FDR and other systems on the a/c resulting in a reset of the FDR and perhaps loss of data in the buffer and that either power was never restored or a reset was not complete before the aircraft was torn apart as it impacted the Pentagon.

The TCAS and EICAS inputs to the FDAU are likely "power ok" type of discretes. Whether they are ground seeking or VDC seeking I'm not sure of. I'd guess the FDAU is looking for a ground and when power is lost, the FDAU sees an open and the state would change from "OK" to "FAIL".

I'd say this looks like a fairly solid theory now. Of course, Sunstrand, or whoever makes the engine integrated drive generators would likely disagree, so might Rolls Royce...but the evidence is definately pointing at the engine.

I concur. This is starting to get rather plausible, in my opinion:

• The aircraft is at extreme speed and low altitude, stressing the aircraft
• The terrorists have the throttles firewalled, hitting max EGT and losing power
• They further entered a mild PIO, around a moderate pull-up of roughly 1.5 to 2 g's
• They may have struck ground obstacles or birds further out than is known
• The combined aerodynamic and other stresses shake the exterior, either enough to fail door sensors or actually pop doors open
• The engines may also experience mild compressor stall at this time
• All of this combines to create a glitch on the power bus, either by upsetting the engines, popping cables, or arcing somewhere in the aircraft
• Power failure on the main bus is also indicated by failure of avionics such as TCAS, as reported on the last valid FDR frame
• As the FDR data appears to be fully valid and uncorrupted, we accept this final report as plausible evidence of power failures on the aircraft
• The suspected power failure kills repeaters or the DFDAU, either leaving them unpowered or forced into a recycle
• Data stops arriving at the FDR, approximately six seconds before impact
• The FDR writes two empty frame markers after the last packet is transcribed, and then goes silent

Anything else? Again, there are of course other possibilities, but the above seems pretty darn reasonable to me.

This is how you know this is science, and not pseudo-science. We may never prove the answer, but the more we work on it, the more we know.

 

[BCR]

Makes more sense than the "cuckoo flew over the cuckoo's nest" hypothesis.

 

[beachnut]

Last 30 second vertical acceleration.

Or one of the terrorists hit his head on the GEN CTR and turned off the GENs in a .3-G head-hit.


Norseman found this just marking in the data. See above.

9:37:40 Main Cargo Door -- Closed - the whole flight (col IZ on tab data NTSB)
9:37:44 Main Cargo Door -- OPEN - sampled at 4 seconds


9:37:40 FWD ACCESS DR -- Closed - the whole flight (col GG on tab data NTSB)
9:37:44 FWD ACCESS DR -- OPEN - sampled at 4 seconds

 

[BCR]

Well, I thought I would take another crack at obtaining the compression algorithm. I spent some time with L3 Communications tech support to see if I could glean a little insight into the compression algorithm. He did tell me that they did not make a Model F-2100, but did make a FA-2100.

Unfortunately, he really did not give me much insight beyond what I already know and was tight-lipped about the algorithm. He did however say that he could sell me a copy of the ROSE software which would uncompress the file for me. I just did not have $7,000 to spare today for a licensed copy

 

[jaydeehess]

(as to the bolded)
The door warning sensors are inductive pickup proximity sensors like this one. This switch is made/closed when a ferrous target is inside a specific distance. So that still supports our budding theory of the 4-6 seconds as all such sensor wiring gets routed to a box called PSEU(Proximity Switch Elex Unit), which won't work without power obviously. You'll probably find similar state changes in the leading edge slats and thrust reverser sleeves, which also use inductive prox switches. The TCAS and EICAS inputs to the FDAU are likely "power ok" type of discretes. Whether they are ground seeking or VDC seeking I'm not sure of. I'd guess the FDAU is looking for a ground and when power is lost, the FDAU sees an open and the state would change from "OK" to "FAIL".

I'd say this looks like a fairly solid theory now. Of course, Sunstrand, or whoever makes the engine integrated drive generators would likely disagree, so might Rolls Royce...but the evidence is definately pointing at the engine.

Eccellent, basically the same idea, it is a fail-safe system that generates a 'not ok' whether the system is actually 'not ok' or the sensor is 'not ok'. Either way it will be investigated by the crew. That is if the 'crew' is not bent on smashing the aircraft into tiny bits in the next few seconds.

In the electronic systems in my experience it is often still a physical relay contact closure since that eliminates having the sensor signal path having any electronic path to the system. If one uses an SCR or similar one does have a possible route for transients on the remote sensing path to enter the system being monitored via the SCR gate. But I have no experience with onboard systems, just ground based systems.