"Bad" Hexcodes

Recently, i have been seeing a lot of hexcodes in these patterns: CE0xxx, C90xxx and 9C0xxx. They will appear, sometimes, 10-20 at a time. They will stay visible for a short period of time and then disappear. I have researched several of them through various sources and none have come back as valid. Anyone have any ideas as to what they are?




I get a bunch of those too. Due to our close proximity to O’Hare, maybe it has to do with aircraft on the ground there. When some of those 9c… aircraft pop up, there is usually another aircraft that pops up without a bad hex code. I then can cross check the hex with the aircraft and I usually find that they are on the ground at O’Hare.

Thanks for the response, Ryan.


I see a whopping lot of C60xxx perambulating around LAX at 0-20 mph in Planeplotter. LAX recently ‘upgraded’ and ground vehicles are transmitting ADS-B. Location, altitude and speed are worth checking. :smiley:

What version of dump1090 is this? What arguments are you running it with?

(I have a vague recollection it may be related to TIS-B)

If you’re willing to capture some data while the problem is happening I can take a look at it and see if there’s anything obviously wrong.

$ nc -q60 localhost 30005 >capture.beast </dev/null

This should exit after 60 seconds. Get the capture.beast file off the Pi and put it on Dropbox or similar and I can take a look.

Hmmm…Interesting theory on them being vehicles. I have yet to see any position, altitude or speed from these hexcodes.


Here is the file. I think I was able to get it running in time before the suspect hexcodes disappeared. I can try again if this capture didn’t see them in time.

dl.dropboxusercontent.com/u/147 … ture.beast


Here is a second file:

dl.dropboxusercontent.com/u/147 … re_2.beast


Cheers. From that capture I’m pretty sure it is TIS-B getting misinterpreted:

CRC: 000000 (ok)
DF 18: Extended Squitter.
Control Field : 5 (TIS-B relay of ADS-B message with other address)

this then appears as a bogus entry for 9c0bf8 as that’s where the ICAO address would be for a TIS-B relay that used an ICAO address.

I guess this might be a relay of UAT? Not sure.

Here’s the issue I was remembering: github.com/MalcolmRobb/dump1090/pull/52
Looks like it never did get fixed… I’ll take a look.

Here is another screenshot of them.



One quick decoder hack later I get this:

DF 18: Extended Squitter.
  Control Field : 5 (TIS-B relay of ADS-B message with other address)
  ICAO Address  : 9c0bf8
  Extended Squitter  Type: 13
  Extended Squitter  Sub : 0
  Extended Squitter  Name: Airborne Position (Baro Altitude)
    F flag   : odd
    T flag   : non-UTC
    Altitude : 7000 feet
    Local CPR decoding used.
    Latitude : 41.884305 (113295)
    Longitude: -87.864820 (66196)

DF 18: Extended Squitter.
  Control Field : 5 (TIS-B relay of ADS-B message with other address)
  ICAO Address  : 9c07f0
  Extended Squitter  Type: 13
  Extended Squitter  Sub : 0
  Extended Squitter  Name: Airborne Position (Baro Altitude)
    F flag   : even
    T flag   : non-UTC
    Altitude : 9450 feet
    Local CPR decoding used.
    Latitude : 42.139069 (3038)
    Longitude: -88.074209 (30851)

Which looks… plausible, at least.

I’ll try to find some time to do this properly soon.
The addresses are apparently randomly allocated, so I’m not sure how good the resulting tracks will look - depends on if the transmitter is “sticky” about the address assignments or not.

After obj’s post… so much for the ground traffic theory :confused:

They could still be ground traffic, TIS-B can retransmit that too and maybe PP knows how to decode those message types.

(edit: I mean the LAX contacts, not your ones … unless there are usually ground vehicles at 7000ft :wink:)

dump1090-mutability 1.13 has support for these message types - you’ll still get the “bad” hexcodes appearing, but

(a) they’ll be italicized in the webmap to indicate they’re not real ICAO addresses, just temporary ones
(b) they should have useful speed/position/altitude/etc information associated with them.


I saw in the other dump1090-mutability thread that dump1090-mutability can be installed along with a normal dump1090 installation. To run dump1090-mutability, the normal dump1090 needs to be stopped.

This is how I run my current dump1090 installation:
dump1090 --net --net-sbs-port 30003 --quiet --gain -10 &

Would the same parameters work or are there additional parameters that would be needed?


Should be fine. You might want to add --phase-enhance --oversample --fix, and perhaps set your receiver location, but your existing commandline should work.
If you’re using one of the prebuilt packages and want to start dump1090-mutability yourself, rather than having the provided init script do it all, then be sure to say “no” to the start-automatically? question when configuring.

I see these “bad” hexcodes quite a bit from my KFUL site (Only 24nm from KLAX). I saw them in the list of a/c with dump1090, but never had positions showing for them. dump1090-mutability does give me their positions.

So, if I understand TIS-B… these “bad” hexcodes are non-adsb a/c that have their positions broadcasted via ads-b ground stations to ads-b equipped a/c. The TIS-B info seems to stay fairly persistent with my KFUL site, but does drop off from time to time. I have not watched it long enough to see if there is some pattern. My KCNO site pics up the info occasionally, but I have hills between the KCNO and KFUL site that I am sure is blocking the ads-b ground station broadcasting this info.

I just noticed the TIS-B info drop off for about a minute or two. When it did come back, my a/c count went up by about 70-80.

It would be great if the real hexcodes could be determined. However, if not, can these a/c be colored differently on the map to indicate that they are TIS-B a/c?

Here is a track of what appears to the a police helicopter that departed from KLGB and did a few orbits and is patrolling.

The ‘beehive’ around KLAX when I am reeving TIS-B


That’s a lot of contacts!

Changing the color is relatively easy, will put that in the next release.

I don’t know of any way to get the “real” hexcode, the place where the hexcode would usually be is where the c60… value comes from and there isn’t any space to put another value somewhere else in the message. Some of the encodings for DF18 claim to put the squawk value as part of the pseudo-address, but CF=5 doesn’t say that (well, the description of CF=5 is almost nonexistant anyway…), and looking at the addresses you see they don’t seem to decode usefully if I try to interpret them as squawks.