TALOS Project: Recent & Emerging Technologies for Satellite Ground Station Networks¶

Date: April 2026 Scope: Technology survey and practical upgrade recommendations for the TALOS ground station network project

Table of Contents¶

Orbit Propagation & Space Situational Awareness
Ground Station Software Trends
Communication & Messaging
Frontend & Visualization
AI/ML in Ground Operations
Hardware Trends
Recommended Technology Upgrades

1. Orbit Propagation & Space Situational Awareness¶

1.1 Beyond SGP4: Next-Generation Propagation¶

TALOS currently uses SGP4 via Skyfield, which is adequate for pass prediction but has known accuracy limitations, especially for objects with high drag or in rapidly changing orbits.

dSGP4 (ESA, 2024) -- The most significant recent advancement is dSGP4, a differentiable SGP4 implementation built on PyTorch and released by ESA's Advanced Concepts Team. Key capabilities:

GPU-accelerated batch propagation: Enables embarrassingly parallel orbital propagation across thousands of TLEs simultaneously using CUDA. For a network like TALOS that may track hundreds of satellites, this reduces bulk propagation from minutes to seconds.
ML-dSGP4 hybrid model: Integrates neural networks into the propagator to correct SGP4's known error patterns. Through stochastic gradient descent, the combined model surpasses standard SGP4 precision, partially closing the gap with high-fidelity numerical propagators.
Differentiability: Enables gradient-based orbit determination, covariance propagation, and state transition matrix computation -- useful if TALOS ever needs to refine orbits from station observations.
Available on PyPI (dsgp4) and conda-forge. Written in Python/PyTorch, making integration with TALOS's Python stack straightforward.

TALOS relevance: High. Even without GPU hardware, dSGP4's batch CPU propagation is faster than serial Skyfield SGP4 calls. The ML-corrected propagation model would improve pass prediction accuracy, particularly for LEO objects with significant drag.

Other Python libraries worth noting:

poliastro: Mature astrodynamics library for interactive orbit analysis, maneuver planning, and visualization. Good for analysis tasks but lacks native SGP4 integration, so it complements rather than replaces Skyfield.
beyond (python-beyond): Lightweight orbital mechanics library with TLE support, event computation, and ground station modeling. Less mature than Skyfield but more focused on ground station operations.
Orekit (via orekit-python / JCC wrapper): Industrial-strength Java library with Python bindings. Offers high-fidelity propagation (numerical, semi-analytical DSST), conjunction screening, and orbit determination. Heavy dependency (requires JVM) but unmatched in capability. Best reserved for cases where SGP4 accuracy is genuinely insufficient.
heyoka.py: Provides a differentiable SGP4 propagator alongside high-precision numerical integration via Taylor methods. Strong for research-grade accuracy requirements.

1.2 Space Situational Awareness & Data Sources¶

Current state: TALOS uses SatNOGS APIs for satellite metadata and presumably CelesTrak/Space-Track for TLEs.

Commercial SSA providers emerging as practical options:

LeoLabs: Operates a network of phased-array radars (11 as of 2024) providing persistent LEO tracking. Their API offers conjunction screening, orbit history, and collision probability calculations. In 2024, LeoLabs secured over $50M in contracts and achieved 140% year-over-year revenue growth, indicating strong market validation. Their API could augment TALOS with collision avoidance alerts for tracked objects.
Space-Track.org (18th SDS): Remains the primary free source for GP (TLE) data. The new GP JSON format is more machine-friendly than traditional TLE text. TALOS should use the GP JSON API rather than parsing two-line elements.
CelesTrak: Dr. Kelso's supplemental TLE service continues to be valuable for timely updates. The new CSV and JSON formats reduce parsing overhead.

Conjunction screening relevance to TALOS: While TALOS is a ground station network (not a spacecraft operator), conjunction awareness matters for scheduling -- an object about to maneuver may shift its pass window. Integrating basic conjunction data from Space-Track CDMs (Conjunction Data Messages) could flag passes where orbital parameters may be stale.

1.3 Practical Recommendations for TALOS¶

Action	Priority	Effort
Evaluate dSGP4 for batch pass prediction	High	Low (pip install, API similar to sgp4)
Switch to Space-Track GP JSON API	Medium	Low
Add LeoLabs API integration for high-value objects	Low	Medium
Keep Skyfield as primary for single-object propagation	--	No change needed

