Skip to content

TALOS-SatNOGS Integration Analysis

Date: 2026-04-01 Status: Research Complete

1. SatNOGS Architecture Overview

SatNOGS (Satellite Networked Open Ground Station) is the flagship project of the Libre Space Foundation. It is the largest open-source satellite ground station network in the world, with over 12 million observations recorded as of mid-2025 across hundreds of stations globally.

Core Sub-Projects

SatNOGS is composed of four distinct sub-projects:

SatNOGS Network (network.satnogs.org) The central web application that manages observation scheduling. Observers (any registered user) can schedule observations on any station in the network. Stations poll the Network API for assigned jobs, execute them, and upload results. The Network stores waterfall images, audio files, and decoded data frames. It also handles station status tracking, observation vetting (good/bad/failed), and provides the auto-scheduler infrastructure.

Key API endpoints: - GET /api/jobs/ -- Stations pull pending observation jobs - POST /api/observations/ -- Submit observation results (waterfall, audio, decoded data) - GET /api/stations/ -- Station metadata (location, capabilities, status)

SatNOGS DB (db.satnogs.org) A crowd-sourced database of satellite metadata, transmitter information, TLEs, and decoded telemetry. This is the authoritative open-source satellite database, containing information on thousands of satellites. As of late 2023, it surpassed 200 million decoded data frames.

Key API endpoints: - GET /api/satellites/ -- Satellite metadata (name, NORAD ID, status) - GET /api/transmitters/ -- Transmitter details (frequency, mode, baud rate) - GET /api/tle/ -- Two-Line Element sets for orbital propagation - POST /api/telemetry/ -- Submit decoded telemetry frames (SiDS protocol)

SatNOGS Client (satnogs-client) A Python daemon that runs on station hosts (typically Raspberry Pi). It: 1. Polls SatNOGS Network API at configurable intervals for scheduled observation jobs 2. Spawns GNU Radio flowgraphs (satnogs-flowgraphs + gr-satnogs) at the scheduled time 3. Controls rotator via Hamlib's rotctld 4. Controls rig frequency via Hamlib's rigctld 5. Performs Doppler correction during the observation 6. Generates waterfall images (PNG) and optionally audio recordings 7. Uploads artifacts back to SatNOGS Network after each observation 8. Submits decoded data frames to SatNOGS DB

SatNOGS Ground Station Hardware Open-source hardware designs including 3D-printed rotators, antenna designs, and electronics. This is the physical layer -- not directly relevant to TALOS software integration.

Observation Lifecycle in SatNOGS

Observer schedules observation on Network
         |
         v
Station client polls /api/jobs/ (every ~60s)
         |
         v
Job arrives: satellite ID, transmitter, start/end time
         |
         v
Client waits for AOS, spawns GNU Radio flowgraph
         |
         v
gr-satnogs handles: SDR capture, demodulation, waterfall generation
Client handles: rotator tracking, Doppler correction
         |
         v
Observation ends at LOS
         |
         v
Client uploads: waterfall PNG, audio OGG, decoded frames, HDF5
         |
         v
Network stores artifacts, community vets observation quality

Key Architectural Properties

  • Scheduling is centralized, execution is distributed. The Network decides what gets observed; the Client decides how to execute it.
  • One observation at a time per station. Stations are single-threaded in their observation pipeline.
  • Polling model. Clients poll for jobs on a timer. There is no push mechanism.
  • GNU Radio dependency. Signal processing is tightly coupled to GNU Radio via gr-satnogs and satnogs-flowgraphs.
  • Autonomous stations. Each station operates independently. There is no real-time coordination between stations.

2. Feature Comparison: SatNOGS vs TALOS

Capability SatNOGS TALOS
Station count Hundreds globally Single-operator fleet
Scheduling Web UI + auto-scheduler, per-station Mission-based, fleet-wide
Observation model Pre-scheduled jobs, polled by client Real-time continuous tracking
Doppler correction Client-side, per-station (GNU Radio) Centralized physics engine, pushed to agents
Rotator control Client-side via rotctld Centralized via MQTT, sub-second updates
Multi-station coordination None -- stations are independent Core feature -- director drives all stations simultaneously
Signal processing GNU Radio flowgraphs (gr-satnogs) Not implemented (rig tuning only)
Data products Waterfall, audio, decoded frames, HDF5 None currently
Satellite database SatNOGS DB (crowd-sourced, massive) Consumes SatNOGS DB API
TLE source SatNOGS DB + CelesTrak SatNOGS DB API
Sky scanning Not available "Magic Find" -- scans 8000+ orbits in real-time
Communication protocol HTTP polling (REST API) MQTT pub/sub (real-time)
Pass prediction Server-side (Network scheduler) Mission Director, real-time SGP4 via Skyfield
Station provisioning Manual registration + satnogs-config One-command agent deploy, auto-config via SatNOGS Network API
User interface Functional web UI Cyberpunk mission control dashboard
Community Large global community Single-operator tool
Data contribution Uploads to global open dataset No data contribution pipeline

