ValidatedMeasured

Recovery System

Fault-tolerant recovery avionics with triple-MCU voting and ten high-current deployment channels

Design Responsible Engineer

AvionicsEmbedded SystemsPower ElectronicsHigh Current

Schematic

Browse the exported schematic and design sheets.

Layout

Look through the copper layers and routing.

3D Model

Spin around the board model in 3D.

Design Notes

The reasoning, bring-up, bugs, and test results behind the board.

Project overview

What I worked on

Deployment Channels

Independent MCU Domains

300 W → 0 W

Simultaneous Load Dump

Independent Power Trees

A six-layer recovery controller built around two power trees, three independent STM32 domains, hardware voting, local sensing, and ten 24 V deployment channels. I owned the board end to end, from architecture and layout through bring-up and the full ten-channel deployment test.

This page shows the architecture, layout, and bench results I can share publicly; a few team-internal implementation details are left out.

Hardware & test evidence

Photos, measurements, and validation

Measured

Power-stage efficiency sweep

Measured 24 V efficiency during Rev 5 bring-up; the sweep peaked at 95.62% at 144 W external load.

Validated

Simultaneous-deployment load dump

When all ten deployment loads turned off together, the load dropped from about 300 W to 0 W. Retuning the 48 V → 24 V converter cut the 3.3 V peak from 8.2 V to 3.9 V and the 24 V peak from 32.5 V to 26.9 V.

Integration

Installed in the flight vehicle

Recovery Rev 5 installed in the rocket with the real harnessing around it.

Validation

Ten-channel deployment test

The full ten-channel deployment setup used to reproduce and then validate the worst-case transient.

Test history

Bring-up, validation, and revisions

Simultaneous deployment load dump

Check that the control electronics stay within safe rail limits when all ten deployment loads turn off together.

Pass

Setup: I fired all ten e-match loads together and captured the turn-off event, when the deployment load dropped from approximately 300 W to 0 W, while watching the 24 V and 3.3 V rails.
Expected: All ten outputs fire, then the control rails remain in a safe range through the 300 W → 0 W load dump.
Measured / observed: Initial testing peaked at 8.2 V on the 3.3 V rail and 32.5 V on the 24 V rail. Increasing the upstream converter crossover frequency from 22.6 kHz to 49.7 kHz reduced the peaks to 3.9 V and 26.9 V and eliminated the MCU overvoltage condition.

The scope captures are from the same ten-channel test before and after the compensation change.

Initial bring-up

Assembled

The first simultaneous-deployment run exposed a slow upstream transient response and large rail overshoot.

Compensation update

Validated

I retuned the converter compensation and reran the same ten-channel event without the MCU overvoltage/reset condition.

RBF hot-plug rework

Validated

Hot-plugging the RBF tag produced a transient large enough to kill one STM32. I isolated the failure, moved further testing to another Rev 5 copy, and validated a series-damping fix with an inline resistor rework. A proper PCB footprint is planned for the next revision.

Design deep dives

A closer look

Power

300 W → 0 W Load Dump

Dual-Tree Power Architecture

How the two power trees are split up, where they intentionally come back together, and what changed after the 300 W deployment transient exposed a control-loop problem.