2. Ground Station Software Trends¶

2.1 Cloud Ground Station as a Service (GSaaS)¶

The GSaaS market has undergone significant shifts:

AWS Ground Station: Continues to operate, primarily serving its Kuiper constellation and government customers. Provides antenna time scheduling via API with direct data delivery into AWS services (S3, EC2). The model -- paying per-minute for antenna access at globally distributed stations -- is relevant as a conceptual reference for TALOS's scheduling architecture, but the service targets high-bandwidth commercial/government downlinks, not amateur operations.
Azure Orbital: Microsoft retired this service in October 2024 and sold its antenna assets to Space Leasing International. This is a cautionary signal about cloud providers' commitment to niche space services.
Leaf Space: European GSaaS provider focused on LEO small satellites. Their "Leaf Line" network offers API-driven scheduling similar to what TALOS builds for its distributed stations.

TALOS takeaway: The GSaaS trend validates TALOS's API-driven, distributed scheduling approach. TALOS is essentially building a federated GSaaS for its own network. Key patterns to adopt from commercial GSaaS: standardized pass scheduling APIs, automated conflict resolution, and post-pass data delivery pipelines.

2.2 SDR Software Ecosystem¶

GNU Radio: Remains the dominant open-source SDR framework. Version 3.10+ brought improved Python 3 support and a more modular architecture. For TALOS, GNU Radio is relevant if stations move beyond Hamlib-controlled radios to SDR-based receivers.

gr-satellites: Daniel Estevez's GNU Radio out-of-tree module provides decoders for nearly 40 amateur satellites. It handles demodulation, forward error correction, and frame parsing for common amateur protocols (AX.25, CCSDS, custom formats). This is directly relevant if TALOS stations use SDRs -- gr-satellites could automate signal decoding during passes.

SatDump: Standalone satellite data decoder focused on weather and Earth observation satellites (NOAA, Meteor-M, GOES, Fengyun). Handles the full pipeline from raw IQ recording to decoded imagery. Useful if any TALOS stations track weather satellites, but less relevant for general amateur satellite operations.

OpenC3/COSMOS: Command and telemetry system used by multiple satellite missions. A 2025 SmallSat Conference paper (HERMES project) demonstrated OpenC3 COSMOS integrated with SDR-based ground stations for full command/telemetry validation. OpenC3 provides a mature, tested framework for structuring satellite command and telemetry -- if TALOS ever needs to send commands (beyond just receiving), OpenC3 would be the reference architecture.

Ground Station (open-source project): A recent web-based SDR orchestration platform that automates the full satellite pass workflow: pass prediction, SDR control, recording, decoding, and rotator management. It integrates with SatDump for complex protocols. This project's architecture (web UI + automated SDR pipeline) closely parallels what TALOS could become with SDR integration.

2.3 Practical Recommendations for TALOS¶

Action	Priority	Effort
Study GSaaS API patterns for scheduling design	Medium	Low (research only)
Evaluate gr-satellites integration for SDR stations	Medium	Medium
Add SatDump support for weather satellite stations	Low	Medium
Monitor OpenC3/COSMOS for command architecture patterns	Low	Low (research only)

3. Communication & Messaging¶

3.1 MQTT 5.0: Upgrade Path for Current Stack¶

TALOS uses Eclipse Mosquitto 2 with MQTT (likely 3.1.1). Upgrading to MQTT 5.0 offers several features directly useful for ground station operations:

Shared Subscriptions: Allow multiple backend workers to load-balance message processing from a single topic. For TALOS, this means multiple scheduling or telemetry processing services can share the workload of incoming station data without custom load-balancing logic. Topic format: $share/group-name/talos/stations/+/telemetry.

Flow Control: The "Receive Maximum" property prevents fast publishers from overwhelming slow subscribers. Critical when a station bursts telemetry data during a pass while the backend is under load. Each connection negotiates its own receive window.

Enhanced Reason Codes: MQTT 5.0 expands to 43 reason codes across all packet types. TALOS can now programmatically detect why a station disconnected, why a subscription failed, or why a message publication was rejected -- essential for monitoring distributed station health.

Topic Aliases: Reduce bandwidth by replacing long topic strings (e.g., talos/stations/athens-01/telemetry/raw) with short integer aliases after initial exchange. Meaningful for stations on constrained network links.

