Differences

This shows you the differences between two versions of the page.

--- flight:hfdl-wrong-hexes [2024/02/22 14:49] – 2m0iig
+++ flight:hfdl-wrong-hexes [2024/02/23 10:07] (current) – 2m0iig
@@ Line 4: / Line 4: @@
 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.
-[img-aircraft comms]
 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.
-[hf wrong track]
+[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.
-[ads-b of same plane]
 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.
-[correct track]
+{{ :flight:img-correcttrack.png?400 |}}
 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!
@@ Line 33: / Line 29: @@
 {{ :flight:img-multi-hex-replacement.png?600 |}}
-And I got a result very quickly, with a plane's hex being changed on the way to readsb and a nice, complete track. Bonza!
+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!
-[Full track image]
+{{ :flight:img-fixedtrack.png?600 |}}
 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.