Project 12: Ground Station Command Console (The HMI)

Build a ground station console that decodes CCSDS telemetry, validates commands, and displays pass windows with safe operation gating.

Quick Reference

Attribute Value
Difficulty Level 2: Intermediate
Time Estimate 2-3 weeks
Main Programming Language TypeScript/React
Alternative Programming Languages Python (CLI)
Coolness Level Level 3: The Operator
Business Potential Level 3: Ground Segment UX
Prerequisites Web basics, JSON, basic networking
Key Topics Telemetry decoding, command validation, pass scheduling

1. Learning Objectives

By completing this project, you will:

  1. Decode CCSDS telemetry packets into human-readable metrics.
  2. Design a safe command console with validation and gating.
  3. Display pass windows and enforce transmission only during visibility.
  4. Provide deterministic logs of sent commands and received telemetry.
  5. Understand operator workflows for short ground passes.

2. All Theory Needed (Per-Concept Breakdown)

Telemetry Decoding and CCSDS Metadata

Fundamentals Telemetry decoding turns binary packets into meaningful values. CCSDS headers tell you which subsystem a packet belongs to and how long it is. A ground console must parse headers correctly, then decode payload fields using mission-specific schemas. Without correct decoding, operators misinterpret the spacecraft state. Therefore, telemetry decoding is the foundation of any ground system.

Deep Dive into the concept Telemetry arrives as binary packets with CCSDS primary headers. The APID identifies the subsystem (EPS, ADCS, COMMS). The payload is typically structured with fixed fields: integers, floats, bit flags. The decoder must map raw bytes to engineering units. This mapping is defined in an ICD (Interface Control Document). For example, a battery voltage might be stored as a 16-bit ADC count that must be scaled by a factor. A magnetometer reading might be a signed 16-bit value representing microtesla. The decoder applies these scale factors and unit conversions before displaying values.

Telemetry decoding should be deterministic and versioned. If the spacecraft firmware changes the payload layout, the ground system must update accordingly. Including a packet “version” or “schema ID” in telemetry allows the decoder to handle multiple formats. In this project, you can implement a static schema map keyed by APID. Each schema defines field offsets, types, and scaling. For example: voltage = raw_u16 * 0.01.

The decoding pipeline should validate packet length and checksum. If the packet is malformed, the decoder should reject it and log an error. It should also record the time received and include the packet’s onboard timestamp if available. Operators need both: onboard time for mission context, and ground time for troubleshooting.

Visualization is part of decoding. Raw numbers are not enough; you should present key metrics in panels: battery SoC, temperatures, mode, and pass countdown. This helps operators make quick decisions during a short pass. A well-designed console prioritizes clarity: highlight out-of-range values in red, show trends with small plots, and expose raw values for debugging.

How this fit on projects This concept drives Section 3.2 telemetry requirements and Section 4 architecture (decoder), and connects to P01 packet parsing.

Definitions & key terms

  • APID -> Identifies telemetry source.
  • ICD -> Interface Control Document defining payload layout.
  • Engineering units -> Physical units after scaling (V, C, deg/s).

Mental model diagram (ASCII)

Binary Packet -> CCSDS Header -> Payload Schema -> Engineering Values

How it works (step-by-step, with invariants and failure modes)

  1. Parse CCSDS header and validate length.
  2. Select schema by APID.
  3. Decode payload fields with scaling.
  4. Display values and log raw packet.

Invariants: length matches schema; scaling applied consistently; timestamps recorded.

Failure modes: wrong schema, unit mismatch, silent data corruption.

Minimal concrete example

const voltage = rawU16 * 0.01; // V

Common misconceptions

  • “If the header parses, the payload is correct” -> Schema mismatches are common.
  • “Units are obvious” -> They must be explicitly defined.

Check-your-understanding questions

  1. Why use APIDs to select schemas?
  2. What happens if a scaling factor is wrong?
  3. Why log both onboard and ground time?

Check-your-understanding answers

  1. Each APID represents a distinct payload layout.
  2. All derived values become wrong, leading to bad decisions.
  3. Onboard time gives mission context; ground time helps debugging.

Real-world applications

  • Mission control dashboards.
  • Telemetry ingestion pipelines.

Where you’ll apply it

References

  • CCSDS 133.0-B-1 (Space Packet Protocol)
  • Space Mission Engineering (ground operations)

Key insights Telemetry decoding is a contract between flight software and ground.

Summary A reliable decoder turns raw packets into mission decisions.

Homework/Exercises to practice the concept

  • Define a schema for a 16-byte EPS packet and decode a sample hex string.

Solutions to the homework/exercises

  • Map each field offset to type and apply scaling.

Command Validation and Pass Scheduling

Fundamentals Commands can change spacecraft state, so they must be validated. The ground console should prevent unsafe commands by checking current mode, SoC, and pass visibility. Additionally, commands can only be sent during contact windows; if you send a command outside a pass, it will never reach the satellite. Therefore the console must display pass windows and gate the send button accordingly.

