RF Telemetry System Engineering Notes

System

This is the flight telemetry hardware I am currently designing for the next vehicle. It is not an eval board that got repurposed later; I am designing it around the actual flight requirements from the start.

One Semtech LR2021 handles both 915 MHz and 2.4 GHz. A Raspberry Pi CM5 owns radio configuration, route selection, packet scheduling, monitoring, and recovery.

Only one band, one direction, and one antenna route can be active at a time.

Every route change follows:

SAFE → ROUTE → SETTLE → ACTIVE

For now I am using at least 100 µs of settling time until the real hardware gives me a reason to tighten it. I also never want an RF switch changing state while a PA is actively transmitting.

RF Paths

915 MHz transmit

LR2021 → YP2233W PA → LFCN-1000+ LPF → X3C09P2-30S coupler → route switches → selected antenna

915 MHz receive

selected antenna → RFSW1012 switching → TQL9092 LNA → 915 MHz BPF → LR2021

2.4 GHz transmit

LR2021 → YP2233W PA → LFCN-2750D+ LPF → X3C26P1-30S coupler → route switches → selected antenna

2.4 GHz receive

selected antenna → RFSW1012 switching → TQL9092 LNA → 2.4 GHz BPF → LR2021

The working conducted-power target is about +30.5 dBm at the selected antenna feed plane. That is still a design target, not a measured result.

Power Architecture

The current power tree is:

8S vehicle battery (28–33.6 V) → LM5185-Q1 isolated flyback → 12 V → TPS566242 → 5 V / 6 A → TPS259474L RF eFuse → RF loads

A TPS7A2033 makes 3.3 V for the lower-power control/monitoring circuitry.

I put the RF rail behind its own eFuse so the board can kill the PA/LNA/switch/detector domain without also taking down the CM5.

The current budget is:

RF Power Budget — Google Sheets

Monitoring

I am intentionally measuring more than a single “radio alive” signal.

• 3 × INA4235 devices give me twelve high-side monitor channels.
• One ADL5519 per band measures forward and reverse coupled power.
• INA281B3 + TLV3202 paths handle fast PA-current protection.
• TMP235 devices provide local temperature trips.
• The RF eFuse can remove the whole protected 5 V RF domain.

Forward/reverse RF measurement lets software tell the difference between “the PA made power” and “the antenna path actually accepted it,” while the hard protection paths do not have to wait on Linux.

Fault Tree

I have 20 explicit fault cases in the current fault tree instead of relying on a vague “watchdog + overcurrent” plan.

They cover PA thermal/current faults, LNA/detector/radio temperature, RF rail faults, transformer temperature, poor VSWR, no forward power, illegal switch states, CM5 watchdog timeout, stuck PA control, and bad measurement data.

The point is to decide ahead of time which faults need a hardware response, which can be handled in software, and which need both.

RF Fault Tree — Google Sheets

Architecture Source

The live system block diagram is kept as a Draw.io source file in the RF design folder.

rf.drawio — Google Drive

I also keep the working links/docs in one place so I do not have to hunt through bookmarks every time a part changes.

Live RF Links — Google Docs

PCB Layout Priorities

I am treating the layout like RF hardware, not like a digital carrier board with some RF traces added later:

• uninterrupted ground reference under RF routes;
• via fencing around controlled-impedance paths;
• CM5 clocks and switching nodes kept away from LNA inputs and detector lines;
• Kelvin routing around current shunts;
• deliberate thermal paths under the PA/high-loss parts;
• useful probe/de-embedding access;
• no route changes while transmit is active.

Current Status

The architecture, parts, power budget, fault tree, and RF state machine are pretty well defined. The PCB and validation are not done yet.

I am intentionally not putting output power, VSWR, sensitivity, thermal limits, or protection thresholds on the page as “results” until Rev 1 exists and I can measure them.