Where They Overlap

Both systems: - Control rotators via Hamlib/rotctld - Perform Doppler correction - Use SatNOGS DB for satellite/transmitter metadata - Use TLE-based SGP4 propagation for pass prediction - Target amateur radio ground stations with SDR receivers

Where They Diverge Fundamentally

SatNOGS is a network of autonomous stations; TALOS is a centralized fleet controller.

SatNOGS treats each station as an independent actor that receives scheduled jobs and executes them in isolation. The Network is a job dispatcher, not a real-time controller. TALOS treats stations as remote actuators driven by a central physics engine in real-time. The Mission Director does all orbital math and pushes commands at sub-second intervals.

This is not a small difference -- it represents two fundamentally different operational philosophies: - SatNOGS: "Schedule an observation of satellite X on station Y at time T" - TALOS: "Track satellite X right now across all available stations continuously"

3. Integration Opportunities

3.1 Observation Data Submission to SatNOGS Network

Current state: TALOS controls rotators and tunes radios but produces no data products.

Opportunity: When TALOS drives a station through a satellite pass, it could capture and submit observation data to SatNOGS Network, contributing to the global dataset.

Implementation path: 1. Add SDR capture capability to the TALOS agent (record raw IQ during a pass) 2. Post-process with gr-satnogs flowgraphs to generate waterfall PNG and demodulated data 3. Submit to SatNOGS Network API using the station's API token: - POST /api/observations/ with waterfall image, audio file, and observation metadata 4. Submit decoded frames to SatNOGS DB via SiDS endpoint: - POST /api/telemetry/ with binary frame data

Complexity: High. This requires integrating GNU Radio or an equivalent DSP pipeline into the TALOS agent, which is currently a lightweight MQTT-to-Hamlib bridge.

Alternative: Run satnogs-client alongside talos-agent on the same host. Let TALOS handle real-time tracking and let satnogs-client handle signal processing and data upload for scheduled observations. This is the pragmatic near-term approach.

3.2 Station Status Reporting

Current state: TALOS stations report telemetry (az/el, freq, mode) to the Mission Director via MQTT.

Opportunity: Mirror station health data to SatNOGS Network so TALOS-managed stations appear as active, healthy stations in the global network.

Implementation: Periodically update station status via the SatNOGS Network API. The client normally does this as part of its heartbeat. If running satnogs-client alongside TALOS, this happens automatically.

3.3 Consuming SatNOGS Scheduling

Current state: TALOS has no observation scheduler. It tracks whatever mission the operator selects.

Opportunity: Pull scheduled observations from SatNOGS Network for TALOS-managed stations and execute them when no active TALOS mission is running. This would make TALOS stations useful contributors to the SatNOGS network during idle time.

Implementation: 1. Poll GET /api/jobs/?ground_station={station_id} for pending observations 2. When TALOS has no active mission, queue SatNOGS jobs 3. At the scheduled time, configure TALOS to track the target satellite 4. After the pass, trigger data capture and upload

3.4 Waterfall and Demodulated Data Upload

Current state: TALOS does not capture RF data.

Opportunity: The TALOS agent already controls the SDR frequency. Adding IQ recording and waterfall generation would be a natural extension.

Implementation options: - Lightweight: Use SoapySDR to record IQ, generate waterfall with matplotlib or a simple FFT pipeline. Skip GNU Radio entirely. - Full compatibility: Invoke satnogs-flowgraphs for signal processing, producing artifacts in the exact format SatNOGS Network expects. - Hybrid: Record IQ during TALOS missions, batch-process later with gr-satnogs tools.

3.5 Using SatNOGS Auto-Scheduler

The satnogs-auto-scheduler is a standalone Python tool that computes optimal observation schedules based on satellite priority lists and station capabilities. TALOS could use it to: - Fill idle time between operator-directed missions - Prioritize high-value satellites for data collection - Coordinate with the global SatNOGS network to avoid duplicate observations

4. Where TALOS Adds Value Over SatNOGS

4.1 Real-Time Multi-Station Coordination

