Bill of materials

RP2350 microcontroller

Drag-and-drop UF2 flashing means a beginner installs no toolchain to get a working payload: the board appears as a USB drive and you copy a file onto it. That single property removes the most common place a first-time builder gives up. Beyond that, the part is cheap, the community is large, and the PIO blocks give clean timing-critical IO without burning CPU.

RP2350 or RP2040 development module

The Modules path needs a carrier that already solves USB, the 3V3 rail, and the boot button, so the builder's soldering is limited to sensor connections.

QSPI NOR flash

Onboard flash with LittleFS, soldered down. There is no microSD socket on this design and that is a deliberate decision, not an omission. A microSD card is held in its socket by a friction detent, and boost acceleration on even a modest motor is enough to unseat one. In DIY flight computers the card socket is the single most common in-flight failure point, and its failure mode is the worst one available: the flight proceeds normally and the data is simply gone. A soldered part cannot unseat. The cost is that offloading data requires plugging in USB rather than moving a card, which is a mild inconvenience on the ground in exchange for removing a failure mode in the air.

BMP390 barometric pressure sensor

Altitude is the number this entire project exists to produce, so the barometer is the one part not to economise on. Resolution here sets the resolution of the apogee figure.

6-axis IMU, accelerometer and gyroscope

Orientation, and the vertical acceleration channel that the sensor fusion integrates to cover for the barometer during the pressure disturbance around burnout and, on faster flights, transonic effects.

High-g accelerometer

A general purpose IMU has a full-scale range, and boost acceleration can exceed it. When an accelerometer saturates it does not report an error, it reports its maximum value for as long as the real acceleration is higher. The result is a boost phase that looks like a flat plateau sitting exactly at the full-scale limit, which is not merely imprecise, it is wrong in a way that looks plausible. Integrating that flat top underestimates velocity, which propagates into every fused altitude estimate during the part of the flight the fusion is most needed. A dedicated high-g part exists solely so the boost data means something. The full-scale range and the motor class at which the 6-axis IMU actually saturates are recorded in the verify note on this part and are deliberately not stated here.

SX1262 LoRa transceiver

LoRa trades data rate for link budget, which is exactly the trade a telemetry downlink wants: the packets are small and infrequent, and the requirement is that they arrive from far away through a rocket body tube at an unfavourable angle.

Region: 902 to 928 MHz for US builds under FCC Part 15. 863 to 870 MHz for EU and UK builds. This is a hardware selection issue as well as a firmware one, because the matching network and antenna are tuned per band. See the Safety and rules page.

SX1262 module

A pre-certified module removes both the RF layout risk and most of the regulatory burden from a first-time builder.

902 to 928 MHz antenna, airborne side

The antenna is the cheapest part on the board and the one most able to ruin the link. It gets its own treatment on the Ground station page.

u-blox M10 GNSS receiver

Position for recovery. The value is not the flight track, it is the last fix before the signal is lost, which turns a search into a walk.

Gotcha: u-blox receivers ship with a dynamic platform model that assumes ground vehicle behaviour and will reject the position solution under rocket accelerations, losing lock exactly when it is needed. The airborne model must be configured explicitly at startup, and the configuration must be saved or reapplied on every boot. This is the single most common reason a GNSS-equipped model rocket payload comes back with no track. Also document the CoCom velocity and altitude limits, note that they are not reachable at the altitudes oApogee targets, and note that they will matter to anyone scaling this design up.

1S LiPo cell with protection circuit, 150 to 250 mAh

Single cell keeps the power design trivial and the mass low. Protection circuit is not optional, see the Safety and rules page.

LiPo charge controller

USB-C in, charge and run from the same connector, nothing to remove from the airframe to top the battery up between flights.

3V3 regulator

The rail everything else runs from. It is called out separately rather than hidden inside the microcontroller row because the choice between buck, boost, and buck-boost is decided by the cell chemistry, and getting it wrong shows up as a payload that dies at 60 percent battery.

USB-C receptacle

One connector for power, charging, configuration, and data offload. No programming header, no card slot, no second cable to lose.

JST-PH 2.0 mm right-angle header, 2 position

The de facto standard for small LiPo cells, so a replacement is easy to buy anywhere.

Piezo buzzer

On a Solo build with no radio, the buzzer is the only recovery aid there is. It earns its mass.

Addressable RGB LED

Arm state has to be readable from a few metres away while the rocket is on the pad and you are walking back to the flight line. That is the whole requirement.