PROTON-III Flight Computer

PROTON-III is a modular flight controller concept for model rockets, built around a simple idea: make a flight stack that you can trust, test, and debug quickly. Instead of chasing “maximum features,” the design prioritizes stable canard control, high-rate sensor logging with clean timing, and a recovery workflow that is structured, redundant, and safety-oriented.

For code and more cad visit: 

Proton-Flightcomputers/README.md at main · Sandgrube/Proton-Flightcomputers

What it’s meant to do

The controller is designed to sit at the center of a small rocket that actively steers using canards (servo-driven control surfaces). While it’s flying, it records the full sensor stream at high rate, keeps the timing consistent across IMU and barometer data, and stores everything to a microSD card in a way that survives real-world issues like SD write latency, partial writes, or a reboot. Around that core, it adds a clear set of “operating modes” (safe, armed, flight, recovery, postflight), so the system behaves predictably and doesn’t do anything dangerous just because software misbehaves.

Hardware overview

At the heart of PROTON-3 is an ESP32-S3 module (ESP32-S3-WROOM-1U, N8R8). The ESP32-S3 is chosen for practical reasons: native USB makes flashing and serial logging straightforward without needing a separate USB-UART chip, and Wi-Fi plus an external antenna connection supports a clean preflight workflow.

A key architectural decision is how servos are handled. Servo PWM generation is moved off the MCU and onto a PCA9685 PWM driver (16 channels, with 8 intended for the canards and headroom for expansion). This avoids servo timing jitter caused by CPU load, logging spikes, or other real-time tasks. It also keeps the control loop “pure”: the MCU computes the desired angles, and the PWM chip handles the actual pulse generation.

The sensor set is intentionally minimal at the base level: IMU + barometer, with GNSS as an option mainly for tracking and recovery support. The important part isn’t the sensor count, it’s the timing discipline. The concept prefers using sensor interrupt lines where possible, because that reduces sampling jitter and gives you a cleaner dataset for attitude estimation and post-flight analysis.

For storage, microSD is the primary medium (log files on a normal filesystem), but the design assumes SD cards are not real-time devices. To compensate, PSRAM on the ESP32-S3 is used as a ring buffer: fast sensor tasks write into memory immediately, and a background logger task writes to the SD card in larger bursts. That decouples sensor timing from file system latency and reduces dropouts.

Power is treated as a first-class problem, not an afterthought. USB 5 V is stepped down to 3.3 V for logic (ESP, sensors, PWM driver). In flight, the controller expects a battery supply and, ideally, separate rails: one for logic (3.3 V) and another for servos (typically 5–6 V). The point is simple: servo current spikes must not pull the logic rail down. This drives decisions like regulator sizing, bulk capacitance close to servo headers, and careful ground routing. There’s also an explicit requirement to prevent USB backfeed (handled via diode/power mux approaches depending on the final system design).

Interfaces and “safe” pin planning

