Recovery System Wiki

Purpose

At a high level, the Recovery System is the board that decides when the rocket is allowed to deploy recovery parachutes. It combines redundant compute, hardware voting, safing interfaces, local sensing, protected power conversion, and ten high-current ignition channels on a single six-layer PCB.

The goal was not just to fire deployment loads. The board had to stay inhibited during integration, tolerate a single control-domain fault, survive the simultaneous firing transient, and keep running without resetting its microcontrollers or corrupting sensor data.

My Responsibility

I was the Design Responsible Engineer for the board. I owned the system architecture, schematic, PCB layout, design reviews, bring-up, debugging, validation, and day-to-day board operation.

Architecture

Two protected battery feeds enter independent power paths before supplying the board's deployment and logic rails. Four buck converters generate the required 24 V and 3.3 V domains.

Three STM32 control domains independently process local sensor data via an Extended Kalman Filter (EKF) and receive flight-computer commands. Their deployment commands pass through discrete digital median voting logic before reaching the driver banks. Hardware RBF, ESTOP, abort, and software-enable paths provide multiple independent mechanisms for preventing an unintended deployment.

Ten output channels drive 24 V deployment loads. Each channel provides command, current-control, sensing, and fault-feedback behavior.

Fault-Tolerant Design

The control, power, and deployment architecture is split up so one MCU or local power fault cannot directly command an output. Redundant command paths stay separated until the voting stage, and safing inputs can inhibit the deployment path without relying on flight software.

The PCB routing follows the same fault-domain boundaries. Signals belonging to separate control channels are kept physically distinct where practical, and shared circuitry is limited to intentionally centralized functions.

PCB Layout

The layout problem that mattered most was the transient current path during deployment. Switching devices, output connectors, bulk capacitance, and return paths were placed to keep the current loop tight and reduce parasitic inductance.

Low-level sensing, MCU, and voting circuitry were separated from the driver banks and switching nodes. The six-layer stackup provides two ground-reference layers, a dedicated power layer, and three signal layers to support low-impedance current paths and predictable signal references.

Bring-Up and Validation

Bring-up moved in stages: isolated power-path checks, regulated-rail validation, MCU communication, sensor interfaces, voting behavior, safing inputs, and finally deployment testing.

The maximum-load test fired ten e-match loads simultaneously, creating an approximately 300 W transient. Initial testing produced an 8.2 V peak on the 3.3 V rail and a 32.5 V peak on the 24 V rail.

The issue came from insufficient upstream transient response. Increasing the 48 V-to-24 V converter crossover frequency from 22.6 kHz to 49.7 kHz reduced 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. That change eliminated the MCU overvoltage condition during simultaneous deployment.

Key Result

The final design demonstrated simultaneous operation of all ten deployment channels without resetting or overstressing the downstream control electronics.

Next Revision

A future revision would add more high-bandwidth rail-monitoring test points, improve separation between some shared support circuitry and redundant domains, and put the validation setup directly into the production test docs.