Message Expiry: Set per-message TTLs so stale pass commands or telemetry data auto-expire if not delivered promptly. Prevents stations from acting on outdated scheduling commands after reconnecting.

User Properties: Attach key-value metadata to any message without modifying the payload schema. Useful for passing correlation IDs, station identifiers, or priority flags alongside existing MQTT topics.

Migration effort: Mosquitto 2.x already supports MQTT 5.0. Client libraries (Paho MQTT Python, Paho MQTT JS) support v5. Migration is primarily about updating client connection code to request MQTT 5.0 and then incrementally adopting new features.

3.2 Alternatives: When MQTT Is Not Enough¶

NATS: A compelling alternative or complement to MQTT, particularly as TALOS scales:

Single static binary, no external dependencies, deployable on Raspberry Pi through to cloud clusters.
Sub-millisecond latency, capable of millions of messages per second -- significantly higher throughput than MQTT brokers.
JetStream provides persistent streaming (comparable to Kafka) built into the same binary.
Native support for pub/sub, request/reply, and queue groups in a single system -- TALOS currently would need MQTT plus a separate mechanism for request/reply patterns.
Built-in MQTT bridge: NATS can accept MQTT client connections natively, allowing a gradual migration where existing MQTT clients connect to NATS without code changes.
Leaf nodes enable hub-and-spoke topologies where edge stations connect to a central cluster with automatic reconnection and data sync.
NEX (NATS Execution Engine, announced at KubeCon 2024): Enables scheduling and running workloads on edge nodes, even when disconnected from the cloud. This could allow TALOS stations to run autonomous pass execution locally.

gRPC Streaming: Appropriate for specific inter-service communication within the TALOS backend (scheduler to database, API to scheduler) where type-safe contracts and bidirectional streaming are valuable. Not a replacement for the pub/sub messaging pattern but a strong complement for service-to-service RPC.

WebSockets: TALOS already uses Paho MQTT over WebSocket for the browser frontend. Direct WebSocket connections (without MQTT) offer lower overhead for the dashboard's real-time updates but lose the pub/sub routing that MQTT provides.

3.3 Practical Recommendations for TALOS¶

Action	Priority	Effort
Upgrade MQTT clients to v5.0 protocol	High	Low (Mosquitto 2 already supports it)
Implement shared subscriptions for backend scaling	High	Low
Add message expiry to pass commands	Medium	Low
Evaluate NATS as long-term MQTT replacement	Medium	Medium (proof of concept)
Use gRPC for internal service-to-service calls	Low	Medium

4. Frontend & Visualization¶

4.1 CesiumJS: The Clear Upgrade from Leaflet 2D Maps¶

TALOS currently uses Leaflet.js for 2D map display. CesiumJS is the most mature option for upgrading to 3D orbital visualization:

3D globe with time-dynamic data: CesiumJS natively supports CZML (a JSON-based format for time-dynamic 3D scenes), making it straightforward to render satellite orbits, ground tracks, station coverage cones, and pass geometries on a 3D globe.
Proven in satellite operations: OrbPro (DigitalArsenal) uses CesiumJS to visualize 100,000+ space objects simultaneously. Cognitive Space pairs CesiumJS with AI for satellite mission management. Multiple open-source satellite tracker implementations exist on GitHub.
Photorealistic 3D Tiles: CesiumJS integrates with Google's Photorealistic 3D Tiles for high-fidelity terrain visualization around ground station locations.
Active development: CesiumJS is maintained by Cesium (the company), with regular releases and commercial support available.
Integration path for TALOS: Generate CZML from the Python backend (satellite positions over time from SGP4/dSGP4) and stream it to a CesiumJS frontend. The Cesium Viewer widget handles camera controls, time animation, and entity picking out of the box.

Considerations: CesiumJS requires a Cesium Ion access token for terrain and imagery tiles (free tier available with limits). The library is larger than Leaflet (~3MB gzipped vs ~40KB), so initial page load is heavier.

4.2 Alternative Visualization Libraries¶

deck.gl: Open-source (OpenJS Foundation, originally from Uber) WebGL2/WebGPU framework for large-scale data visualization. Strong for rendering large datasets (thousands of satellite points, ground tracks as line layers). Can integrate with existing map libraries (Mapbox GL JS, Google Maps). A demo exists showing 1,400+ satellite orbits with interactive filtering by orbit type. deck.gl is less "space-native" than CesiumJS -- it excels at data layers on a globe but does not natively handle time-dynamic orbital mechanics or 3D perspective views of space.

