New FDR Decode

reply to post by 767doctor


FFS, I didn't mean you as "you". I meant you as in "your company".

Nevertheless you did answer my question by in essence saying you don't give a f***.

I shall assume that is also your company's take on the question since you are their representative here.

Originally posted by JFrickenK
reply to post by 767doctor

 

FFS, I didn't mean you as "you". I meant you as in "your company".

Nevertheless you did answer my question by in essence saying you don't give a f***.

I shall assume that is also your company's take on the question since you are their representative here.

As I said, it's not my job to give a damn about what data frame layouts are needed for a particular ship number. It's someone else's job, and I'm sure they have a decent handle on it. My job concerns airworthiness, compliance, configuration control and quality control for non-RII mx.

If you have a better solution than the current one for decoding FDRs, I'm sure the airlines and the NTSB will be glad to hear it.

Originally posted by JFrickenK
reply to post by 767doctor

 

No, Rob is saying that the AoA angle displayed is based on that -15 degree figure.

I disagree because if that were the case there would be notes stating such in the generic Boeing DFL and there are none, and indeed the calibration units in the custom DFL are degrees.

I agree that we are looking at 'degrees' as the DFL would undoubtedly have corrected that sort of a glaring flaw by now. But we know the value doesn't represent AoA in the traditional sense - the angle between the wing chord line and direction of the slipstream - because:

- 16 degrees means the nose would be down significantly while traveling parallel to the horizon.
+ 16 degrees means the nose would be up significantly while traveling parallel to the horizon.

The angle of incidence is 6 degrees, so the nose would be up or down about 10 degrees relative to the airstream during what Rob calls "level AoA"(which I can only assume means when the plane is in level flight), which is one of the most stupifyingly retarded things he's ever said.

What we are looking at is most likely stall margin in degrees, which would basically be a pitch limit indication. Even though the stall warning computer computes "Pitch Limit Indication", the raw value coming from the AoA vane could very well be indexed where zero is a rough fix for the stall point, this angle being conditioned further by the SWC.

Calling such a parameter "indicated AoA" is little odd. But everything indicates that it is a margin to stall, as evidenced by a near 0 value being recorded just after wheels off and reaching the highest values in cruise. It's really the only explanation.

BTW, why do you keep referring to the _1 DFL as custom? The fact that it is from the 757-3B DFL means its not custom, by definition. There is an option for a 'Customer Unique Frame'; see D226A101-3G, Section 3.2.1 'Data Frame Selection'.

The 757-3B_1 DFL includes all the Pratt & Whitney specific parameters and HUD parameters. Odd considering that no AA 757's have HUDs and N644AA, being a legacy AA 757, was equipped with Rolls Royce powerplants.
Its a generic layout.



[edit on 10-1-2010 by 767doctor]

The released .TXT file is a custom DFL from American. The .PDF file is a generic DFL from Boeing.

They ARE different.

Of course you would know this had you ever gotten off your high horse and actually done any studying of them... Or read any of the documentation accompanying that FOIA release.

In any event thanks for confirming what I had suspected since I discovered that the majority of the FDR data for that field is negative....

That -16° represents a nose down condition.

reply to post by 767doctor


I guess you didn't realize the the next generation of FDR's will include their very own custom DFL's embedded within the data header.

Why it was not done that way from the start I haven't a clue.

Redacted

[edit on 14-1-2010 by JFrickenK]

Here is some info surrounding the latest discussion on Angle of Attack.

It contains some interesting info regarding how the 757 determines,
and measures AoA:

biggles-software.com...

biggles-software.com...

So in your opinion what would cause the FDR to register a negative AoA consistantly ?

reply to post by turbofan


turbofan, we'll make you an honorary pilot yet!!

Just a glance at the biggles link, good find.

Figure 11, that's the stuff familiar to me. Our normal attention paid to AoA is, as the discussion relates, only since the advent of the electronic ADI. Primarily for windsear encounters, and recovery techniques. Also, terrain avoidance maneuvers were starting to come into the syllabus in later years due to several CFIT accidents of note. This involves reacting to the GPWS when it triggers unexpectedly by applying full thrust, checking speed brakes are stowed, and pitching up into the stick shaker --- and when the PLI (we call them the 'yellow whiskers') is displayed (flaps not up, it's there all the time. Flaps up, it will appear as you near the stall angle) using it as a pitch reference. No configuration changes, and the pilot not flying calls out radio altitude, until clear (hopefully) of the terrain threat.

