Rocket Telemetry Project Docs
Project

Project Architecture Overview

High-level project architecture overview for the rocket telemetry platform.

1. Purpose

This document defines the system-level design for the rocket telemetry receiver platform:

  • a phased-array SDR receive node connected to the antenna hardware
  • a central aggregator/control server that turns node outputs into operator-facing services
  • a mission-control frontend used during launch operations

This architecture treats the main application as a rocket telemetry receiver system. Satellite monitoring, passive radar, spectrum intelligence, drone detection, and RF interference detection remain valid extensions, but they are secondary to the rocket telemetry mission.

2. System Goal

The system must:

  • receive a rocket telemetry signal in the antenna node bandwidth and operating band
  • steer or schedule phased-array beams toward the rocket or detected source
  • demodulate and decode telemetry with low latency
  • expose both machine-usable and operator-usable outputs
  • allow a central server to coordinate one or more antenna nodes
  • provide a browser-based launch and telemetry console for operators

The architecture therefore has three execution environments:

  1. Antenna node
  2. Central aggregator server
  3. Frontend application

That separation is the most important design decision because the raw RF path, mission logic, and operator UI have very different performance constraints.

3. Architecture Baseline

The baseline design includes the following core technical capabilities.

3.1 RF and node capabilities

  • phased-array beam steering and beam scheduling
  • SDR control through SoapySDR
  • GNU Radio or C++ DSP for high-rate processing
  • tracking support through DoA estimation and signal metrics
  • multiple output modes: raw IQ, encoded frames, decoded telemetry after source selection
  • support for future scan, heatmap, and spectrum-monitoring functions

3.2 Operations UI capabilities

  • the mission-control dashboard concept
  • separate pages for telemetry, antenna control, position, video, and calibration
  • operator workflow during pre-launch, ascent, and recovery
  • event logs, status indicators, and mission-timeline concepts
  • multi-antenna visibility and operator control points

3.3 Platform constraints and implementation direction

  • the frontend implementation stack is still provisional; TanStack Start + SciCharts are current candidates, not commitments, and the frontend lives inside a full-stack application boundary
  • the central system is a real backend service with APIs, stream brokering, logging, and node orchestration, but the framework/runtime is still open
  • the antenna node may also use TypeScript with Hono or another typed stack to improve type safety, but that choice is not finalized
  • simulated mission data becomes a development and replay mode, not the main operating model
  • per-antenna UI controls must map to real antenna-node control and status contracts

Next: Read Project End-to-End to understand use cases and the three-tier architecture, or jump directly to the topic relevant to your role (see audience nav at top).

Project Architecture Documents Index

Navigation guide to the project-wide architecture documents.

Project End-to-End Architecture, Hardware, and Software Placement

End-to-end project architecture, primary use cases, and hardware/software placement for telemetry reception.

On this page

1. Purpose2. System Goal3. Architecture Baseline3.1 RF and node capabilities3.2 Operations UI capabilities3.3 Platform constraints and implementation direction