If you are looking to understand the entire sequence of what it takes to identify that aircraft that's passing overhead, here's a list of the components I'm using at home to power a web site that I can view from anywhere to identify aircraft - or blimps - overhead.
This is not the easiest of tutorials, as many of these parts have their own levels of expertise. I've assembled this plane spotting stack over the course of about two years, and in that time some of the design decisions have changed. In any case, this is mostly what I'm running right now on this site:
The parts, in order.
- Aircraft ADS-B transponder
- 1090 MHz antenna
- RTL-SDR USB tuner
- Raspberry Pi
- Packet server
- Wireguard hub
- Name server
- Let's Encrypt
ADS-B is a standard for aircraft self-reported position information. Aircraft have transponders that broadcast on 1090 Mhz details such as airspeed, location, direction, and flight status. A "squawk code" (discrete transponder code) is set at the aircraft to identify it to air traffic controllers.
There is a US Federal deadline of January 1, 2020 for aircraft operating in Class A, B, and C airspace to have equipment capable of transmitting ADS-B signals.
The Garmin GTX 335 is one of several devices available to the general aviation pilot to satisfy this requirement. It has a a digital display, a pressure altitude readout, and push buttons for squawk code entry. It weighs about 3 pounds and costs about $3000.
You don't need to have a commercial receiver to pick up ADS-B signals. A software-defined radio with a simple antenna can hear signals from tens of miles away, and a well-designed antenna with a good view of the sky can have a reach of hundreds of miles.
1090 MHz antenna
The 1090 Mhz frequency travels by line of sight. Fortunately the airplanes are way up in the sky. With good conditions including a properly designed antenna with a clear view of the sky you can see hundreds of miles.
The antenna I have does not have a clear view of the sky, and the attic roof quite evidently blocks some signals. The best installations go outside. You can run power over ethernet to a small computer inside an outdoor enclosure, and then have a very short antenna feed line.
The antenna designs are generally pretty small, so even an indoor setup is unobtrusive.
RTL-SDR USB tuner
The antenna plugs into a USB tuner stick with an RTL chip on it, originally designed to receive European TV broadcasts. The drivers have been tuned to pick up raw radio signals that are decoded in software on the attached computer.
A number of companies make SDR tuner sticks. I have liked the support from Nooelec. Flightaware makes a special tuner that also has a 1090 Mhz filter and amplifier in it, which should improve reception.
The tuner stick is plugged into a Raspberry Pi in my attic. It's a Pi 2, with 4 32-bit armv7 cores at about 900 Mhz and 1 GB of memory. Surprisingly, that turns out to be plenty for the task at hand of decoding SDR transmissions.
The Pi 2 is kind of slow if you want your system to do more things, and a modern build would probably start with the 64-bit Pi 3 B+.
There are lots of systems that are better than a Pi for some measure of better (faster network, more memory, faster CPU, more reliable power, better storage). The next system I want to try once I convince myself that the kernel support is good enough would be the RK3399 based RockPro64 or Rock Pi 4.
Operating system for the Pi: Hypriot
I'm running Hypriot on the Pi, an operating system with a Debian userland and a kernel designed to run Docker out-of-the-box. When first developed by a crew in Germany a few years back, this was a remarkable configuration, since otherwise building your own kernel to run Docker was a long painful compile.
Now days, there are lot more choices for operating systems. In particular, there are a number of mainstream distributions (Fedora, SUSE) that support a 64 bit userland on the Pi 3. If I were to swap this partiular computer out for a new one, I'd think hard about moving to Fedora.
dump1090 is the software that listens to the SDR tuner and decodes the 1090 MHz transmissions. It's been developed by a number of people over the years, and forked several times either to make radio improvements or to provide a nicer user interface.
The fork I am tracking is the "mutability" one, which has the right balance of good user interface design and impressive performance at decoding. The other software that would be worth evaluating in a rebuild is from Flightaware and is called PiAware; it has a slightly shinier user interface.
The configuration for dump1090-mutability is designed to go with the lighttpd web server. As the name suggests, this is a lightweight web server designed for systems like the Raspberry Pi that don't have much memory. The configuration is fairly simple.
Earlier versions of dump1090 had a built-in web server, but the cost and complexity of maintaining server code (especially when so many alternatives were available) prompted discontinuation of this part of the codebase.
The computer that sits in the attic is behind a firewall provided by my ISP (ATT Uverse). For lots of reasons I want to be able to reach it from other parts of the net, either to provide data for public services or for remote management and administration.
Wireguard is VPN software that's implemented in the Linux kernel. It runs on all of the systems I care about (Linux, Mac, Android) and has a small footprint. The software is still under vigorous development, so right now you would only want to run it where security needs allow you to be an alpha tester.
A previous iteration of this remote access setup originally used an SSH tunnel, and then subsequently was configured with OpenVPN. I prefer Wireguard to both of them, because it's that much smaller (ideal on a Pi) and because the development of kernel-based VPN services promises to ease everyone's burden. The configuration file is compact and easy to set up, and it performs as well as I need it to.
I'm using a Packet t1.small server as the hub for this effort. It's really helpful to have a server in a data center with a fixed IP address and a reliable network to help bootstrap the more transient and less reliable parts of the infrastructure.
In previous designs, I had used an AWS EC2 server instance as the core of the design. All you really need for the minimum configuration is something with a permanent IP address and enough disk to store logs and configuration files. It happens that this server does a lot more stuff than just airplane tracking, so it was a minimal additional effort to make it happen.
As noted above, Wireguard also runs on the data center server as the central hub of a VPN network. This lets me connect my laptop at home, my laptop that travels with me, the attic Pi, an Arm server, and a few Pis that are only occasionally powered on into a single network with connectivity among all of them.
I am not currently using the Wireguard system as a general purpose VPN to transit all of my web traffic; that's possible, but it can be complex to get all of the portable cases right.
The key to getting a set of machines to work together is the configuration at the hub, which needs to have a couple of iptables rules installed to proxy traffic between the endpoints. I'm still sorting out how to best minimize the amount of effort to set up a new machine.
In a previous design, the hub acted to assign certificates to OpenVPN clients using a "salt" configuration. This was very nifty but somewhat brittle; it worked great when it worked, but I never really fully understood it. Wireguard is so much simpler that this mechanism is not needed.
The modern Internet runs on HTTPS, not HTTP, as a result of decisions by browser vendors like Google to prefer encrypted transport. This means that even simple trivial setups really want to have names for all of the hosts, rather than just using numerical addresses inserted into /etc/hosts.
I've been running a DNS server on AWS "Route 53" for a long time, and it's completely functional for this purpose. There are lots of web-based name server admin tools these days and one of them might be right for you.
If I were to do this differently, I'd run CoreDNS as the authoritative server for the domain, and host my own zone files. CoreDNS is very flexible and has lots of customization for service discovery, in such a way that it's a fine companion to Kubernetes. For this exercise the name server has not been the critical path just yet.
Because we need certificates for HTTPS, and because we're not about to go buy them from somewhere, it was super useful that the Let's Encrypt project was set up to support self-service HTTPS certificates with easy renewals.
Let's Encrypt assigns you a relatively short lived certificate upon confirmation that you control a domain name, e.g. by placing a special file into a well-known location in a web server, or by adding records to a name server. The process is largely automated.
Be aware that by default Let's Encrypt will use an IPv6 address if your DNS advertises one, and so which ever web server you use to verify yourself will thus need to support IPv6 to answer the challenge.
nginx is a web server that includes proxy and routing capabilities. It's very powerful, and can handle a high volume of traffic.
The proxy service allows a nginx front end to pass through traffic to another server - either running on your localhost as a microservice, or running on a remote system - and rewrite it so that it comes from the nginx server itself.
The final piece of the Pi puzzle has been to use nginx to front the lighttpd server on the Pi over the Wireguard VPN.
nginx can do caching, which should speed up initial load of the dump1090 front end code. I haven't gotten there yet.