Note, please, as you look more and more at ADI displays, you will see two types of flight directors. The one you linked is called a "dual-cue" FD, and the other (looks like two triangular-shaped wedges to represent the wings) is a "single-cue". Just so you don't get confused. The choice of FD display is up to the customer, and factors into the fleet standardization needs of the various airlines. (i.e., crew training/familiarization and fleet compatibility in crew cross-training and currency requirements).



About the AoA data, and what is measured in various pitch attitudes, speeds, climbs, descents, etc, that will vary greatly, especially in the case of AA 77 and its exceedence of normal flight envelope regimes.

I wil ponder on it.

reply to post by JFrickenK


I have no definite idea at this time, and honestly haven't thought much
about it. After doing some reading on AoA, it's not as intuitive as many
people may believe.

My only guesses as to why the values are negative are:

- The reference point for the B757 may be measuring beyond the
centerline of the airframe

- The values are to be taken as absolute

- the FMU is storing those values as calculate maximum before triggering
the cockpit warning signals (not as likely)

I've given up on the data with respect to finding 'system errors'. As I
mentioned before, whether you believe this data is fake, or authentic
it wasn't typed by a human. It was taken from an aircraft, and/or flight
simulator and therefore I would not expect to see some glaring record
indicating foul play.

I'm more interested in things like:

- Why the time/date stamp does not agree with the official story

- Why the altimeter descending through 18,000 feet does not snap back,
yet the ascending values are corrected

- Why there are no signs of engine damage, pole strikes, origin of white smoke, etc.

reply to post by turbofan


tf, I can assure you of a few things:

It was taken from an aircraft...

Yes, exactly. As installed on the airframe known as "AA 77".

...and/or flight simulator...

No, that is completely incorrect. There is simply no way for an FDR to interface in the same way with a full-motion airliner simulator in the way you imply. It can work the other way, for purposes of demonstration however. Some (but not all) aspects of the data can be used, and interpreted in order to 'experience' the fatal flight, whether in a computerized simulation, or in the actual simulator itself. But, all of those hundreds and hundreds of minor (buy important) other recorded values??? The simulator computer software recreates those values, but only as an illusion to recreate the impression, and faithful reproduce as realisitically as possible, the actual pilot's experience.

I'm more interested in things like:

- Why the time/date stamp does not agree with the official story...

First I've heard of this issue with AA 77. You know that, absent the GPS updating that is more common today, the internal time onboard came only from the settings of the Captain's clock. IT provides the time reference for the ADC, and the FDR gets the time from the ADC.

Not everyone was particular about getting the clock set exactly to the second, especially for a Domestic leg. Some pilots might think "A few minutes off" was close enough, and not bother to re-set it, because it's a bit involved, the process. Not hard, with practice and familiarity, but at some companies it's a mindset thing --- like it's Maintenance's job.

Personally, I was a little more particular, and used the HF radios to tune in the Universal Time recordings (frequency 5,000, 10,000, 15,000 and 20,000 kHz) to set the clock, before we had the GPS installed on all of the airplanes.

- Why the altimeter descending through 18,000 feet does not snap back, yet the ascending values are corrected ...

I think I've told you before. It depends greatly on the actual rate of descent at the time, and how fast the Baro set knob is turned. Go flying to see for yourself.

- Why there are no signs of engine damage, pole strikes, origin of white smoke, etc.

"white smoke" (if it actually existed) could simply have been a severed fuel or hydraulic line. No signs of engine damage? I know you mean prior to impact with the Pentagon --- look at where the engines are mounted, and the locations of any obstacles that were struck (light poles, trees, etc).

That would be a good starting point to investigate - because if the strikes to the airframe occurred outboard of the engines' locations, then they would have not been affected at all.

Surely you've seen what Jet-A looks like when it's escaping into the airstream?



