It would be nice if the piAware MLAT software was updated so that it could triangulate Mode C transponder equipped aircraft. Granted, this is a little bit more difficult, because Mode C doesn’t include any aircraft identification info. However in rural areas, where traffic density is pretty low, I would imagine that you could come up with an algorithm that would uniquely identify aircraft based on the squawk code and the approximate time of the transponder transmission.
Then you know the location and the altitude, but no callsign, nothing else.
ModeC isn’t even shown in the the local webinterface even if you have it enabled and that’s because it’s not too interesting. (maybe i misread the code in regards to that but i don’t think so)
I rural areas, aircraft are likely squawking 1200 (VFR). It would not be easy to track multiple aircraft squawking the same ID, granted that they should have different altitudes.
From memory, they only squawk when pinged by radar.
I remember when I turned on Mode C on my radarcape I received about 6,000 messages per second (I am in busy NYC, with several major airports within 20NM and a busy VFR corridor).
We prototyped mode A/C mlat a while ago but the results turned out to not be very useful; the data quality was poor.
The major hurdles were
-
working out which tracked aircraft to assign each set of TDOA data to. This is necessarily a fuzzy match because of the lack of uniqueness in both Mode A and Mode C replies; at best you end up with a set of candidates and have to try each in turn to see which produces the best fit to the data (or it might not match anything well and you need to create a new track)
-
not being able to distinguish Mode A from Mode C (all mode C replies are also valid mode A replies; many Mode A replies are valid mode C replies) which leads to e.g. duplicate tracks differing only by altitude.
It’d basically be entirely redundant to show it for Mode S targets. dump1090 tries to match Mode A/C responses to Mode S aircraft, so that it can then show anything that’s unmatched as A/C-only aircraft. So if you have a Mode S target there’s no point in displaying the associated mode A/C data separately because by definition it matches the Mode S data. You could show an indicator to say “hey I also heard A/C data for this Mode S target” which is basically what interactive mode / view1090-fa does.
Correct. And for low-flying GA they may well be below radar coverage.
There are only so many altitudes available; and pattern altitude is a thing. You really can’t assume that different VFR aircraft will be at different altitudes.
2 Likes
Does it show those in the json?
Probably i just misread the code 
I don’t think it currently emits it, but it’s tracked as part of aircraft state (modeA_hit / modeC_hit) so it should be easy to add.
Except military planes, I think that nobody uses anymore Modes A/C exclusively. Not in 2020.
I’m sure there are Mode C transponder equipped aircraft flying around in rural areas of the US that have not yet upgraded to ADS-B OUT, or they have equipped with UAT ADS-B OUT and kept their existing Mode C units.
I think they all have been updated long time ago to mode S. And since the FAA requirement for 2020, I doubt that are too many left that don’t have either ADS-B or UAT
I’ve added modea / modec values to aircraft.json if you want to have a play with it: Expose modea_hit / modec_hit in aircraft.json · flightaware/dump1090@1dbb8ab · GitHub
1 Like
Yeah … mostly was trying to illustrate how irrelevant it is 
So maybe that didn’t get across.
But i also maybe misunderstood the code.
Are aircraft that are ModeC ONLY shown in the json?
1 Like
Oh, right, I see what you’re asking.
No, those don’t get emitted and they wouldn’t really fit into aircraft.json since they’re really just a list of unmatched ModeA/ModeC values (no associated hexid or any sort of persistent identity, etc). Not much you can do with them other than have a list of unmatched values (which is basically what interactive mode does if you tell it you want A/C).
No reason they can’t be emitted, I just don’t know what you can usefully do with them.
1 Like
Yeah but that’s basically the aircraft people asked about for MLAT, at least as far as i understand.
I mean displaying ModeC only hits like ModeS with some random ~123456 code would work i suppose.
Then you get squawk / altitude / signal strength.
I do agree it’s not super useful
Well if you see some plane fly by and you don’t get any signal you could check the ModeC craft.
I was just trying to explain that people are asking for MLAT on aircraft they don’t even see without position right now.
Maybe clear up some misunderstanding …
Also fascinating that quite a few people turn on --modeac or did in the past and never see the results in the webinterface.
Or did the original dump1090 somehow show them? (in the webinterface)
Well… not exactly. You get a list of random codes that might be a squawk, or might be an altitude, or might be an old altitude that’s was valid 10 seconds ago but is stale now because that aircraft is transmitting a different altitude, or might be an altitude being interpreted as a squawk, or might be a squawk being interpreted as an altitude, or might just be complete garbage because there’s almost no error detection present. Mode A/C is really hard to interpret as a passive receiver because the responses are ambiguous and you don’t even know if they’re from the same aircraft or not.
Signal strength would be across all aircraft that happened to share a ModeA or ModeC value (if the demodulator even measures it - I’m not sure that it does)
It’s never been on the web interface AFAIK, only in view1090.
For those who are interested in Mode A/C I’d suggest first pulling up view1090 --modeac and see the sort of garbage we’re dealing with
here’s a quick example. note that AFAIK, all that A/C only data is garbage, looks like single bit noise.
(key for interpreting the “mode” column:
S = Mode S
2 = ADS-B v2
a = Mode A/C matched with a Mode S target squawk
c = Mode A/C matched with a Mode S target altitude
A = Mode A/C not matched with a Mode S target, and could be a valid Mode A squawk
C = Mode A/C not matched with a Mode S target, and could be a valid Mode C altitude)
2 Likes
The only difference in the interface was a sharp rise in the Messages count. Maybe that made some people feel better?
Thanks for that explanation. I live in a very rural area. I’m going to spend some time today watching for A or C responses in view1090-fa. Aircraft are generally few and far between, so hearing something on the radio and correlating it to data in view1090-fa should be straightforward.
Isn’t the U2 coming back from the East a non-typical example though? It will have a unique squawk and almost certainly be at 60000’ on inital squawk allocation. You thus know far more than just the IDless RADAR ping. Similarly a bunch of eurofarce will be on a specificaly allocated squawk and not a generic conspicuity one. If close together, or perhaps the only users of a designated Danger Area, a flight might have a single squawk. If the latter then multilateration would be difficult. Of course, if operating with individual squawks and you know their altitudes then the connection between a multilaterated position calculation and a specific aircraft is easier to assume.
All of this requires other data - ie. voice reception to tie up a squawk code…how would the Flightaware automatic multilateration get that extra required data? I guess it could be set to alert for and track UFOs based on their flight level
For conspicuity squawks such as those for LARS monitoring there is the added problem of many aircraft at similar flight level and identical squawk.
As an aside - given that PlanePlotter omits certain aircraft I guess it doesn’t show the tracked U2 on it’s global feed, just on the display of those people who manually initiatiate a multilateration fix?
Yes it shows on the feed to anyone with that chart area open. Similarly F15s which are Mode A/C only. Just need a few more sharers with Mode A/C configured.
That is strange given their restriction on other SIGINT/COMINT assets being shown.