Dan the IT Man
ProjectsAircraft trackerEngineering notes

A HOME LAB SYSTEM, FROM RF TO RECOVERY

Radio to browser.

Receiving an aircraft message is the beginning. The interesting part is deciding when to trust it, what to publish, and how the system recovers when something stops working.

Try the signal lab Open the aircraft map
BUILD STATUS

The server and public interface are built. The antenna and SDR are on the way. The public feed stays in waiting; there are no real aircraft observations yet.

EXPLORE THE BEHAVIOR

What happens when
the signal stops?

Replay fictional aircraft messages, introduce a fault, and inspect what the display keeps or clears. The signal lab uses the map’s actual browser-side validation and freshness rules.

Run a simulated scenario

Browser-only simulation. No radio, private receiver connection or live traffic.

INPUT → DECISION → DISPLAY

  1. 01
    Fresh aircraft fieldsValidate types, bounds and age.
    ACCEPT
  2. 02
    A position ages outRemove its coordinates.
    EXPIRE
  3. 03
    The feed becomes staleClear aircraft from the view.
    CLEAR

These are rules to exercise, not a live system readout.

01 ARCHITECTURE

Small at the edge.
Observable on the server.

Equipped aircraft broadcast identity, position and motion using ADS-B. This build starts with reception at 1090 MHz: an antenna and USB radio connected to a Raspberry Pi 4.

The Pi will decode near the antenna. Processing, monitoring and recovery live in a dedicated Proxmox virtual machine. That separates a replaceable radio appliance from the services I want to inspect and maintain.

ADS-B background · FAA
THE SYSTEM AND ITS BOUNDARIESSelect a stage to inspect its role
01 / HARDWARE ORDEREDAntenna + SDRTurn radio broadcasts into a digital signal.Inspect hardware

A 1090/978 MHz antenna and AirNav FlightStick are ordered. Initial reception will use 1090 MHz.

Placement, cable loss and gain still need measurement. An ordered antenna is not evidence of coverage.

02 / PI ON HANDRaspberry Pi 4Decode locally; forward timestamped messages.Inspect the edge

The planned Pi service is readsb, forwarding Beast messages to the server. Keeping the RF cable short is an installation goal.

OS, power, storage and network setup remain to be inspected. A source-restricted ingest path must be tested before connection.

03 / DEPLOYED PRIVATELYProcessing VMDecode, validate, monitor and recover.Inspect the services

Ultrafeeder and a custom collector handle messages and approved fields. Prometheus and Grafana track service health and message progress.

All four services share an internal container network with no published application ports. Operator access uses SSH forwarding.

04 / INTERFACE PUBLISHEDAircraft websiteShow approved data with an explicit age and state.Inspect publication

The public site currently serves an empty waiting feed. Its fictional examples and signal lab are separate, labeled browser experiences.

A live connection to the private collector is still pending a privacy review and a narrowly scoped transport.

Receiver → Pi → VM: connection pendingVM → website: live publication pending
The stages describe the intended data path. The deployed private services and published website are currently separate systems.

02 THE DATA CONTRACT

A healthy process
can have an unhealthy feed.

Service availability, message progress and position freshness are separate questions. The system checks each one.

Require progress before calling it live.

The private collector requires fresh snapshots with advancing timestamps and message counts. A successful health check only says the process is responding. Waiting for hardware is a valid state, so receiver-inactivity alerts stay disarmed until commissioning.

Make old data disappear.

Positions expire after 15 seconds; aircraft records after 30. A stale or failed feed returns no aircraft. The browser checks the received data again and ages it locally, so a stopped stream cannot leave its last positions looking current.

waitinglivestale / error

Build a new object at the boundary.

The collector copies only approved scalar aircraft fields into a new response. It validates types and bounds, drops unknown and nested fields, and keeps no aircraft history on disk.

SELECTED AIRCRAFT DATA
Identity, position, motion and freshness.
STAYS PRIVATE
Receiver metadata, signal measurements, distance and bearing, operator maps and metrics.

Coverage patterns can still suggest a receiver’s general area. Real public observations need a separate coverage and delay policy; removing a home marker is insufficient.

03 A FAILURE WORTH FINDING

The first backup
refused to finish.

A clean shutdown is part of a consistent application backup. The first attempt found a problem before any receiver was connected.

  1. DETECTED

    A service did not stop cleanly.

    Telegraf’s supervising shell deferred its termination handling. The backup refused a forced-stop snapshot and restarted the four services.

  2. CORRECTED

    Fix the shutdown path, then repeat it.

    A local service override replaced the shell process with its supervisor. Two isolated shutdown and restart cycles completed cleanly before the production replacement.

  3. RESTORED

    Open the recovered applications.

    An independent backup copy restored 310 files with matching hashes, sizes, modes and ownership. Restored Grafana accepted login and served its dashboard; restored Prometheus recovered the recorded series.

Verified scope: application files and cached-image Grafana/Prometheus recovery. Full VM recovery, recovery without image layers, off-site backups and a Pi rebuild remain untested.

04 EVIDENCE, WITH LIMITS

What has actually
been exercised.

Private server checkpoint: October 16, 2026. These results establish software behavior and application recovery. RF performance is still unknown.

42 + 7source checks passed
42 collector checks cover filtering, freshness and failure behavior. Seven backup safety tests cover guarded capture and restoration of the prior running state.
6isolated decoder checks
The pinned readsb decoder processed valid synthetic Beast messages. Checks covered fixture isolation, waiting, decoding with filtering, position expiry, message staleness and decoder failure.
RESTOREindependent copy verified
310 restored files matched. Grafana and Prometheus were exercised in isolation while the deployed service identities and volumes were preserved.
REBOOTguest recovery passed
All four services and monitoring targets returned healthy after a processing-VM reboot. Physical-host and Pi reboot recovery remain untested.

COMMISSIONING GATES

The next test
comes over the air.

Hardware arrival begins a new validation phase. The software checks cannot establish reception, range or thermal stability.

  1. 01

    Inspect and connect

    Confirm Pi OS, power and storage, identify the SDR, and test both permitted and denied clients against the restricted ingest path.

  2. 02

    Measure and interrupt

    Verify real timestamped messages, time sync, disconnect/reconnect and reboot recovery. Measure temperature, gain and directional coverage at the actual installation.

  3. 03

    Review before publishing

    Audit the real output and privacy policy before connecting the public feed. Third-party feeding, MLAT, notifications and an Atlas aircraft layer remain future work.

Built with open-source tools.

readsb decodes the messages. SDR Enthusiasts’ ultrafeeder brings the receiver software together. Prometheus and Grafana support the private monitoring side. The readsb JSON schema informs the explicit data boundary.

A personal learning project. The map is not an air traffic control, navigation or emergency service.

Explore the signal lab