One web app controls passes, radios, and recording
Ground Station combines orbit tracking, a live SDR waterfall, rig and antenna control, signal decoding, and observation scheduling. Its FastAPI backend coordinates worker processes while a React interface shows targets, hardware state, audio, packets, and saved files. Scheduled jobs can start tracking at acquisition of signal, stop at loss of signal, and combine IQ or audio recording with decoding and optional transcription.
The broad scope is the reason to consider it. A SigMF recording can be replayed through the same processing path as live radio, including FFT display, demodulation, and decoders. Multiple SDRs can observe one pass, while isolated internal VFO sessions keep scheduled work separate from an interactive session. Two account roles, admin and operator, cover a small station better than exposing every control to every browser user.
Device coverage includes paths that remain untested or unfinished
The README names RTL-SDR over USB or rtl_tcp, local and remote SoapySDR devices, MiriSDR, UHD or USRP, and a virtual SigMF source. Rotator and rig integration use the usual radio control paths, including Doppler-corrected tuning. Release v0.8.6, published September 6, 2026, added MiriSDR support through SoapyMiri and shipped separate AMD64 and ARM64 container tags.
Support depth varies. Airspy HF+ is explicitly untested, and the architecture section labels some AFSK, LoRa, and GMSK decoder work as unfinished even though the larger feature list names those protocol families. Native LoRa development requires building GNU Radio 3.10 and gr-lora_sdr; the guide estimates 15 to 30 minutes for that GNU Radio build. The release image includes those pieces, which makes Docker the saner evaluation path for most operators.
What happened when we ran it
Our sandbox installed the Python backend in 95 seconds, adding 139 packages and using 505 MB on disk. The build step succeeded in 7 seconds. Tests exited 2 after 11 seconds, and pip-audit reported 3 known vulnerabilities. We ran commit 7846137 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets.
The failing log did not report any passed or failed tests. Instead, __main__.py printed the Ground Station application usage and rejected pytest options including -q, --maxfail=200, --continue-on-collection-errors, and --timeout=120. That is the complete supported conclusion: the test command and application argument parser collided in our environment. The log does not show which tests would pass after correcting invocation.
The checkout contained 2,328 files, about 246,507 source lines, and occupied 167.3 MB. Our scan found 3 CI workflow files and a tests directory, but reported no Dockerfile in the measured scope. The current README now describes a root multi-stage Dockerfile and published images. Our 7-second source build therefore says nothing about USB passthrough, SDR libraries, frontend startup, or hardware behavior inside v0.8.6.
Docker needs broad hardware access for the documented USB path
The release examples mount persistent data at /app/backend/data and expose the web interface on port 7000. Direct USB examples pass the bus into the container and use privileged mode. Remote SoapySDR discovery over mDNS also requires host networking; bridge mode works for local receivers and other features. Host administrators still need device-specific udev rules and must verify USB access before startup.
Those permissions deserve deliberate treatment on a machine that stores recordings or shares a LAN with other equipment. Put TLS and access policy at a reverse proxy, bind only where intended, keep the data mount backed up, and confirm the admin account after first setup. The project documents an Nginx route, but the sample container itself is reached over plain HTTP. A Raspberry Pi deployment is recommended only for Pi 5 hardware.
SDRplay adds a separate licensing wrinkle. The Docker build uses a pinned archive of the proprietary RSP API v3.15, verifies its SHA-256, and tells distributors to review its EULA. This is more careful than silently downloading a moving binary. It still means GPL-3.0 coverage of Ground Station does not make every bundled vendor component open source.
A single station still depends on several outside services
Orbit and transmitter data come from configured sources, with CelesTrak feeds and SatNOGS integration documented. Celestial and deep-space targets can call NASA JPL Horizons. Gemini Live or Deepgram power optional transcription and therefore bring separate credentials, network traffic, cost, and retention choices. SatDump can post-process IQ recordings for supported weather-satellite workflows.
The application can run without every optional service, but a planned observation must be tested with the exact combination it will use. Check orbital updates, clock and timezone, receiver selection, rotator limits, disk space, and loss-of-signal cleanup before leaving it unattended. Issue 86 reports that the setup wizard selected a local timezone but the dashboard came up as Europe/Athens until the preference was changed manually.
v0.8.6 is active enough to demand careful upgrades
GitHub recorded a last push on September 9, 2026. Ground Station had 4,771 stars and 13 combined open issues and pull requests when fetched. Fresh reports covered timezone selection, a default rotator port, direct antenna positioning, and another SDR request. That issue activity, together with v0.8.6 three days earlier, shows maintainers and users are currently exercising real station setups.
Fast releases also change operational behavior. v0.8.4 corrected a timezone interpretation bug in orbital epochs, while v0.8.3 changed recording controls and database restore handling. Pin a release tag, preserve the data volume, and rehearse restore before upgrading. Ground Station earns a trial for an experienced radio operator who wants integration more than simplicity, but the 11-second failed test run and 3 dependency findings keep it out of unattended duty until locally verified.