Build a Raspberry Pi ADS-B Feeder

[Pavel]

Short answer: Build the feeder in layers: stable RTL-SDR, local readsb or dump1090 decoding, local map, then one or more feeder clients consuming the decoder's network output. Only the local decoder should open the USB radio.

Before you start​

• Prove the SDR on the Raspberry Pi interactively before turning it into a service. Record the device serial, USB path, driver and sample rate.
• Use a power supply, cable and USB topology that can support the Pi and every attached SDR under sustained load.

Step-by-step method​

1. Step 1: Install and test the dongle, 1090 MHz antenna and manual gain with a local decoder. Confirm aircraft and message rate before entering any external account details.
2. Step 2: Set approximate receiver coordinates privately in the decoder or feeder configuration and protect feeder identifiers. Do not publish exact home coordinates in screenshots.
3. Step 3: Configure feeder clients to read Beast or AVR data from the local decoder's port rather than each trying to claim the RTL-SDR.
4. Step 4: Enable services at boot, rotate logs and monitor temperature, disk use, message rate and last successful feed connection for several days.

Concrete example​

A clean topology is RTL-SDR → readsb → local map plus network outputs → feeder clients. Starting separate dump1090 instances for each network creates USB conflicts and inconsistent gain settings.

How to judge the result​

The feeder is healthy when local decoding continues even if an external network is unavailable, services recover after reboot and no client exposes credentials or precise private location publicly.

What to record​

• Run a sustained stream while monitoring undervoltage, USB resets, CPU temperature, dropped samples and storage growth.
• A headless service should restart cleanly, wait for networking and the SDR, write bounded logs and expose a health check.
• For remote access, prefer a VPN and least-privilege accounts instead of exposing receiver-control ports directly to the internet.

Common mistakes​

• Changing several hardware, software or RF variables at once, which removes the controlled comparison needed to identify the cause.
• Treating one autoscaled screenshot or one unusually good result as proof without recording the settings and repeating the test.
• Installing a full feeder image before proving antenna and local decoder performance makes RF faults harder to separate from account and network setup.

Final check​

Reboot the Raspberry Pi and reproduce the complete service or stream without an interactive login. Check power, USB, logs, storage and remote access before leaving it unattended.