How to Build an OpenClaw Raspberry Pi ADS-B Flight Tracking Agent

An ADS-B flight tracking agent decodes 1090 MHz transponder signals from aircraft and archives flight tracks. On a Raspberry Pi, that job splits into three layers.

The radio layer is an RTL-SDR dongle, a cheap software-defined radio tuned to the 1090 MHz band. Aircraft broadcast ADS-B position, altitude, velocity, and callsign on this frequency, unencrypted, roughly once per second while airborne.

The decoder layer is dump1090, an open-source program that reads raw samples from the SDR and turns them into structured messages. Mictronics maintains the most active community fork, and FlightAware ships its own build used by its feeder image. Dump1090 exposes decoded data over a TCP port in Beast or SBS (BaseStation) format, publishes a JSON snapshot of currently visible aircraft, and optionally serves a small map UI.

The agent layer is where most home projects stop. Typical tutorials feed data to FlightAware, FlightRadar24, or ADS-B Exchange in exchange for free premium access, then let those services own the archive. That works if you want to contribute to a shared network, but it leaves you without a personal history. You cannot rerun a query against last Tuesday's traffic, cannot train a model on your own feed, and cannot hand the archive to a teammate without granting them third-party access.

An agent-driven archive solves that. Instead of only forwarding, a small process on the Pi watches dump1090's outputs, rolls them into time-bucketed files, enriches them with context, and ships them somewhere durable. OpenClaw is one option for that agent: it runs on the Pi and can drive file operations, shell commands, and API calls on a schedule or in response to events.

Helpful references: Fastio Workspaces, Fastio Collaboration, and Fastio AI.

You can build a capable receiver for under $100. The minimum viable kit:

• Raspberry Pi 4 (2 GB or 4 GB) or a Pi 5. A Pi 3B+ still works but is tight once you add enrichment.
• RTL-SDR Blog V3 or V4 dongle, the community-standard receiver. The purpose-built FlightAware Pro Stick Plus has a 1090 MHz saw filter built in and runs quieter in RF-noisy areas.
• 1090 MHz antenna. A simple coaxial collinear antenna works for a few kilometers indoors. A proper outdoor antenna like the FlightAware 26-inch or a DPD Productions 1090 MHz vertical gets you the real numbers.
• Low-loss coax (LMR-240 or LMR-400) between antenna and dongle. RG-58 is acceptable for short runs.
• 32 GB microSD card, a reliable power supply, and a case with airflow.

RTL-SDR dongles can receive ADS-B at 200+ km range with good antennas, clear horizons, and properly tuned gain. Indoor setups with a stock whip typically see 30 to 80 km. Roof-mounted antennas on a clear line of sight regularly clear 300 km, and operators with elevated sites in flat terrain have reported single-aircraft receptions beyond 400 km.

Two factors dominate real-world range. First, ADS-B is line-of-sight at microwave frequencies, so antenna height matters far more than radio sensitivity. An extra three meters of antenna height routinely doubles the number of aircraft seen. Second, 1090 MHz sits in a crowded band with cellular and pager traffic nearby, so filtering and gain tuning (usually between 40 and 49 dB on RTL-SDR) matter more than chasing a more expensive radio.

Start with a fresh Raspberry Pi OS Lite install. Update the system, then install the RTL-SDR userspace library and a dump1090 build. Most operators pick one of three paths.

The first is the Mictronics fork of dump1090, which is actively maintained and adds the web UI most people recognize. The second is FlightAware's piaware image, which bundles dump1090-fa, a feeder client, and a preconfigured map at port 8080. The third is readsb, a more modern decoder that supports multiple receivers and better aggregation for larger setups.

Whichever build you pick, the install follows the same shape. You flash the OS, enable SSH, blacklist the kernel DVB-T driver that otherwise claims the RTL-SDR dongle, install the decoder package, and confirm it can see the radio. Once running, dump1090 typically exposes three useful endpoints on the local network:

• A TCP port (usually 30003 for SBS/BaseStation format, 30005 for Beast) that streams every decoded message.
• A JSON aircraft snapshot updated every second, describing currently visible aircraft with ICAO hex, callsign, position, altitude, speed, and signal level.
• A web UI on port 8080 or similar, useful for confirming things work and for visualizing local traffic.

Before you invest in the agent layer, let it run for an hour with the default web UI open. If you are seeing a realistic traffic pattern for your location, the hardware is doing its job.

Give your flight archive a home that survives the Pi

Fastio's Business Trial includes 50 GB of storage, included credits, and no credit card. Ship your dump1090 output into a shared workspace your agents and teammates can query. Built for openclaw raspberry ads flight tracking agent workflows.

Start 14-Day Trial

FlightAware feeder, FR24 feeder, and ADSBexchange-feeder all do the same core job: read from dump1090, send to a central service, receive a small thank-you in the form of premium features. They are well-engineered, easy to install, and worth running if you want to contribute to a shared network.

