Project Deployment, Risks, and Next Steps
MVP scope, deployment risks, and recommended mitigations for the project.
1. MVP Scope
1.1 Rocket telemetry MVP
Minimum viable product must deliver:
- Single antenna node (phased-array or motorized primary, fixed as fallback)
- Real-time rocket telemetry reception with lock acquisition and tracking
- Preferred-stream telemetry display on web-based mission-control dashboard
- Manual antenna control with az/el or target-coordinate steering
- Trajectory-driven tracking with optional manual override
- Signal health and node status monitoring
- Post-flight replay and event log archival
1.2 Strongly recommended early additions
These fit the MVP architecture and should be prioritized for the first deployment:
- Frequency hold (AFC) for Doppler-compensated lock during ascent
- Multi-payload support (flight computer + science payload on same downlink)
- Capability discovery so frontend automatically enables/disables controls per node
- Alarm thresholds with graphical alerts
- Mission profile editor (pre-launch payload and frequency configuration)
1.3 Later extensions
These remain valid but should not block MVP release:
- Multiple antenna nodes with central orchestration
- Beam heatmap generation and visualization
- Auto-tracking via Direction of Arrival (DoA) algorithm
- Passive radar or spectrum intelligence layers
- Video ingest and synchronization
- Contingency modes (beam widening, rescan, multi-emitter separation)
2. Risks and Constraints
2.1 Major technical risks
| Risk | Impact | Mitigation |
|---|---|---|
| RF path latency exceeds 100 ms | Mission fail | Profile DSP pipeline early; use FPGA for beamforming |
| Beam steering math inconsistency (node vs. UI) | User error | Central server owns no steering math; node is single source of truth |
| Multi-payload sync-word collision | False lock | Ensure Hamming distance ≥8; use high confidence threshold (>0.95) |
| GNSS outage during ascent | Degraded mode | Fallback to trajectory-driven or signal-led tracking |
| Central server loss during flight | Continued ops | Node caches mission plan; continues local DSP and telemetry output |
| Frontend WebSocket disconnect | Data gap | Central buffers telemetry; frontend reconnects and catch-up fetches |
2.2 Major product risks
| Risk | Impact | Mitigation |
|---|---|---|
| Operator confusion (too many controls) | Control error | Role-based UI gating; capability-driven control enable/disable |
| Telemetry parameter mismatch | Operator misreads | Per-target binding; unbound parameters visible in inspector |
| Non-deterministic frame decode | Intermittent data | Central selects the source first, then decodes the winner; node pre-decode stays optional |
| Mission-critical secret leak (API key) | Security breach | TLS mutual auth (ADR-001); audit log all API calls |
| Operator lockout during critical phase | Mission delay/fail | Multi-layer authentication; emergency override with cost |
3. Recommended Next Implementation Steps
-
Prototype central aggregator and simple frontend (1-2 weeks)
- REST API endpoint stubs
- WebSocket telemetry subscription
- Static dashboard with mock data
-
Integrate first real antenna node (2-3 weeks)
- Deploy node software to target SBC
- Test radio configuration and status queries
- Validate endpoint schemas
-
Implement mission state machine (1 week)
- Countdown state model
- Phase transitions (pre-launch → armed → ascent → recovery)
- Role-gated control enable/disable
-
Build real mission-control frontend (3-4 weeks)
- TanStack Router app skeleton
- Dashboard, telemetry, antenna control pages
- WebSocket live update
- Payload definition UI
-
Conduct mode validation test (1 week)
- Static RF source (signal generator)
- Verify all tracking modes (manual, fixed, trajectory, signal-led)
- Validate frequency hold and Doppler tracking
-
Field test with real rocket or missile (schedule TBD)
- End-to-end validation
- Operator workflow refinement
- Fallback behavior confirmation
4. Final Architectural Position
This system is designed as a three-tier rocket telemetry receiver platform that preserves separation of concerns:
- Antenna node is an RF acquisition appliance, no mission logic, no UI coupling
- Central aggregator owns mission context, user authority, and data normalization
- Frontend is an operator dashboard built in modern JavaScript
This separation allows:
- Different teams to own different tiers
- The node to remain stable while UI and mission logic evolve
- Graceful degradation (node keeps working if central is down; central buffers if frontend is down)
- Mixed antenna fleets without code changes (phased, motorized, fixed supported by same platform)
Success criteria:
- Lock acquisition and frame decode within 500 ms of signal arrival
- Operators can display preferred-stream telemetry and control antenna without RF expertise
- Central server can coordinate multiple heterogeneous nodes
- System remains operational if any single layer (node, central, or frontend) fails temporarily
Related: Project Reasoning Notes explains the rationale for this separation. ADR-INDEX tracks unresolved decisions.
Project Operational Flow and Mission States
Operational flow and mission-state relationships between antenna nodes, central server, and frontend.
Project Supporting Reasoning Notes
This section explains the key design decisions embedded in this architecture. These notes provide the "why" behind the scope boundaries, tier separation, and responsibility assignments.