ADS-B Aircraft Tracker: From RF Hardware to Real-Time Detection

To catch the signals, I used an RTL-SDR, a cheap USB radio stick originally designed as a digital TV tuner. It turned out to be capable of tuning to 1090 MHz as well, which helped fuel the recent growth in RF engineering and experimentation. I plugged it into a Raspberry Pi 3B so the receiving station could run quietly around the clock. After flashing my Raspberry Pi SD card with the ADS-B Exchange station image, I wrote a small Python service and packaged it in Docker so it would be easy to start, restart, and recover if the station lost connectivity. The service then takes each decoded ADS-B message and writes it into a PostGIS database.

I like PostGIS a lot. I work with PostgreSQL regularly, and with my background in GIS, I appreciate having spatial data readily accessible. So I chose PostgreSQL with the PostGIS extension. While you can store latitude and longitude as plain numbers in almost any database, PostGIS treats them as real locations with georeferencing, so I can run faster spatial queries. I can ask which aircraft passed within five kilometers of a specific point, or which compass directions my receiver is hearing best. A live map of moving points is not really the focus here, so this local PostGIS database does not need to be especially fast. I can use a nightly runner to pull data down into my local database. I wanted to be able to extract insights that accumulate over time, such as which aircraft keep returning day after day. I also loaded a reference table of about 520,000 aircraft from a public registry, because the identifiers a plane broadcasts, a short hex code and a callsign, say almost nothing on their own. Matching them against that table turns a bare code into the operator, the registration, and the aircraft type, and that context lets me ask more meaningful questions.

There was still a speed problem to solve. Since I was sending every message into one enormous raw table, re-running the same heavy geographic query against millions of rows each time the page loaded was becoming painfully slow. So I created materialized views, which are precomputed answers to queries that the database refreshes on a schedule. A handful of questions come up most often: where air traffic is concentrated, which directions my receiver covers best, and which aircraft behave differently from ordinary commercial routes. All of them now read from these views, so the dashboard stays fast.

On top of the database, I built a small API with FastAPI, using Python and an existing framework I already knew. I exposed twelve endpoints for the statistics, positions, routes, and range data I was interested in. The dashboard itself is a React app that draws the map and charts using Leaflet.js. The whole project runs together via Docker Compose inside a Linux environment (WSL2 Ubuntu), managed by Windows so it can start on its own and keep running without me forgetting to launch it.

One evening, the detector began flagging many messages simultaneously. Two rules fired at the same time across several aircraft in the same area: night_operations and low_altitude_ops (1,000 to 3,000 ft above ground level). The aircraft were flying low and repeatedly over the same urban corridors, with a single aircraft holding higher up.

One aircraft in the same airspace was stranger still. It broadcast only its position with no callsign attached, it flew back and forth at a constant altitude in a pattern that did not match any normal commercial route I could find, and its hex code returned no matching entry in any public registry I could find. In Colorado, that is not too unusual. Buckley Space Force Base is not far away, and there are many coordinated training and rescue operations involving national and state guardsmen in Colorado, given the state's strong aerospace presence and rugged terrain.

Thanks for reading this little post. To summarize, this project runs as a live 24/7 production system. I keep the dashboard reachable only from devices on my own local network, and the ingest pipeline never sends data anywhere outside it. Contacts and detections keep building up locally in my database, with 1,083,226 position messages as of the last count.

Source available on request.