Deep Dive into the concept Command validation is a safety layer. Each command has prerequisites, such as allowed modes and required system health. For example, a payload enable command may only be allowed in SCIENCE mode with SoC above 60% and no eclipse. Validation should be encoded in a policy table so it is transparent and auditable. When a command is rejected, the UI must display a reason (e.g., “SoC below 60%”). This reduces operator error and builds trust.

Pass scheduling requires predicting visibility windows. For this project, you can accept pass windows as input (from a file or service). The console should display the next pass, time remaining, and whether the spacecraft is currently visible. The send button should be disabled outside a pass. If a command is time-tagged for later execution, the console should validate that the scheduled time falls within a pass.

Command queues are useful for short passes: operators can queue multiple commands that will be sent in order. The console should track command status (queued, sent, acknowledged). If telemetry confirms command execution, update status. This requires a simple command log and correlation with telemetry acknowledgments.

Security matters even in a local simulator. Implement at least a basic authentication layer (e.g., confirmation modal, or a session token) to simulate operational discipline. In real systems, commands are cryptographically signed. For this project, the point is to show the workflow: validate -> confirm -> send -> log.

How this fit on projects This concept drives Section 3.2 command requirements and Section 5.5 design questions. It ties to P02 mode gating and P04 pass prediction.

Definitions & key terms

  • Command gating -> Blocking unsafe commands.
  • Pass window -> Visibility interval when commands can be sent.
  • Ack -> Telemetry confirmation of command execution.

Mental model diagram (ASCII)

Command -> Validation -> (Pass OK?) -> Send -> Log -> Ack

How it works (step-by-step, with invariants and failure modes)

  1. Operator selects command.
  2. Validate against policy and telemetry.
  3. Ensure inside pass window.
  4. Send and log command.
  5. Await acknowledgment.

Invariants: no commands sent outside pass; validation always enforced.

Failure modes: unsafe command acceptance, pass schedule mismatch, missing logs.

Minimal concrete example

if (!passActive) disableSend();
if (soc < 0.6) reject("LOW_SOC");

Common misconceptions

  • “Operators can decide safety manually” -> Software must enforce it.
  • “Commands can be sent anytime” -> Pass windows are strict.

Check-your-understanding questions

  1. Why gate command send by pass windows?
  2. What info is needed to validate a payload enable command?
  3. Why log command reasons?

Check-your-understanding answers

  1. Outside a pass, the command won’t reach the spacecraft.
  2. Mode, SoC, eclipse, thermal limits.
  3. For audit and debugging.

Real-world applications

  • Mission control command consoles.
  • Ground ops safety systems.

Where you’ll apply it

References

  • Space Mission Engineering (ops planning)
  • Clean Code (input validation)

Key insights Command safety is a policy problem implemented in UI and logic.

Summary Validation + pass gating prevent operator mistakes.

Homework/Exercises to practice the concept

  • Write validation rules for three commands and simulate outcomes.

Solutions to the homework/exercises

  • Example: PAYLOAD_ON requires mode SCIENCE and SoC > 0.6.

3. Project Specification

3.1 What You Will Build

A web-based ground console that decodes telemetry, displays key health metrics, shows pass windows, and validates commands before sending.

3.2 Functional Requirements

  1. Telemetry decoder: parse CCSDS packets and map to fields.
  2. Dashboard UI: show health panels and mode state.
  3. Command console: validate commands and show reason codes.
  4. Pass timer: countdown to next pass and disable send outside pass.

3.3 Non-Functional Requirements

  • Determinism: mock telemetry stream is deterministic.
  • Usability: clear visual indicators and error messages.
  • Reliability: no unsafe command sent.

3.4 Example Usage / Output

[UI] Battery: 72% | Temp: 22C | Mode: NOMINAL
[UI] Next pass in 00:04:12

3.5 Data Formats / Schemas / Protocols

Telemetry JSON stream:

{"apid":1,"fields":{"soc":0.72,"temp":22.1,"mode":"NOMINAL"}}

3.6 Edge Cases

  • Telemetry packets missing or malformed.
  • Pass window starts while user is editing a command.
  • Commands without acknowledgments.

3.7 Real World Outcome

A UI that shows live telemetry, enforces safe command gating, and logs all actions.

3.7.1 How to Run (Copy/Paste)

npm install
npm run dev

3.7.2 Golden Path Demo (Deterministic)

  • Use a fixed mock telemetry file.
  • UI renders expected values and pass timer.

3.7.3 Failure Demo (Deterministic)

Attempt to send a payload command in SAFE mode -> UI shows rejection reason and no send.

3.7.4 If Web App: ASCII Wireframe

+----------------------------------------------------+
|  Battery 72%  Temp 22C  Mode NOMINAL  Pass 04:12   |
+----------------------------------------------------+
| Telemetry Log                                      |
| - EPS: V=7.6, I=0.3                                |
| - ADCS: rate=0.01                                  |
+----------------------------------------------------+
| Command Console                                    |
| [Select Command] [Parameters] [Send (disabled)]    |
+----------------------------------------------------+