Three.js: General-purpose 3D graphics engine (~107k GitHub stars). Maximum flexibility for custom visualizations but requires building all space-specific functionality from scratch (globe rendering, orbit math, coordinate transforms). Best for highly custom visual experiences, not for rapid operational dashboard development.

Comparison for TALOS:

Feature	CesiumJS	deck.gl	Three.js
3D globe with terrain	Built-in	Via map integration	Build from scratch
Time-dynamic orbits	CZML native support	Custom implementation	Custom implementation
Satellite ecosystem	Strong (multiple projects)	Limited	Limited
Learning curve for space apps	Moderate	Moderate	High
Bundle size	Large (~3MB)	Medium (~1MB)	Medium (~600KB)
Best for TALOS	Primary 3D view	Data overlay layers	Custom 3D scenes

4.3 Real-Time Dashboards¶

Grafana: Increasingly used in space operations. JAXA used 10+ Grafana dashboards during their SLIM lunar landing. Pixxel uses Grafana for real-time spacecraft health monitoring across their satellite constellation. A dedicated satellite visualization plugin exists for Grafana.

For TALOS, Grafana is best positioned as a complementary monitoring layer rather than a replacement for the custom dashboard: - Station health metrics (CPU, temperature, network latency, rotator status) - Pass success/failure rates and trends over time - System-level observability (MQTT broker metrics, API response times, database performance) - Integrates with PostgreSQL directly for historical data visualization

Grafana connects natively to PostgreSQL, MQTT (via plugin), and Prometheus, making it low-effort to add alongside the existing TALOS stack.

4.4 Practical Recommendations for TALOS¶

Action	Priority	Effort
Add CesiumJS 3D view alongside existing Leaflet map	High	Medium-High
Generate CZML from backend for orbit visualization	High	Medium
Deploy Grafana for station health monitoring	Medium	Low-Medium
Evaluate deck.gl for high-density data overlays	Low	Medium

5. AI/ML in Ground Operations¶

5.1 Autonomous Scheduling Optimization¶

Current satellite pass scheduling in ground station networks is typically rule-based (priority queues, first-come-first-served, or manual). ML-based scheduling represents the most impactful AI application for TALOS.

Deep reinforcement learning (DRL) for scheduling: Recent research demonstrates attention-based DRL models (ADSMP) where each station can independently make scheduling decisions. The attention mechanism allows the model to weigh competing pass opportunities across the network. This approach scales better than centralized optimization as the network grows.

