Why F1B77E and C397DB Should Never Fly
By Dr. Matthias Schäfer, CEO SeRo Systems
Let’s face it: this post is for a very select audience. A very select audience. Maybe twenty people in the world, give or take, will find this interesting. Fewer still might find it funny. But here we are anyway. Welcome, fellow Mode S nerds—this one’s for you.
So… What’s So Special About F1B77E?
Let’s start with a simple question: what’s the deal with the 24-bit transponder address F1B77E? Why should it never, ever be used by any transponder? Spoiler: it’s haunted by the ghosts of the Mode S and ADS-B history.
This address has become a sort of ghost in our 1090 MHz monitoring system—mysteriously appearing across multiple receivers around the world, all at the same time, always transmitting only DF 21 (long identity reply) messages. Creepy? Yes. Real? Kind of.
Why F1B77E and C397DB Should Never Fly
By Dr. Matthias Schäfer, CEO SeRo Systems
Let’s face it: this post is for a very select audience. A very select audience. Maybe twenty people in the world, give or take, will find this interesting. Fewer still might find it funny. But here we are anyway. Welcome, fellow Mode S nerds—this one’s for you.
So… What’s So Special About F1B77E?
Let’s start with a simple question: what’s the deal with the 24-bit transponder address F1B77E? Why should it never, ever be used by any transponder? Spoiler: it’s haunted by the ghosts of the Mode S and ADS-B history.
This address has become a sort of ghost in our 1090 MHz monitoring system—mysteriously appearing across multiple receivers around the world, all at the same time, always transmitting only DF 21 (long identity reply) messages. Creepy? Yes. Real? Kind of.
A Quick(ish) Primer
SeRo Systems builds 1090 MHz monitoring devices that listen for all kinds of Mode S signals, including TCAS and 1090ES ADS-B. We’re in the “passive” camp: no interrogations, just vigilant eavesdropping.
Our receivers are really good at dealing with overlapping transmissions, also known as “interference” or “degenerately garbled airwave spaghetti”. Thanks to fancy degarbling algorithms (compliant with the A3 performance class in the ADS-B spec, thank you very much), our devices can decode useful data even when multiple aircraft are yelling over each other.
Now, Mode S messages include a checksum (CRC) at the end, which helps us figure out whether a message was received correctly. But things get tricky because in many downlink formats (DFs), this CRC isn’t just a CRC. It’s been sneakily XORed with the transponder’s unique 24-bit address. So, to get the address, you have to calculate the CRC syndrome of the rest of the message and XOR it with the last 24 bits. Et voilà: you’ve got your address.
But if even one bit is wrong—because, say, someone was transmitting a bunch of Mode A squawks on top of it in an unfortunate constellation of timings and signal levels—your address calculation is toast.
Enter the Guesswork
Passive receivers like ours usually don’t know which aircraft are out there ahead of time. So, to deal with corrupted signals, we maintain a list of “known” transponder addresses. If a message comes in that almost matches something we’re tracking, our error correction kicks in and tries to make it fit. The exact algorithm behind how that’s done is… well, proprietary.
(And to be clear: this isn’t unique to our system or a sign of flawed implementation—it’s a common and widely accepted practice in passive transponder tracking. In fact, it’s pretty much state of the art.)
Some DFs Are Easier Than Others
- DF 0, 4, 5, 16, 20, 21: These use the transponder address XORed with a CRC syndrome. DF 20 and 21 can even have another code XORed on top of it (a passive receiver’s nightmare known as BDS overlay). Bit errors = big headaches.
- DF 11, 17, 18: These are more forgiving. DF 17 and 18 (ADS-B, TIS-B) have standard CRCs. DF 11 uses a CRC XORed with an interrogator ID—but there are only ~80 of those, so it’s manageable.
DF 17, in particular, is our golden child: if everything goes right, the CRC syndrome is always zero.
Keep that in mind. It becomes important.
Back to F1B77E and C397DB…
We started noticing that transponder IDs F1B77E and C397DB were regularly on the tracking lists of several of our receivers at the same time on different continents. Oddly, F1B77E was always sending only DF 21 messages and C397DB was always sending only DF 16, at a very low rate, and always from locations with very busy airspaces.
That’s weird.
We pulled some raw signal data from our receivers and confirmed that the messages were legit Mode S frames—seemingly well-formed, except for a tiny bit of interference at the beginning of the message:
After more digging, and quite a bit of bit-flipping fun, we discovered the key:
If you take any valid DF 17 message (which, remember, always has a CRC syndrome of 0) and flip bit 3, you change the DF field from 10001 (DF 17) to 10101 (DF 21). Now, apply the CRC check to this corrupted message and what syndrome (aka transponder address) do you get?
🎩 F1B77E Every. Single. Time.
It’s like magic. Very boring, mathy magic.
And the same trick works for flipping bit 5, except that instead of DF 21 and transponder address F1B77E, you end up with a DF 16 signal from transponder C397DB:
This address is actually allocated to Canada, though it does not appear to be currently in use, at least according to open flight data sources. But unlike F1B77E, it’s a real address, and if it were assigned, this bit-flip phenomenon could in rare cases cause actual confusion in receiving systems.
Why Does This Happen?
Let’s run the numbers:
- In dense airspaces, overlapping signals are common and bit errors unavoidable.
- Bit flips are essentially random, but when you have thousands of transmissions per second, even low-probability events become pretty likely.
- The Hamming distance between 17 (10001) and 21 (10101) or 16 (10000) is only 1—just one bit flip! If it had a hamming distance of 2 or more, the probability would likely be small enough that these bit flips vanish in the background noise.
- Because DF 17’s CRC is always 0, flipping bit 3 (or bit 5) guarantees a CRC remainder of F1B77E (or C397DB, respectively), no matter what the rest of the message is.
So what you’re seeing isn’t a ghost aircraft—it’s a very mundane ADS-B message that got bonked on the head by RF noise and now thinks it’s DF 21, complete with a perfectly convincing transponder ID that nobody actually uses.
Are There Any Other Cases?
I don’t think so, no. Any address that is also a CRC syndrome of a DF 17 (or 11) with a single bit flip in its DF field that results in a different yet valid DF, may cause this issue. For 17, DF 16 and 21 with addresses F1B77E and C397DB are the only ones. A flip to DF 20, for example, requires 2 bits to flip (10001 -> 10100) and, as a result, is unlikely enough to pass any noise filter.
As for DF 11, it’s probably not an issue. First of all, many replies are also XORed with the interrogator ID, so the syndrome wouldn’t be 0. In cases where the syndrome is 0 (squitters), there is still no other valid short Mode S reply DF that has a hamming distance of 1 to it.
So… Should We Be Worried?
Not really.
The transponder addresses F1B77E and C397DB are currently unused, which is why this phenomenon is harmless—so far. But if someone did assign them to an actual aircraft in the future?
That aircraft (or rather the target in the surveillance system) could live a very confusing life.
Flight trackers, surveillance systems and collision avoidance systems might start combining valid and spurious messages, leading to phantom squawks and fluctuations in other information contained in DF 21 or DF 16. Surveillance systems would think the aircraft is saying: “I’m definitely here, maybe… Or somewhere else. And also I have a completely unrelated squawk code.”
The exact outcome, of course, depends on a number of unknowns—how specific receivers and trackers handle edge cases, whether previous interrogations influence message interpretation, and countless other implementation details. It’s entirely possible that even if a real aircraft were assigned F1B77E or C397DB, any glitches this caused might be subtle or sporadic enough to go unnoticed for a long time. After all, who would ever think to trace a few odd squawk reports back to a single flipped bit in a crowded RF environment? Personally, I’d rather not find out.
Recommendations from the Nerd Cave
To avoid waking the gremlins:
- Never assign F1B77E or C397DB to a transponder. Just don’t.
- If you’re designing or deploying receivers, be aware that this sort of anomaly exists, especially in high-traffic environments.
- Passive receivers should use robust filtering logic—but maybe keep a window open for oddities. After all, we found this issue because our system wasn’t throwing it away.
TL;DR
If your passive 1090 MHz receiver starts seeing the transponder address F1B77E or C397DB, congratulations: you’ve just witnessed the universe trying to tell you that DF 17 is fragile, RF interference is wild, and XOR math can have some spooky consequences.
Also, you might be one of about 20 people in the world who care. Welcome to the Club!