That, of course, was from the dump nozzle on the left wing, but any leak (unintentional) would appear similar, from different location.



[edit on 18 January 2010 by weedwhacker]

Originally posted by weedwhacker

No, that is completely incorrect. There is simply no way for an FDR to interface in the same way with a full-motion airliner simulator in the way you imply.

Hey WW, let me clarify this part of my post. I don't mean the FDR as a
physical device; I meant the flight data file may have been created using
a flight sim.

First I've heard of this issue with AA 77.

I may be confusing you. The time/date I'm referring to is the file creation
date of the .fdr file. The FOIA CD-ROM contains the information when
looking at the file details.

This file is created before the report of recovering the FDR in the Pentagon.

Very strange. Even more strange is this contradicts those who state there
was no need to investigate the crash because it was a 'suicide bomber'.

So...why the quick act to download the data?

More important, why does the file date lead the discovery date of the FDR in the building?

Just a few things here that really bother me (and others).

I think I've told you before. It depends greatly on the actual rate of descent at the time, and how fast the Baro set knob is turned. Go flying to see for yourself.

I agree, however the knob was turned and set approximately 18 minutes
before impact, yet there was no reflection of this calibration in the Pressure
Altimeter gauge (animation).

The common argument to this point is that the animation is a "working copy". If that's the case, then why was the ascending BARO correction
included, and not the descending?

The correction must be applied to the entire data set, not just a few
seconds worth. In other words, if you were to assign (approx. non-linear)
the following values to the BARO parameter, the Pressure Altitude in the
animation would have been more accurate:

Sea level to 5,000 ft_____1.006 in/Hg___994
___5,000 to 10,000______0.862_______1,160
___10,000 to 15,000_____0.740_______1,350

My question is, why did "they" run the animation with only part of the
values corrected? It would take a simple equation to fix this in the CSV
file, and I'm fairly certain the super expensive software can accomplish
this with a few minor inputs.

"white smoke" (if it actually existed) could simply have been a severed fuel or hydraulic line.

Quite possible...however I would have expected a fire. Maybe, maybe not.
I would have also expected the FDR data to support the level flying object
in the DoD video.

Futhermore, I'm not convinced the PA values were severly affected by
overspeed when looking at the rate of change in RAD ALT. If we use
the DME values and a known ground elevation (the highway, or terrain
around the gas station) we can compare the altitudes to find a trend
within 1-2 seconds of 'impact' using the NTSB supplied data, and the
extended decode by Mr. Stutt.

The aircraft was well over Vmo before the Annex and within range of
RAD ALT to trend against Pressure Altitude.

Using DME and RAD ALT alone along the damage path makes it difficult
to support the pole strike theory as-is.

reply to post by turbofan

Hey WW, let me clarify this part of my post. I don't mean the FDR as a physical device; I meant the flight data file may have been created using a flight sim.

But, you see, ALL the other parameters aren't recorded, for the simulator, in the same way as on the real airplane.

What I mean is, on the real airframe there are physical switches, sensors, devices to supply the input --- in the computer of the simulator those actual devices don't exist, they are 'simulated'. (or, more correctly, their behaviour is simulated, but only when it's pertinent to what is displayed for the flight crew).

Example:

