TALOS Ground Station Network -- Executive Summary¶

Date: April 2026 Version: 0.5.0 Repository: gitlab.com/pierros/talos Built by: Libre Space Foundation

1. Project Status¶

TALOS (Tracking, Acquisition, and Link Operation System) is a distributed satellite ground station controller that coordinates multiple antenna stations in real time from a centralized SGP4 physics engine running at 2 Hz with Doppler correction. No other open-source ground station network offers real-time multi-station coordination from a central propagator.

At v0.4.0, the system completed a significant security, observability, and architecture modernization cycle -- 21 items delivered across four work streams. The codebase is now production-hardened:

Capability	Implementation
Modular core	17-module package replacing the 1,630-line monolith
MQTT security	Authenticated broker with per-station ACLs, TLS on port 8883
Observability	Prometheus metrics endpoints on Core and Director, Grafana dashboards
Async agent	aiomqtt-based agent with structured error handling
API hardening	Rate limiting, CORS with origin allowlist, structured JSON logging
WebSocket relay	Dashboard data routed through FastAPI, browser-to-broker path eliminated

Test coverage: ~220 tests across unit, integration, campaign lifecycle, physics, agent hardware, load test, and smoke suites. CI runs 18+ jobs in a DAG pipeline including SAST, secret detection, dependency scanning, Docker builds, and Fly.io deploys.

2. Release History¶

v0.1.0 -- Monorepo Consolidation (April 1, 2026)¶

Merged three separate repositories into a single monorepo. Extracted the Director as a standalone process. Created the shared library. Added signed session cookies, MQTT authentication, CI/CD, SatNOGS API caching, and six architecture research reports.

v0.2.0 -- Organization-Grade Architecture (April 1, 2026)¶

Replaced the single-mission model with a multi-tenant organization system. Added organization model with RBAC, campaign lifecycle management, per-station assignments, multi-satellite concurrent tracking, org-scoped MQTT topics, and Alembic database migrations.

v0.2.1 -- Operational Hardening (April 2, 2026)¶

Stabilized the v0.2 feature set. Added management pages, magic link authentication via Resend API, simplified assignment model, and shipped 71 end-to-end tests.

v0.3.0 -- Design System and CI/CD (April 3, 2026)¶

Introduced the TALOS Design System based on Astro UXDS. Migrated from GitHub Actions to full GitLab CI/CD pipeline. Added 16-target Makefile, campaign end-to-end tests, and smoke tests.

v0.4.0 -- Security, Observability, and Architecture Modernization (April 2026)¶

Delivered 21 items across four work streams:

Architecture -- Split core/main.py into 17-module package (routers, services, middleware, dependencies). Introduced PropagatorProtocol abstract interface for swappable propagation backends.
Security -- MQTT ACLs restricting each agent to its station prefix. CORS middleware with origin allowlist. Rate limiting on authentication endpoints. Eliminated the direct browser-to-MQTT broker WebSocket path.
Observability -- Prometheus metrics on Core API (request latency, active users) and Director (loop timing, propagation duration, MQTT publish rate, active campaigns). Grafana dashboard with station health panels. Structured JSON logging with correlation IDs.
Agent -- Migrated to async architecture with aiomqtt. Added structured error handling for malformed MQTT payloads. Docker health checks on all services.

3. Current Capabilities¶

Real-time multi-campaign tracking -- Different stations track different satellites concurrently, coordinated from a single 2 Hz physics engine with Doppler correction.
Organization model -- Multi-org support with membership management, station ownership scoped to organizations, and auto-org creation for new users.
Role-based access control -- Owner, operator, and viewer roles enforced on all org-scoped API endpoints.
Campaign lifecycle -- Draft, scheduled, active, completed, cancelled states with per-station assignment management.
SatNOGS integration -- Satellite catalog, TLEs, and transmitter metadata sourced from SatNOGS DB with response caching.
Magic link authentication -- Passwordless email login via Resend API with JWT tokens (10-minute TTL).
Public satellite tracker -- Standalone tracking page showcasing PHASMA-LAMARR, PHASMA-DIRAC, PeakSat, and ISS.
TALOS Design System -- Astro UXDS-based dark theme with CSS custom properties applied across all pages.
Observability stack -- Prometheus metrics, Grafana dashboards, structured JSON logging, Director health-check endpoint.
Secured MQTT -- Authenticated broker with per-station topic ACLs, TLS transport, no direct browser access.
Edge-native agents -- Async Python clients on Raspberry Pi bridging MQTT to Hamlib (rotctld/rigctld).
Magic Find -- Sky scanning across 8,000+ satellite orbits in milliseconds to identify unknown signals.

4. Architecture Health¶

Strengths:

Clean 17-module Core package with separation between routers, services, middleware, and dependencies.
Director properly decoupled from HTTP layer with its own DB connection and MQTT client.
PropagatorProtocol interface enables swapping Skyfield for dSGP4 without Director changes.
Prometheus metrics provide runtime visibility into both Core API and Director performance.
Pydantic v2 data contracts for all MQTT payloads prevent schema drift.
Alembic migrations provide safe, versioned schema evolution.
Comprehensive CI/CD pipeline: lint, type check, 8+ test suites, 3 security scanners, Docker builds, automated releases.

Concerns:

Director scaling wall at ~50 stations. The single-threaded Python physics loop handles ~10 stations comfortably but pass prediction still runs inline in the 2 Hz loop. Ground track visualization wastes ~48 redundant SGP4 calls per tick. Background threading is the critical next step.
No automated scheduling. Station-to-campaign assignment remains manual. Operators must know which stations have line-of-sight to which satellites and at what times. This does not scale beyond a handful of campaigns.
No telemetry persistence. Prometheus provides real-time metrics but no historical tracking data storage. Az/el/frequency measurements are fire-and-forget over MQTT with no database backing.
CelesTrak TLE format change. NORAD catalog numbers will exceed 5 digits in July 2026. The current raw JSON TLE format will break without migration to OMM.

5. Key Risks¶

#	Risk	Impact	Mitigation
1	Director scaling wall at ~50 stations -- Single-threaded Python with inline pass prediction blocks 2 Hz loop	Cannot grow network; missed tracking windows during prediction stalls	Move pass prediction to background thread; integrate dSGP4 batch propagation; cache ground tracks
2	CelesTrak TLE format change July 2026 -- 5-digit to 6-digit NORAD catalog numbers	TLE parsing breaks for newly cataloged objects; inability to track new satellites	Migrate to CCSDS OMM JSON format; add CelesTrak GP API as fallback TLE source
3	No automated scheduling -- Manual station-campaign assignment	Operator burden grows quadratically with stations x campaigns; suboptimal pass utilization	Integrate OR-Tools CP-SAT solver for automated multi-campaign scheduling
4	No telemetry persistence -- Prometheus only, no historical analysis	Cannot analyze tracking accuracy trends; no post-pass review capability	Add TimescaleDB with hypertables for time-series tracking data
5	Single TLE source -- SatNOGS DB is the only TLE provider	Service degradation if SatNOGS API is unavailable	Add CelesTrak GP API fallback with priority cascade: SatNOGS, CelesTrak, stale cache

6. Strategic Priorities¶

v0.5 -- Scheduling and Scale¶

Move from manual station assignment to automated scheduling, and remove the Director's scaling bottleneck.

OR-Tools CP-SAT scheduler -- Constraint-based multi-campaign optimization with conflict detection, priority weighting, and antenna slew time constraints.
Background pass prediction -- ThreadPoolExecutor with cached results on a 10-second refresh cycle, protecting the 2 Hz real-time loop.
dSGP4 integration -- GPU-accelerated batch propagation via the PropagatorProtocol interface. Environment variable toggle between Skyfield and dSGP4 backends.
CelesTrak GP API fallback -- OMM JSON format from celestrak.org/NORAD/elements/gp.php with automatic failover from SatNOGS.
Ground track caching -- Eliminate ~48 redundant SGP4 calls per tick by caching computed tracks per satellite.
TimescaleDB -- Historical telemetry persistence with continuous aggregates for rolling statistics.
Coverage gate CI job -- Enforce minimum test coverage threshold in pipeline.

v0.6 -- Visualization and Standards¶

Adopt space industry standards and upgrade the visualization layer.

CesiumJS 3D globe -- CZML generation from Director for satellite position, footprint, and ground track visualization. Opt-in alongside existing Leaflet 2D.
HTMX v2 -- FastAPI partial response pattern for non-realtime pages (station list, campaign management, settings).
CCSDS 502.0 (OMM) -- Standardized TLE interchange replacing raw JSON, aligned with CelesTrak GP API format.
CCSDS 503.0 (TDM) -- Tracking data export in standard format (azimuth, elevation, Doppler measurements).

v0.7+ -- Advanced Capabilities¶

Rust agent -- High-performance edge client using tokio + rumqttc for constrained hardware.
IQ capture pipeline -- SoapySDR-based signal capture with NumPy FFT and waterfall generation, without GNU Radio dependency.
Regional Director sharding -- Multiple Director instances partitioned by geographic region for 500+ station networks.
NATS evaluation -- Assess NATS as MQTT replacement at scale (500+ stations with shared subscriptions).

7. Research Index¶

The following companion documents provide detailed analysis behind this summary:

Document	Focus
01 -- Scheduling Architecture	OR-Tools CP-SAT formulation, conflict detection, API design, assignment integration
02 -- Performance and Scaling	Background threading, dSGP4 evaluation, ground-track caching, load testing targets
03 -- Data Resilience	CelesTrak fallback, TLE source priority, TimescaleDB telemetry persistence, coverage gate
04 -- Visualization and Standards	CesiumJS, HTMX, CCSDS OMM/TDM, CZML generation
05 -- SatNOGS Coexistence	Hardware mutex, IQ capture pipeline, SatNOGS observation submission, idle-time scheduling
06 -- Technology Decisions	dSGP4 vs Skyfield, OR-Tools, CesiumJS, NATS vs MQTT 5.0, Rust agent, TimescaleDB

Previous research is preserved in docs/research/archive/ for historical reference:

archive/v0.3/ -- v0.3 era research (architecture, security, operations, SatNOGS, technology roadmap)
archive/ (root) -- v0.1-v0.2 era research (architecture, operations, security, CCSDS, SatNOGS, technologies)

One-Line Summary¶

TALOS v0.4.0 is a production-hardened real-time multi-station satellite tracker with modular architecture, secured MQTT, and full observability -- the next priorities are constraint-based scheduling, background-threaded propagation, and CelesTrak fallback to scale the network beyond 50 stations.