Project End-to-End Architecture, Hardware, and Software Placement
End-to-end project architecture, primary use cases, and hardware/software placement for telemetry reception.
1. Primary and Secondary Use Cases
1.1 Primary use case
Rocket telemetry reception
This includes:
- pre-launch acquisition of the expected telemetry carrier
- lock acquisition after launch
- beam steering and optional auto-tracking during ascent
- real-time telemetry decoding and operator display
- health monitoring of link quality, demodulator state, and node status
- logging for replay and post-flight analysis
1.2 Secondary use cases
These fit the same platform but should not drive the initial MVP architecture:
- satellite monitoring
- passive radar experiments
- optional spectrum intelligence
- drone detection
- RF interference detection
These capabilities influence the architecture because they require scan modes, spectrum storage, classification hooks, and richer stream types, but they should remain extensions layered on top of the rocket telemetry baseline.
2. End-to-End Architecture
Rocket transmitter
|
v
Phased-array antenna hardware
|
v
FPGA beamforming and RF interface
|
v
Antenna-node SBC
- SoapySDR access
- GNU Radio or C++ DSP
- control API
- local metrics
|
| decoded events / encoded frames / optional raw taps
v
Central aggregator server
- node orchestration
- stream normalization
- telemetry routing
- mission state
- logging and replay
- frontend APIs and WebSocket streams
|
v
Mission-control frontend
- operator dashboard
- telemetry views
- antenna and node control
- event timeline
- replay and analysis viewsThe node is where RF work happens. The central server is where system coordination happens. The browser is where humans operate the system.
3. Hardware Inventory
3.1 Antenna-node hardware
| Component | Role |
|---|---|
| Phased-array antenna | Directional receive and optional transmit beamforming |
| RF front end | Filtering, amplification, and radio-frequency conversion |
| Lattice ECP5 FPGA | Beamforming, weight application, low-latency preprocessing |
| SBC | Runs local API, SDR control, DSP orchestration, metrics, and node services |
| GNSS or GPS receiver | Position, timing, and synchronization source |
| Power system | Supplies the node and antenna electronics |
| Local network interface | Connects node to central aggregator |
3.2 Central site hardware
| Component | Role |
|---|---|
| Central application server | Aggregation, APIs, telemetry routing, mission state |
| Storage | Telemetry history, raw captures, replay sessions, logs |
| Operator workstations | Mission-control UI and analysis tools |
| Optional video ingest hardware | Camera feed capture and redistribution |
| Optional precision timing infrastructure | Needed only for later multi-node coherent or TDoA scenarios |
3.3 Optional expansion hardware
| Component | Role |
|---|---|
| Additional antenna nodes | Coverage, redundancy, or multi-station reception |
| Rotor or external pointing systems | If non-phased elements or hybrid mounts are used |
| GPSDO or better clocking | Required for tighter multi-node synchronization |
| Additional RF references | Useful for calibration, passive radar, or test modes |
3.4 Antenna type variability
The system must support different physical antenna node types behind one logical control model.
Supported classes should include:
- phased-array nodes
- parabolic motorized nodes
- fixed parabolic nodes
- future custom RF node classes
Mixed fleets are technically possible but operationally harder. Different bandwidth, polarization, steering authority, and retune latency should be treated as scheduling constraints by the central server.
4. What Software Runs Where
4.1 Antenna node
The antenna node is the only place that should directly control RF hardware and beam-pointing hardware.
| Layer | Recommended software | Why it runs here |
|---|---|---|
| RF device control | SoapySDR | Direct hardware driver access |
| High-rate DSP | GNU Radio, custom C++ blocks, VOLK-accelerated signal processing | Python is not suitable for sustained 40 MHz raw IQ processing |
| Local control API | FastAPI or equivalent Python service | Good for configuration, status, and low-rate orchestration |
| Node telemetry and metrics | Prometheus exporter or internal metrics service | Needed for central monitoring |
| Antenna control adapter | Python or C++ service with pluggable drivers | Converts abstract pointing requests into phased-array weights or motor commands |
| Local buffering and IPC | ring buffer plus ZeroMQ or shared-memory IPC | Decouples DSP path from API path |
The antenna control adapter must expose one abstract interface across antenna classes.
Core adapter responsibilities:
- convert azimuth and elevation requests to device commands
- compute azimuth and elevation from target coordinates plus local GNSS fix
- enforce local angle and safety limits
- report capability and status models in a common schema
4.2 Central aggregator server
The central server is the control and data integration plane for the whole station.
| Layer | Recommended software | Why it runs here |
|---|---|---|
| Node orchestration API | TypeScript or Python backend service | Coordinates one or more antenna nodes |
| Stream normalization | Worker services | Converts node-specific events into frontend-friendly contracts |
| Telemetry router | Message broker or internal event bus | Splits streams by mission, vehicle, emitter, payload, and consumer |
| Mission-state service | Stateful application service | Keeps countdown, mission phase, lock state, active source, and operator actions |
| Logging and replay | database plus object storage | Stores telemetry, metrics, events, optional frame captures |
| Auth and audit | backend service | Required for real operations and control authority |
The central server should maintain a capability registry per node so UI and mission services can discover what each node supports before sending commands.
4.3 Frontend application
The browser frontend should be implemented as a real-time mission-control application aligned with the platform stack defined in this document.
| Layer | Recommended software | Why it runs here |
|---|---|---|
| App shell and routing | TanStack Router | Matches the stated project direction |
| Styling system | Tailwind CSS v4 | Enables consistent design tokens and responsive operator layouts |
| Component primitives | shadcn components on Radix primitives | Recommended for accessibility, consistency, and faster control-surface development |
| Data fetching and caching | TanStack Query | Handles polling, caching, refetch, and optimistic control flows |
| Visualization | Plotly plus optional specialized chart libraries | Plotly is default for telemetry, polar, and heatmaps; use alternatives where needed |
| UI state and workflows | application stores plus route loaders | Supports mission timelines and complex operator panels |
| Live updates | WebSocket client | Receives telemetry, health, lock, and event streams |
Use of shadcn is strongly recommended but not mandatory. If selected, centralize wrappers for role-gated actions and mission-critical confirmation dialogs.
4.4 Central node software profile
The central node should be delivered as one platform with three deployable services:
- control and mission API service
- stream gateway service
- TanStack Router frontend service
This keeps operations simple while preserving internal separation between API logic, high-rate stream fan-out, and browser delivery.
Next: Read Shared Antenna Capabilities for antenna and RF details, or Node DSP Pipeline to understand why raw DSP stays out of Python.