HUMA Rocket Flight Computer

HUMA — STM32H7 Rocket Flight Computer

An unfinished high-performance rocket flight computer designed around the STM32H7 family, redundant inertial and barometric sensing, high-g and high-bandwidth data acquisition, microSD black-box logging, 915 MHz LoRa telemetry, analog-video OSD, expansion I/O, and four isolated e-match output channels.

The project was stopped before fabrication and full bring-up because of budget cuts. The complete KiCad design snapshot is being published so that anyone interested can inspect it, learn from it, correct it, manufacture a prototype, or continue the design.

Important status warning

This board was not completed, assembled, bench-validated, flight-tested, or qualified.

The repository should therefore be treated as an engineering handoff / research prototype, not as production-ready avionics.

In particular:

• no manufactured board from this revision was validated;
• no firmware is included in the recovered design archive;
• no released BOM is included;
• no released Gerber/drill package is included;
• no ERC/DRC report is included;
• component availability and footprints must be rechecked;
• the power system needs thermal and transient validation;
• the RF section needs antenna and conducted/radiated testing;
• the e-match outputs require a complete independent safety review before they are ever connected to a live initiator;
• the schematic and PCB contain at least a small number of value inconsistencies that must be reconciled before ordering.

Do not connect live pyrotechnic initiators during initial development. Use inert electrical loads while validating logic, isolation, fault behavior, and power switching. A real flight implementation should also include independent hardware arming and launch-site safety procedures appropriate to the applicable rocketry rules.

1. Project background

HUMA was developed as a high-data-rate rocket flight computer for UCLR Rocket.

The recovered top-level schematic identifies the project as:

The project evolved over time. The files in this repository are therefore a snapshot of the hardware at the point development stopped, rather than a polished final release.

The goal was to build much more than a simple altitude logger. The board was intended to act as a central avionics and data-acquisition platform that could:

• record high-rate inertial data through launch, powered flight, coast, deployment, and landing;
• remain useful when one sensor gives bad data or saturates;
• capture both ordinary vehicle motion and very high acceleration/shock events;
• record high-frequency structural vibration separately from the normal navigation IMUs;
• estimate altitude using redundant pressure sensors;
• record temperatures around the avionics system;
• retain a complete local flight record even if the radio link is lost;
• transmit selected telemetry over a long-range LoRa link;
• overlay important flight information onto an external analog video feed;
• expose a large amount of STM32 I/O for later expansion;
• provide controlled outputs for recovery-system initiators;
• leave enough computing headroom for future estimation and control research.

Active guided takeoff / landing was discussed as a possible later research direction, but it was not part of the scope of this hardware revision.

2. Design philosophy

Several architectural decisions make more sense when the original priorities are understood.

2.1 Preserve raw data before deriving state

The most important data product was intended to be the raw, timestamped sensor stream.

Orientation estimates, filtered acceleration, altitude, event detection, and other derived values are useful, but they should not replace the underlying measurements. A post-flight algorithm can be improved later; data that was never recorded cannot be recreated.

A future firmware implementation should therefore prioritize:

1. deterministic acquisition;
2. accurate timestamps;
3. FIFO / DMA handling;
4. loss-resistant microSD logging;
5. health/status metadata;
6. only then real-time fusion and higher-level state estimation.

2.2 Redundancy is for detecting disagreement, not merely duplicating sensors

The board includes two main 6-axis IMUs and two barometers.

The point was not simply to average every measurement. Multiple sensors allow firmware to ask:

• Do both IMUs agree?
• Did one device saturate?
• Did one SPI device stop updating?
• Is one barometer drifting?
• Is an apparent acceleration physical, or isolated to one sensor?
• Did a shock event create a permanent offset?
• Can one sensor be excluded while the rest of the system continues?

A continuation of the project should log per-sensor health flags and raw values independently, even if a fused value is also computed.

2.3 Sensor diversity matters

A rocket sees very different physical regimes:

• relatively ordinary rigid-body motion;
• high angular rate;
• launch acceleration;
• short-duration shock;
• broadband mechanical vibration;
• slowly changing atmospheric pressure;
• magnetic disturbances;
• large temperature changes.

Trying to make one IMU solve all of these problems forces compromises.

HUMA therefore separated several measurement roles:

• normal 6-axis inertial sensing;
• extreme-g impact/launch measurement;
• high-bandwidth vibration measurement;
• pressure altitude;
• magnetic field / heading;
• temperature monitoring.

2.4 Local storage is primary; telemetry is secondary to data integrity

The radio should be useful, but the success of the experiment should not depend on maintaining a perfect radio link.

The intended hierarchy was:

Sensors
   │
   ├──> deterministic acquisition
   │
   ├──> RAM/FIFO buffering
   │
   ├──> microSD black-box record  ← primary full-resolution record
   │
   └──> selected/downsampled packets
             │
             └──> 915 MHz LoRa telemetry

A robust firmware implementation should continue recording locally when telemetry drops out.

2.5 Separate high-rate traffic where practical

The design does not place every inertial sensor on one shared bus.

The dual main IMUs use one SPI bus, while the high-g / high-bandwidth group is placed on another set of STM32 SPI-capable pins. This reduces bus contention and makes it easier to:

• use DMA;
• preserve deterministic timing;
• service high-rate sensors without delaying the main IMUs;
• isolate a bus fault;
• assign different acquisition priorities.

2.6 Expansion was deliberately kept available

Two large 2×25 headers expose a substantial fraction of the MCU I/O together with power rails.

This increased PCB area, but it avoided turning revision 1.5 into a dead-end design. Future modules could add GNSS, a second external magnetometer, additional radios, actuators, CAN/RS-485 interfaces, or experimental sensors without immediately respinning the flight computer.

3. High-level architecture

