For those of you not fully familiar with the northern Scottish isles, Scatsta is a small airfield on the Shetland Islands and the closest land airport to the North Sea oil rigs. It is mainly used for oil and gas workers changing from fixed wing services to helicopters, making the helicopter journey as short as possible.
Photo: Shetland News
It’s further north than you think, being north of Bergen and Oslo in Norway and on a level with Hudsons Bay.
For those of you not fully familiar with the northern Canadian coastline (oh, I digress…)
The thing about Scatsta is that it has two elements which come together. An ILS (localizer only) on runway 24 at a frequency of 110.15 MHz and one of the aircraft types operating there has a data recording problem. For those of you not fully familiar with crosswind landings, take a look here to see what we are talking about today.
Binary Coded Decimal
OK, let’s get serious. On a Flight Data Recorder (FDR), frequency signals are normally recorded in Binary Coded Decimal (BCD) format. In this method, each digit is treated as a separate value and encoded into a 4-bit binary value. Hence, 6 is stored as 0110 and 59 is stored as the decimal 5 = 0101 and 9 = 1001 giving 01011001. With 12-bit words on the FDR, we can store three decimal digits in this way.
ILS and VOR frequencies are in the range 108.10 MHz and 117.95 MHz, so we have a problem as there are five digits to encode. The first step is to ignore the leading 1. As all frequencies are over 100MHz, we can just add 100 MHz to any answer we get, so that reduces the problem to 4 digits. Still more than 3.
Fortunately the second digit can only be 0 or 1, so we don’t need to use the full range of 4 bits to store values from 0-9; indeed, a single bit would be enough to record the range 0-1.
Similarly, the final digit can only be 0 or 5 as the increments between channels are 0.05 MHz. Again, we need just one bit to store this. To summarize, we need
100 MHz – not recorded; always set
10 MHz – needs 1 bit for 0 or 1
1 MHz – needs 4 bits for 0-9
0.1 MHz – needs 4 bits for 0-9
0.01 MHz – needs 1 bit for 0 or 5
With a total of ten bits needed, there is a little room for manoeuvre and we can clearly record this in 12 bits.
When the engineer came to encode this data on the aircraft in question, they allowed 3 bits for the 10 MHz field and set off with the BCD pattern from there.
The value can be encoded with the required range for 10, 1 and 0.1 MHz decimal characters and the pattern starts to repeat for the final digit.
Here comes the snag. The final bit has the binary value of 8 so is only set for frequencies such as 111.18 MHz or 111.19 MHz. These frequencies are not in the ILS/VOR range, which only has 0 or 5 as the last digit.
The clue above is that Scatsta’s ILS is at 110.15 MHz and recording on this aircraft gives the value
This decodes as 110.10 MHz. (Of course, the same applies to any airport with a 5 in the last digit, but this is where the problem came to light). This aircraft type cannot record the ILS and VOR signal frequencies unambiguously.
What’s the relevance of Boston? This is one of many airports with parallel runways. When aircraft land there we need to know which runway the aircraft is approaching, so we check the ILS frequency that the pilots have tuned against the frequencies transmitted by the ILS systems for each runway. In this way we can align the aircraft with the right runway. Quite often the pilot will approach on one runway’s ILS, then change over and land on the other runway (sometimes re-tuning the receiver for the new runway, late on the approach).
To make sure we analyse these cases correctly, we ignore the ILS localizer and glideslope signals that are coming from runways we cannot confirm are correct. Of course, this logic falls apart for aircraft of the type describe here, and landing at airports with frequencies of 1XX.X5 MHz, so we have to make a special exception for this type.
Well, as my old colleague Eric Grummitt used to say, “if it was easy, any fool could do it”.