Back to RF Telemetry System

Architecture

System Architecture

How flight data gets into the radio, what the CM5 owns, and where the hardware protection sits outside the software path.

Ethernet → SPI

System Architecture

This page is basically the 'who owns what?' view of the LR2021 telemetry system. I want someone looking at it later to be able to tell where flight data comes from, what the CM5 owns, what crosses board boundaries, and which RF states are actually legal.

Data Flow

Flight telemetry data-flow diagram
The CM5 is the telemetry supervisor between the vehicle flight computer and the LR2021 RF transceiver; health telemetry and hardware protection form a parallel supervision path.
LinkInterfacePurpose
Flight computer → CM5EthernetMove vehicle telemetry into the communications subsystem
CM5 → LR2021SPI + control GPIOConfigure the radio, load packets, select mode, and service interrupts/status
CM5 → RF front endGPIO / enablesSequence PAs, LNAs, T/R switches, and antenna-selection switches
Sensors/monitors → CM5ADC / digital telemetryReport current, voltage, temperature, forward power, reflected power, and fault state
Hardware protection → RF front endDirect logic / power controlForce unsafe RF loads off independently of software

Responsibility Split

I do not want the Flight Computer caring about PA enables, T/R switches, or detector details. It should hand over telemetry and let the comms subsystem deal with the RF-specific mess. The CM5 owns buffering, radio configuration, RF-state sequencing, health interpretation, and logging. The LR2021 owns the modem/transceiver function, while the external RF front end provides the gain, filtering, switching, diversity, and high-power sensing that the radio alone does not provide.

Operating Modes

ModePurposeRequired RF state
Safe / standbyBoot, fault handling, or no active linkPAs off; LNAs off unless explicitly required; switch state known
RX 915Long-range receive915 receive path enabled; all TX PAs off
TX 915Long-range transmit915 TX path selected; 915 PA enabled only after switches settle
RX 2.4Higher-rate receive2.4 receive path enabled; all TX PAs off
TX 2.4Higher-rate transmit2.4 TX path selected; 2.4 PA enabled only after switches settle
Fault holdUnsafe thermal/electrical/RF conditionAffected PA or RF power domain forced off and fault recorded

Transition Rules

Every transition involving a T/R or antenna-selection switch follows the same invariant: remove RF power first, switch second, re-enable gain last.

  1. Command all relevant PA and LNA enables low.
  2. Confirm or wait long enough for stored RF energy and amplifier output to decay.
  3. Change the RF switch state.
  4. Wait for the switch settling interval required by the selected part.
  5. Enable only the PA or LNA required by the destination mode.
  6. Start TX or RX operation.

The 100 µs-style waits are placeholders for now. Once the hardware exists, I want those delays tied back to the actual switch/amplifier timing and then tightened with measurements.

Band Strategy

I am treating 915 MHz as the 'give me margin' mode and 2.4 GHz as the higher-rate option when the link is healthy enough to support it. The 2.4 GHz path is intended for conditions where the link is strong enough to support the higher-rate mode. I do not want to switch bands just because the vehicle crossed some arbitrary distance threshold; the final policy should use real link health.

Interface Questions Still Open

  • Final packet contract between the flight computer and CM5
  • Exact LR2021 interrupt/BUSY handling and SPI timing budget
  • Which RF switch enables receive direct hardware gating versus CM5-only control
  • Fault-latch ownership and the conditions required to clear a latched RF shutdown
  • Whether link-mode switching is commanded by ground, autonomous, or hybrid
  • Final watchdog behavior for a CM5 or radio-control software failure