CCSDS Compliance Analysis for TALOS Ground Station Network¶
Date: 2026-04-01 Scope: Assessment of TALOS system alignment with Consultative Committee for Space Data Systems (CCSDS) Recommended Standards, focused on practical applicability to an open-source distributed ground station controller.
1. Executive Summary¶
TALOS is a distributed satellite ground station network controller handling orbit prediction, pass scheduling, antenna pointing, Doppler correction, and multi-station coordination via MQTT. It currently operates with proprietary internal data formats and protocols. While TALOS is not a deep-space mission system and does not need full CCSDS stack compliance, selective adoption of CCSDS data format standards -- particularly for orbit data, tracking data, and time codes -- would significantly improve interoperability with the broader space operations ecosystem at relatively low implementation cost.
This analysis identifies which CCSDS standards are relevant, where gaps exist, and which standards deliver practical value versus those that would be overkill for the TALOS use case.
2. Relevant CCSDS Standards¶
2.1 High Relevance (Directly Applicable)¶
CCSDS 502.0 -- Orbit Data Messages (ODM)¶
- Standard: CCSDS 502.0-B-3 (Blue Book), also ISO 26900:2024
- Content: Defines four message formats for exchanging spacecraft orbit information:
- OPM (Orbit Parameter Message): Position/velocity state vector at a single epoch, with optional osculating Keplerian elements.
- OMM (Orbit Mean-Elements Message): Mean orbital elements -- this is the CCSDS-standard way to exchange what TALOS currently gets as raw TLE data. The OMM includes the SGP4 mean elements (inclination, RAAN, eccentricity, argument of perigee, mean anomaly, mean motion) in a structured, self-describing format.
- OEM (Orbit Ephemeris Message): Time-series of state vectors for interpolation -- useful for predicted orbit tracks.
- OCM (Orbit Comprehensive Message): Extended format incorporating perturbation models and covariance.
- Formats: Both KVN (Keyword=Value Notation, plain ASCII) and XML (per CCSDS 505.0-B-3).
- TALOS Relevance: Critical. TALOS currently ingests raw TLE lines from SatNOGS and passes them directly to Skyfield's
EarthSatellite(). The OMM is the CCSDS-standard wrapper for exactly this data. Space-Track.org, 18th Space Defense Squadron, and commercial SSA providers increasingly distribute orbit data in OMM/OEM format alongside or instead of raw TLEs.
CCSDS 503.0 -- Tracking Data Message (TDM)¶
- Standard: CCSDS 503.0-B-2 (Blue Book, 2020)
- Content: Standardized message format for exchanging spacecraft tracking data between agencies. Includes range, Doppler, angles (azimuth/elevation), receive/transmit frequencies, and signal metadata. Data is structured as Header + Metadata + Data Sections with timestamped tracking records.
- Formats: KVN and XML.
- TALOS Relevance: High. TALOS already computes and distributes azimuth, elevation, and Doppler-corrected frequencies to ground stations via MQTT. If TALOS were to log or export this tracking data, the TDM format would be the standard way to do it. This matters for: (a) validating tracking accuracy against other systems, (b) contributing tracking data to orbit determination campaigns, (c) interoperating with professional ground networks.
CCSDS 301.0 -- Time Code Formats¶
- Standard: CCSDS 301.0-B-4 (Blue Book)
- Content: Defines standard time code representations:
- CUC (CCSDS Unsegmented Code): Binary counter from a defined epoch (default: 1958-01-01 TAI). Resolution configurable from 1 second to ~60 nanoseconds. Not UTC-based, so no leap-second discontinuities.
- CCS (CCSDS Calendar Segmented Code): Calendar-based (year, month, day, hour, minute, second) -- analogous to ISO 8601 but with specific binary encoding.
- CDS (CCSDS Day Segmented Code): Day count + milliseconds-of-day.
- TALOS Relevance: Medium-High. TALOS currently uses a mix of
time.time()(Unix epoch),datetime.utcnow().isoformat(), and Skyfield's internal timescale. There is no consistent time representation standard. For MQTT messages, TALOS publishes raw Unix timestamps ("ts": time.time()). Adopting CCSDS time codes, or at minimum ISO 8601 with explicit UTC designation, would improve data integrity and interoperability.
2.2 Medium Relevance (Valuable for Growth)¶
CCSDS 508.0 -- Conjunction Data Message (CDM)¶
- Standard: CCSDS 508.0-B-1 (Blue Book), currently being updated
- Content: Standard format for exchanging conjunction (close-approach) information between space objects. Includes: object identification, Time of Closest Approach (TCA), miss distance, state vectors at TCA, and covariance matrices.
- TALOS Relevance: Medium. TALOS does not currently perform conjunction assessment, but as a multi-satellite tracking system it has the orbital data needed to flag potential conjunctions. Consuming CDM data from providers like Space-Track.org or LeoLabs would allow TALOS to alert operators about conjunction risks for tracked satellites. This is increasingly important in the congested LEO environment.
CCSDS 910.3 / SLE -- Space Link Extension Services¶
- Standard: CCSDS 910.3-G-3 (Cross Support Concept, Part 1: SLE), plus specific service standards (RAF, RCF, CLTU, FSP)
- Content: SLE defines how ground station telemetry/telecommand data is transferred between a ground station (provider) and a mission control center (user) over TCP/IP. It is essentially a container protocol that wraps TM frames (Return All Frames / Return Channel Frames services) and TC frames (Forward CLTU / Forward Space Packet services).
- TALOS Relevance: Medium. SLE is the standard way professional ground stations expose their services to remote mission control centers. If TALOS stations were to offer cross-support to external missions (or consume data from SLE-compliant stations like those in ESA's ESTRACK or NASA's DSN/NEN), SLE support would be necessary. A Python SLE library exists on PyPI (
slepackage). However, for TALOS's current architecture where the Mission Director directly commands stations via MQTT, SLE is not strictly necessary -- it becomes relevant when federating with external networks.
CCSDS 520.0 -- Mission Operations Services Concept¶
- Standard: CCSDS 520.0-G-3 (Green Book)
- Content: Defines a service-oriented architecture for mission operations including monitoring and control, planning, scheduling, and automation. Uses a publish-subscribe pattern with standardized service interfaces.
- TALOS Relevance: Medium. The CCSDS Mission Operations (MO) framework is conceptually aligned with what TALOS already does -- it uses MQTT pub/sub for command and control. However, the MO service definitions (MAL, COM, MC services) are heavyweight and designed for full spacecraft operations. The architectural patterns are more relevant than the specific protocol implementations.
2.3 Lower Relevance (Overkill for Current Scope)¶
CCSDS 401.0 -- Radio Frequency and Modulation Systems¶
- Standard: CCSDS 401.0-B-32 (Blue Book)
- Content: Defines RF characteristics, modulation schemes, frequency bands, symbol rates, and Earth station categories for space communications. Covers S-band, X-band, Ka-band, and optical links.
- TALOS Relevance: Low. TALOS does not define or constrain the RF layer -- it passes frequency and mode information from SatNOGS metadata to ground station SDRs via Hamlib/rigctld. The actual modulation and demodulation is handled by the SDR software (GNU Radio, SDR++, etc.), not by TALOS. CCSDS 401 is relevant to the hardware and SDR software layer, not the orchestration layer where TALOS operates.
CCSDS 131.0 / 132.0 -- TM Synchronization and Channel Coding / TM Space Data Link Protocol¶
- Standard: CCSDS 131.0-B-4 (TM Sync & Channel Coding), CCSDS 132.0-B-3 (TM Space Data Link Protocol)
- Content: Defines how telemetry data is framed, synchronized, and error-protected on the space-to-ground link. Includes virtual channel multiplexing, frame structure, and Reed-Solomon/LDPC/Turbo coding.
- TALOS Relevance: Low. These standards apply to the baseband signal processing layer -- how bits on the RF link are structured into frames. TALOS does not process TM frames; it orchestrates when and where the antenna points and what frequency the receiver tunes to. If TALOS were to add a data processing pipeline that decoded actual satellite telemetry, these standards would become relevant for missions that use CCSDS framing (many LEO missions use AX.25 or custom protocols instead).
CCSDS 232.0 -- TC Space Data Link Protocol¶
- Standard: CCSDS 232.0-B-4 (Blue Book)
- Content: Defines telecommand frame structure and the Communications Operation Procedure (COP-1) for reliable command delivery.
- TALOS Relevance: Low. Same reasoning as TM protocols above. TALOS is a receive-focused system. If uplink capability were added, TC standards would matter for missions using CCSDS command protocols, but many small satellites use simpler command formats.
3. Gap Analysis¶
3.1 Orbit Data Handling¶
| Aspect | Current TALOS Behavior | CCSDS Standard | Gap |
|---|---|---|---|
| TLE Ingestion | Raw TLE lines from SatNOGS API, parsed by Skyfield | CCSDS 502.0 OMM format | TALOS consumes TLE1/TLE2 strings directly. No support for OMM/OPM/OEM import or export. |
| Orbit State Storage | TLE lines cached in memory; SatelliteCache table stores metadata only |
CCSDS 502.0 OPM/OEM | No standardized orbit state persistence. |
| Ephemeris Export | Ground track computed internally (calculate_ground_track), published as lat/lon arrays via MQTT |
CCSDS 502.0 OEM | Ephemeris data is in a custom JSON format, not OEM. |
| Epoch Reference | Uses SatNOGS sat_id as primary key |
CCSDS 502.0 requires NORAD ID or COSPAR ID | Partial -- norad_id is stored but sat_id (SatNOGS UUID) is the primary identifier. |
3.2 Tracking Data¶
| Aspect | Current TALOS Behavior | CCSDS Standard | Gap |
|---|---|---|---|
| Az/El Data | Published as JSON {"az": float, "el": float} on MQTT |
CCSDS 503.0 TDM ANGLE_1/ANGLE_2 keywords | Custom format, no TDM compliance. |
| Doppler Data | Computed and published as corrected frequency integer | CCSDS 503.0 TDM DOPPLER_INSTANTANEOUS keyword | No standard Doppler data export. |
| Pass Events | AOS/LOS detected by elevation threshold (0 degrees), published as {"action": "START/STOP"} |
CCSDS 503.0 TDM with time-tagged records | Events are command-oriented, not logged as tracking data. |
| Tracking Data Archive | None -- data is ephemeral on MQTT | CCSDS 503.0 TDM file format | No tracking data persistence or export. |
3.3 Time Representation¶
| Aspect | Current TALOS Behavior | CCSDS Standard | Gap |
|---|---|---|---|
| MQTT Timestamps | time.time() (Unix epoch float) |
CCSDS 301.0 CDS or ISO 8601 | Non-standard. Unix timestamps are ambiguous about leap seconds. |
| Event Timestamps | datetime.utcnow().isoformat() |
CCSDS 301.0 recommends TAI or explicit UTC | utcnow() is deprecated in Python 3.12+. No timezone annotation. |
| Pass Predictions | Skyfield internal times, converted to Unix timestamps for MQTT | CCSDS 301.0 | Skyfield uses TT (Terrestrial Time) internally, which is correct, but export format is non-standard. |
| Database Timestamps | datetime.utcnow as default factory |
CCSDS 301.0 | Should use datetime.now(timezone.utc) with explicit UTC. |
3.4 Inter-System Communication¶
| Aspect | Current TALOS Behavior | CCSDS Standard | Gap |
|---|---|---|---|
| Station-to-Director Protocol | Custom MQTT JSON topics (talos/gs/+/cmd/rot, etc.) |
CCSDS SLE (910.x series) | Completely custom. No SLE compatibility. |
| Service Discovery | MQTT topic-based (talos/gs/+/info) |
CCSDS Cross Support (910.x) | Custom handshake protocol. |
| Mission Planning | Manual via web dashboard | CCSDS MO Services (520.x) | No standardized planning interface. |
4. Practical Recommendations¶
Prioritized by effort-to-value ratio, from highest value to lowest.
Priority 1: Adopt OMM for Orbit Data Exchange (Low Effort, High Value)¶
What: Add OMM import/export capability alongside existing TLE support.
Why: The OMM is essentially a self-describing wrapper around TLE/SGP4 mean elements. Space-Track.org already provides OMM-format data via its GP (General Perturbations) API. The OMM adds metadata that raw TLEs lack: originator, message ID, reference frame, and center name. This costs almost nothing to implement since the underlying data is the same SGP4 element set.
How:
- Parse OMM KVN files (simple keyword=value text parsing).
- Export mission orbit data in OMM format for sharing.
- Use NORAD Catalog ID as the authoritative object identifier (TALOS already stores this).
- Consider the orekit or astropy Python libraries which have CCSDS message parsers.
Estimated effort: 1-2 days.
Priority 2: Standardize Time Representation (Low Effort, High Value)¶
What: Adopt ISO 8601 with explicit UTC designation across all MQTT messages and database records.
Why: TALOS currently mixes time.time(), datetime.utcnow(), and Skyfield times. This is fragile and the utcnow() call is deprecated. Standardizing on ISO 8601 with "Z" suffix (e.g., 2026-04-01T14:30:00.000Z) aligns with CCSDS 301.0 CCS format and is universally parseable.
How:
- Replace all time.time() in MQTT payloads with datetime.now(timezone.utc).isoformat().
- Replace all datetime.utcnow() with datetime.now(timezone.utc).
- Document that all TALOS timestamps are UTC.
Estimated effort: Half a day.
Priority 3: Add TDM Export for Tracking Data (Medium Effort, High Value)¶
What: Log tracking data (az, el, Doppler, frequency) in CCSDS 503.0 TDM format.
Why: TALOS already computes all the data that goes into a TDM -- azimuth, elevation, Doppler shift, receive frequency -- but it only publishes this ephemerally on MQTT. Persisting it in TDM format creates a permanent record that can be: (a) used to validate tracking accuracy, (b) shared with other operators, (c) contributed to orbit determination. The TDM KVN format is simple ASCII text.
How:
- Create a tracking data logger that subscribes to talos/gs/+/cmd/rot and talos/gs/+/cmd/rig topics.
- Write accumulated pass data to TDM KVN files at LOS (end of pass).
- Include metadata: station location, satellite ID, time system (UTC), reference frame.
Example TDM output for a TALOS pass:
CCSDS_TDM_VERS = 2.0
CREATION_DATE = 2026-04-01T14:30:00.000Z
ORIGINATOR = TALOS
META_START
TIME_SYSTEM = UTC
PARTICIPANT_1 = ISS (ZARYA)
PARTICIPANT_2 = GS_ATHENS_01
MODE = SEQUENTIAL
PATH = 1,2
ANGLE_TYPE = AZEL
META_STOP
DATA_START
ANGLE_1 = 2026-04-01T14:30:00.000Z 180.25
ANGLE_2 = 2026-04-01T14:30:00.000Z 5.30
RECEIVE_FREQ = 2026-04-01T14:30:00.000Z 145919850
DATA_STOP
Estimated effort: 2-3 days.
Priority 4: OEM Export for Predicted Passes (Medium Effort, Medium Value)¶
What: Export predicted satellite ephemeris (the data behind calculate_ground_track and pass predictions) in OEM format.
Why: TALOS already computes predicted positions for visualization and scheduling. Exporting this as OEM makes it consumable by any CCSDS-compliant tool (STK, GMAT, Orekit, etc.) for validation or further analysis.
Estimated effort: 1-2 days.
Priority 5: CDM Consumption for Conjunction Awareness (Medium Effort, Medium Value)¶
What: Ingest CDM data from Space-Track.org or other SSA providers to alert operators about conjunction risks for tracked satellites.
Why: As a system that tracks specific satellites, TALOS is a natural place to surface conjunction warnings. Space-Track.org provides CDM data for registered satellites. This is a safety-relevant feature.
Estimated effort: 3-5 days (including Space-Track.org API integration).
Priority 6: SLE Gateway (High Effort, Situational Value)¶
What: Implement an SLE interface so TALOS stations can provide cross-support to external mission control centers.
Why: SLE is the standard protocol for ground station cross-support. If TALOS stations are ever to serve external missions (beyond the TALOS ecosystem), SLE is the interoperability standard. A Python SLE library exists (sle on PyPI).
When to do this: Only when TALOS stations need to interoperate with professional ground networks (ESA ESTRACK, NASA NEN, commercial providers). For an internal amateur/small-sat network, MQTT is simpler and sufficient.
Estimated effort: 2-4 weeks.
Not Recommended for TALOS¶
- CCSDS 401.0 (RF/Modulation): TALOS is an orchestration layer, not an RF system. The SDR and radio hardware/software handle this independently.
- CCSDS 131/132/232 (TM/TC Data Link): These are baseband/frame-level protocols. Only relevant if TALOS adds a signal processing pipeline for CCSDS-compliant satellites. Most amateur/small-sat targets use AX.25 or custom protocols.
- CCSDS MO Services (Full Implementation): The MAL/COM/MC service framework is enterprise-grade middleware. The architectural patterns (pub/sub, service orientation) are already present in TALOS via MQTT. Adopting the full MO stack would be over-engineering for the current use case.
5. Data Format Standards Summary¶
Recommended Format Adoption¶
| Data Type | Current Format | Recommended CCSDS Format | Standard |
|---|---|---|---|
| Orbit elements (TLE equivalent) | Raw TLE1/TLE2 strings | OMM (KVN or XML) | CCSDS 502.0 |
| Predicted ephemeris | Custom JSON lat/lon arrays | OEM (KVN or XML) | CCSDS 502.0 |
| Tracking angles/Doppler | Custom MQTT JSON | TDM (KVN) | CCSDS 503.0 |
| Timestamps | Unix epoch float / naive datetime | ISO 8601 UTC (CCS-compatible) | CCSDS 301.0 |
| Conjunction alerts | Not implemented | CDM (KVN or XML) | CCSDS 508.0 |
| Station-to-MCC data transfer | Custom MQTT JSON | SLE RAF/RCF (when needed) | CCSDS 910.x |
Format Selection: KVN vs XML¶
For TALOS, KVN (Keyword=Value Notation) is recommended as the primary format for CCSDS messages:
- KVN is human-readable plain ASCII text, easy to debug.
- KVN is simpler to generate and parse than XML.
- KVN files are smaller than equivalent XML.
- XML (per CCSDS 505.0-B-3) should be supported as a secondary format for machine-to-machine exchanges where schema validation is needed.
6. Interoperability Benefits¶
6.1 With Space-Track.org and SSA Providers¶
Adopting OMM/OEM/CDM formats enables direct data exchange with: - 18th Space Defense Squadron (Space-Track.org) -- primary source of orbit data for most LEO objects. - LeoLabs, ExoAnalytic, Slingshot -- commercial SSA providers that use CCSDS formats. - ESA's Space Debris Office -- uses CCSDS navigation data messages. - US Office of Space Commerce (TraCSS) -- the new civil space traffic coordination system mandates CCSDS formats (OMM, CDM, OCM).
6.2 With Other Ground Station Networks¶
TDM export enables TALOS tracking data to be consumed by: - SatNOGS -- while SatNOGS uses its own formats, TDM provides a bridge to professional networks. - AMSAT -- amateur satellite community could benefit from standardized tracking data. - University ground stations -- many university programs are adopting CCSDS standards for educational value.
6.3 With Mission Planning and Analysis Tools¶
OEM/OMM support enables orbit data exchange with: - GMAT (General Mission Analysis Tool) -- NASA's open-source mission analysis software. - Orekit -- open-source orbital mechanics library (Java/Python) with native CCSDS support. - STK/ODTK -- AGI/Ansys commercial tools that import/export CCSDS messages. - Astropy -- the Python astronomy library has CCSDS time code support.
6.4 Federation with Professional Networks¶
If TALOS were to add SLE support, it could: - Provide cross-support to missions that need additional ground coverage. - Consume data from professional networks (e.g., receive TM frames from an ESA station and process them locally). - Participate in international ground network confederations where SLE is the expected interface.
7. Implementation Roadmap¶
Phase 1: Data Formats (Weeks 1-2)¶
- Fix time handling: replace
utcnow()with timezone-aware UTC, use ISO 8601 in all MQTT messages. - Add OMM parser for orbit data ingestion (complement existing TLE support).
- Add OMM/OEM export endpoints to the FastAPI API.
Phase 2: Tracking Data (Weeks 3-4)¶
- Implement tracking data logger (subscribe to MQTT tracking topics).
- Write TDM exporter for completed passes.
- Add TDM download endpoint to the dashboard.
Phase 3: Situational Awareness (Weeks 5-8)¶
- Integrate Space-Track.org API for CDM data.
- Add conjunction alerting for active missions.
- Implement OEM export for predicted passes.
Phase 4: Interoperability (Future)¶
- Evaluate SLE gateway implementation based on demand.
- Consider CCSDS MO patterns for service interface standardization.
- Explore CCSDS Cross Support Transfer Services (CSTS) as next-generation SLE.
8. Conclusion¶
TALOS already performs many functions that CCSDS standards are designed to standardize -- orbit propagation, pass prediction, antenna steering, Doppler computation, and multi-station coordination. The gap is not in capability but in data format and protocol compliance. The highest-value improvements are in the data layer: adopting OMM for orbit data, TDM for tracking data, and ISO 8601/CCSDS 301 for time representation. These changes are low-effort, high-impact improvements that position TALOS for interoperability with the broader space operations ecosystem without requiring the heavyweight protocol stacks (SLE, MO Services) that are designed for agency-scale operations.
The key insight is that CCSDS compliance is not all-or-nothing. TALOS can selectively adopt the data format standards (Blue Books 301, 502, 503) that add real interoperability value while continuing to use MQTT as its internal transport -- an approach that is pragmatic, achievable, and genuinely useful.
References¶
- CCSDS 502.0-B-3, Orbit Data Messages (Blue Book) -- https://ccsds.org/Pubs/502x0b3e1.pdf
- CCSDS 503.0-B-2, Tracking Data Message (Blue Book) -- https://ccsds.org/Pubs/503x0b2c1.pdf
- CCSDS 301.0-B-4, Time Code Formats (Blue Book) -- https://ccsds.org/Pubs/301x0b4e1.pdf
- CCSDS 505.0-B-3, XML Specification for Navigation Data Messages -- https://ccsds.org/Pubs/505x0b3e2.pdf
- CCSDS 508.0-B-1, Conjunction Data Message -- https://ccsds.org/Pubs/508x0b1e2s.pdf
- CCSDS 910.3-G-3, Cross Support Concept Part 1: SLE -- https://public.ccsds.org/Pubs/910x3g3.pdf
- CCSDS 520.0-G-3, Mission Operations Services Concept -- https://ccsds.org/Pubs/520x0g3.pdf
- CCSDS 401.0-B-32, Radio Frequency and Modulation Systems Part 1 -- https://ccsds.org/Pubs/401x0b32.pdf
- CCSDS 132.0-B-3, TM Space Data Link Protocol -- https://ccsds.org/Pubs/132x0b3.pdf
- CCSDS Blue Books Index -- https://ccsds.org/publications/bluebooks/
- NASA Small Spacecraft Technology: Ground Data Systems -- https://www.nasa.gov/smallsat-institute/sst-soa/ground-data-systems-and-mission-operations/
- CCSDS Navigation Data Messages Overview -- https://ccsds.org/Pubs/500x2g3.pdf