The concept includes a conservative pin plan for the ESP32-S3. USB data lines stay dedicated to native USB (D- on GPIO19, D+ on GPIO20). For I²C, a robust choice is GPIO8 (SDA) and GPIO9 (SCL) with pullups to 3.3 V. A dedicated GPIO can control the PCA9685 output enable (OE#, active-low), and the default behavior is chosen so that on boot the servos do not receive random pulses. BOOT (GPIO0) and EN/RESET are wired with buttons and pullups so you can always force a known-good download mode during bring-up and debugging.

Safety model and recovery philosophy

PROTON-3’s recovery approach is described as redundant logic rather than a single trigger. In practice that means an apogee detection path plus independent backup criteria, wrapped in a state machine with explicit transitions. The key safety point is that “arming” should not be purely a software flag. A hardware arming element (switch, key, plug, etc.) is expected so that a firmware crash cannot accidentally enable a deployment output.

The proposed operating states are:

• SAFE: recovery outputs disabled; servos can be held neutral; logging/setup is allowed.

• ARMED: sensors are stable and checks pass (battery, SD, IMU status); recovery outputs are hardware-enabled.

• FLIGHT: control loop active; high-rate logging; telemetry (if used) can be reduced or selective.

• RECOVERY: deployment triggered by apogee/backup; logging continues; tracking/beacon behavior can take over.

• POSTFLIGHT: safe shutdown and clean data extraction.

Even without going into any specific deployment hardware, the intent is clear: predictable behavior, clear gating, and no “surprises” during handling.

Software concept

The software architecture is built around FreeRTOS task separation, so that timing-critical work stays stable even when other parts are busy:

• Sensor task: reads IMU/baro on a fixed schedule (preferably interrupt-aligned) and pushes data into the PSRAM ring buffer with monotonic timestamps.

• Estimation/control task: runs the attitude filter (complementary or Kalman-style depending on need), mixes the canard outputs, and produces target angles.

• Servo task: updates the PCA9685 via I²C at a controlled rate with smoothing/limits.

• Logger task: drains the ring buffer and writes large blocks to microSD to minimize write jitter and overhead.

• Comms task: handles USB and Wi-Fi interaction (preflight UI, downloads, parameter changes).

• Safety task: enforces the state machine, runs checks, and integrates watchdog behavior.

For logs, the concept explicitly discourages relying on CSV for everything. CSV is convenient, but it’s inefficient and fragile for high-rate data. The proposed approach is a binary frame format with a header, timestamp, sensor payload, and CRC, plus an offline converter to CSV or Parquet later. That gives robust logs even if the device resets mid-write.

Reproducibility is also built in: configuration and calibration values should be versioned and stored inside the log (firmware hash, config block, sensor scaling). That way you can compare flights honestly instead of guessing which parameters were active.

Test and roadmap mindset

PROTON-3 is framed as a project you bring up in stages, with a verification plan rather than a single “final build” leap. The steps start with basic bring-up (USB flash/CDC, I²C scan, SD read/write, servo neutral). Then come power integrity tests (brownout tests under servo peaks, measuring 3.3 V behavior and logging reset flags). Sensor validation follows (static tests, rotation tests for gyro bias and accel scale, barometer drift, sampling jitter). Hardware-in-the-loop is explicitly part of the plan: replay real flight logs through the estimator/controller without real hardware to iterate quickly. Field testing is incremental: preflight checklists, dry runs without recovery actions, then enabling features step-by-step.

The staged roadmap reflects that approach:

• R0: dev kit + PCA9685 breakout, servo bench tests, logging pipeline.

• R1: first custom PCB with USB-C, 3.3 V buck, I²C, SD, servo power header.

• R2: flight-ready robustness: EMC, mechanical integration, connectors, recovery arming, end-to-end tests.

• R3: telemetry option (LoRa) plus extra robustness features like CRC and failsafes.

In short, PROTON-3 is a flight controller concept designed to be engineered like a system, not a demo: stable control outputs, disciplined timing, logs that survive reality, and safety states that remain safe even when software doesn’t.

This block is the ICM-42688-P 6-axis IMU (3-axis gyroscope + 3-axis accelerometer) on the PROTON-3 flight computer. It’s connected via I²C (SDA/SCL) and provides the high-rate motion data the firmware needs for attitude estimation, stability control, and clean flight logging.

The AD0/address strap lets the same sensor coexist with other devices on the bus (0x68 when Pin 1 = GND, 0x69 when Pin 1 = 3V3). The INT pins are routed so the MCU can timestamp samples precisely and reduce jitter, which matters for reliable control loops. The local 1 µF + 100 nF decoupling on the supply rails keeps the sensor stable under fast current spikes and high-vibration conditions typical for model rockets.

This page is the “processor + user interface + external I/O” section of the PROTON-3 flight computer.

• ESP32-S3-WROOM-1U (U1): The main MCU that runs the flight state machine, sensor acquisition, logging, and telemetry. All key buses and control nets are broken out cleanly for reliable routing and debugging.

• Reset & Boot circuitry: Two tactile switches implement the standard ESP32 workflow:

  • EN/Reset (SW1) with a small 100 nF capacitor for clean reset behavior and a 10 kΩ pull-up to 3V3.

  • BOOT (SW2 / GPIO0) with a 10 kΩ pull-up so the board boots normally, but can be forced into the ROM bootloader for flashing/recovery.
    This makes firmware bring-up and field recovery painless.

• Buzzer driver: A small 4 kHz buzzer is switched via an AO3400A MOSFET from a GPIO. This gives loud, unmissable audible feedback for arming states, errors, continuity checks, or recovery events—useful when you can’t stare at a screen on a launch site.

• Power-rail indicator LEDs (3V3 / 5V / 6V): Three simple LEDs show which rails are present. That sounds basic, but it saves real time when diagnosing power issues in the field or after a hard landing.

• RGB status LED: A multi-channel LED driven through series resistors provides an immediate “system health / mode” indicator (safe, armed, logging, error, etc.) without needing a serial console.

• I²C pull-ups: 4.7 kΩ pull-ups on SDA/SCL ensure the bus behaves predictably even with mixed sensor modules and cable lengths—important for stable IMU/baro operation and clean timestamps.

• GPS connector: A dedicated 4-pin connector (GND, 3V3, RX, TX) for an external GPS module keeps integration simple and mechanically robust.

• External screw-terminal breakouts: Power and bus lines are brought to screw terminals for easy bench testing, modular expansion, and quick swapping of external modules (SPI/I²C devices, auxiliary sensors, test harnesses) without reworking the PCB.

Overall, this sheet is about making the flight computer easy to flash, easy to debug, and easy to operate at the pad—with clear status feedback, robust bus wiring, and straightforward expansion points.

This block is the Peripheral Radio Connector: a dedicated 10-pin header that lets PROTON-3 plug into an external RF/telemetry module without baking a specific radio into the main PCB.

It exposes a clean SPI interface (SCK/MOSI/MISO + CS) plus several PERI GPIO lines for IRQ, reset, enable, or module-specific handshakes. Power is provided as 3V3 and GND, with local bulk + high-frequency decoupling (10 µF + 100 nF) right at the connector to keep the radio supply stable during TX current bursts. The small series resistors on the signal lines help reduce ringing/EMI and make the link more robust with real wiring and connectors.

Net result: a modular, swappable telemetry port that supports different radios (LoRa, FSK, custom links) while keeping signal integrity and power stability under control.This block is the Peripheral Radio Connector: a dedicated 10-pin header that lets PROTON-3 plug into an external RF/telemetry module without baking a specific radio into the main PCB.

It exposes a clean SPI interface (SCK/MOSI/MISO + CS) plus several PERI GPIO lines for IRQ, reset, enable, or module-specific handshakes. Power is provided as 3V3 and GND, with local bulk + high-frequency decoupling (10 µF + 100 nF) right at the connector to keep the radio supply stable during TX current bursts. The small series resistors on the signal lines help reduce ringing/EMI and make the link more robust with real wiring and connectors.

Net result: a modular, swappable telemetry port that supports different radios (LoRa, FSK, custom links) while keeping signal integrity and power stability under control.

This block is the 6 V power stage, built around the AOZ6605PI-1 synchronous buck regulator. It takes the upstream supply rail (battery/USB-derived system input) and generates a clean, efficient 6 V bus for high-current peripherals like servos and actuators, keeping those noisy loads off the sensitive 3.3 V logic domain.

Key design points:

• 4.7 µH inductor (L4) and low-ESR output capacitors (22 µF + 22 µF) provide low ripple and good transient response when a servo suddenly loads/unloads.

• Feedback divider sets the output voltage precisely to 6 V.

• COMP/compensation network stabilizes the control loop so the regulator doesn’t oscillate with real-world wiring and pulsed loads.

• Bootstrap cap + local decoupling are placed close to the IC to support fast switching edges and reduce EMI.

• Input filtering and bulk caps help absorb input spikes so the rest of the system remains stable during high dynamic current events.

Net result: a robust 6 V rail that’s efficient, tolerant to aggressive load steps, and designed for the kind of current pulses you get in flight-control hardware.

This block is the 5 V power stage, again using the AOZ6605PI-1 synchronous buck regulator. It generates the board’s 5 V bus from the upstream system input (battery/USB-side rail), providing an efficient intermediate rail for peripherals and downstream regulators.

Why it’s there:

• A dedicated 5 V rail is a practical “workhorse” supply for external modules, expansion connectors, and any 5 V-rated subsystems, while keeping switching noise and load spikes away from the 3.3 V logic domain.

• It also gives you a stable source for any secondary regulation (e.g., clean 3.3 V generation) without relying on USB quality.

Design highlights:

• 4.7 µH inductor (L5) plus bulk/ceramic output capacitors (22 µF + 22 µF) to handle fast load steps with low ripple.

• Feedback divider programs the output to exactly 5 V.

• The COMP network sets loop stability, so the converter stays well-behaved with real wiring, mixed loads, and high dI/dt events.

• Proper bootstrap + local decoupling close to the IC improves switching performance and reduces EMI.

Net result: a clean, efficient, and robust 5 V rail that supports the “messy” external world while protecting the flight-critical 3.3 V domain.

This block is the onboard 5 V → 3.3 V step-down supply for the flight computer logic, built around an AP63203WU-7 synchronous buck regulator. It converts the available 5 V rail (USB or the internal 5 V bus) into a stable 3V3 domain for the ESP32-S3 and all sensors.

Why it’s used:

• A switching buck is far more efficient than an LDO when dropping from 5 V to 3.3 V, which reduces heat and keeps the board reliable in a closed airframe.

• It provides a stiff, low-impedance 3.3 V rail that tolerates the ESP32’s Wi-Fi/CPU current bursts and high-rate sensor sampling without brownouts.

Design highlights:

• 4.7 µH inductor and 22 µF + 22 µF output capacitance to handle load steps and keep ripple low.

• Input bulk capacitor (10 µF) and high-frequency decoupling (100 nF) placed close to the IC to keep switching noise under control.

• Simple, robust reference/feedback wiring for predictable startup and regulation behavior.

Net result: a cool-running, dependable 3.3 V supply that keeps the flight stack stable even when the system is logging hard or transmitting telemetry.

This block is the BMI088 IMU: a high-performance 3-axis accelerometer + 3-axis gyroscope used as the flight computer’s primary “hard” motion sensor. In a rocket, you want an IMU that stays stable under high vibration and high acceleration, and the BMI088 is built for exactly that kind of environment.

What you see here:

• SPI interface (SCK/MOSI/MISO + chip-selects) for fast, deterministic sampling and clean timing compared to a slow, shared bus.

• Separate CS lines for gyro and accel (typical for BMI088), so each part can be configured and read independently at high rate.

• INT lines routed to the MCU for precise data-ready interrupts and consistent timestamping—critical for control loops and for correlating IMU data with baro/GPS logs.

• Local decoupling (1 µF + 100 nF on the supply rails) placed close to the IC to keep the sensor quiet when the MCU and radio create transient current spikes.

• Small series resistors on SPI lines to tame edge ringing and reduce EMI/crosstalk, which matters with high-speed digital lines running near sensitive analog sensing.

Net result: a robust, high-rate inertial sensing block that supports reliable attitude estimation and flight control even when the airframe is shaking and the dynamics get violent.

This block is the BMP388 barometric pressure sensor, used for altitude measurement and apogee detection. Baro altitude is still one of the most reliable signals for flight events (liftoff, coast, apogee, descent), especially when GPS is noisy or has low update rate.

What’s implemented here:

• I²C connection (SDA/SCL) for simple integration alongside other sensors.

• The SDO/address strap selects the I²C address (0x76 when SDO = GND, 0x77 when SDO = 3V3), which avoids conflicts on the shared bus.

• Local decoupling capacitors (100 nF) close to the supply pins to keep the sensor stable and reduce noise that would show up as altitude jitter.

• The CSB pin is set for I²C mode, and the INT pin is available for data-ready/interrupt-driven sampling if needed.

Net result: a clean, high-resolution altitude source that complements the IMU and enables robust flight-state decisions and reliable recovery triggering.

This block is the battery voltage measurement divider. It scales the raw BAT+ voltage down to a safe range for the MCU’s ADC, so the flight computer can continuously monitor battery state during arming, flight, and recovery.

• R29 (100 kΩ) + R31 (10 kΩ) form the divider (≈ 11:1), so the ADC sees roughly one eleventh of the pack voltage.

• R30 (1 kΩ) is a small series resistor that protects the ADC pin and, together with C35 (100 nF), forms a low-pass filter. That reduces switching noise and servo/transmitter spikes that would otherwise show up as jitter in the reading.

Net result: a low-current, robust voltage sense that enables brownout prevention, flight logging of battery behavior, and clean pre-flight “battery OK” checks.

This page implements the pyro / deployment output stage: four independent high-current channels intended for recovery events (e.g., igniters for ejection charges, cutters, separation devices), routed to robust screw terminals for field wiring.

Each channel uses an AO3400A N-MOSFET as a low-side switch, so the flight computer can fire a load reliably while keeping the control electronics isolated from the high-current path. The 33 Ω gate resistors tame switching edges (less EMI, cleaner behavior), and the 100 kΩ gate pull-downs make the default state fail-safe: if the MCU is unpowered, reset, or a pin floats, the MOSFET stays hard OFF. The SS54 Schottky diodes add extra protection/isolation against reverse or parasitic current paths and help prevent one channel or external wiring from feeding back into the pyro supply rail.

Net result: a modular, serviceable, safety-oriented deployment interface with clear channel separation, robust connectors, and protective details that matter in real launch conditions.

This block is the microSD logging interface, which is a core part of PROTON-3: it enables high-rate flight data recording directly on the vehicle, independent of radio link quality.

What’s going on here:

• The socket is wired in SPI mode (CS, SCK, MOSI, MISO) for simple, reliable integration with the ESP32.

• 0 Ω series links on the SPI lines are used as “configuration jumpers” / debug options: they let you add damping resistors later if signal integrity ever becomes an issue, without redesigning the PCB.

• The 10 kΩ pull-ups on the data/command lines provide defined logic levels during reset and power-up so the card doesn’t boot into weird states.

• A dedicated card-detect switch is routed to a GPIO (with a pull-up), so firmware can detect insertion/removal and handle logging safely.

• Local decoupling (1 µF + 100 nF) near the socket helps absorb the SD card’s short current spikes during write bursts, improving stability and reducing brownout risk.

Net result: a robust SD subsystem designed for real-world flight logging—clean startup behavior, debuggable SPI routing, and power integrity measures that protect data capture under vibration and supply transients.

This block is the PCA9685 16-channel PWM driver (often mistaken for an I²C multiplexer, but it’s actually a PWM expander). It’s used to generate clean, hardware-timed servo pulses without tying up the ESP32’s timers or adding jitter when the MCU is busy logging sensors or handling telemetry.

What it does in PROTON-3:

• Drives up to 16 PWM outputs (here used for SERVO1…SERVO8 plus extra signals), ideal for canards/TVC servos, release servos, or other actuators.

• Runs over I²C (SDA/SCL), so the control interface stays simple while the timing is handled by dedicated hardware.

• Provides a stable output update behavior even under CPU load — important when you want repeatable control response in flight.

Design details visible here:

• Local decoupling (100 nF + 1 µF) on the PCA9685 supply to keep it stable during switching edges on many channels.

• Address pins A0–A5 are broken out/strapped so multiple PCA9685s could coexist if you ever expand.

• OE (Output Enable) is routed (with a pull-up/down strategy) so you can globally disable all servo outputs as a safety feature (e.g., SAFE mode / disarmed state).

• Notes about bulk capacitance on the servo power rail: servos cause nasty current spikes, so the design anticipates local buffering close to the actuator supply.

Net result: a low-jitter, scalable actuator control layer that makes PROTON-3’s control surfaces behave consistently, even while the ESP32 is doing high-rate sensor acquisition and SD logging.

This block is the USB-C interface used for power and direct wired data access (flashing, debugging, log download) on the PROTON-3 flight computer.

What’s implemented here:

• USB-C receptacle (USB1) with VBUS and GND brought onto the board for the 5 V supply path.

• CC1/CC2 pull-downs (5.1 kΩ) advertise the board as a USB device (UFP), so any standard USB-C cable/host will reliably provide 5 V on VBUS.

• D+ / D− lines are routed from the connector to the MCU USB pins, with 22 Ω series resistors for signal integrity (edge damping, reduced ringing/EMI), which improves reliability across different cables and hosts.

• Proper grounding on the connector shell/pins helps with ESD robustness and noise, which matters a lot for a launch-site environment.

Net result: a clean, standards-correct USB-C port that makes the flight computer easy to power, program, and debug without adapters or fragile wiring.

This block is the battery input protection stage for PROTON-3: it combines reverse-polarity protection, short-circuit fault limiting, and surge suppression so the rest of the flight computer doesn’t die from one wiring mistake or a nasty transient.

• F1 (fuse) sits right at BAT+ and is the first line of defense against hard shorts, damaged wiring, or a failed load downstream.

• Q1 (P-channel MOSFET “ideal diode” style) provides low-loss reverse polarity protection. With correct polarity it behaves like a low-resistance switch; with reversed polarity it blocks current instead of dumping power into the board like a simple diode would.

• R10/R11 bias the MOSFET gate so it turns on cleanly with the right polarity and stays off when it shouldn’t.

• D1 (zener clamp) limits Vgs to keep the MOSFET gate safe during higher input voltages and fast transients.

• D2 (TVS diode, SMBJ24A) clamps large spikes (ESD, hot-plug transients, inductive kicks from wiring), protecting the downstream regulators and sensitive electronics.

Net result: a robust, low-drop input front-end that makes the board much harder to fail in real launch prep—where connectors get swapped fast, cables get stressed, and voltage spikes are common.

This block is the 5 V power OR-ing stage for the flight computer. It allows PROTON-3 to be powered from either USB VBUS or the onboard 5 V regulator — automatically and safely — without back-feeding one source into the other.

• Two LM66100 “ideal diode” controllers (U13/U14) sit in series with each input path. They behave like ultra-low-drop diodes: the higher/healthier source wins, while the other is cleanly blocked.

• This gives seamless power handover (plug/unplug USB while the battery system is connected) and prevents the classic failure mode where USB tries to charge your 5 V rail or your 5 V rail drives back into the USB port.

• The surrounding bulk + decoupling capacitors provide local energy storage for load steps and reduce the impact of cable hot-plug transients on the MCU rail.

• The small resistor networks set the LM66100 enable / control behavior so the OR-ing remains deterministic and stable.

Net result: a robust dual-source power input that makes development and field operation safer: you can program/debug over USB while the rocket battery is connected, and you don’t have to worry about accidental back-powering paths.

This block is the servo power + output harness for PROTON-3. It breaks out eight servo channels (SERVO1…SERVO8) to standard 3-pin headers, each carrying PWM signal + 6 V + GND, so actuators can be plugged in directly with no adapter wiring.

A large 1000 µF bulk capacitor sits on the 6 V rail near the headers. Servos draw sharp current spikes when they start, stall, or get hit by aerodynamic loads; the bulk cap buffers those peaks, reduces rail dip, and prevents the rest of the flight computer from seeing brownouts or noisy resets.

Net result: a field-friendly, high-current servo interface designed for real control surfaces—stable power delivery, clean wiring, and scalable channel count for canards, TVC, and recovery mechanisms.