The proximity switches that determine the landing gear posiiton. In the simulator no such actual switches exist, the computer is merely programmed to show, visually, what would be seen on the real airplane --- same time for the gear to cycle, same light indications, etc. Also, the hydraulic guages can be programmed to "show" the effects, as the gear is operated, by simulating the 'bumps' in the pressure readings. There is no actual hydraulic system on the simulator, of course... (it has its own hydraulics, but that's different).

So, no....highly unlikely that the simulator could be used to somehow "fake" the FDR data. I suppose one could contact Sundstrand or Honeywell to ask them for clarification on this...

I may be confusing you. The time/date I'm referring to is the file creation date of the .fdr file. The FOIA CD-ROM contains the information when looking at the file details.

This file is created before the report of recovering the FDR in the Pentagon.

Is this, could this, merely be a case of when the file was created??? I mean, if the date stamp for the file creation was based on whatever system's internal clock settings at that time??

Not sure if I'm describing that correctly....but the time/date info FROM the FDR, that it recorded internally, is the important bit. The clock running on whatever system was used to create the FOIA CD-ROM would seem to be irrelevant. Sloppy on the part of whomever was responsible for it, surely, but not a "smoking gun" of any sort....

Originally posted by trebor451

Originally posted by TrueAmerican
I could almost understand if it was just on one plane. But it was on ALL the FDRs provided, making that an extremely unlikely possibility that all serial numbers everywhere were destroyed because of the impacts. Now if that doesn't spell coverup, I don't know what does. There is more on that in the thread I posted.

Why would the serial numbers be destroyed because of the impacts?

You people just can't get over the fact that you are not important enough to be given those serial numbers by the FBI. To risk a tad bit of moral equivalency here, who are YOU (and/or PfT and/or Cit and/or etc) to demand such information? You are nothing more than fodder for online entertainment in forums such as this, so why SHOULD the FBI or anyone, for that matter, give you anything?.

To simply say "To prove the aircraft were real" would really be one of the most absurd reasons for wanting those serial numbers, so I can see why your huffy indignation and making up stories and lies about why you can't get that information is your best tactic.

And yet somehow these "people" were given the FDR and related files via FOIA. So really your point is moot with regards to serial numbers.

Originally posted by weedwhacker
reply to post by turbofan

 

Hey WW, let me clarify this part of my post. I don't mean the FDR as a physical device; I meant the flight data file may have been created using a flight sim.

But, you see, ALL the other parameters aren't recorded, for the simulator, in the same way as on the real airplane.

What I mean is, on the real airframe there are physical switches, sensors, devices to supply the input --- in the computer of the simulator those actual devices don't exist, they are 'simulated'. (or, more correctly, their behaviour is simulated, but only when it's pertinent to what is displayed for the flight crew).

Example:

The proximity switches that determine the landing gear posiiton. In the simulator no such actual switches exist, the computer is merely programmed to show, visually, what would be seen on the real airplane --- same time for the gear to cycle, same light indications, etc. Also, the hydraulic guages can be programmed to "show" the effects, as the gear is operated, by simulating the 'bumps' in the pressure readings. There is no actual hydraulic system on the simulator, of course... (it has its own hydraulics, but that's different).

So, no....highly unlikely that the simulator could be used to somehow "fake" the FDR data. I suppose one could contact Sundstrand or Honeywell to ask them for clarification on this...

I'm not an expert but couldn't a ground based FDAU unit simply be used to send specific data frames to the FDR? If I'm not mistaken, the FAA requires all FDR's to go through an annual test to make sure necessary parameters are recorded?

And besides, how could and FDR even be developed if they could not program on the ground the items the FDR would be recording??

So the idea that they couldn't use a simulator to produce is an FDR is really unfounded. Not only that you wouldn't even need a simulator. Program a computer to change the parameters in the FDAU and then send it to the FDR. N'uff said. Your not going to need a 'real switch' to get the FDAU to send that data to the FDR, you only need the 'command' to do so.

How does the manufacturer know an FDR can record what it is suppose to? Testing. How do you determine every parameter is being recorded before putting the FDR into a plane? Testing. Do you need to have an FDR in a plane to test? No.

Tell this guy you need to flip the actual switch to get the readout on the FDR!

Hi WW, I hate to disagree but unfortunately there are easy methods to accomplish such a task with respect to recording parameters that don't
exist on a flight sim.

Originally posted by weedwhacker
But, you see, ALL the other parameters aren't recorded, for the simulator, in the same way as on the real airplane...

The proximity switches that determine the landing gear posiiton. In the simulator no such actual switches exist, the computer is merely programmed to show, visually, what would be seen on the real airplane ---

Your example of landing gear is one of the most basic to emulate because
it's an 'open', or 'close' value (either a one, or a zero). The flight simulator
control software take the input from the pilot's panel and uses the value
to turn on indicators on the display and write the logic to a file all at the
same time.

As another example, the flight simulator does not have engines, however
the program uses complex instructions, along with trainee inputs to display
speed on the monitor. The logic reads the position of the throttle controls,
converts it into a signal and determines the percentage of thrust to be
simulated. It can even perform real word alarms like over-speed.

All this is possible even though engines, fuel, sensors are not present.
The flight simulator is able to record the actions by the trainee for playback
at a later time. This file is what I believe might have been used to recreate
the flight path.

These are basic technologies that we learn in first year electronics. Anyone
who has taken an electronics program probably remembers the process
control labs where you were taught how to control LED's, or circuits, etc.
with low level code (assembly / debug) in the old Microsoft DOS?

This sort of communication allows software to manipulate anything you
can imagine with the help of a circuit. THis is one that I'm wiring up for
the demo on data extraction.

[atsimg]http://files.abovetopsecret.com/images/member/705aca7e62bf.jpg[/atsimg]

If I was ambitious, this circuit could be connected to the printer port of
my computer, and I could write a small program to automate the LED's,
or I could type in a command to personally control the circuit.

The same logic signals that turn on the lights can be interfaced to a
recording device (another computer, FDR, etc.) to record everything in
real time.

So yes, it can be done. It has been done; and it's currently happening.

Is this, could this, merely be a case of when the file was created??? I mean, if the date stamp for the file creation was based on whatever system's internal clock settings at that time??

I agree, it's not a smoking gun...but geez...it's a real smelly mistake.
Any computer connected to a network will have the date and time controlled
by the main sever system. I find it pretty tough to swallow that the Pentagon, FBI, and/or NTSB would have their network set to an incorrect
date and time?

It's things like these mistakes that continue to pile up and make the official
story harder and harder to accept.

reply to post by turbofan

Your example of landing gear is one of the most basic to emulate ...

No, you see its not as simple as you're thinking it might be.

True, there may be a value to describe (on the FDR, in one parameter --- whatever the technical term is) for a condition where ALL of the gear are up and locked, or ALL are down and locked. But, in between those two simplified states, there are multiple possibilites, and I suggest you look to see if maybe those are also recorded.

You could (if you were having the free time, but it's not worth wasting) look at a schematic, for example, to see ALL of the circuitry for the landing gear position indication system. It's quite complex.

Gear door position sensors (if one or both Main Gear Doors doesn't open, the gear won't retract, for instance). On the Main Gear, the Bogie (wheel truck) tilt sensors (no retract if gear bogies don't pivot to proper postion after liftoff). Bogie tilt sensors also provide Air/Ground sensing logic, as well as the nosewheel strut compression.

ALL of those various sensors only go to an indication, for pilots, of the three green down and locked lights, and the amber "unsafe" light (labeled 'gear') along with the amber 'doors' light, and the EICAS messages, as appropriate.

In addition, for dispatch reliability many of those sensors (especially down and locked) have redundancy, things that are transparent to the pilots, but will be caught by Maintenance as part of their normal EICAS and FDAU data dumps that they accomplish periodically.

That's why I used the LDG GEAR as an example --- deceptively simple at first glance, but very complicated with many aspects once you examine it.

In a simulator training scenario the instructor merely presses a button to 'simulate' that one main gear won't lock (or nose gear). It does NOT involve all the various and sundry sensors, etc, it's programmed into the software to 'simulate', and the machine (simulator) will react accordingly. One MLG not locked down, then after landing it shows the correct amount of roll, and in all we just do that to practice the various QRH procedures, for the unlikely event it actually happens in real life. (And, that's usually, FYI, one of the last bits, end of a session, since we usually go through a full evacuation simulation too, which is quite involved...)

No, the world of the training simulator is nothing like the real airplane, not in the way it's programmed, or recorded in various software modes.

BTW, if you research into this more, you'll probably find that different sim manufacturers have entirely different and incompatible software protocls, for their specific devices. AND, I'd guess, also incompatible with Honeywell, Sundstrand, et al....

According to this 757-200 manual, the circuit really is as simple as a logic switch (on/off, open/closed )

biggles-software.com...

There is a timer that displays a warning if the landing gear does not strike
either the retracted switch, or locked position switch within 25 seconds.

There is no method of recording the gear position during the extension, or retraction.

Later this evening, I can confirm this with the maintenance manual and
post a diagram of the circuit and switches.

[edit on 21-1-2010 by turbofan]