SatNOGS has zero concept of coordinating multiple stations on the same satellite pass. Each station is an island. TALOS can drive multiple stations to track the same satellite simultaneously, which enables:

  • Spatial diversity combining -- multiple receivers at different locations can be combined for better SNR or longer effective pass durations
  • Handoff tracking -- as a satellite moves out of range of one station, another picks it up seamlessly
  • Simultaneous multi-frequency reception -- different stations can monitor different transmitters on the same satellite

This is something SatNOGS cannot do architecturally. Their scheduling is per-station, per-observation. There is no concept of a coordinated multi-station mission.

4.2 Centralized Real-Time Physics Engine

TALOS runs SGP4 propagation centrally and pushes computed positions to all stations at 2 Hz. This means:

  • Consistent orbital model -- all stations use the same TLE and propagation, eliminating per-station drift
  • Instant Doppler correction -- computed centrally and pushed to rigs in real-time
  • Sub-second rotator updates -- TALOS pushes az/el every 500ms, compared to SatNOGS client's internal tracking which runs at a similar rate but independently

4.3 Real-Time Sky Scanning ("Magic Find")

TALOS maintains an in-memory registry of 8000+ satellite orbital models and can scan the entire sky from any station's perspective in milliseconds. SatNOGS has no equivalent feature. In SatNOGS, you must know what satellite you want to observe before scheduling. TALOS can answer "what is overhead right now?" instantly.

4.4 Live Mission Control Experience

TALOS provides a real-time dashboard with: - Live satellite footprint and ground track visualization - Real-time rotator telemetry from all stations - Doppler-corrected frequency display - Mission activation and transmitter selection

SatNOGS Network is a scheduling and data browsing tool. It does not provide a real-time operational view of active observations.

4.5 Instant Station Provisioning

TALOS provisions a station with a single command. The operator enters a SatNOGS Network station ID, and TALOS pulls the station metadata (name, location, altitude) automatically, generates credentials, and provides a one-liner to start the agent. SatNOGS station setup requires satnogs-config, typically involves multiple configuration steps, and requires installing GNU Radio and the full gr-satnogs stack.

5. Integration vs Replacement: Strategic Position

Option A: TALOS as a SatNOGS Client (Replace satnogs-client)

Verdict: No. Bad idea.

This would mean reimplementing all of satnogs-client's functionality: GNU Radio integration, waterfall generation, data upload pipelines, observation artifact formatting, SiDS submission, HDF5 generation. The SatNOGS client has years of development and handles hundreds of edge cases in signal processing. Replacing it would be an enormous effort with no clear benefit.

Option B: TALOS as a SatNOGS Complement (Run Alongside)

Verdict: Yes. This is the right answer.

TALOS and SatNOGS solve different problems: - SatNOGS solves: "How do we collect satellite data at scale across a global volunteer network?" - TALOS solves: "How do I control my fleet of ground stations in real-time from a central mission control?"

They are complementary. The practical architecture:

                    +-------------------+
                    |  SatNOGS Network  |  (Scheduling, data archive)
                    +-------------------+
                            |
              +-------------+-------------+
              |                           |
    +---------v---------+      +----------v----------+
    |  satnogs-client   |      |   TALOS Director    |
    | (GNU Radio, DSP)  |      | (Physics, MQTT)     |
    +---------+---------+      +----------+----------+
              |                           |
              +-------------+-------------+
                            |
                    +-------v-------+
                    |  Station Host |  (Raspberry Pi / PC)
                    |  rotctld      |
                    |  SDR          |
                    +---------------+

On a station host, both satnogs-client and talos-agent can coexist: - satnogs-client handles scheduled SatNOGS observations (signal capture, processing, upload) - talos-agent handles real-time operator-directed missions (rotator + rig control) - A coordination layer prevents conflicts (when TALOS is active, satnogs-client defers, and vice versa)

Option C: TALOS as an Alternative Network (Fork/Replace SatNOGS)

Verdict: No. Unnecessary and counterproductive.

SatNOGS has a massive community, 12+ million observations, and a proven data pipeline. Building a competing network would fragment the amateur satellite community. TALOS should contribute to SatNOGS, not compete with it.

TALOS is a real-time mission control layer that sits above SatNOGS. It uses SatNOGS DB as its satellite catalog. It can drive stations that are also registered on SatNOGS Network. During idle time, it defers to SatNOGS scheduled observations. During active missions, it takes over station control for real-time multi-station tracking.

6. Other Ground Station Networks

TinyGS

