Stop Paying for Satellite Tools! ground-station Is Insane

What if I told you that everything you need to track satellites, decode mysterious radio signals from space, and build a professional-grade ground station is sitting on GitHub right now—completely free?

Here's the painful truth most developers and radio enthusiasts learn the hard way: commercial satellite tracking software costs thousands of dollars. SDR tools are fragmented across a dozen incompatible applications. You're juggling GQRX for spectrum analysis, Orbitron for tracking, random Python scripts for decoding, and praying nothing crashes during that precious 10-minute satellite pass. Miss the window? Wait another 90 minutes. Or another day. The frustration is real.

But what if one open-source project eliminated every single one of these headaches?

Enter ground-station—the all-in-one satellite monitoring suite that's making professional radio astronomers and amateur satellite operators do a double-take. Built with modern web technologies, powered by serious DSP engineering, and designed to run on everything from a Raspberry Pi to a beefy server, this isn't your grandpa's satellite tracking software. This is the ground-station satellite tracking platform that could finally unify your entire radio workflow.

Ready to discover why developers are abandoning their expensive toolchains? Let's dive in.

What Is ground-station?

Ground Station is a full-featured, open-source software solution for satellite tracking and radio communication created by Stratos Goudelis. Designed for amateur radio operators, satellite enthusiasts, and researchers, it provides a comprehensive and easy-to-use platform for monitoring spacecraft, controlling radio equipment, and receiving live radio signals from satellites.

What makes this project genuinely fascinating isn't just its feature set—it's the context of its creation. This project was built with the help of Claude Code and Codex, representing a new wave of AI-assisted systems programming where complex DSP algorithms, multi-threaded signal processing pipelines, and real-time web interfaces emerge from human-AI collaboration. The signal processing components are clearly marked in the source code and licensed under GPL-3.0, maintaining full transparency about their origins.

