Flight Data Recorders and Data Extraction

First of all, I'd like to get some stuff of my mind before getting into the technical
part of this thread. According to some people, I'm the guy to blame for what
happened regarding the FLT_DECK_DOOR 'incident'

If anyone has a problem with me for the recent uproar, I'd like to know your
thoughts. Tell me what you think in general about my actions, and your side
of the story. Please use the U2U feature to keep the thread clean.

FYI: I haven't changed 'sides', nor have I stopped researching. I simply choose
to associate myself with other organizations and people during my studies.

Next, I'd like to clear up some misconceptions about how the flight data is extracted
from the Flight Data Recorder [FDR] and transposed into a format such as an
Excel Spreadsheet.

I'll try to keep the terminology simple for all to understand, and use real world
examples whenever possible. As time permits, my intention is to upload a video
to show how a digital circuit (much like the one used on the cockpit door) triggers
signals which are recorded by the FDR.

First off, it's probably best to mention that I'm not an FDR technician so i wont
get into any details about how to interpret the data; we're just going to discuss
how the bits are recorded and then pulled into a software file.


How is the data stored? Much like your computer's hard drive, the flight data
is recorded on a device that translates electrical pulses from sensors to binary
logic levels. In the case of the FDR, it uses a computer chip as opposed to
moving parts that you would find in a typical home desktop PC.

The computer chip inside the FDR does not have any moving parts and therefore
is not susceptible to write errors from bumps and turbulence, or things of that
nature. The data is written using logic gates and electricity only. Logic gates
for this particular device are known as the "Floating" type that you will find in
FLASH EEPROM (look it up on Google. Please note the difference between EPROM
and FLASH EEPROM).

Due to this fact, a logic state of only zero (0 = logic low, low voltage) , or one
(1 = logic high, higher voltage) may be stored. There is no "in between",
and there is no exception. The gate is either conducting, or it is not.

At times you will read about "missing bits", or "blank cells", etc. This has nothing
to do with the Flight Data Recorder. We are talking about the lowest level in the
chain (the computer chip), not data you see in Excel spreadsheets.

I'll stop there for now, and continue in my next post. While you're waiting, check
your understanding of how data is carried on a wire:

#1. An entire word is presented on a data line at any given point in time.

IE: 0000 1101 0101

OR

#2. Only one bit is present on a data line at any given point in time.

IE: 0

OR

#3. Sometimes no data is present on a data line, and therefore nothing is
recorded.

[edit on 18-12-2009 by turbofan]

Originally posted by turbofan
At times you will read about "missing bits", or "blank cells", etc. This has nothing
to do with the Flight Data Recorder. We are talking about the lowest level in the
chain (the computer chip), not data you see in Excel spreadsheets.

Why are there sometimes missing bits though?

Originally posted by turbofan
I'll stop there for now, and continue in my next post. While you're waiting, check
your understanding of how data is carried on a wire:

#1. An entire word is presented on a data line at any given point in time.

IE: 0000 1101 0101

#2. Only one bit is present on a data line at any given point in time.

IE: 0

#3. Sometimes no data is present on a data line, and therefore nothing is
recorded.

I found this part confusing. You seem to saying that all 3 are true, but the way you worded it, that doesn't seem to make sense. You seem to be saying:

1- An entire word is on a data line.
2- Only one bit is on a data line.
3- sometimes there is no data (bits?) on a data line.

The way I worded it, these statements all contradict each other. I know your wording is more nuanced, but it would help if you could make it clearer...

Sorry, to be more clear:

The scenarios are based on myths revolving around the flight data. Only one of those statements is correct.

I've edited the original post to include the word, "OR" between each option.

With respect to your question about "missing bits", which stage of the
process do you mean? Are you thinking the "missing bits" occur from
within the FLASH EEPROM, or elsewhere (IE: uploading the data to a
software file, or converting to a CSV file, etc?)

[edit on 18-12-2009 by turbofan]

Much respect for going to the trouble of clearing up the misconceptions that seem to abound regarding this subject
I suspect it'll be something of a foreign language at first for a lot of viewers.

I have nearly 40 years experience in digital circuits and programming but I've slowed down a tad in recent decades (some say it's age) - I still program the odd micro-controller etc though. I could offer some help in explaining some of the concepts but perhaps I'd only end up making it more confusing.

I am just wondering why someone who knows nothing about FDR's and/or the data starts a thread presuming to 'educate' others.

I wouldn't say I know 'nothing' about FDR's, or the data. Over the past
3+ years I have studied the data and avionics. I'm also no stranger
to digital circuits, networking and programming. As I mentioned, this
will be about how the data is recorded and extracted, and not so much
about the FDR itself, or interpreting the data.

Primarily, I'd like to squash some myths about the differences between
the FLASH EEPROM data vs. the converted CSV file data. As I get the
chance, I'm also going to build a digital circuit like the type used on
the Cockpit Door, and Comparator and post a video of the function
(to illustrate how parameters are recorded that are not necessarily
connected to the DAU).

I may even redraw some of the 757 schematics for reference.

[edit on 18-12-2009 by turbofan]

reply to post by 911files


If you had Balsamo living in your basement posting as you, you would think you were an expert at everything after seeing Balsamo's work.

