Node DSP Pipeline and Python Constraints

1. Why the Raw DSP Path Must Stay Out of Python

The most important implementation limit is that raw IQ at this bandwidth is too expensive for a Python-only DSP path.

At 40 MHz bandwidth the data rate becomes extremely high, especially when multiple antenna channels are involved. Python can still coordinate the node, but it should only handle:

• configuration
• state transitions
• control-plane requests
• stream registration
• low-rate metrics and optional decoded telemetry objects

Python should not be responsible for:

• sustained raw IQ ingestion from the SDR
• real-time demodulation loops at full bandwidth
• covariance or beamforming math over full-rate sample windows
• high-rate packet scanning across all possible emitters

Those workloads belong in:

• FPGA logic
• GNU Radio blocks
• optimized C++ services

2. Detailed DSP Pipeline on the Antenna Node

The exact implementation can vary by modulation and coding, but the merged system should assume the following receive path.

RF front end
  -> FPGA preprocessing or beamforming
  -> SoapySDR source
  -> frequency translation
  -> channel filter
  -> AGC
  -> carrier recovery
  -> symbol timing recovery
  -> demodulator
  -> FEC decode when used
  -> frame synchronization
  -> telemetry frame extraction
  -> local event stream

2.1 Node outputs from this pipeline

The node should be able to publish at least three output classes:

The central server should normally consume decoded telemetry objects and metrics, while raw IQ and raw frame bytes stay on the capture or analysis path.

2.2 Antenna-node process model

The node computer should run independent processes rather than one monolith.

Recommended runtime split:

1. Control API service (FastAPI)
2. Antenna control service (driver abstraction for phased array or motors)
3. SDR and DSP runtime (GNU Radio and native blocks)
4. Telemetry packager and publisher
5. Node health service

This allows DSP restarts without dropping the full API process.

2.3 FastAPI to SDR and antenna-software communication

FastAPI should not call GNU Radio internals directly in request handlers. It should issue validated commands to internal workers over IPC.

Recommended internal buses:

• command channel: ZeroMQ request or reply, NATS, or local gRPC
• status channel: pub or sub updates from DSP and antenna drivers
• event channel: lock changes, alarms, and state transitions

Command path example:

1. API receives configuration request.
2. API validates against node capabilities and mission policy.
3. API writes command to control bus with command ID.
4. DSP or antenna worker applies command.
5. Worker emits accepted or failed response with detailed reason.
6. API returns command acknowledgment and stores audit event.

2.4 Antenna-type agnostic control adapter

The control adapter should implement one logical interface regardless of hardware type:

• set absolute azimuth and elevation target
• set coordinate target with optional predicted motion
• stop or hold motion or beam updates
• start and stop scan profile
• report current pointing state and authority

Implementation by class:

• phased array: convert to beam weights and apply in FPGA chain
• motorized parabolic: convert to motor azimuth and elevation commands
• fixed antenna: reject moving commands and report fixed pointing capability only

2.5 Coordinate-based steering and local geodesy

The node must support steering from target coordinates and altitude using local GNSS position.

Required inputs:

• local node latitude, longitude, altitude from GNSS
• target latitude, longitude, altitude
• reference frame and timestamp

Output:

• computed azimuth
• computed elevation
• range estimate (optional but useful for diagnostics)

The local node should perform this conversion so it can continue tracking when central connectivity is degraded.

2.6 Data sources used by the node

The node should ingest data from outside in clearly defined channels:

• local GNSS receiver for position and timing
• central mission plan for frequency profiles and expected trajectory
• external rocket position feed when available
• SDR measurement path for signal-derived tracking
• optional configuration store for calibration tables

Next: See Node-SoftwareProcesses-IPC for detailed process architecture and IPC bus design.