Understanding flight data
Dave Jesse on October 12, 2012

Why does flight data use 12-bit format?

Last time you were here, we chatted about The Black Box, what it is and where it came from. Now it’s time to look at how it has developed.

When the interface design for accident recorders was established in the ‘60s, a decision had to be made about the data format. There was very little capacity on recorders at that time, so data had to be stored in a very compact manner. Keeping each measurement in a single 8-bit byte is too crude. For example, recording the aircraft heading would be in steps of 1.4 degrees per step.

Equally, using two 8-bit bytes would give steps of 1/200th of a degree – far more accurate than the aircraft compass!

So engineers settled on 12-bits and this is the format we use today!

Part of the fun of working in flight data at the low level is that we still operate at the binary level, with decimal, octal and hexadecimal numbers. This is the world where 1107 = 247.

So, what does Flight Data Software do?

Data Conversion

The data coming from the recorders is a stream of 1’s and 0’s with no joins, no gaps, no “start here” or “page 1” information – it can be pretty complicated stuff. To get any idea of what is happening, it’s best to start by looking for a set of flag words that have special values. In fact, 001001000111 is the first of these and if we find 000111011010 one second (756 bits) later we can be fairly sure the data in between was one second of usable data.

And did you know? When the specification was written, no-one remembered to define which order the synchronisation words would be stored in, so it’s perfectly permissible to record them backwards!

With the data edges found, each 12-bit word needs to be converted into engineering units, and this is done according to a “Logical Frame Layout” (LFL) file. There are different LFLs for each aircraft type and they also vary by age of manufacture, and can be changed by the airline.

Converting raw flight data using rules stored in an LFL file is the job of a Flight Data Converter, and details of the possible formats of flight data are given in the POLARIS Frame Format Specification document.

If anyone wants to try writing an LFL decode file, you will find Flight Data Plotter is a handy tool for checking each parameter as you create the file.

Flight Data Analysis

With the data now in engineering units, the Flight Data Analyzer software will compute some derived parameters, such as height above the airfield, from the recorded data, then work out when and where the aircraft took off and landed. Each step of the analysis adds more detail and we end up with a set of numbers that describe the flight. These “Key Point Values”(KPVs) tell us how fast the aircraft took off, how rapidly it climbed, what height the undercarriage was raised and hundreds of other measurements.

The KPVs are then used to identify safety issues, possible fuel economies, areas needing maintenance etc. … but that’s for another day!


If you’ve made it this far, well done! We’ve covered a lot in this post, but it’s always best to start at the beginning. We’d love to help novices to understand what we do and hope we haven’t bored those of you who have done this stuff before.

Next time we’ll look at why Open Source before delving into algorithms.