The project has been gaining serious traction in the amateur radio and satellite communities because it solves a fundamental problem: fragmentation. Before ground-station, you needed separate tools for tracking (GPredict, Orbitron), SDR control (GQRX, SDR#), decoding (various GNU Radio flowgraphs), logging, and observation management. ground-station unifies all of this into a single, coherent web application that you can access from your desktop, tablet, or even your phone.

The repository shows active development with automated testing, release pipelines, and regular commits. The GPL v3 license ensures the project remains free and open, while the Docker-based deployment makes it accessible to users who aren't Python packaging experts.

Key Features That Will Blow Your Mind

Let's break down what makes ground-station genuinely powerful from a technical perspective:

Real-Time Satellite Tracking with Precision Orbital Mechanics

ground-station leverages Skyfield and SGP4—the same propagation models used by professional space agencies—to compute satellite positions with sub-kilometer accuracy. TLE (Two-Line Element) data auto-updates from CelesTrak and SatNOGS, ensuring your orbital predictions stay current without manual intervention.

Multi-Target Tracking Fleet Architecture

Here's where it gets technically impressive: you can run multiple target trackers simultaneously, each with independent rotator/rig control paths. This means tracking NOAA-19 on your VHF antenna while simultaneously monitoring the ISS on UHF—completely automated, with separate hardware chains for each target.

Advanced SDR Integration via Pub/Sub

The signal processing architecture uses a sophisticated IQ Broadcaster implementing the publish-subscribe pattern. Raw IQ samples stream from your SDR hardware and get distributed to multiple consumers independently: FFT processor for spectrum display, demodulators for audio, IQ recorder for SigMF capture, and raw IQ decoders for digital modes. Slow consumers drop messages rather than blocking the pipeline—critical for maintaining real-time performance.

AI-Powered Transcription

Real-time speech-to-text for demodulated audio using Gemini Live or Deepgram. This isn't just a gimmick—imagine automatically transcribing ISS crew communications or weather satellite voice bulletins. Privacy-conscious implementation: user-provided API keys only, with optional translation and file output.

SigMF Standard Compliance

IQ recordings use the Signal Metadata Format standard with complete metadata capture: center frequency, sample rate, satellite identification, waterfall snapshots. Your recordings are immediately portable to other SigMF-compatible tools like GNU Radio.

Performance Monitoring & DSP Topology Visualization

Real-time visualization of the entire signal processing chain showing data flow, queue health, throughput rates, and component statistics. This isn't just eye candy—it's essential for diagnosing bottlenecks when your FFT processor can't keep up with your SDR sample rate.

Real-World Use Cases Where ground-station Dominates

1. Automated Weather Satellite Reception

Configure ground-station to automatically track and record NOAA-18, NOAA-19, and METEOR-M2 passes. The system controls your rotator, tunes your SDR, records IQ data, and invokes SatDump for LRPT/HRPT image decoding—all while you're sleeping. Wake up to fresh weather imagery without touching a single dial.

2. ISS Communication Monitoring

Track the International Space Station across multiple frequencies simultaneously. Monitor 145.800 MHz for crew voice communications with AI transcription, while simultaneously decoding 145.825 MHz packet radio on a separate SDR chain. The multi-target fleet handles both targets with independent hardware control.

3. Amateur Satellite DXpeditions

Field day operations or remote DX locations benefit enormously from ground-station's web interface. Mount a tablet on your operating position and control everything—tracking, tuning, recording—from a single device. No more laptop + multiple applications + USB hub chaos.

4. Satellite Signal Analysis & Research

Record suspicious or unknown satellite transmissions in SigMF format, then replay through the virtual SDR device for iterative analysis. Try different demodulators, adjust parameters, compare decoding algorithms—all without losing the original capture. The packet viewer's hex + ASCII display reveals telemetry structures for reverse engineering.

5. Educational Ground Station Networks

Universities and schools can deploy identical ground-station instances across multiple locations, sharing observation schedules and comparing reception quality. The Docker deployment ensures consistent environments, while the web interface lowers the barrier for students without Linux command-line experience.

Step-by-Step Installation & Setup Guide

Docker Deployment (Recommended)

The fastest path to a working ground-station is Docker. The project provides multi-architecture images for both AMD64 and ARM64 platforms.

Pull the latest release:

# Replace <version> with the latest release tag from GitHub
# Check https://github.com/sgoudelis/ground-station/releases for current version
docker pull ghcr.io/sgoudelis/ground-station:<version>

Run with host networking (recommended for SoapySDR remote discovery):

# For standard x86_64 systems
docker run -d \
  --platform linux/amd64 \
  --network host \
  --name ground-station \
  --restart unless-stopped \
  --device=/dev/bus/usb \
  --privileged \
  -v /path/to/data:/app/backend/data \
  -e GS_ENVIRONMENT=production \
  -e GR_BUFFER_TYPE=vmcirc_mmap_tmpfile \
  ghcr.io/sgoudelis/ground-station:<version>

# For Raspberry Pi 5 (ARM64)
docker run -d \
  --platform linux/arm64 \
  --network host \
  --name ground-station \
  --restart unless-stopped \
  -v /dev:/dev \
  --privileged \
  -v /path/to/data:/app/backend/data \
  -e GS_ENVIRONMENT=production \
  -e GR_BUFFER_TYPE=vmcirc_mmap_tmpfile \
  ghcr.io/sgoudelis/ground-station:<version>

Critical configuration notes:

• Replace /path/to/data with your persistent storage directory for recordings, configurations, and decoded outputs
• --network host is required for automatic mDNS discovery of SoapySDR remote servers
• --privileged and --device=/dev/bus/usb (or -v /dev:/dev on ARM64) grant USB device access for RTL-SDR and other USB-based radios
• GR_BUFFER_TYPE=vmcirc_mmap_tmpfile optimizes GNU Radio buffer allocation for containerized environments
• Raspberry Pi 5 is explicitly recommended for ARM64; earlier Pi models may struggle with DSP workload

Alternative: Standard bridge mode (if you don't need SoapySDR remote discovery):

docker run -d \
  --platform linux/amd64 \
  -p 7000:7000 \
  --name ground-station \
  --restart unless-stopped \
  --device=/dev/bus/usb \
  --privileged \
  -v /path/to/data:/app/backend/data \
  -e GS_ENVIRONMENT=production \
  -e GR_BUFFER_TYPE=vmcirc_mmap_tmpfile \
  ghcr.io/sgoudelis/ground-station:<version>

Access the web interface at: http://<YOUR_HOST>:7000

Building from Source

For development or customization, clone the repository and build locally:

# Clone the repository
git clone https://github.com/sgoudelis/ground-station.git
cd ground-station

# Build the multi-stage Dockerfile (frontend + Python backend with SDR libraries)
docker build -t ground-station .

# Run with USB device access
docker run --rm -p 7000:7000 --device /dev/bus/usb ground-station

For detailed development setup, build steps, and testing procedures, consult the DEVELOPMENT.md file in the repository.

Post-Installation Configuration

After first launch, navigate to Settings → Settings in the web UI to configure:

1. TLE Data Sources: Verify CelesTrak and SatNOGS connectivity
2. SDR Devices: Detect and configure your RTL-SDR, SoapySDR, or UHD/USRP hardware
3. Rotator Control: Configure Hamlib-compatible antenna rotator parameters
4. Rig Control: Set up CAT control for your transceiver with Doppler correction parameters
5. AI Transcription (Optional): Add your Gemini Live or Deepgram API key

Configuration persists in backend/data/configs/app_config.json with precedence: CLI flags > config file > built-in defaults.

REAL Code Examples from the Repository

Let's examine actual implementation patterns from the ground-station codebase and architecture documentation.

Example 1: Docker Run Command with Full Hardware Access

The README provides this production deployment pattern for ARM64 systems:

docker run -d \
  --platform linux/arm64 \
  --network host \
  --name ground-station \
  --restart unless-stopped \
  -v /dev:/dev \
  --privileged \
  -v /path/to/data:/app/backend/data \
  -e GS_ENVIRONMENT=production \
  -e GR_BUFFER_TYPE=vmcirc_mmap_tmpfile \
  ghcr.io/sgoudelis/ground-station:<version>

What's happening here? This command demonstrates sophisticated container runtime configuration for SDR hardware access. The -v /dev:/dev mount is specifically required for ARM64 platforms (Raspberry Pi) because USB device enumeration differs from x86_64 systems. --privileged bypasses Docker's default security restrictions to allow direct hardware register access needed by SDR libraries. --network host enables mDNS/Bonjour discovery for SoapyRemote servers on your local network—a critical feature for distributed SDR setups where the radio hardware sits on a different machine. The environment variables optimize GNU Radio's buffer allocation strategy for memory-mapped temporary files, preventing performance degradation in containerized environments.

Example 2: Standard Bridge Mode Deployment

For simpler setups without remote SDR discovery requirements:

docker run -d \
  --platform linux/amd64 \
  -p 7000:7000 \
  --name ground-station \
  --restart unless-stopped \
  --device=/dev/bus/usb \
  --privileged \
  -v /path/to/data:/app/backend/data \
  -e GS_ENVIRONMENT=production \
  -e GR_BUFFER_TYPE=vmcirc_mmap_tmpfile \
  ghcr.io/sgoudelis/ground-station:<version>

Key difference: Explicit port mapping -p 7000:7000 replaces --network host. This provides better network isolation and predictability but sacrifices automatic SoapySDR remote server discovery. Use this mode when your SDR hardware is directly attached to the same machine running the container, and you don't need network-distributed radio resources.

Example 3: Building from Source

docker build -t ground-station .

# Option 1: Standard bridge mode (works for local SDRs)
docker run --rm -p 7000:7000 --device /dev/bus/usb ground-station

# Option 2: Host networking (required for SoapySDR remote server discovery via mDNS)
docker run --rm --network host --device /dev/bus/usb ground-station

Build process insight: The multi-stage Dockerfile first builds the React frontend with Vite, then constructs a Python environment with compiled SDR libraries (rtl-sdr, SoapySDR, UHD). This explains why the build can take several minutes—it's compiling native extensions against your target architecture. The --rm flag in run commands creates ephemeral containers ideal for testing; remove it for persistent deployments. Notice the identical --device and --network tradeoffs between the two run options, reinforcing the architectural decision between local-only and network-distributed SDR configurations.

Example 4: IQ Broadcaster Pub/Sub Pattern (Architecture)

While not explicit code, the architecture documentation reveals this critical data flow:

SDR Hardware → IQ Broadcaster (Pub/Sub) → Multiple Independent Consumers
                                           ├── FFT Processor (spectrum/waterfall)
                                           ├── Demodulators (FM/SSB/AM)
                                           ├── IQ Recorder (SigMF files)
                                           └── Raw IQ Decoders (BPSK/GMSK)

Engineering significance: This pattern solves the classic "one producer, many consumers" problem in real-time signal processing. The IQ Broadcaster implements deep-copy semantics for each subscriber, meaning every consumer gets its own independent sample queue. If your FFT processor lags due to complex display rendering, it drops frames rather than starving your IQ recorder—that's non-blocking backpressure in action. The architecture explicitly notes "slow consumers: messages dropped rather than blocking producer," which is essential for maintaining SDR sample rate integrity. Without this, a single slow component would create cascading latency through your entire signal chain, potentially causing buffer overruns and lost samples.

Example 5: Audio Broadcaster for Decoder Chains

The SSTV decoding pipeline demonstrates chained broadcasters:

SDR → IQ Broadcaster → Internal FM Demodulator (SSTV) → Audio Broadcaster → Decoder Subscriber → SSTV Decoder → Image Output
                                                       → UI Subscriber → Browser Audio Player

Why two broadcasters? This separation of concerns is elegant: IQ samples (raw radio data) and audio samples (demodulated baseband) have fundamentally different characteristics. IQ data flows at high sample rates (MHz) with complex-valued samples; audio flows at much lower rates (kHz) with real-valued samples. Decoupling these domains allows independent scaling, different queue depths, and specialized monitoring. The statistics tracking—"delivered/dropped message counts per subscriber"—provides observability into decoder performance that would be impossible with simple thread pipelines.

Advanced Usage & Best Practices

Optimize Your DSP Pipeline

Monitor the DSP topology view during operation. If you see queue buildup in the FFT processor but not the IQ recorder, your display rendering is the bottleneck—not your SDR or storage. Consider reducing FFT size or waterfall update rate.

Leverage Internal VFO Sessions

Automated observations run in isolated internal:<observation_id> namespaces. This means you can manually explore a frequency range on the same SDR without disrupting an ongoing scheduled recording—as long as you don't change center frequency or bandwidth. Use this for "piggyback" monitoring during automated passes.

Multi-SDR Parallel Observing

The ultimate power move: configure one SDR for automated IQ recording while using additional SDRs for real-time decoding and listening on the same satellite pass. This captures maximum data while maintaining human situational awareness.

SigMF Playback for Algorithm Development

Record challenging signals in SigMF format, then iterate decoder parameters using playback through the virtual SDR device. This reproducible workflow transforms guesswork into systematic optimization.

Hot-Configuration Awareness

The UI indicates which settings apply immediately versus require restart. Respect these indicators—changing SDR device parameters mid-stream without restart can leave hardware in inconsistent states.

Comparison with Alternatives

Verdict: ground-station wins decisively on integration and automation. Individual tools may excel in specific areas—SatDump for weather image decoding workflow, GQRX for manual spectrum exploration—but none match ground-station's unified operational picture. The tradeoff: ground-station requires more initial setup investment that pays dividends in operational efficiency.

FAQ

Q: What SDR hardware works with ground-station?

A: RTL-SDR (USB and rtl_tcp), SoapySDR devices (Airspy, AirspyHF+, HackRF, HydraSDR, LimeSDR, PlutoSDR, SDRplay RSP series), and UHD/USRP radios. SoapyRemote and rtl_tcp enable network-distributed SDRs. Request additional SoapySDR devices via GitHub issue.

Q: Can I run ground-station on Raspberry Pi?

A: Yes, but Raspberry Pi 5 is explicitly recommended for ARM64 deployments. Earlier Pi models lack sufficient CPU performance for real-time DSP workloads. Use the ARM64 Docker image with -v /dev:/dev for USB device access.

Q: Is the AI transcription feature mandatory? Does it send my data to third parties?

A: Completely optional. You provide your own Gemini Live or Deepgram API key; no data flows through project infrastructure. Transcriptions save locally to backend/data/transcriptions/.

Q: What's the difference between "normal" and "internal" demodulator modes?

A: Normal mode outputs audio for user listening. Internal mode feeds the Audio Broadcaster for decoder chains (SSTV, AFSK). This separation prevents user volume adjustments from affecting decoder input levels.

Q: How does automated observation scheduling work?

A: Define satellite monitoring templates with hardware configurations and task definitions. The APScheduler-based system calculates upcoming passes using your criteria (minimum elevation, lookahead window), then triggers at AOS and stops at LOS. Tasks run in isolated internal VFO sessions.

Q: Can I contribute decoders or other features?

A: Absolutely! The project welcomes contributions. AFSK and LoRa decoders are specifically noted as needing help. See CONTRIBUTING.md for guidelines. The GPL v3 license ensures your contributions remain free software.

Q: What happens if my SDR can't keep up with the sample rate?

A: The IQ Broadcaster implements non-blocking backpressure—slow consumers drop messages rather than blocking the producer. Monitor the DSP topology view for dropped frame statistics and optimize accordingly.

Conclusion: Your Ground Station, Reimagined

After dissecting every layer of ground-station—from its pub/sub DSP architecture to its Docker deployment patterns—one thing is crystal clear: this isn't just another satellite tracking tool. It's a fundamental reimagining of how ground station operations should work in 2024.

The integration of real-time orbital mechanics, multi-target hardware orchestration, AI-powered transcription, and standardized recording formats into a single responsive web application represents a generational leap over the fragmented toolchains most operators tolerate. The fact that it's completely free, open source, and actively maintained makes the commercial alternatives look increasingly difficult to justify.

Yes, there's setup complexity. Docker configuration, SDR driver installation, and antenna hardware integration demand initial effort. But that investment pays exponential returns in operational capability: automated all-night observation sessions, parallel multi-satellite monitoring, reproducible signal analysis workflows, and the freedom to access your entire ground station from any device on your network.

The AI-assisted development origin is particularly exciting—it suggests we're entering an era where sophisticated embedded systems and DSP applications can be built faster and more reliably than ever before. ground-station is both a product and a harbinger.

Ready to transform your satellite operations?

Head to https://github.com/sgoudelis/ground-station now. Star the repository, read the DEVELOPMENT.md for build instructions, pull the Docker image, and join the growing community of operators who've stopped fighting their tools and started exploring space. Your next satellite pass is coming—don't miss it with the wrong software.