AF1W

ADS-B Overview

I’ve been getting into monitoring air traffic with ADS-B lately. Initially I was just using ADS-B Exchange over the web to monitor Boston area news, medical, and police helicopters, but then got into monitoring over the air.

For what it’s worth, I bought one of these receivers, paired with a big antenna from DPD Productions. I was pleasantly surprised to find that the image on the microSD card is pretty much plug and play with a Raspberry Pi, giving me something like this:

Screenshot of tar1090 software, showing airplanes overlaid on a map out to a range of approximately 100 miles.

But how does any of this work? I think it will make much more sense to start with some history.

Secondary Surveillance Radar

“Normal” radar used for air traffic control (or just about anything else) can capture that there’s an airplane out there, and an advanced radar could tell you its velocity and a rough estimate of size. But in wartime, it was missing a very important piece of information: is it one of our planes, or is it an enemy? Should we shoot it down, or prepare a welcome party?

So a sort of “two-way” radar (not entirely based on the principles of radar) was developed for use in WW2, called IFF: Identification, Friend or Foe. Instead of just sending a radar pulse and listening for the reflection to gauge distance, it would transmit an interrogation signal, and a transponder in the aircraft would automatically give a coded response indicating that it was a friendly airplane.

This gave way to transponders being used in peacetime. Radar at airports was updated to have a second antenna above the main reflector (see this Wikipedia image), which would transmit an interrogation on 1030 MHz. A transponder aboard the plane receiving such a signal would respond on 1090 MHz with a “squawk” code, a 4-digit (octal) code normally assigned by the air traffic controller. This gave air traffic controllers the ability to identify what they were seeing on their screens. This is sometimes known as “Mode A.”

As an aside, the interrogations and replies are all very brief: on the order of microseconds.

Mode C

That’s all well and good, but it had some major limitations. For one, Mode A helped identify what was on the screen, but radar isn’t great at identifying elevation particularly accurately. With a lot of planes in the sky that will necessarily have their paths intersect at some point, vertical separation is important, and it would sure help if ATC had accurate elevation information. Much of this is in the pre-GPS days, so altimeters were (and largely still are) based on barometric pressure. Mode C allowed aircraft to, beyond squawking their identifier code, indicate what their altimeter showed.

Mode S

Mode S was the beginning of some big changes, though it took care to preserve backwards compatibility.

While a four-character octal squawk code is still sent, Mode S adds a 24-bit identifier allocated by the International Civil Aviation Organization (ICAO), which is unique. This way, instead of 4,096 possible unique identifiers, there are 2^24 (equal to 256^3 for those who think that way), or nearly 17 million, possible codes.

Mode S also permits interrogating a single plane by ICAO code, rather than the broadcast interrogations of earlier modes.

Mode S, as I understand it, would also form the basis of ADS-B.

ADS-B

ADS-B extends Mode S transmissions, but also introduces a fundamental shift: instead of ground radar stations sending interrogation signals, aircraft equipped with GPS/GNSS simply beacon their location autonomously. By relying on GNSS data aboard the plane, the position information is much more reliable.

Another benefit of this is that it enables aircraft to see each other, by listening for ADS-B messages with location information from other aircraft.

The most common type of ADS-B signal is essentially an enhanced Mode S transmission on 1090 MHz. There is another, less common implementation on 978 MHz known as UAT, but it does not yet have international adoption (it is primarily US-only), and only approved for use below 18,000′, so its use is typically limited to small general aviation aircraft (think small Cessnas and such).

MLAT

Not all aircraft are using 1090ES. As best as I can tell, some planes simply never updated to ADS-B at all, but do have traditional Mode S transponders. (It is also my understanding that planes using 978 MHz UAT for ADS-B are required to have a Mode S transponder, since so much is still expecting that.)

How do you track a plane that isn’t transmitting position data? Radar! Well, wait, that doesn’t help us. But there’s another option:

Multilateration! (Shortened to MLAT.) If you compare the differences in arrival time at multiple receive sites of a Mode S transmission, you can (to use the wrong term for simplicity) triangulate its location. This is known as time delay of arrival (TDOA) multilateration.

The ADS-B Exchange has an MLAT Feeder Map, whose output can be a little confusing. Here’s me:

A map showing an ADS-B receiver named "Lowell_MA" with connections to other stations in Maine, New Hampshire, Montreal, and within Massachusetts.

You can also view a list of peers, though the page has an infuriating auto-refresh. On the map view, the lines indicate stations with a shared view of planes that have helped “solve” locations with me, as best as I understand it.

Planes shown on the map with “MLAT” as the source are Mode S planes without location information being transmitted, but being seen by four or more participating ground stations which were able to compute a location.

Truth be told, while I understand the science behind TDOA and MLAT, I’m curious about how it works as well as it does. We’re measuring the difference in arrival times of signals traveling at the speed of light. A timing error of about 4 microseconds should introduce about a kilometer of error. System clocks disciplined by NTP can get into the sub-millisecond level, but you’re not going to get microsecond-level accuracy. And then there’s the receive chain: we’re reading data from the tuner over USB, and then processing it in software. None of that has a deterministic delay. MLAT with USB tuners on Raspberry Pis shouldn’t work.

But it does. And that intrigues me—I assume there’s some clever stuff being done, but I don’t know what it is.