Those of you who have the memory of an elephant will recall that in 2016 we discussed superframes and the superframe counter. While the true aficionados of this blog will go and view G-ACDC, the normal reader could probably do with a brief summary of this topic.
Parameters that vary slowly (or not at all) can be spread across many seconds so that the space used by their recording is minimized. The common way to do this is by recording over 16 frames (i.e. 64 seconds) a pattern. Here is how the flight of G-ACDC from Heathrow to Singapore might be recorded:
This pattern of sixteen will be repeated throughout the flight, so if we included the hour of the day in, say, the seventh word this would increment on the hour.
To know which superframe parameter we are looking at, we need a counter. This is normally the bottom four bits of the frame counter word, although other counters are sometimes used, they are always incrementing integer counters. That is, they count 1, 2, 3, 4 etc..
Why blog about this now?
A colleague of mine was struggling with a new data frame, trying hard to understand why the superframe decoding was not working. He asked me to have a look and after a lengthy struggle we found the answer. One clue was that the superframes were not referred to as 1, 2, 3, but rather A, B, C, D, E, F, G, H. A pattern of only eight things, compared with the more normal repeated pattern of sixteen items. The other clue was that the superframe counter used eight bits. In this frame, the superframe counter was bitmapped, not an integer. The aircraft registration would be encoded with superframe counters like this:
One of the fun things in life is puzzles, and while it is fun, it’s also expensive. The hardware developer had to create something new, and the software developers have to write new decoding algorithms. To quote Flanders and Swann, it all makes work for the working man to do.