They are not, however, a personal archive. The raw stream you see locally only survives as long as your feeder keeps sending. If you want to ask questions like "how many military aircraft appeared over my county last month" or "what was the altitude profile of every departure from that nearby field at 6 am," you need your own copy of the data before any upstream service summarizes or filters it.

A custom agent fills that gap. The job description is simple. Read the dump1090 message stream continuously. Roll it into time-bucketed files, typically one per hour or one per day, in a compact format like newline-delimited JSON or compressed CSV. Upload each bucket to durable storage as soon as it is finalized. Retry on network failures without losing data. Optionally enrich each flight with a lookup against a public aircraft registry so you can query by operator or type later.

None of this requires heavy infrastructure. It does, however, benefit from the agent layer sitting a level above a cron job, because the work is event-driven and the errors (flaky home internet, dongle disconnects, SD card full) are the kind of thing that reward a retry-and-notify loop rather than a one-shot script.

OpenClaw positions itself as an agent framework that can run on a Raspberry Pi and drive local apps, shell commands, and external services. Community tutorials published in 2026 walk through turning a Pi into an OpenClaw-powered assistant that can control other applications and automate tasks, which maps closely to what you want for a flight archive.

At a capability level, the agent on the Pi needs to do four things. It needs to read structured output from dump1090. It needs to maintain a small amount of state, like the current rolling file handle and the upload queue. It needs to make network calls out to a storage backend. And it needs to recover gracefully when the Pi reboots or the network flaps.

If you are evaluating OpenClaw for this role, pin your configuration to whatever the current official documentation recommends for long-running tasks, and keep the agent scoped narrowly. One agent, one job: read from dump1090, write to files, hand off to an uploader. Resist the temptation to chain a dozen capabilities into a single process. Flight tracking runs for months at a time, and the more code paths the agent owns, the more ways it can wedge itself at 3 a.m.

The alternative, if you prefer a lower-level approach, is to skip the agent framework and write a small Python or Go service that does the same thing. Tools like pyModeS and dump1090-tools have years of use behind them. The reason to pick an agent framework instead is that the archive is not the whole story. Once the data is flowing, you probably want to ask questions about it, and agent frameworks are built to combine file operations with an LLM loop over the same data.

Local storage on a Pi is the wrong place to keep months of ADS-B history. SD cards wear out, Pi power supplies fail, and losing a year of traffic because a single card died is a genuinely frustrating experience.

The usual options for the archive tier are S3 (or an S3-compatible target like Backblaze B2 or MinIO), Google Drive or OneDrive via rclone, or a NAS if you run one. Each trades off cost, simplicity, and how useful the data is once it lands.

Fastio fits here as a workspace layer built for agent-produced output. You upload a rolled file, it lands in a shared workspace alongside any other telemetry archives you keep, and Intelligence Mode indexes the content so you can ask plain-language questions over it later. That matters for flight data, because the interesting queries ("show me every helicopter that hovered near the reservoir last weekend") are awkward to express in SQL but natural in chat over an indexed archive.

A few Fastio properties are worth knowing about for this kind of build. File versioning means a replayed hour does not silently overwrite the prior copy. Granular permissions mean you can hand a read-only view to a friend interested in a specific airport without exposing the rest of your feed. Webhooks mean a downstream process can react the moment a new hourly file arrives. And the Business Trial (50 GB storage, included credits, no credit card) is generous enough to carry a typical home feeder for a long time before you think about paying.

Whichever backend you pick, the uploader should do three things: verify the local file is closed and complete before uploading, confirm the upload succeeded before deleting the local copy, and log every upload with timestamp and size so you can reconcile against dump1090's own counters later.

Three failure modes account for most operator-hours lost on Pi-based receivers.

The first is the dongle disappearing. RTL-SDR dongles on powered USB hubs are usually fine, but a marginal PSU on a Pi 4 with a dongle and an active antenna will reset under load. Use an official power supply, and if the dongle still vanishes, move it to a powered hub.

The second is SD card exhaustion. Dump1090 is not especially log-happy, but distribution logs, journal logs, and any local rolling files compound over months. Either ship finalized files off the Pi promptly, or run dump1090 and your agent with reduced log verbosity and a systemd-journald size cap.

The third is silent decoder drift. A receiver can run for weeks with correct-looking stats while the agent has stopped uploading because an auth token expired or the storage quota filled. Build a simple heartbeat. The agent writes a heartbeat.txt file to the archive every fifteen minutes, and an external check (a cheap uptime monitor, or a second script that reads the latest heartbeat) pages you if the file goes stale. This is worth more than any amount of decoder tuning, because it turns "my feed has been dead for nine days" into "my feed has been dead for fifteen minutes."

Once you have that loop, the rest is mostly antenna work and patience. Flight tracking is one of the rare hobbies where small improvements compound visibly, and a well-placed outdoor antenna on a stock RTL-SDR setup keeps surprising people with the numbers it produces.