Project Operational Flow and Mission States

1. Operational Data Flow

1.1 What the antenna node connects to

The antenna node is connected to:

• Local GNSS receiver: provides position, timing, and PPS for synchronization
• RF hardware (SDR/USRP): provides IQ samples from antenna feed
• Central aggregator server: sends telemetry events, metrics, and receives commands via HTTP(S) or gRPC
• Optional external trajectory feed: receives predicted rocket position for trajectory-driven tracking
• Optional external calibration source: loads beamforming coefficients or antenna tuning parameters

1.2 What the central aggregator connects to

The central server is connected to:

• One or more antenna nodes: receives telemetry from nodes, sends configuration and requests
• Frontend layer inside the full-stack application framework: exposes REST APIs and WebSocket streams for mission state, telemetry, and user actions
• Optional external mission plan service: loads frequency plans, rocket trajectory predictions, and expected launch time
• Optional external weather/range-safety service: ingests real-time data for decision support
• Storage backend (database + object store): archives telemetry, events, captures, and replay sessions
• Audit and authentication system: tracks user actions and validates request authority

1.3 What the frontend connects to

The frontend layer, delivered through the full-stack application framework, connects to:

• Central server REST API: fetches mission state, node capabilities, and historical telemetry
• Central server WebSocket: subscribes to live telemetry, lock changes, events, and system status updates
• Optional local browser storage: caches mission profile, UI preferences, and historical data for offline reference

When multiple source streams are available, the central server should promote the preferred one before any expensive decode work. Each node continues emitting its configured outputs independently: raw IQ samples, raw frame bytes, metrics, and optional typed payloads or JSON depending on local configuration. The node is not aware of which stream the central server ultimately prefers.

1.4 External data ingress

Optional external integrations:

• Rocket GPS/telemetry downlink: if available, provides live vehicle position for GPS-driven beam tracking
• Range safety officer authorization: external trigger or endpoint to unlock critical commands
• Video ingest: third-party camera or video distribution system sends frames to central
• Weather radar or atmospheric data: external service provides wind, pressure, condition forecasts
• Incident or abort triggers: external events (e.g., range shut-down signal) that trigger fallback behavior

---

2. Mission States and Runtime Behavior

The system progresses through distinct mission phases with different operator capabilities and system priorities.

2.1 Pre-launch

1. Central server loads mission profile, expected frequency plan, frame definitions, and station configuration.
2. Frontend shows countdown state, configured nodes, and pre-launch checks.
3. Central server pushes radio configuration and initial tracking mode to the antenna node.
4. Node begins monitoring expected spectrum and can optionally perform a beam sweep around the expected launch corridor.
5. Node exposes lock indicators such as searching, carrier_candidate, carrier_lock, symbol_lock, and frame_lock.

Controls enabled: Node discovery, antenna/frequency setup, payload definition, test tracking.
Controls locked: Real-time telemetry parameter changes, critical pointing commands.

2.2 Terminal countdown and ignition

1. Countdown reaches T-5 minutes
2. System enters "armed" state: no configuration changes allowed, all telemetry validation strict
3. T-0 ignition occurs
4. Rocket transmitter comes alive or becomes easier to detect after liftoff
5. Node detects the carrier within the configured band

Controls enabled: Go/no-go decision, emergency stop.
Controls locked: Frequency, payload type (but parameter binding can update if pre-staged).

2.3 Ascent

1. Node detects the carrier within the configured band (T+0 to T+flight_duration)
2. DSP chain performs downconversion, filtering, AGC, carrier recovery, symbol timing recovery, demodulation, and frame sync
3. Beam controller keeps the beam pointed using one of the active tracking modes
4. Node emits its configured telemetry outputs (raw frame bytes and optional typed payloads), lock metrics, and node health to the central server
5. Central server normalizes, stores, and redistributes the data
6. Frontend updates mission panels in real time

Controls enabled: Tracking mode adjustment, frequency-hold tuning, parameter monitoring, manual override emergency stop
Controls locked: Antenna type, frame definition.

2.4 Post-flight or recovery

1. If lock degrades, the node reports degraded state immediately
2. Central server raises operator-visible events and can request fallback behavior
3. Fallback may include beam hold, beam widening, rescan, alternate source selection, or manual takeover
4. After flight, central server closes the session and stores all time-series, events, and optional captures for replay

Controls enabled: Replay, analysis, export, archive capture.
Controls locked: Real-time control (except manual-override if beacon still active).

---

Next: See Project Deployment & Risks for MVP scope and risk posture, or Project Reasoning Notes for design rationale.