TinyGS is a LoRa-only ground station network built on ESP32 microcontrollers. It is simpler and cheaper than SatNOGS (no rotator, no SDR -- just a LoRa receiver and antenna). As of 2023, TinyGS had more online stations than SatNOGS due to the extremely low barrier to entry (~$15 hardware), but it can only receive LoRa signals from a handful of satellites.

Relevance to TALOS: Minimal. TinyGS stations are fixed-antenna LoRa receivers with no rotator or SDR control. TALOS has nothing to integrate with here.

Libre Space Foundation (LSF) Ecosystem

LSF is the parent organization behind SatNOGS. They also run: - OpenSatCom -- An ESA-backed initiative exploring open-source methodology in satellite communications. Focused on policy and methodology rather than operational software. - UPSat -- A completed CubeSat mission (launched 2017) that was the first open-source satellite.

Relevance to TALOS: LSF is the natural community partner. TALOS contributing data back to the SatNOGS ecosystem aligns with LSF's mission.

FoxTelem / AMSAT

AMSAT's FoxTelem software is a single-station tool for receiving and decoding AMSAT satellite telemetry. It is not a networked system.

Relevance to TALOS: Could be an integration target for specific AMSAT satellite decoding, but it is a niche use case.

Commercial Ground Station as a Service (GSaaS)

AWS Ground Station, Azure Orbital, KSAT Lite, and others provide commercial ground station access. These are professional-grade, high-cost services targeting commercial satellite operators.

Relevance to TALOS: Different market entirely. TALOS is an amateur/educational tool. However, TALOS's architecture (centralized director, MQTT command bus, multi-station coordination) resembles a simplified version of what these commercial systems do. This validates TALOS's design.

Phase 1: Deepen SatNOGS DB Integration (Now)

TALOS already consumes SatNOGS DB API for satellite metadata, TLEs, and transmitter data. Improvements: - Cache TLEs locally with age tracking and automatic refresh (partially done) - Subscribe to SatNOGS DB API for transmitter updates rather than fetching on-demand - Add satellite status change detection (new launches, re-entries) - Display SatNOGS DB links in the dashboard for each tracked satellite

Phase 2: SatNOGS Network Coexistence (Next)

Enable TALOS-managed stations to also function as SatNOGS Network stations: - Implement a station mutex so satnogs-client and talos-agent do not fight over hardware - When TALOS has no active mission, signal satnogs-client to accept SatNOGS jobs - When a TALOS mission activates, signal satnogs-client to defer - Report station health to both TALOS Director and SatNOGS Network

Phase 3: Data Contribution Pipeline (Future)

Add lightweight data capture to TALOS missions: - Record IQ data during active tracking passes - Generate waterfall images from captured IQ (simple FFT, no GNU Radio needed) - Submit waterfalls and metadata to SatNOGS Network as unvetted observations - Submit decoded frames to SatNOGS DB via SiDS protocol - This makes every TALOS mission also contribute to the global open dataset

Phase 4: Coordinated Scheduling (Aspirational)

Build a TALOS scheduler that integrates with SatNOGS: - Pull SatNOGS auto-scheduler priority lists - Schedule TALOS multi-station missions for high-priority targets - Coordinate with SatNOGS Network to avoid scheduling conflicts - Enable "TALOS-enhanced" observations where multiple stations simultaneously observe the same pass, uploading correlated data

Design Principles

  1. Never duplicate SatNOGS DB. It is the authoritative satellite catalog. Always consume, never fork.
  2. Contribute data back. Every TALOS observation should produce data that flows back to the open commons.
  3. Coexist, do not compete. Stations should be able to serve both TALOS and SatNOGS without conflict.
  4. TALOS adds the real-time layer. SatNOGS is batch-oriented (schedule, execute, upload). TALOS is real-time (track now, coordinate across stations, live Doppler). These are complementary.
  5. Keep the agent lightweight. Do not turn talos-agent into a full satnogs-client clone. Run them side-by-side instead.

Summary

TALOS and SatNOGS are not competitors. SatNOGS is a global observation network with a scheduling model, a massive data archive, and a large volunteer community. TALOS is a real-time fleet controller with centralized physics, multi-station coordination, and a live mission control experience.

The right strategy is to position TALOS as a complementary real-time control layer that: - Consumes SatNOGS DB as its satellite catalog (already done) - Coexists with SatNOGS Client on shared station hardware (to be built) - Contributes observation data back to SatNOGS Network (future) - Adds capabilities SatNOGS does not have: real-time multi-station coordination, centralized Doppler, live sky scanning

TALOS should never try to replace SatNOGS. It should make SatNOGS stations more capable when an operator wants real-time control.