Incorrect hexes from HFDL transponders (WIP!)

I've noticed something very strange recently during my time extracting signals from aircraft from out of the air. For those unaware aircraft are usually pinging away on multiple areas of the EM spectrum, and I receive in two of them. Firstly, 1090 MHz - this is the one most people are familiar with and the ADS-B/Mode S data received powers the vast majority of the flight tracking websites. Secondly I receive HFDL data via shortwave signals ranging from 3-21 MHz, covering huge swathes of the planet with a much slower update rate, but used for a totally different purpose. You may know it as ACARS, and it contains information such as ATC control and status messages, but positions are available too, usually every thirty minutes or so.

Without going into too much detail both of these types of signals contain all sorts of information, and are usually accompanied by an aircraft's 24-bit ICAO address. This is a 6 character hexadecimal ID that identifies a specific aircraft on the planet. However, these codes are not immutable. If a plane's registration/country is changed then a new hex is assigned, according to the registration country of the aircraft. Different blocks (ie, the characters the code starts with) exist for different countries.

Along with ACARS via satellite comms and VHF airband @ around 136 MHz, this means that there are usually 4 different systems pinging away. And usually everything is fine and dandy. However, I spotted an issue the other week that caused me a small amount of interest: it seems that sometimes these 4 systems don't always have the same hex ID.

[hfdl/ads-b track of same plane side by side]

I spotted a HFDL track going through my ADS-B range that didn't switch to an ADS-B track - the track was HFDL-only. The plane would definitely have been pinging ADS-B or Mode S, so I checked on my feeder to see what plane was in the same area on ADS-B/Mode S at the same time as the HFDL ping. And to my surprise, I found a totally different hex ID, with a similar callsign to the HFDL ping (OCNxxx/LHxxxx). The callsign being different (even though some numbers were the same, allowing me to make a match) is explained by the difference between ICAO and IATA callsign prefixes, and is outside of the scope of this article. The hex ID, however, is a different proposition.

Why does this matter, though? Well, it'd be nice to see an entire line as a plane's signal is received in different modes and have a complete, unbroken track. With this issue we'd have two separate, unconnected tracks. This is a bit of a pain when analysing data and looking at the entire route of an aircraft. Here's one that worked fine, showing the HF points, then a dotted line to connect it to the ADS-B track.

So now we have to figure out what the hex on HFDL is. Is it a bad decode? Well, I had multiple pings with the same ID over an hour and a half, and so did other receiving colleagues, so it's definitely not a bad decode. Which means the hex was entered on purpose. Is it just mistyped? Was the plane previously set to this hex code in the past? There's only one way to find out… to Google!

Thanks to the incredibly meticulous job people do of recording information within the aviation community, we do have some ways to figure this out. Take hex code 424363, which showed up on my aggregator lately. This came up over Russia as having no type information on my map, despite my aircraft database being as up to date as possible. When I checked on another website with ADS-B coverage I found the same callsign, 73797, on a plane with hex 152045. The callsign happened to match the Russian registration of the aircraft, RA-73797, allowing a simple match.

When I googled 424363 I found that the plane USED to have this hex, but has been transferred a few times since. It now has hex 152045, but the HFDL transponder is still set to 424363. The engineers or maintenance folk just forgot, perhaps.

Now then: what to do with this information. Well, for a start, I wanted to find and replace these hexes on their way to my local map. And I realised this may be a fine time to start working on learning Node-Red. I could set up a little workflow and find and replace according to a lookup table.

First of all, can I change a single hex. And yes, I could. I set up an inject with a test SBS Basestation message. I then used a TCP input node to fire in messages from dumphfdl into the flow and a TCP output node to fire them out at the end to the local readsb system powering my map. Testing worked via the inject, so I enabled the live data and one changed exactly as planned. After proving that it worked for one aircraft I then had to use a function node to setup a table of key:value pairs, so that they could be easily referenced and replaced on the way through the flow.

And I got a result very quickly, with a plane's hex (second in the list above) being changed on the way to readsb and a nice, complete track. Bonza!

The other thing I could also possibly do with this is to contact the airlines and report the issue. You'd have to imagine they know already, because they see this data all the time. It may not be a huge issue for them. But my OCD won't let it drop. Surely this is better for record keeping if they match. But apparently there's no requirement for them to match. So is there a requirement for one to be correct? Is there an order of preference? Anyway, I'm going to try to see if there's any technical contact I can find for some of these airlines and let them know. I will report back on this.

For now, I am going to maintain a hopefully small list of these problematic aircraft. I feel there'll be more than I expect. There's like 20 right now…