Antenna Capabilities
Capabilities and operational roles of the phased-array antenna system.
1. Antenna Capabilities
The phased-array system supports more than simple pointing. The merged design should expose those capabilities in a controlled way.
1.1 Core capabilities for the rocket telemetry mission
| Capability | Operational purpose |
|---|---|
| Beam steering by azimuth and elevation | Keep the receive beam aligned with the rocket |
| Frequency tuning and sample-rate control | Match the expected telemetry link |
| Signal metrics reporting | Show RSSI, SNR, frequency offset, frame rate, and lock status |
| Encoded and decoded output modes | Support both machine-oriented and operator-oriented consumers |
| Tracking mode selection | Switch between manual, trajectory, GPS-assisted, and signal-led tracking |
| Status and health reporting | Confirm beam position, node temperature, FPGA load, and channel health |
1.2 Advanced phased-array capabilities
| Capability | Value | MVP status |
|---|---|---|
| Beam sweep | Useful for pre-launch carrier search and environment characterization | useful early |
| Beam heatmap generation | Helps locate emitters or interference sources | extension |
| Auto-tracking using DoA | Supports signal-led tracking when trajectory data is incomplete | important extension |
| Multi-beam scheduling | Time-slices the array across several targets or emitters | extension |
| Multi-emitter detection | Helps separate rocket telemetry from other RF sources | important extension |
| Adaptive beamforming and nulling | Suppresses interferers | later |
| Spectrum monitoring and classification | Useful for interference and situational awareness | later |
1.3 Beam steering math responsibility
The frontend and central server should never own beamforming math directly. They request a target direction or tracking mode. The node converts those requests into the proper control primitive:
- azimuth and elevation setpoints
- phase vectors
- complex beamforming weights
That conversion belongs in the node because it depends on actual array geometry, calibration offsets, and FPGA control format.
1.4 Capability discovery contract
Each antenna node must publish a machine-readable capability model to central.
Capability groups should include at minimum:
- node identity and antenna type
- RF receive and transmit bands
- supported sample rates and effective bandwidth
- steering modes supported: az/el, coordinate-tracking, schedule, scan
- angle limits, slew limits, and update-rate limits
- local GNSS capability and current fix quality
- hardware state: FPGA present, motor present, SDR chain type
- optional features: heatmap, DoA, multi-emitter tracking
This capability model is the source of truth for which UI controls should be enabled.
2. Tracking Modes
The system should support multiple tracking modes because the best source of pointing truth changes over the mission.
| Mode | Source of truth | Best use |
|---|---|---|
| Manual | operator command | setup, test, contingency |
| Fixed point | static azimuth and elevation | lab tests and known targets |
| Trajectory-driven | predicted rocket path | pre-launch and early ascent |
| GPS-driven | live rocket coordinates | nominal operations if rocket position is available |
| Signal-led auto-track | DoA or peak-power tracking | backup or augmentation mode |
| Scheduled multi-target | beam schedule table | later multi-emitter or multi-asset use |
Each mode should declare required prerequisites such as GNSS fix quality, motor availability, phased-array support, and external target feed availability.
Frequency hold is a separate RF stabilization function, not a tracking mode. It runs in parallel with whichever tracking mode is active and can be toggled on or off independently.
The production design should preserve these mode concepts while using real node and server contracts.
3. Multi-Emitter and Multi-Payload Handling
This requirement matters for rocket telemetry operations.
There are two different multi-source problems:
3.1 Multiple emitters in the band
Examples:
- rocket telemetry
- support equipment emitters
- nearby drones
- radar or unrelated RF energy
The node and central server must distinguish candidate signals by at least:
- frequency
- bandwidth
- direction or beam index
- modulation guess or protocol family
- lock state
- confidence or verification state
3.2 Multiple payload streams within the telemetry mission
Examples:
- flight computer telemetry
- payload experiment data
- GPS or navigation packets
- video or imaging side channels
This separation should happen at the frame or protocol layer, not at the beam layer. The central server must route payloads using frame identifiers, payload IDs, or protocol descriptors.
3.3 Architectural implication
The node should maintain candidate tracks and demodulation contexts. The central server should maintain logical stream identities. The frontend should present both levels:
- RF source level
- decoded payload level
Related: See Node-SourceTracking-DoA for implementation details on MUSIC and ESPRIT algorithms.
Shared Reference
Cross-cutting terminology, contracts, and reference material.
APIs and Data Contracts
This section does not lock the exact schema, but it defines the contract families the implementation must support. Detailed endpoint examples and payload structures are provided to guide implementation.