flowchart TD
    BAT[Vehicle power / Vin]

    BAT --> BUCK[TPS56528<br/>Vin to 5 V]
    BUCK --> RAIL5[5 V rail]
    RAIL5 --> LDO[MCP1826S<br/>5 V to 3.3 V]
    LDO --> RAIL33[3.3 V rail]

    USB[USB-C] --> USBPROT[ESD + series resistors]
    USBPROT --> MCU[STM32H750VBTx<br/>archived revision]
    USB --> ORING[Schottky power path]
    ORING --> RAIL5

    RAIL33 --> IMU1[LSM6DSO32 #1]
    RAIL33 --> IMU2[LSM6DSO32 #2]
    RAIL33 --> HIGHG[ADXL37x / intended ADXL373]
    RAIL33 --> VIB[IIS3DWB]
    RAIL33 --> MAG[LIS3MDL]
    RAIL33 --> BARO1[MS5611 #1]
    RAIL33 --> BARO2[MS5611 #2]
    RAIL33 --> TEMP[5 × NTC channels]

    IMU1 --> MCU
    IMU2 --> MCU

4. Archived implementation versus later design intent

This distinction is important for anyone continuing the project.

The files in the repository should be treated as the source of truth for what is actually routed.
Earlier or later architecture discussions explain the motivation, but they do not prove that a feature exists on this PCB.

5. Main processor subsystem

5.1 Archived MCU — STM32H750VBTx

The PCB currently contains:

U1 — STM32H750VBTx, LQFP-100

Official ST page:
https://www.st.com/en/microcontrollers-microprocessors/stm32h750vb.html

The STM32H750 family provides a Cortex-M7 core running at up to 480 MHz, a large SRAM system, DMA resources, multiple SPI peripherals, SDMMC, USB, ADCs, timers, and enough computational throughput for a multi-sensor acquisition system.

Why an STM32H7?

The decision was driven less by raw CPU benchmark performance and more by peripheral bandwidth and deterministic acquisition.

HUMA needed to deal with several independent streams simultaneously:

• dual 6-axis IMUs;
• a high-g accelerometer;
• a high-bandwidth vibration sensor;
• two barometers;
• magnetometer data;
• multiple ADC temperature channels;
• microSD writes;
• telemetry;
• OSD communication;
• event outputs.

A smaller MCU could operate many of these parts individually. The H7 gives significantly more headroom to handle them at the same time using DMA, interrupts and buffered logging.

5.2 Why the H750 was later reconsidered

The H750 is unusually attractive for computation but has relatively limited internal Flash compared with other STM32H7 variants.

As the proposed firmware grew to include:

• multiple sensor drivers;
• filesystem / logging code;
• radio stack;
• health monitoring;
• OSD;
• estimation;
• boot / recovery logic;

more internal Flash became desirable.

Later project discussions therefore considered migrating to an STM32H753-family device in a compatible package/pinout.

A contributor should not blindly substitute the MCU. Verify the exact order code, LQFP-100 pinout, power pins, boot behavior, Flash size, peripheral mapping and option-byte behavior against the current ST datasheets before changing U1.

5.3 Clocking

The main MCU uses:

• Y1 — 25 MHz crystal
• C1 — 8 pF
• C2 — 8 pF

The crystal network should be revalidated using the exact crystal part number, specified load capacitance, PCB parasitics and ST oscillator guidance.

The text value in the schematic indicates 25MHz 9pF, while the fitted load capacitors are 8 pF. That may be reasonable depending on the actual crystal and stray capacitance, but it should be calculated rather than assumed.

5.4 Core power and decoupling

The MCU is supplied from the 3.3 V rail.

The design includes:

• local 100 nF decoupling around the MCU supply pins;
• bulk 3.3 V capacitance;
• separate VCAP capacitors for the STM32 internal regulator;
• VDDA filtering from the digital 3.3 V rail;
• VBAT connection;
• BOOT0 pull-down;
• hardware reset switch.

Before manufacture, compare this section directly against the current STM32H750/H753 hardware-design recommendations.

5.5 Boot and reset

• BOOT0 is held low through R1 = 10 kΩ.
• SW1 pulls RESET low.
• The ARM debug connector also exposes reset.

The intended normal state is therefore a conventional boot from user Flash.

Future firmware should also define a recovery procedure for a corrupt firmware image or failed boot.

5.6 Debug interface

J4 is a 20-pin ARM JTAG/SWD-style connector.

Important signals include:

The unused legacy JTAG signals are intentionally left unconnected in this snapshot.

For first bring-up, SWD should be the primary programming method.

6. Inertial sensing architecture

The inertial subsystem was intentionally split into several measurement roles.

6.1 Dual LSM6DSO32 main IMUs

The board contains:

• U6 — LSM6DSO32TR
• U10 — LSM6DSO32TR

Official ST page:
https://www.st.com/en/mems-and-sensors/lsm6dso32.html

Each device provides a 3-axis accelerometer and 3-axis gyroscope.

Why two?

Two main IMUs provide:

• cross-checking;
• failure detection;
• saturation comparison;
• post-shock offset comparison;
• the possibility of voting or confidence weighting;
• continued operation if one sensor stops responding.

The original goal was not to blindly average them. Firmware should keep both measurements separate and record an explicit health state for each device.

Bus arrangement

Both main IMUs share SPI1:

Individual chip-select and interrupt lines keep the devices independently controllable.

U6

U10

The CS lines have pull-ups so that the devices remain deselected while the MCU is resetting or its GPIO is high-impedance.

Why ±32 g-capable main IMUs?

A normal ±16 g IMU can saturate in aggressive rocket motion. The LSM6DSO32 family increases the useful accelerometer range while still providing normal gyro data.

However, even ±32 g is not enough for every shock or launch event. That is the reason for the separate ADXL37x channel.

Common-mode limitation

Using two identical IMUs improves redundancy but not component diversity. A firmware bug, electrical issue, vibration sensitivity, or failure mode common to that sensor family could affect both.

A future revision could deliberately use two different IMU families if fault diversity matters more than software simplicity.

7. Extreme-g accelerometer

The PCB contains:

U7 — ADXL37x

Later design work identified ADXL373 as the intended concrete part.

Analog Devices ADXL373 page:
https://www.analog.com/en/products/adxl373.html

The ADXL373 is a digital 3-axis ±400 g accelerometer.

Why include it?

The normal IMUs are useful for state estimation and ordinary vehicle dynamics, but can saturate during:

• ignition;
• staging or separation events;
• parachute deployment shock;
• landing impact;
• abnormal structural events.

Once an accelerometer clips, the true peak is lost.

The high-g channel was intended to retain useful data during events that are outside the normal IMU measurement range.

Interface in the archived board

The device is connected through the PE2 / PE5 / PE6 SPI-capable signal group:

This group is separate from the two main LSM6DSO32 devices.

That separation was intentional: the high-g/high-bandwidth sensors can generate different traffic and interrupt behavior from the normal navigation IMUs.

Important continuation item

The symbol/value in the archived KiCad design is still generic: ADXL37x.

Before ordering:

• select the exact sensor;
• verify its pinout against the footprint;
• verify voltage requirements;
• check interrupt polarity and interface mode;
• update the symbol value and BOM with the exact manufacturer part number.

8. High-bandwidth vibration sensor

The PCB contains:

U9 — IIS3DWBTR

Official ST page:
https://www.st.com/en/mems-and-sensors/iis3dwb.html

The IIS3DWB is a low-noise, wide-bandwidth 3-axis digital vibration sensor. ST specifies a flat response extending to approximately 6 kHz and an output data rate up to 26.7 kHz.

Why is this different from the main IMUs?

The main IMUs answer questions such as:

How is the vehicle translating and rotating?

The IIS3DWB was included to answer a different class of question:

What high-frequency vibration and structural energy is present in the vehicle?

That can be useful for studying:

• motor vibration;
• airframe resonance;
• structural coupling;
• mounting behavior;
• sensor contamination by vibration;
• transient events.

Using a dedicated vibration sensor avoids forcing the main IMUs to act as instruments they were not optimized to be.

Interface

It therefore shares the high-rate PE2/PE5/PE6 bus with the high-g sensor, while keeping an independent chip select and interrupt lines.

Firmware implication

Do not assume that logging every IIS3DWB sample continuously at maximum rate is automatically useful.

A continuation should first define:

• desired vibration bandwidth;
• sample format;
• FIFO strategy;
• event windows;
• expected microSD throughput;
• whether full-rate data is continuous or event-triggered.

The hardware provides the opportunity for high-rate capture; the logging architecture still needs to be engineered.

9. Magnetic sensing

The archived board contains:

U5 — LIS3MDL

Official ST page:
https://www.st.com/en/mems-and-sensors/lis3mdl.html

The LIS3MDL is a 3-axis digital magnetometer with SPI/I²C capability.

Archived interface

The CS line is pulled high by default.

Why the magnetometer was not the highest-priority sensor

For raw high-dynamic rocket sensing, acceleration and angular rate are usually more important than magnetic heading.

Magnetometers can also be badly disturbed by:

• high-current wiring;
• RF hardware;
• steel fasteners;
• switching regulators;
• recovery-system wiring;
• vehicle structure.

The magnetometer was therefore useful as an additional absolute-reference sensor, but it was not intended to replace the inertial data.

Later dual-compass intention

Later HUMA architecture discussions targeted dual compasses.

This archived PCB contains only one onboard LIS3MDL.

A sensible continuation would place the second compass externally or on a daughterboard, away from the high-current and RF sections.

Component-lifecycle warning

ST currently lists the LIS3MDL as obsolete / out of production and points to LIS2MDL as a replacement family.

Do not assume LIS2MDL is a drop-in replacement. Recheck footprint, supply, interface and firmware requirements before substitution.

10. Redundant barometric sensing

The board contains:

• U8 — MS5611-01BA
• U17 — MS5611-01BA

TE Connectivity product family:
https://www.te.com/en/product-MS561101BA03-50.html

Why two barometers?

Pressure altitude is extremely useful during a rocket flight because it gives an independent measurement channel from inertial integration.

A second barometer allows:

• comparison for drift;
• detection of a failed sensor;
• detection of impossible pressure steps;
• continuity of altitude estimation after a single-device failure;
• post-flight validation.

Interface

Both sensors share SPI2 and have independent chip-select lines.

Both CS lines have pull-ups so they remain inactive during MCU reset.

Mechanical design matters as much as electronics

A pressure sensor can be electrically perfect and still produce poor flight data if the pressure port is exposed to:

• direct airflow;
• dynamic pressure;
• propulsive flow;
• pressure oscillation;
• heat.

Anyone continuing this project should treat enclosure venting, sensor placement, foam/filtering and pressure-port design as part of the barometer subsystem.

11. Temperature monitoring

The board contains five NTC channels:

• TH1
• TH2
• TH3
• TH4
• TH5

Each thermistor forms a divider with a 10 kΩ resistor and feeds an STM32 analog-capable pin.

Why multiple temperature points?

Temperature can affect:

• MEMS bias;
• pressure-sensor offset;
• regulator behavior;
• battery performance;
• RF performance;
• calibration.

Multiple channels were intended to allow temperature to be logged alongside the sensor data so post-flight calibration or anomaly analysis could account for thermal conditions.

Unfinished detail

The schematic only identifies the parts as Thermistor_NTC.

The exact:

• nominal resistance;
• beta value;
• tolerance;
• package;
• temperature range;

must be defined before manufacture.

Firmware should store either raw ADC values or enough calibration metadata that the temperature conversion can be reproduced later.

12. Sensor bus organization

The bus arrangement is one of the more important architectural choices.

SPI1 — primary IMUs

STM32
 └── SPI1
      ├── LSM6DSO32 #1
      └── LSM6DSO32 #2

Purpose: deterministic acquisition of the two normal flight IMUs.

PE2 / PE5 / PE6 SPI-capable bus — high-dynamic sensors

STM32
 └── high-rate SPI group
      ├── ADXL37x / intended ADXL373
      └── IIS3DWB

Purpose: keep high-g / vibration traffic from unnecessarily competing with the primary IMU bus.

SPI2 — lower-rate and peripheral devices

The archived design places multiple devices on SPI2, including:

• LIS3MDL magnetometer;
• MS5611 #1;
• MS5611 #2;
• MAX7456 OSD;
• E22-900M30S LoRa module.

This is a much more heterogeneous bus.

That is acceptable because several of these devices are relatively low-duty-cycle compared with the inertial acquisition path, but firmware must arbitrate the bus carefully.

A stuck peripheral on a shared MISO line can affect several subsystems, so a future firmware design should include:

• transaction timeouts;
• peripheral reset/recovery;
• clear CS ownership;
• startup sequencing;
• error counters.

13. microSD black-box logging

J1 is a microSD socket with card-detect support.

The design uses the STM32 SDMMC interface, rather than treating the card as a slow SPI peripheral.

Signal mapping

The routing corresponds to a 4-bit SDMMC-style connection:

The data/command lines have pull-ups.

The microSD supply is fed from the 3.3 V rail through a filtered branch and includes local bulk and high-frequency decoupling.

Why SDMMC?

The board potentially generates a large amount of sensor data.

Using SDMMC instead of one more SPI device provides:

• higher throughput;
• lower bus contention;
• cleaner separation from the sensor buses;
• more margin for burst writes.

Intended logging model

The preferred firmware architecture is a black-box logger, not a collection of independent text files written directly from interrupt handlers.

A robust implementation should use:

1. interrupt/FIFO-driven sensor acquisition;
2. precise timestamps;
3. fixed-size binary records;
4. RAM ring buffers;
5. block-oriented SD writes;
6. sequence counters;
7. periodic metadata / health frames;
8. recovery from an interrupted final write.

Do not perform slow filesystem operations directly inside sensor interrupts.

Recommended record philosophy

Every record should make it possible to reconstruct:

• which sensor produced the data;
• when it was sampled;
• whether it was valid;
• whether FIFO overflow occurred;
• current board state;
• reset reason;
• configuration used for the flight.

Raw sensor data should be retained even when a fused estimate is also logged.

14. 915 MHz LoRa telemetry

The RF subsystem contains:

U16 — E22-900M30S

Manufacturer page:
https://www.ebyte.com/product/451.html

The module is based on the Semtech SX1262 family and supports the 850–930 MHz region. Ebyte specifies up to 30 dBm transmit power for this module.

HUMA's intended telemetry band was 915 MHz.

Why LoRa?

The design goal favored:

• long range;
• good link budget;
• relatively low data-rate status telemetry;
• simple packetized communication;
• operation independent of local Wi-Fi/cellular infrastructure.

The radio was not intended to replace the microSD record.

Interface

The module is connected by SPI plus control lines.

The reset net has a pull-up and capacitor.

Local 5 V decoupling is placed close to the radio.

Why the radio is on 5 V

The E22-900M30S is a comparatively high-power module. Ebyte lists transmit current in the several-hundred-milliamp range at maximum output power.

That is one reason the architecture has a substantial 5 V rail instead of trying to run every subsystem through the 3.3 V LDO.

Intended packet philosophy

Telemetry should contain selected information such as:

• packet sequence;
• timestamp;
• flight state;
• altitude;
• selected acceleration/angular-rate values;
• battery/power status;
• sensor health;
• event state;
• error flags.

Packets should include an integrity check such as CRC and should not assume that every packet will arrive.

Regulatory note

Allowed frequencies, bandwidths, duty cycle and transmit power depend on jurisdiction.

A 30 dBm-capable module does not mean maximum power is legal everywhere. Anyone continuing the project must configure and operate the radio according to the rules applicable to the launch location.

15. RF / antenna interface

The radio's antenna pin is routed to AE1, an antenna/coax interface.

The shield/reference network contains a small capacitor and high-value resistor path to ground.

Before fabrication, this area deserves a dedicated RF review:

• confirm the exact connector footprint;
• confirm the 50 Ω routing geometry using the chosen PCB stackup;
• minimize discontinuities;
• check return-current continuity;
• verify ground-via placement;
• check antenna keep-out requirements;
• verify module manufacturer's reference layout;
• perform conducted power and receive-sensitivity testing before relying on range.

The original board was never RF-qualified.

16. Analog video OSD subsystem

The helper-processor sheet contains:

U15 — MAX7456EUI+

Analog Devices page:
https://www.analog.com/en/products/max7456.html

The MAX7456 is a monochrome analog-video on-screen-display generator controlled over SPI.

It can insert text/graphics into NTSC/PAL composite video.

Why include a dedicated OSD chip?

The intention was to allow a camera feed to carry information such as:

• altitude;
• flight state;
• battery status;
• radio status;
• timer;
• warnings;

without asking the STM32 to generate or process video pixels directly.

The MCU only has to update OSD registers/character memory.

This gives an independent, human-readable telemetry path when using an analog FPV/video system.

Video connectors

J2 — video input

J3 — video output

The connectors therefore carry the video signal plus supply and analog ground for external camera/video hardware.

MAX7456 supplies

The archived design uses:

• 3.3 V digital supply;
• 5 V analog/video supply;
• separate analog-ground domain;
• 27 MHz crystal.

The chip shares SPI2 with several other peripherals.

Component-lifecycle warning

Analog Devices currently lists the original MAX7456 as obsolete.

A future revision should therefore decide whether to:

• use a verified compatible replacement such as an AT7456E-class device;
• use a separate OSD module;
• remove analog OSD entirely;
• replace the video system with a digital architecture.

Do not change the part without checking pinout, oscillator, supply and analog-video requirements.

17. Analog ground strategy

The design contains both:

• Earth — main board ground;
• GNDA — analog video ground.

GNDA is connected to the main ground through R12 = 10 Ω.

The video connectors and the analog side of the OSD use GNDA.

Why separate them?

Composite analog video is sensitive to:

• regulator switching noise;
• digital edge currents;
• RF currents;
• high-current recovery-system transients.

The intent was to keep noisy digital/power return currents from directly contaminating the analog video path.

What must be reviewed

Ground partitioning is easy to get wrong.

A continuation should inspect:

• where return currents actually flow;
• whether the 10 Ω connection causes unwanted ground offset;
• whether external camera/VTX equipment creates another ground connection;
• how the e-match return path flows;
• how RF shield current returns;
• whether a solid reference plane with localized filtering would perform better.

Treat the current GNDA implementation as a design decision to evaluate, not as a proven solution.

18. Power architecture

The board has three important power domains:

Vin
 │
 ├──> recovery/e-match output side
 │
 └──> TPS56528 buck
          │
          └──> +5 V
                 │
                 ├──> LoRa
                 ├──> OSD analog/video power
                 ├──> external 5 V
                 └──> MCP1826S LDO
                          │
                          └──> +3.3 V
                                 ├──> STM32
                                 ├──> IMUs
                                 ├──> pressure sensors
                                 ├──> magnetometer
                                 └──> logic

18.1 Vin to 5 V — TPS56528

U3 — TPS56528DDA

TI page:
https://www.ti.com/product/TPS56528

TI specifies the TPS56528 as a synchronous buck regulator with:

• 4.5–18 V input range;
• up to 5 A output capability;
• programmable output.

The resistor network in this design configures the rail for approximately 5 V.

Why a relatively powerful 5 V regulator?

The 5 V rail has to support more than logic.

Notably:

• the E22 high-power radio can draw large transmit-current pulses;
• the OSD/video system uses 5 V;
• external equipment may use the rail;
• transient load margin is useful.

The design includes local and bulk capacitance to support load steps.

System-level battery concept

Earlier system planning considered a 3S battery arrangement with parallel capacity/current redundancy.

The exact battery architecture is not defined by this PCB archive, so future builders must redesign the pack around the actual vehicle, current budget, protection strategy and applicable safety requirements.

18.2 5 V to 3.3 V — MCP1826S

U2 — MCP1826S

Microchip page:
https://www.microchip.com/en-us/product/mcp1826s

The MCP1826S is a 1 A LDO family.

Why an LDO after the buck?

The intended advantages were:

• a simple 3.3 V rail;
• low switching noise for sensors and MCU;
• isolation of the logic rail from some 5 V load transients;
• inexpensive implementation.

Thermal trade-off

An LDO dropping 5 V to 3.3 V dissipates:

P ≈ (5.0 V - 3.3 V) × I_3V3

At 500 mA, that is already about 0.85 W.

At 1 A, it is about 1.7 W.

The archived design was never thermally validated. A future builder should calculate the real 3.3 V current and junction temperature and may decide that a second switching stage followed by filtering is more appropriate.

Package verification required

The archived PCB assigns U2 a vertical TO-220-style footprint.

The exact MCP1826S order code/package must be checked before ordering. Do not assume the generic device name guarantees package compatibility.

18.3 USB-C power path

USB-C VBUS reaches the board's 5 V rail through a Schottky diode (D3, SS34-class footprint).

This allows USB to power at least part of the board during development while reducing direct backfeed from the local 5 V rail toward the host.

However, the complete power-sharing behavior must be checked before simultaneously connecting:

• USB;
• main Vin;
• external 5 V sources.

USB should not be assumed capable of supplying the full high-power radio, external video equipment or recovery-system load.

18.4 Bulk capacitance

The design contains substantial bulk capacitance on Vin, 5 V and 3.3 V in addition to local ceramic decoupling.

That is appropriate for a board with:

• high-current radio bursts;
• digital switching;
• microSD write transients;
• external loads.

The final capacitor values, voltage ratings, ESR and mechanical robustness still require BOM-level verification.

18.5 Power-good signal

The TPS56528 PG output is brought to the MCU-side net IO34 with a pull-up.

A future firmware implementation can use this to detect whether the 5 V regulator is in regulation.

That signal should be assigned an explicit STM32 pin/function name in the firmware documentation rather than leaving it as the design-time label IO34.

18.6 Power input through mounting-pad footprints

The PCB contains two plated mounting-hole-style pads:

• H1 connected to ground;
• H2 connected to Vin.

This appears to provide a mechanically strong power connection / mounting interface.

Because electrically live mounting hardware can create unexpected chassis or fastener paths, a future builder should explicitly decide whether this is still desired.

If ordinary metal mounting hardware is used, verify that H2 = Vin cannot accidentally contact a grounded structure.

19. USB-C interface

J6 is a 16-pin USB-C receptacle.

The implementation includes:

• 5.1 kΩ CC pull-down resistors;
• USBLC6-2P6 ESD protection;
• 22 Ω series resistors on D+ and D−;
• USB VBUS sensing/protection path;
• shield network.

Data mapping

Why USB-C?

USB is useful for:

• firmware development;
• configuration;
• bench data transfer;
• diagnostics;
• a future bootloader;
• powering the low-power sections during development.

The connector is implemented as a USB device/sink-style interface, not as USB Power Delivery.

20. microSD power filtering

The microSD socket does not simply connect its supply directly to the general 3.3 V rail.

A dedicated branch includes filtering and local capacitance.

That is useful because microSD cards can generate short current transients during writes. Isolating that disturbance reduces the chance that card activity contaminates sensitive sensor rails or causes MCU instability.

A future layout review should confirm the ferrite/inductor impedance selection and ensure the SD rail does not experience excessive voltage drop during peak card current.

21. Recovery / e-match output subsystem

The design contains four channels:

• J9
• J10
• J11
• J12

Each channel uses:

• a logic-level NMOS;
• a gate series resistor;
• a 100 kΩ gate pull-down;
• an SSR / PhotoMOS-style device;
• a current-limiting resistor on the SSR input side;
• a two-pin e-match connector.

The MCU control pins are:

Signal path

Conceptually, each channel is:

MCU GPIO
   │
 47 Ω
   │
 NMOS gate
   │
 NMOS pulls SSR input low
   │
 isolated / solid-state switch closes
   │
 Vin -> output connector -> external load -> GND

The 100 kΩ gate pull-downs are important because they bias the MOSFETs off while the MCU is unpowered, reset, or high-impedance.

Why use an SSR stage?

The intention was to put an electrically controlled isolation/switching stage between the MCU logic and the recovery-current path rather than asking the STM32 GPIO circuitry to interact directly with that high-current domain.

This also gives a clear point at which the recovery subsystem can be reviewed or replaced without redesigning the sensor system.

Critical unresolved issue: exact SSR

The current symbol/value is only:

aqz-ssr

That is not a complete manufacturer part number.

The exact device must be selected and verified for:

• output topology;
• DC voltage;
• repetitive current;
• pulse current;
• on-resistance;
• thermal rise;
• isolation rating;
• turn-on/off behavior;
• package/footprint.

Earlier system-level planning assumed that an initiator event could involve very high instantaneous current. The archived PCB does not demonstrate that the unspecified SSR can safely carry that pulse.

Do not infer current capability from the footprint.

Missing safety functions

This archive should not be treated as a complete recovery controller.

Before real use, review the need for:

• physical arming switch;
• independent remove-before-flight key;
• hardware inhibit;
• continuity measurement;
• current limiting/fusing;
• connector retention;
• accidental short protection;
• watchdog behavior;
• brownout behavior;
• reset behavior;
• firmware two-step arming;
• launch-detect qualification;
• output-state telemetry.

Initial testing should use resistive dummy loads only.

22. Analog video power consideration

The video input/output headers expose Vin, not merely the regulated 5 V rail.

This matters.

A future builder should check the voltage requirements of the intended camera and VTX before populating or connecting those headers.

Do not assume an external video device designed for 5 V should be connected to Vin.

The PCB net names must be checked directly during harness design.

23. Expansion headers

The board includes two large 2×25, 1.27 mm-pitch headers:

• J5
• J7

They expose a substantial fraction of the STM32 I/O and several power rails.

Why such large expansion headers?

The project was meant to remain useful for experimental avionics development.

The headers make it possible to add a mezzanine or wiring harness for:

• GNSS;
• additional magnetometer;
• external ADCs;
• CAN transceiver;
• RS-485;
• servo/actuator interfaces;
• additional radio;
• experimental sensors;
• vehicle-specific I/O.

They also make many MCU pins accessible for debugging.

J5 — notable signals

J5 contains:

• SPI1 signals;
• SPI2 signals;
• many GPIOs;
• repeated 3.3 V pins;
• repeated 5 V pins;
• Vin pins;
• ground.

Because multiple power voltages are adjacent on a fine-pitch connector, a future carrier board must use the exact pinout rather than assuming a generic GPIO-header pattern.

J7 — notable signals

J7 carries additional GPIO and a large number of ground pins.

The high ground-pin count is useful for:

• signal return paths;
• reduced connector inductance;
• daughterboard grounding;
• separating fast signals with ground references.

24. 5 V auxiliary connector

J8 is a 2-pin Molex Nano-Fit style connector carrying:

• ground;
• +5 V.

This provides a dedicated regulated auxiliary supply connection separate from the large expansion header.

Any external load should be included in the TPS56528 current and thermal budget.

25. PCB construction

The archived PCB is a 6-layer, 1.6 mm FR-4 design.

Approximate edge dimensions extracted from the KiCad board outline:

51.85 mm × 113.75 mm

The stackup stored in the KiCad PCB uses 35 µm copper on all six copper layers.

Copper layers:

F.Cu
In1.Cu
In2.Cu
In3.Cu
In4.Cu
B.Cu

The project contains substantial routing already; it is not an empty placement draft.

Why six layers?

For a board combining:

• fast MCU digital signals;
• several SPI buses;
• SDMMC;
• USB;
• switching power;
• RF;
• analog video;
• multiple MEMS sensors;
• high-current recovery outputs;

additional copper layers make it easier to preserve ground references, distribute power and keep routing manageable.

However, the inner layers are only named generically in the KiCad file.

Before fabrication, explicitly document which layers are intended as:

• continuous ground;
• power;
• signal;

and confirm the final stackup with the PCB manufacturer.

26. Placement considerations

A future layout review should pay special attention to:

Inertial sensors

• mechanical stiffness beneath the sensors;
• distance from mounting holes and board flex;
• distance from inductors and heavy components;
• consistent axis orientation documentation;
• local decoupling;
• uninterrupted ground reference.

Magnetometer

• distance from power inductor;
• distance from high-current recovery traces;
• distance from RF module;
• ferromagnetic hardware;
• external compass option.

Barometers

• enclosure vent path;
• protection from direct airflow;
• distance from heat;
• pressure equalization.

RF

• antenna feed geometry;
• ground stitching;
• keep-out;
• connector launch;
• nearby metal.

Switching regulator

• smallest possible switching-current loop;
• thermal pad;
• inductor/current path;
• separation from sensitive sensors.

Recovery outputs

• trace current capability;
• creepage/clearance;
• separation from analog/sensor areas;
• connector retention;
• return-current path.

27. Schematic hierarchy

The KiCad project is already divided into useful subsystem sheets.

pcb.kicad_sch
├── power.kicad_sch
├── connectors.kicad_sch
├── sensors.kicad_sch
├── untitled.kicad_sch          # recovery / relay channels
├── helper_processors.kicad_sch # MAX7456 OSD
└── rf.kicad_sch                # LoRa radio

For a future cleanup, untitled.kicad_sch should be renamed to something descriptive such as:

recovery_outputs.kicad_sch

Do the rename from inside KiCad or update the hierarchical-sheet references carefully.

28. Known source-tree issues

28.1 Schematic/PCB value mismatch

The recovered files contain at least two component-value mismatches between schematic and PCB metadata:

These may be the result of editing values directly in PCB Editor after the last schematic-to-PCB update.

Reconcile these before generating a BOM or Gerbers.

28.2 Custom footprint-library references

The PCB includes footprints referenced from custom libraries such as:

• Library-kicad
• PCM_JLCPCB

Examples include:

• E22-900M30S;
• AQZ SSR;
• MAX7456 package;
• custom SOT-323 MOSFET pin order;
• USB-C receptacle;
• thermistor footprint;
• SS34 footprint.

The geometry of placed footprints is stored inside the .kicad_pcb, so the layout can still be inspected.

However, a fresh installation may not be able to reassign or update those footprints unless the original libraries are recreated or the footprints are copied into this repository.

A contributor should create a project-local library, for example:

hardware/
└── footprints/
    └── HUMA.pretty/

and migrate every nonstandard footprint into it.

28.3 Generic / incomplete part definitions

Several components still need exact MPNs, including especially:

• ADXL37x exact variant;
• AQZ SSR exact variant;
• N-channel MOSFET exact type;
• NTC thermistors;
• some passives where voltage/power/package rating matters;
• exact USB-C connector ordering code;
• antenna connector;
• crystal part numbers.

A reproducible BOM must contain:

• manufacturer;
• manufacturer part number;
• package;
• value;
• tolerance;
• voltage/current rating;
• preferred supplier;
• approved alternate where appropriate.

29. Firmware architecture that matches the hardware

No firmware is included in this archive.

A clean continuation should avoid starting with one giant main.c.

A possible architecture is:

firmware/
├── Core/
├── drivers/
│   ├── lsm6dso32/
│   ├── adxl373/
│   ├── iis3dwb/
│   ├── ms5611/
│   ├── lis3mdl/
│   ├── e22_sx1262/
│   └── max7456/
├── acquisition/
│   ├── timestamp.c
│   ├── sensor_scheduler.c
│   └── health_monitor.c
├── logging/
│   ├── record_format.c
│   ├── ring_buffer.c
│   └── sd_writer.c
├── telemetry/
│   ├── packet.c
│   └── radio.c
├── flight/
│   ├── state_machine.c
│   └── estimator.c

30. Timing and acquisition strategy

A good implementation should use one monotonic hardware timebase for the entire system.

Each sensor sample should be associated with a timestamp from the same clock domain.

Where possible:

• use sensor DRDY interrupts;
• use FIFO watermark interrupts;
• use DMA for SPI transfers;
• avoid polling loops;
• avoid filesystem writes in interrupts;
• timestamp the event as close to acquisition as practical.

For very high-rate sensors, distinguish between:

• sample time;
• time transferred from FIFO;
• time written to SD.

They are not the same.

31. Data integrity

Each stored block should ideally contain:

• format/version identifier;
• block type;
• sequence number;
• timestamp;
• payload length;
• payload;
• checksum/CRC.

This allows a partially corrupted SD file to be scanned and recovered.

A power loss during landing should not make all earlier flight data unreadable.

32. Watchdog and safe-state philosophy

The flight computer should be designed under the assumption that software can crash.

A future implementation should use:

• independent watchdog;
• brownout handling;
• reset-reason logging;
• explicit startup self-test;
• sensor timeout detection;
• recovery-output safe defaults.

A reset must never automatically activate an output.

The GPIO pull-downs in the recovery driver are a useful hardware starting point, but system safety cannot rely on those resistors alone.

33. Sensor health and voting

Rather than returning only a single fused IMU value, the health layer should maintain something like:

IMU1:
    present
    self_test_ok
    timestamp_age
    fifo_overflow_count
    saturation_flags
    temperature
    bias_estimate

IMU2:
    ...

BARO1:
    ...

BARO2:
    ...

The estimator can then decide which sensors to trust.

This makes post-flight debugging far easier than silently discarding a sensor.

34. Suggested flight-state architecture

A possible state machine is:

BOOT
  ↓
SELF_TEST
  ↓
SAFE
  ↓
ARMED
  ↓
LAUNCH_DETECTED
  ↓
POWERED_ASCENT
  ↓
COAST
  ↓
APOGEE / RECOVERY_EVENT
  ↓
DESCENT
  ↓
LANDED

This is only an architectural example.

Actual event logic, thresholds and any recovery actuation must be independently designed, simulated, reviewed and ground-tested.

35. What should be tested first?

Do not populate everything and immediately connect a rocket battery.

A much safer continuation sequence is below.

Stage 1 — source cleanup

• open the project in KiCad 9;
• repair missing library references;
• reconcile schematic/PCB values;
• select exact MPNs;
• run ERC;
• run DRC;
• inspect all unconnected pins;
• compare every critical IC against its latest datasheet.

Stage 2 — power review

Before fabrication:

• recalculate TPS56528 feedback values;
• check inductor current rating;
• check input/output capacitor requirements;
• calculate 3.3 V LDO dissipation;
• review USB/main-power interaction;
• review ground returns;
• review recovery-current paths.

Stage 3 — manufacture a non-pyrotechnic prototype

Initially leave recovery outputs unconnected from any live initiator.

Bring the board up on a current-limited bench supply.

Verify:

• no shorts;
• Vin;
• 5 V;
• 3.3 V;
• regulator temperature;
• power-good behavior.

Stage 4 — MCU bring-up

• verify SWD;
• identify the MCU;
• test reset;
• test oscillator;
• run basic GPIO;
• validate USB.

Stage 5 — one sensor at a time

Recommended order:

1. one LSM6DSO32;
2. second LSM6DSO32;
3. one MS5611;
4. second MS5611;
5. LIS3MDL / replacement;
6. high-g accelerometer;
7. IIS3DWB;
8. thermistor ADC channels.

Only after every device works independently should simultaneous high-rate logging be attempted.

Stage 6 — microSD

• test card initialization;
• test SDMMC width/speed;
• sustained write test;
• random power-loss test;
• filesystem recovery;
• buffer-overrun logging.

Stage 7 — telemetry

• low-power conducted bench test first;
• packet integrity;
• receive sensitivity;
• power-rail droop during TX;
• current measurement;
• antenna/VNA checks;
• legal power/frequency configuration;
• range test.

Stage 8 — OSD

Use a bench composite-video source and display.

Verify:

• video pass-through;
• sync stability;
• NTSC/PAL configuration;
• OSD updates;
• analog-ground behavior.

Stage 9 — environmental sensing tests

• static calibration;
• temperature sweep if possible;
• vibration test;
• shock/inertial comparison;
• barometer chamber or controlled altitude test.

Stage 10 — recovery-output validation

Only with dummy loads:

• verify power-off state;
• verify reset state;
• verify boot state;
• verify watchdog reset;
• verify single-channel command;
• verify no cross-channel activation;
• measure switch voltage/current;
• test open and shorted loads;
• test power interruption.

A live initiator should only be considered after the electronics and safety architecture have passed an independent review.

36. Suggested continuation priorities

If I were continuing the original design from this archive, I would prioritize the work in this order:

Priority 1 — make the source reproducible

• local footprint library;
• exact BOM;
• exact MPNs;
• no schematic/PCB mismatches;
• tagged KiCad revision.

Priority 2 — resolve processor choice

Decide whether to retain STM32H750 or migrate to an STM32H753/H743-family part with more internal Flash.

Do this before firmware development becomes large.

Priority 3 — validate the power tree

The radio and 3.3 V thermal budget can decide whether the rest of the board is viable.

Priority 4 — finish sensor architecture

Resolve:

• exact high-g part;
• magnetometer replacement;
• whether a second compass is onboard or external;
• whether both MS5611s remain the preferred choice.

Priority 5 — review recovery hardware from first principles

Do not inherit the current SSR choice merely because it is already routed.

Priority 6 — build the logging firmware

A reliable black-box recorder is more valuable than immediately implementing complex flight algorithms.

Priority 7 — add telemetry and OSD

These should sit on top of a stable local acquisition/logging system.

37. Recommended repository structure

The recovered archive currently consists almost entirely of KiCad files.

For a maintainable GitHub project, reorganize it as:

HUMA-Rocket-Flight-Computer/
├── README.md
├── LICENSE
├── .gitignore
│
├── hardware/
│   ├── kicad/
│   │   ├── pcb.kicad_pro
│   │   ├── pcb.kicad_sch
│   │   ├── pcb.kicad_pcb
│   │   ├── power.kicad_sch
│   │   ├── connectors.kicad_sch
│   │   ├── sensors.kicad_sch
│   │   ├── recovery_outputs.kicad_sch
│   │   ├── helper_processors.kicad_sch
│   │   └── rf.kicad_sch
│   │
│   ├── footprints/
│   │   └── HUMA.pretty/
│   │
│   ├── bom/
│   │   └── BOM.csv
│   │
│   └── manufacturing/

Do not move/rename hierarchical schematic files carelessly; preserve a working commit before reorganizing.

38. Reproducibility checklist

The project should not be labelled "reproducible" until another person can start from a clean machine and do all of the following:

• Clone the repository.
• Open the KiCad project without missing libraries.
• Run ERC without unexplained errors.
• Run DRC without unexplained errors.
• Generate the BOM.
• Generate Gerbers and drill files.
• Order every component by exact MPN.
• Identify every connector and mating part.
• Assemble the board.
• Program the MCU over SWD.
• Run a documented bring-up sequence.
• Reproduce sensor tests.
• Reproduce power measurements.
• Reproduce SD logging tests.
• Reproduce radio tests.
• Reproduce dummy-load recovery-output tests.

39. Known issues / open questions

This is the section a future contributor should read before touching the design.

• Board has never been manufactured/validated in this revision.
• STM32H750 versus later STM32H753-family direction must be resolved.
• Exact high-g accelerometer must be frozen.
• LIS3MDL is now obsolete.
• Archived board contains one magnetometer although later architecture targeted two.
• MAX7456 is obsolete.
• Exact AQZ SSR part is not defined.
• Recovery-channel pulse-current capability is unverified.
• No complete hardware arming architecture is documented.
• Thermistor MPN/calibration is undefined.
• U2 exact MCP1826S package must be checked against the TO-220 footprint.
• C5/C6 schematic-vs-PCB values must be reconciled.
• Exact crystal MPN/load calculation must be verified.
• Inner-layer roles should be documented.
• RF trace/connector impedance should be reviewed using the final fab stackup.
• GNDA strategy should be reviewed with real external camera/VTX grounding.
• USB and main-power simultaneous-connection behavior should be validated.
• Full 5 V peak-current budget should be calculated.
• 3.3 V LDO thermal budget should be calculated.
• microSD sustained-write performance is untested.
• No firmware is included.
• No released BOM exists.
• No manufacturing package exists.
• No test results exist.
• No calibration data exists.
• No flight data exists.

40. Component-status notes for a new revision

As of the 2026 reconstruction of this repository:

• STM32H750 remains listed by ST as an active product.
• LSM6DSO32 remains active.
• IIS3DWB remains active.
• ADXL373 remains in production at Analog Devices.
• TPS56528 remains active at Texas Instruments.
• MCP1826S remains in production at Microchip.
• LIS3MDL is listed by ST as obsolete.
• MAX7456 is listed by Analog Devices as obsolete.

Always check current manufacturer status before ordering; this list will age.

41. Datasheet / reference links

MCU

• STM32H750VB
  https://www.st.com/en/microcontrollers-microprocessors/stm32h750vb.html

Main IMUs

• LSM6DSO32
  https://www.st.com/en/mems-and-sensors/lsm6dso32.html

Vibration sensor

• IIS3DWB
  https://www.st.com/en/mems-and-sensors/iis3dwb.html

High-g accelerometer

• ADXL373
  https://www.analog.com/en/products/adxl373.html

Magnetometer

• LIS3MDL
  https://www.st.com/en/mems-and-sensors/lis3mdl.html

Pressure sensor

• MS5611 family
  https://www.te.com/en/product-MS561101BA03-50.html

LoRa

• E22-900M30S
  https://www.ebyte.com/product/451.html

OSD

• MAX7456
  https://www.analog.com/en/products/max7456.html

5 V buck

• TPS56528
  https://www.ti.com/product/TPS56528

3.3 V LDO

• MCP1826S
  https://www.microchip.com/en-us/product/mcp1826s

42. Contributing

This repository is being published specifically because the original project stopped before completion.

Contributions are welcome in areas such as:

• schematic review;
• PCB review;
• power integrity;
• RF review;
• component replacement;
• BOM cleanup;
• footprint cleanup;
• STM32 firmware;
• sensor drivers;
• deterministic logging;
• telemetry protocol;
• log-decoding tools;
• simulation;
• test fixtures;
• hardware safety;
• documentation.

For meaningful hardware changes, please document:

1. what was changed;
2. why it was changed;
3. which hardware revision was tested;
4. what measurements were taken;
5. what remains unverified.

A change that "looks right" in KiCad should not be described as validated until hardware evidence exists.

43. Suggested issues for the GitHub issue tracker

Useful first issues would be:

[HW] Reconcile C5/C6 schematic and PCB values
[HW] Verify MCP1826S package / footprint
[HW] Select exact ADXL37x device and update symbol/BOM
[HW] Replace obsolete LIS3MDL
[HW] Decide H750 vs higher-Flash STM32H7
[HW] Review six-layer stackup and inner-plane assignment
[POWER] Validate 5 V rail worst-case load
[POWER] Validate 3.3 V LDO thermal performance
[RF] Validate E22 antenna feed and connector
[OSD] Replace or remove obsolete MAX7456
[RECOVERY] Redesign/review four output channels and hardware arming
[PCB] Move custom footprints into project-local library
[FW] Initial STM32Cube project and SWD bring-up
[FW] LSM6DSO32 dual-IMU driver
[FW] Binary log format + SDMMC writer
[FW] Sensor health / voting layer
[FW] SX1262/E22 telemetry driver
[TOOLS] Python flight-log decoder
[TEST] Power-up and rail validation procedure
[TEST] Sensor vibration/shock characterization

44. License

The recovered archive does not contain an explicit open-hardware license.

If the intention is genuinely to allow other people to continue, modify and manufacture the hardware, add a clear license before public release.

A suitable option for permissive open hardware is:

CERN Open Hardware Licence Version 2 — Permissive (CERN-OHL-P-2.0)

Firmware can be licensed separately, for example under MIT or another appropriate software license.

Do not simply write "open source" without including an actual license file; without a license, reuse rights are unclear.

45. Project status

What exists

• multi-sheet KiCad schematic;
• substantially routed six-layer PCB;
• STM32H7 processor architecture;
• dual main IMUs;
• high-g sensor interface;
• high-bandwidth vibration sensor;
• dual barometers;
• magnetometer;
• five temperature channels;
• microSD;
• USB-C;
• SWD/JTAG;
• E22 LoRa module;
• MAX7456 OSD;
• four recovery output circuits;
• large expansion headers.

What does not yet exist as a validated release

• manufactured/verified revision;
• finalized BOM;
• released fabrication package;
• firmware;
• calibration;
• bench-test report;
• RF-test report;
• environmental-test report;
• flight test.

46. Final note

HUMA stopped because the available budget could no longer support completing and validating the hardware, not because the design had reached a finished state.

I am publishing the work at the point where it stopped so that the engineering effort is not lost.

If you want to continue it, the most useful contribution is not simply ordering the existing PCB unchanged. Start by reviewing the open issues, making the source reproducible, checking the power and recovery sections, updating obsolete components, and then build a controlled bench prototype.

If this project becomes a working flight computer in someone else's hands, that is exactly why this repository exists.

Original designer

Taylan ARSLAN
Original project: HUMA / UCLR Rocket Flight Computer