Practical entry point for TALOS: Before jumping to DRL, simpler optimization approaches yield significant gains: - Constraint satisfaction with heuristics: Model pass scheduling as a constraint satisfaction problem (station availability, minimum elevation, priority, overlap avoidance) and solve with OR-Tools (Google's open-source optimization suite, Python API). - Genetic algorithms: Well-studied for multi-satellite scheduling. Can optimize for network-wide coverage, priority satisfaction, and resource utilization simultaneously. - Greedy + local search: A greedy scheduler with simulated annealing refinement often achieves 90%+ of optimal solutions at a fraction of the computational cost.

5.2 Anomaly Detection in Telemetry¶

This is the most active area of ML research in satellite operations. Key developments:

OPS-SAT benchmark (ESA, 2024-2025): A standardized dataset of 2,123 satellite telemetry fragments with labeled anomalies (drift, stuck, out-of-limit, spike). Thirty ML algorithms were benchmarked, with GCN and TCN models achieving up to 94% precision. This dataset provides a ready-made training and evaluation resource.
Transformer-based approaches (2025): Transformer architectures adapted for time-series telemetry data show strong performance for detecting subtle anomalies that traditional threshold-based monitoring misses.
Supervised models achieve 98.4% accuracy on real satellite telemetry in recent studies, using standard algorithms (logistic regression, SVM, decision trees, deep learning).

TALOS application: Station health telemetry (rotator angles, signal strength, temperature, network metrics) can be monitored with lightweight anomaly detection. Start with statistical methods (Z-score, moving average deviation) and graduate to ML models as labeled data accumulates.

5.3 Signal Classification¶

Automatic identification of satellite signals from SDR recordings. Relevant if TALOS stations use SDRs and need to identify unknown signals or verify correct satellite acquisition. Convolutional neural networks trained on spectrograms have shown strong results for classifying modulation types and identifying satellite-specific signal patterns.

5.4 Predictive Maintenance¶

Using station telemetry trends to predict hardware failures (rotator motor wear, LNA degradation, antenna alignment drift). Requires accumulating historical failure data, which TALOS should start collecting now even if predictive models come later.

5.5 Practical Recommendations for TALOS¶

Action	Priority	Effort
Implement constraint-based scheduling with OR-Tools	High	Medium
Add statistical anomaly detection for station telemetry	Medium	Low-Medium
Begin collecting labeled station health data for future ML	Medium	Low
Evaluate signal classification for SDR-equipped stations	Low	High
Explore DRL scheduling as a research project	Low	High

6. Hardware Trends¶

6.1 Software Defined Radio Advancements¶

The SDR landscape has matured significantly, with several platforms relevant to TALOS stations:

ADALM-Pluto (Analog Devices): Full-duplex RX/TX, 70 MHz to 6 GHz, up to 56 MHz bandwidth. At approximately $200, it is the most cost-effective entry point for SDR-based satellite reception. Sufficient for most amateur satellite bands (VHF, UHF, S-band). LibreSpace (the SatNOGS parent organization) conducted a comprehensive laboratory comparison of multiple SDRs, providing empirical data for selection.

LimeSDR Mini 2.0: 10 MHz to 3.5 GHz, 30.72 MHz bandwidth, full duplex. Open-source hardware with strong community support. Good middle ground between Pluto's simplicity and USRP's capability.

Ettus USRP B210: 70 MHz to 6 GHz, 56 MHz bandwidth, 2x2 MIMO. The professional reference platform for SDR development. Higher cost (~$1,500) but exceptional driver support, documentation, and GNU Radio integration. Suitable for stations that need reliable, high-performance SDR capability.

RTL-SDR Blog V4: The latest revision of the ubiquitous RTL-SDR dongle. Receive-only, but at $30 it enables low-cost receive stations. Adequate for many amateur satellite downlinks.

6.2 Phased Array Antennas¶

The commercial ground station industry is moving toward electronically steered phased arrays that eliminate mechanical rotators:

ADALM-PHASER (Analog Devices): Educational/prototyping kit combining PlutoSDR with ADAR1000 beamformer chips and an 8-element patch antenna array. Operates at 10-11 GHz with 500 MHz bandwidth. While not directly applicable to VHF/UHF amateur bands, it demonstrates accessible phased array technology.
Commercial phased arrays: Companies are deploying multi-beam arrays that can track multiple satellites simultaneously without mechanical movement. This eliminates the rotator as a single point of failure and enables simultaneous multi-satellite passes.
TALOS relevance: Phased arrays at VHF/UHF frequencies require physically large elements, making them less practical for amateur stations. However, at S-band and above, the element sizes become manageable. For TALOS, phased arrays are a future consideration rather than an immediate upgrade path. The current Hamlib/rotctld approach remains appropriate for mechanically steered antennas.

6.3 Edge Compute Devices¶

Beyond Raspberry Pi, several platforms offer better performance for station-level processing:

Raspberry Pi 5: Significant CPU upgrade over Pi 4 (2-3x performance). Adequate for station control, pass scheduling, and light SDR processing. Remains the default choice for cost-sensitive deployments.
NVIDIA Jetson Orin Nano: GPU-accelerated edge compute. Relevant if stations need local ML inference (signal classification, anomaly detection) or GNU Radio DSP acceleration.
Intel NUC / Mini PCs: x86 compatibility eliminates ARM compilation issues. Fanless models suitable for outdoor enclosures. 8-16GB RAM handles GNU Radio flowgraphs comfortably.
Orange Pi 5 / Rock 5B: ARM alternatives to Raspberry Pi with better price/performance ratios and more RAM options (up to 16GB).

6.4 Practical Recommendations for TALOS¶

Action	Priority	Effort
Standardize on ADALM-Pluto or RTL-SDR V4 for new stations	Medium	Low
Test Raspberry Pi 5 as station controller upgrade	Medium	Low
Evaluate Intel NUC for stations needing GNU Radio DSP	Low	Medium
Monitor phased array developments for future adoption	Low	Low (research only)

7. Recommended Technology Upgrades -- Prioritized¶

Based on the research above, here is a prioritized roadmap of technology upgrades for TALOS, organized by implementation timeline and impact.

Tier 1: High Impact, Low-Medium Effort (Implement within 3-6 months)¶

Upgrade to MQTT 5.0 protocol
Mosquitto 2 already supports it; update Paho clients to request v5
Immediately adopt shared subscriptions, message expiry, and enhanced reason codes
Zero infrastructure change required
Integrate dSGP4 for batch pass prediction
pip install dsgp4 -- PyTorch-based, compatible with existing Python stack
Batch-propagate all tracked satellites in parallel (CPU or GPU)
Measurably faster and more accurate than serial Skyfield SGP4 calls
Switch Space-Track to GP JSON API
Replace TLE text parsing with structured JSON responses
Cleaner data pipeline, better error handling
Deploy Grafana for station health monitoring
Connect directly to existing PostgreSQL database
Pre-built dashboards for station uptime, pass success rates, system metrics
Satellite visualization plugin available
Implement constraint-based scheduling with Google OR-Tools
Replace rule-based scheduling with proper optimization
Model station availability, priorities, elevation constraints, overlap avoidance
Python API integrates directly with FastAPI backend

Tier 2: High Impact, Medium-High Effort (Implement within 6-12 months)¶

Add CesiumJS 3D orbital visualization
Generate CZML from Python backend for time-dynamic orbit display
Render satellite positions, ground tracks, station coverage cones, and pass geometries
Can coexist with existing Leaflet 2D map (offer both views)
Evaluate NATS as messaging backbone
Build a proof-of-concept replacing Mosquitto with NATS
Test MQTT bridge compatibility (existing clients connect unchanged)
Assess JetStream for persistent message history
Leaf node topology for station-to-hub connectivity with offline resilience
Add statistical anomaly detection for station telemetry
Implement Z-score and moving average deviation monitoring
Alert on rotator drift, signal strength degradation, thermal anomalies
Foundation for future ML-based detection
Integrate gr-satellites for SDR-equipped stations
Enable automatic signal decoding during passes
Supports ~40 amateur satellite protocols
Pairs with ADALM-Pluto or RTL-SDR hardware

Tier 3: Strategic Investments (12+ months, as resources allow)¶

Begin collecting labeled training data
- Station health events, pass quality metrics, hardware failure records
- Essential foundation for any future ML models (anomaly detection, predictive maintenance)
SDR standardization across network
- Select and standardize on 1-2 SDR platforms (ADALM-Pluto for TX/RX, RTL-SDR V4 for receive-only)
- Build automated SDR control into station software
Explore deep reinforcement learning for network-wide scheduling
- Research project building on the constraint-based scheduler
- Attention-based models for distributed scheduling decisions
Evaluate phased array antennas for S-band stations
- Monitor price/availability of commercial phased arrays at relevant frequencies
- Long-term path to eliminating mechanical rotator maintenance

What NOT to Adopt¶

Some technologies, while interesting, are not recommended for TALOS at this time:

AWS Ground Station / commercial GSaaS: Designed for high-bandwidth commercial missions, not amateur operations. Cost-prohibitive for TALOS's use case. Learn from their API patterns, but do not integrate.
Full Orekit integration: The JVM dependency and complexity are not justified when dSGP4 and Skyfield cover TALOS's propagation needs. Reserve for if TALOS needs high-fidelity numerical propagation.
WebRTC for station communication: Adds complexity without clear benefit over MQTT/NATS for the pub/sub telemetry pattern. WebRTC excels at peer-to-peer media streaming, which is not TALOS's communication model.
Kubernetes / complex container orchestration: Docker Compose is sufficient for TALOS's current scale. Kubernetes adds operational overhead that is not justified until the backend requires horizontal scaling across multiple servers.

Summary¶

The most impactful near-term upgrades for TALOS are:

MQTT 5.0 -- free performance and reliability improvements with minimal code changes
dSGP4 -- faster, more accurate batch propagation that drops into the existing Python stack
OR-Tools scheduling -- transforms pass scheduling from heuristic to optimized
Grafana -- immediate operational visibility with near-zero development effort
CesiumJS -- transforms the user experience from 2D maps to 3D orbital awareness

These five upgrades align with TALOS's existing technology choices (Python, PostgreSQL, Docker, web frontend) and can be adopted incrementally without architectural overhaul.