Another Spectacular Data Error
Dave Jesse on September 6, 2016


Another Spectacular Data Error


For those of you new to flight data, may I offer this week’s blog as a salutary lesson to always expect the unexpected. With only 39 years working with flight data I have never come across an error like this, and it just goes to show that there is always something new around the corner.

This error has been in service for over ten years on aircraft manufactured by one of the “big two” manufacturers and operated by a reputable cargo carrier. The data from these aircraft will have been checked for serviceability some 100 times or more by skilled specialists performing annual FDR readouts but, for reasons I will discuss later, this error was never picked up.

Start of the Flight

Let me lead you into this gently. The data error relates to pitch and roll parameters. Pitch is sampled four times in a 128 wps frame at equispaced locations 22, 54, 86 and 118. Roll is sampled twice in the frame, at locations 55 and 119. The importance of word locations will become apparent later, and for simplicity I have extracted them as separate parameters, e.g. Pitch 54, Roll 119 etc.

Here is a plot of the six pitch and roll parameters at takeoff.

Graph One

The timebase is in seconds, so the slight difference in sample timing can be seen where the parameters change most quickly.

End of the Flight

OK, so it’s really easy. We plot the same thing in the approach to landing and see the same kind of display. Yes?

Well, no. Here is what we get:

Graph Two

The timebase is similar – just over 70 seconds across the width of the plot – and the roll scale is similar. The pitch scale is a little larger than i used for takeoff as the variation in pitch on the approach is smaller (I didn’t use data from the landing phase as there is almost no roll change when the aircraft flares, you’ll be pleased to hear!).

The eagle-eyed among you will have spotted the different band with the turquoise pitch signal separate from the other three pitch signals, and the green roll signal separate from the blue one.

Upon detailed examination we were able to show that the shift in time between the roll signals is 3.5 seconds. That is, the blue sample is one frame (4 sec) later than it’s correct sample time which should be 0.5 sec before the green. Similarly the turquoise pitch signal is 4 sec earlier than its correct sample time with respect to the other three pitch signals.

We can embark upon a philosophical debate about the nature of time, how entropy determines the sequence of decay of the universe and the meaning of life and everything but in essence you can’t go backwards in time. It cannot be that the turquoise pitch signal is recorded before the aircraft moves to that position. Measurements can only follow the thing they are measuring.

So, the turquoise measurement of pitch is closest to the correct value and the three other measurements must be recorded 4 seconds after the time those measurements were taken. Similarly, the green roll signal is closest to the truth and the single late roll measurement is 4 seconds later than it should be.

To cap it all, this error starts in mid-flight unannounced. This is why the takeoff looks OK, but the landings are rubbish.

What the Data Looks Like

The graphs above make the data look better than it should. Here is what a normal replay of the data will show, using a 4Hz Pitch signal and a 2Hz Roll signal.

Graph Three

This is the data that has been in service all these years, and you might reasonably ask why this has not been spotted during an annual recorder check. To quote from the FAA’s guidance for FDR readouts (AC 20-141B App 4), “Flight segment selection. The data to be used by the analyst should be extracted from both the takeoff and the landing phases of flight”. So there really isn’t any excuse for not having seen this.

Possible explanations are:

  • Readout tests only check the data at 1Hz
  • The person carrying out the tests has only used takeoff data for validation
  • The system had been passed serviceable before so was assumed to still be OK
  • The tester had bad eyesight

None of the above are really a justification for failing to detect this error.

What Next?

Flight Data Services have informed the operator of the problem, but realistically the chances of a solution for an aircraft that has been in service this long are slim, so we have developed a corrective fix that shifts the samples in time where this error is evident. Not really satisfactory, but sometimes the pragmatic solution is the only one available.