4. Solution Architecture

4.1 High-Level Design

Telemetry Stream -> Decoder -> UI State -> Dashboard
Commands -> Validator -> Send Queue -> Logs

4.2 Key Components

Component Responsibility Key Decisions
Decoder Parse CCSDS -> fields Schema map
UI State Hold latest telemetry In-memory store
Validator Enforce policies Rule table
Pass Timer Countdown display Pass source

4.3 Data Structures (No Full Code)

type CommandRule = { name: string; minSoc: number; modes: string[] };

4.4 Algorithm Overview

Key Algorithm: Command validation

  1. Read current mode and SoC.
  2. Check command rule constraints.
  3. Check pass window.
  4. Allow or reject command.

Complexity Analysis:

  • Time: O(1) per command.
  • Space: O(n) for logs.

5. Implementation Guide

5.1 Development Environment Setup

npm install
npm run dev

5.2 Project Structure

project-root/
+-- src/
|   +-- decoder.ts
|   +-- validator.ts
|   +-- App.tsx
+-- README.md

5.3 The Core Question You’re Answering

“How do you safely control a spacecraft you can only talk to briefly?”

5.4 Concepts You Must Understand First

  1. CCSDS decoding basics.
  2. Command validation policies.
  3. Pass window scheduling.

5.5 Questions to Guide Your Design

  1. What telemetry must always be visible?
  2. Which commands are restricted in SAFE mode?
  3. How do you handle missing telemetry?

5.6 Thinking Exercise

Design a command policy table for PAYLOAD_ON, RADIO_ON, HEATER_ON.

5.7 The Interview Questions They’ll Ask

  1. “How do you prevent unsafe commands?”
  2. “Why is pass scheduling critical?”
  3. “How do you decode telemetry packets?”

5.8 Hints in Layers

Hint 1: Start with a mock telemetry JSON stream.

Hint 2: Add schema decoding and unit conversion.

Hint 3: Add a command validation table.

Hint 4: Add pass timer gating and command logs.

5.9 Books That Will Help

Topic Book Chapter
Input validation Clean Code Validation practices
Space ops Space Mission Engineering Ground ops
Telemetry CCSDS 133.0-B-1 Packet format

5.10 Implementation Phases

Phase 1: Telemetry Decoder (4-5 days)

Goals: decode CCSDS packets to UI fields. Tasks: implement schema map and decoder. Checkpoint: telemetry panels update correctly.

Phase 2: Command Console (4-5 days)

Goals: validate commands. Tasks: implement rule table and reasons. Checkpoint: unsafe commands are blocked.

Phase 3: Pass Timer + Logs (3-4 days)

Goals: enforce pass gating and logs. Tasks: implement countdown and command log. Checkpoint: send button disabled outside pass.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Framework React / Vue / Vanilla React rich UI and state
Telemetry source WebSocket / file file (mock) deterministic
Validation hard-coded / rule table rule table auditability

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Decoder decode EPS packet
Integration Tests UI state telemetry stream
Edge Case Tests Missing data malformed packet

6.2 Critical Test Cases

  1. SAFE mode: payload command rejected.
  2. Pass inactive: send disabled.
  3. Bad packet: decoder logs error.

6.3 Test Data

telemetry_mock.json
passes.json

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Schema mismatch wrong values verify offsets
Missing pass gating commands send anytime disable UI outside pass
No logs no audit trail add command history

7.2 Debugging Strategies

  • Replay telemetry streams deterministically.
  • Log decoded values before rendering.

7.3 Performance Traps

Large telemetry streams can overwhelm UI; throttle updates.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add CSV export of telemetry logs.

8.2 Intermediate Extensions

  • Implement WebSocket live telemetry.

8.3 Advanced Extensions

  • Add command signing and verification.

9. Real-World Connections

9.1 Industry Applications

  • Mission control dashboards.
  • Ground ops command consoles.
  • OpenSatKit ground segment.
  • COSMOS (Ball Aerospace) command/telemetry system.

9.3 Interview Relevance

  • Demonstrates safety-critical UI design and protocol decoding.

10. Resources

10.1 Essential Reading

  • CCSDS 133.0-B-1.
  • Space Mission Engineering.

10.2 Video Resources

  • Ground systems training videos.

10.3 Tools & Documentation

  • React docs.

11. Self-Assessment Checklist

11.1 Understanding

  • I can decode CCSDS telemetry into engineering units.
  • I can explain command validation rules.
  • I can compute pass windows and timers.

11.2 Implementation

  • UI updates deterministically with mock data.
  • Unsafe commands are blocked.
  • Logs are complete and readable.

11.3 Growth

  • I can add authentication or command signing.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Decode telemetry and display key metrics.

Full Completion:

  • Command validation and pass gating.

Excellence (Going Above & Beyond):

  • Live telemetry via WebSocket and command signing.