FDC
When is a Frame not a Frame?
on August 23, 2016

Well, it’s a silly question but there is a point to it. In next week’s blog I am going to explain how superframes can go wrong, but first I need to explain subframes and superframes so that you, gentle reader, can understand what is going on.

If you think you know all about frames and stuff, you can skim read this because I have left the fun exceptions to the end, as normal.

# Frames

Well, in a standard flight data recorder to ARINC standard 573 or 717, data is recorded in a repeated pattern that lasts for four seconds. This is called a “Frame”.

## Subframes

Each one-second pattern within the four second frame has a similar structure, and this is called a “Subframe”. So, there are four Subframes to a Frame. Each subframe has its own synchronisation pattern at the start, so we know which Subframe we are in, and hence after four Subframes, we know we are in a new Frame.

There are 64, 128, 256, 512 or 1024 words in each Subframe, so knowing the word location we can identify the parameter being recorded.

Using this structure we can locate parameters sampled at different rates.

# Sample Rate

A parameter which is recorded once every second will be stored in the same place in every Subframe.

## Lower Sample Rates

A parameter which is recorded once every four seconds will be stored only once in the Frame, and so will only appear in one Subframe. The equivalent location in other Subframes can be used to store other parameters at the same, lower, sample rate.

## Higher Sample Rates

You can store data at 2Hz, 4Hz or 8Hz by putting two, four or eight equi-spaced samples into each Subframe. We normally only use this highest sample rate (8Hz) for Normal Acceleration.

## Very Low Sample Rates

Now, having got the framework in place the question arises, how can we record data that is barely changing, if at all? Such a parameter might be the aircraft registration which is not of course going to change for the duration of a flight.

I can’t help thinking of the James Bond DB5 with revolving number plates…

# Superframe

We really want to store this kind of slowly changing or static information without using too much storage space, which means avoiding repetition. The solution is to store data at a lower sample rate than once every four seconds and the normal solution is to reduce the sample rate down to once every 64 seconds, or 16 Frames.

This very long period pattern is called a Superframe. Data is held in a certain subframe and word location

## Counting

The problem that arises with a Superframe is that the basic Subframe and Frame pattern does not identify which of the sixteen Frames we are in. There is no unique pattern available, so we need something which can identify the Frame within the Superframe pattern.

The normal way to do this is to have a Frame Counter which just counts up throughout the flight. These are normally held in a single 12-bit word, so count 212 = 4096 Frames = 16,384 seconds or about 4.5 hours. I recently took a 12-hour flight back from Singapore, where the same Frame Counter value would have arisen three times, making readout of the data indeterminate as no other timebase was available. I eased the stress by supping another beer.

The joy of Frame Counters is that the bottom four bits of the data will repeat a pattern of counting from 0 to 15, so we can use this as a Superframe Counter without having to add another field. The only problem is that we do need to allocate one word in the frame to this counter.

## Example

Here is a real example of the information contained in one Superframe location for a particular aircraft. While the fuel contents would reduce over the flight, the rate of change is slow enough for one sample per minute to be adequate.

Don’t ask me what happened to the No.1 Reserve Tank – this is all that is documented.

# Exceptions

As with most things in flight data, there are exceptions that prove the rule.

My favourite, for which I have to accept the blame, is the North Sea Integrated Health and Usage Monitoring System (IHUMS) that was developed in the 1990s to improve helicopter safety offshore. We used a Combined Voice and Flight Data Recorder (CVFDR) to save weight on the helicopters. This was established military practice at the time, and we copied this on the helicopters.

The tape speed on the combined recorder meant that we had a minimum data rate of 128 wps, but rather than use a 128 word frame, we stuck with the familiar 64 word frame and used a 2-second Frame and half-second Superframe. My only excuse is that it seemed like a good idea at the time!

Next week we will look at a recent problem that arose, and consider possible solutions.

TTFN

Dave