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
- Hypriot
- dump1090-mutability
- Wireguard
- Packet server
- Wireguard hub
- Name server
- Let's Encrypt
- nginx
ADS-B
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.
Raspberry Pi
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-mutability
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.
lighttpd
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.
Wireguard
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.
Packet server
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.
Wireguard hub
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.
Name server
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.
Let's Encrypt
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
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.
