We Built a Live Aircraft Tracker from Scratch

Every commercial aircraft in the sky is broadcasting its position right now. On a frequency called 1090 MHz, transponders send out a signal called ADS-B — Automatic Dependent Surveillance-Broadcast. It includes the aircraft's GPS coordinates, altitude, speed, heading, and callsign. Anyone with a $30 antenna can pick it up.

We built a decoder from scratch that turns those raw radio signals into live aircraft on a map.

No borrowed decoder libraries. No wrappers around someone else's code. Every bit of the signal processing — from CRC validation to CPR position decoding — written from the ground up.

What You're Looking At

Visit the live site and you'll see aircraft moving in real time. Click one and you get its callsign, altitude, speed, heading, squawk code, and flight trail.

Switch to the 3D globe view and you'll see the same aircraft on a photorealistic Earth with altitude stalks showing exactly how high each plane is flying.

The About page covers the project at a high level. The Features page goes deeper into what the system can do. But here's the part we think is most interesting: how the signal chain actually works.

The Signal Chain: Radio Waves to Map Pins

The pipeline has seven stages, and each one had to be built from first principles.

1. Antenna receives the signal. A cheap RTL-SDR dongle tuned to 1090 MHz picks up the raw radio pulses that aircraft transponders broadcast. These are short bursts — 112 or 56 bits each — sent every half second or so.

2. Demodulation. The raw I/Q samples from the radio get converted into amplitude values. We look for the specific preamble pattern (eight microseconds of on-off-on-off pulses) that marks the start of every ADS-B message.

3. CRC validation. Every ADS-B message includes a 24-bit checksum. We run the message through a CRC polynomial to verify it wasn't corrupted in transit. Bad messages get dropped immediately — no point decoding garbage.

4. Message type identification. ADS-B uses different "type codes" for different kinds of information. Type 1-4 carry identification (callsign). Types 5-8 carry surface position. Types 9-18 carry airborne position. Type 19 carries velocity. We parse each type differently.

5. CPR position decoding. This is the hardest part. Aircraft don't broadcast regular lat/long coordinates. They use a compression scheme called Compact Position Reporting that alternates between "even" and "odd" frames. You need both frames to calculate the actual position. The math involves modular arithmetic across 15 latitude zones and requires handling zone boundary edge cases that break naive implementations.

6. Track assembly. Individual messages get assembled into coherent aircraft tracks. We maintain state for each aircraft — updating position, altitude, speed, and heading as new messages arrive. Aircraft that stop transmitting eventually fade out.

7. Display. The assembled tracks get served over a REST API to a web frontend that renders them on Leaflet.js (2D) and CesiumJS (3D globe). Updates happen in real time — you see aircraft move as new messages arrive.

The full technical breakdown is on the How It Works page.

Why Rust — And What We Learned Along the Way

The project actually started in Python. We built a working decoder, validated it against known-good data, and used it to prove the concept. Then we rewrote the entire thing in Rust.

Why? Three reasons.

Performance. Decoding ADS-B messages in real time means processing thousands of messages per second without dropping any. Python's GIL made this painful. Rust handles it without breaking a sweat.

Correctness. Rust's type system catches entire categories of bugs at compile time. When you're doing bitwise operations on radio signals, that matters. A lot.

Cross-compilation. The decoder runs on a Raspberry Pi connected to the antenna. Rust cross-compiles cleanly to ARM targets. Python's dependency management on embedded devices is a nightmare.

We cross-validated the two implementations against 296 real ADS-B frames. The Rust decoder matched the Python decoder on every single one — 100% parity. Then we threw away the Python version.

The test suite has 269 tests covering everything from CRC computation to CPR zone boundary edge cases. Clippy is clean. Formatting is enforced in CI. Four build targets (x86, ARM, aarch64, cross-validation) all pass on every commit.

Under the Hood

Beyond the core decoder, the system includes several features that pushed us into interesting engineering territory:

3D globe visualization. CesiumJS renders aircraft on a photorealistic Earth. Altitude stalks show how high each plane is. Flight trails persist so you can see where aircraft have been. You can rotate, zoom, and tilt the globe to any angle.

4D replay. Recorded data can be replayed at any speed. Watch a day's worth of air traffic in minutes. Useful for spotting patterns and analyzing routes.

Military aircraft detection. Certain ICAO address ranges and squawk codes indicate military, government, or special-status aircraft. The decoder flags these automatically.

Natural language queries. Ask questions like "show me all aircraft above 35,000 feet" or "find military aircraft near Asheville" and the system filters accordingly.

Multi-receiver federation. Multiple receivers can feed into the same server. The system deduplicates messages from overlapping coverage areas and merges tracks automatically. Each receiver authenticates with a unique token.

Maritime AIS. The same architecture handles ship tracking via AIS (Automatic Identification System) signals. Different protocol, same pipeline pattern.

Full security audit. Three parallel audit agents reviewed the codebase for injection vulnerabilities, authentication bypasses, and data exposure. All HIGH and MEDIUM findings were fixed before deployment.

The Setup page explains how to connect your own receiver if you want to contribute coverage.

Why We Built This (And What It Demonstrates)

This isn't a product we're selling. It's a demonstration of what we do.

When a client comes to us and says "I have raw data from [sensors / equipment / API feeds] and I need it turned into something useful" — this is the kind of project that shows we can deliver. Not because we specialize in aircraft tracking, but because the methodology is the same:

1. Understand the raw input. Whether it's radio signals, CSV exports from legacy software, or API responses from a vendor — start by understanding what you're actually working with.
2. Build the processing pipeline. Transform raw input into clean, structured data. Handle errors. Validate everything.
3. Make it useful. A database full of decoded messages isn't valuable. A live map with real-time updates is.
4. Make it reliable. 269 tests. Security audit. Monitoring. Error recovery. Production systems need all of it.

That's the same process whether we're building a client dashboard, setting up workflow automation, or decoding radio signals.

If you're curious about what custom software costs and how the process works, we wrote an honest guide to custom software pricing. And if you're not sure whether you need custom software or something off-the-shelf, here's our take on why businesses need a technology partner, not just AI.

Try It Yourself

See it live: adsb.blueoctopustechnology.com — watch aircraft move in real time on a 2D map or 3D globe.

Read the code: github.com/blueOctopusAI/adsb-decode — everything is open source. The README walks through the architecture, and every module is documented.

Set up a receiver: The setup guide explains what hardware you need (about $30) and how to connect it to the system.

---

Have a project that involves processing raw data into something useful? That's what we do. Start a conversation — we'll figure out the right approach together.

Blue Octopus Technology builds custom software, integrates AI, and automates workflows for businesses ready to grow. Based in Franklin, NC — serving clients nationwide.