I was wondering how this belong in the 911 section; someone left out the part that relates to 911? Understanding how a FDR works, which Turbofan has no expertise or experience, will not change finding the 77's FDR in the Pentagon.

If you had read my posts you would see I'm not discussing the FDR itself;
I'm talking about the data storage and converting the data into a CSV file.

I have:
- a data frame layout
- source code,
- an authentic 757 manual
- INTEL's FLASH EEPROM schematics and literature (same used in the L-3 FDR for the alleged "AA77")
- 16+ years of electronics (including
networking and programming) along with a clear understanding of how
the system functions.

Believe me, I can take this data from sensor to CSV and then some...
and I'll even build you a circuit on video to prove it.

Why are you suddenly getting nervous? You don't even know the angle
I'm taking on this?

As for the 9/11 aspect: this topic will discuss the myths about "blank
cells" in the CSV file, and how parameters are recorded that don't have
a distinct trace in the schematic manuals.

Sit tight, and if you feel something is incorrect, feel free to flag it.

[edit on 18-12-2009 by turbofan]

Sorry it has taken this long to update this thread, the holiday season is
really eating up my spare time. I've drawn up some very basic logic
circuits to explain how logic states can be produced based on circuit configuration.

I'm almost finished with building the circuit to show how these examples
function in real time. I hope to have a video posted by early next week.

This first diagram shows a simple switch and LED (or light) wired in series.
The light on the output is now off because the switch is open (the circuit is
broken) which means no signal can reach the LED to turn it on.

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

If this circuit were used in the case of the FLT_DECK_DOOR, one could
argue that the switch was broken and the cabin door could be open and
closed without the flight data recorder ever updating.

True 'if' that were the case. In fact, the circuit used to indicate a closed
door on the Boeing 757-200 is comprised of a proximity sensor, and
"inverse logic". This means, there must be positive contact with the door
to the door jamb and a FUNCTIONAL switch in order to produce a LOGIC
LOW (zero, or low voltage) to turn off the LED...or supply the FDR with
a 'CLOSED' state.

[atsimg]http://files.abovetopsecret.com/images/member/881c62cfe8fd.jpg[/atsimg]

As you can see, the LED will remain turned on UNLESS the switch (door) is
closed. In other words, if the cabin door was open, or the switch failed, or
the door was kicked...the failure mode would indicate an OPEN FLT_DECK_DOOR.

If this is confusing, don't worry I'll have a video up soon to show the lights
in action with a simulated door opening and closing.

The next thing I'd like to clear up is the myth about "data updating in the
FDR file that does not have an apparent connection".

There are several instances in the flight data where columns have data updating
and do not show any sort of physical connection. This is because the aircraft
has computers and firmware which performs monitoring, and calculations
outside of human input. The computers in certain cases can monitor the
Captain's side of the instrumentation and COMPARE the data with the
First Officer's instrumentation. For those that have access to the 757 manual,
or have seen excerpts of the EICAS system you will notice the COMPARATOR
circuits.

These circuits output a logic state based on two, or more inputs. For instance,
the LED on the far right will turn ON with both inputs are equal.

RIght now it is showing "OFF" because the upper circuit is producing
a HIGH state on the output, and the lower circuit is producing a LOW
state on the output (notice the LED's; one is on and one is off)

[atsimg]http://files.abovetopsecret.com/images/member/3b501a367fd7.jpg[/atsimg]

There are a couple of ways to turn on the LED on the far right...if you
understand the circuit, it will be very clear how to turn on the LED.
If you're confused, don't worry...a video is forthcoming.

Hopefully this will put to rest some of the myths floating around about
how the flight data is interpreted.

As far as the flight deck door, it is rather clear as to how it is read from the data as can be seen from a snippet of my revision to Warren Stutt's code.

// Uid: FLT_D_DR
// Abbrev: FLT_D_DR
// Name: FLT DECK DOOR
// Units:
// Minimum Value: 0
// Maximum Value: 1
// Digits Displayed: 0
// Signed Value: No
// Parameter Type: Discretes
// Bitval 0 Output: CLOSED
// Bitval 1 Output: OPEN
// Sampling Freq.(hz): 0.25
// Number of bits: 1
// Locations/value: 1
// Frame(s) Subframe(s) Word Start Bit End Bit
// ALL 3 251 1 1
// Number of Tests: 0
Add(new Parameter("W251 FLT_D_DR", "",
new ParameterColumn("",
new ZeroOneParameterRow(251, 3, 0, 1, "CLOSED", "OPEN"))));

Nevertheless I still find no electrical connection ( other than the power bus ) between the flight deck door proxy switch and the FDR. But I do concede that the manual I have was not written specifically for flight 77.

And to clarify for Scott, the above is represented by one of the "1" or "0" 's out of the 12 in Tinos example #1 in his opening post, the other 11 have varying uses... In the case of this particular "12 bit word" it also handles :
FWD CARGO DOOR ( bit 2 )
and
INDICATED AOA (which uses bits 3-12 for a portion of a signed value which ranges from -89.9999 to 89.8241. )

Thanks for posting that bit of info. We can reference that when explaining
how the data words are interpreted from the .fdr file into the decoding
software.

I have finally dragged my butt to the electronics store and picked up the
necessary IC's to complete the circuit above. I'll wire it up and post a
video soon.