Bill of materials

Same silicon as the Board path. That is the whole selection rule for the Modules path and it is worth stating plainly: the RP2350 on the custom board and the RP2350 on this module run one firmware build, so there is one thing to document, one thing to test, and no class of bug that only appears on one of the two paths. A cheaper or lighter module carrying different silicon would double the project's work forever to save a few grams once. It is also the reference board for the part, which means its schematic is published, its bootloader behaviour is the documented one, and a beginner searching for help finds answers about the exact thing in their hand.

Unverified: weigh it, price it, and confirm the pin header footprint the mounting page assumes. Held at confidence unverified on purpose: module product numbers and the boards behind them change without notice, which is why this repository never asserts them.

Also search:LCSCAdafruitSparkFun

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.

Unverified: the RMS noise in Pa at the oversampling and output data rate oApogee configures, from the datasheet, converted to metres of altitude noise at sea level. A headline noise figure with no configuration beside it is not the same number. Also the usable pressure range and the altitude it corresponds to.

Unverified: price, mass, and whether those pull-ups duplicate a pair already fitted on the carrier. The barometer is the only part on the I2C bus, so the failure to look for is a second pair, not several. The product exists and is stocked; none of those numbers is measured.

Also search:LCSCAdafruitSparkFun

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.

Availability:

Buyable as a chip and awkward as a breakout. Searched 2026-08-13: neither Adafruit nor SparkFun sells an ICM-42688-P breakout, and the only assembled board either carries is a MikroElektronika Click. That does not affect the Board path, where the chip is soldered directly. It decides the Modules path, where you need something already assembled, and it is why the substitute below is the recommendation there rather than a fallback.

Unverified: confirm the selectable full-scale ranges and the gyro noise density from the datasheet, and state which range oApogee configures.

Unverified: confirm the Click board exposes SPI and a usable chip select, because the Board path puts this part on SPI and a Modules build that could only reach it over I2C would mean the two paths no longer share one electrical design.

Also search:LCSCAdafruitSparkFun

Optional at every tier, including Solo, because whether a general purpose IMU saturates depends on the motor and not on whether the board has a radio on it. Tying it to Link put the part behind a capability it has nothing to do with, and left the cheapest build, whose entire value is the logged flight profile, as the one most likely to record a boost phase that is silently wrong. 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.

Unverified: two numbers, and neither alone decides anything. First, the ADXL375 full-scale range and bandwidth, and the full-scale range oApogee configures on the ICM-42688-P, each quoted from its datasheet with the table cited. Second, the peak acceleration of a representative loaded airframe on a C, D and E motor from OpenRocket, so the motor class at which the 6-axis IMU saturates is derived rather than asserted.

Unverified: identify a currently-stocked ADXL375 breakout and record whether it exposes SPI and a usable chip select. The Board path puts this part on SPI sharing the IMU's bus. If no SPI-capable breakout can be sourced, the two paths no longer share a bus assignment, and the "Same electrical design, two ways to fabricate it" note at the head of this file has to be amended.

Also search:LCSCAdafruitSparkFun

The same MAX-M10S the Board path uses, so the configuration the firmware sends at startup is identical and the fix behaviour a builder sees on one path is the behaviour they get on the other. This breakout carries a backup cell, which is what makes a warm start possible: without one every power cycle is a cold start, and a cold start on the pad is minutes of waiting with a rocket already on the rail.

Unverified: confirm it acquires a fix through the airframe wall rather than only in open sky, and time a cold start on the pad. Those two numbers decide the pad procedure, and neither can come from a datasheet. Weigh and price it at the same time.

Also search:LCSCAdafruitSparkFun

Carries the same SX1262 as the Board path, for the same reason the microcontroller does: one radio driver, one set of settings, one link budget to explain. A module with a different transceiver would need its own driver and would quietly become a second project. The module form rather than a bare breakout because it arrives shielded and with a matching network already laid out. Radio layout is the part of this design least forgiving of a beginner's first PCB, and the Modules path exists precisely to let somebody skip that.

Unverified: confirm the regulatory position before publishing a build that transmits. A module carrying its own approval does not make a finished payload approved, and the answer differs by country. Also weigh it, price it, and measure its range against the Board path.

Also search:LCSCAdafruitSparkFun

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. It is listed separately from the connector it plugs into because the connector is settled and this is not.

Unverified: choose between a tuned wire monopole and a flexible PCB antenna, measured. Publish the wire length as a trimmed figure with the ground plane it assumes rather than a textbook calculation, which is not what works in a body tube. Also whether a carbon fibre or metallic airframe blocks the link.

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

Unverified: measure the current draw of each tier in each flight state and size the cell from that rather than from the brief's assumed range. Report endurance as pad-idle hours plus post-landing beacon hours. Confirm the cell ships with a protection circuit: unprotected cells are common and must not be recommended.

Decided: the Modules path does need one. The Raspberry Pi Pico 2 has no charger and no battery connector, so without this the Modules path is a payload that has to be disassembled to charge, which is worse than the thing it is trying to be simpler than. It carries the MCP73831 the Board path uses, so the charge behaviour, the status light and the safe way to treat the cell are one explanation rather than two.

Unverified: confirm the charge current the board ships with suits the cell, and change the programming resistor if it does not. Weigh and price it with the rest.

Also search:LCSCAdafruitSparkFun

The flight state machine's first transition is operator-driven, and without an input there is no flight: arming is what starts the pressure reference settling and the pre-arm ring buffer. It sits on a GPIO rather than in the power path, because oApogee is passive, so cutting power arms nothing and protects nobody. What the operator needs is to power the payload up, let the GNSS get a fix and the barometer settle, and then arm it once the rocket is on the rail, which a power switch cannot express. Mechanical rather than magnetic. The sealed-enclosure argument for a reed or Hall sensor does not survive contact with this design, because the pod is deliberately vented: it has static ports cut through it and must have. That leaves a magnetic switch trading an inspectable state for one anything magnetic in a range box can change, and arm state is exactly what an operator has to confirm by eye at the pad. A slide switch shows its position from across a table. SPDT rather than SPST, and only one throw is wired. The common pin goes to the GPIO, one throw goes to ground, and the other is left open so the internal pull-up defines the pin. Driving the spare throw to 3V3 would look tidier and give a defined level in both positions, but a slide switch is open for a moment as the wiper crosses, so the pin would float briefly on every throw and the firmware would have to debounce a state it could otherwise trust.

Needs hardware: a slide switch is the one part on this board that can be moved by the flight rather than by the operator. Shake the built payload on all three axes and drop it from waist height onto carpet, and confirm the switch is in the position you left it in. If it is not, the answer is a detent cover or a screw switch, not a note in the manual.

Also search:LCSCAdafruitSparkFun

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

Unverified: confirm the cell's connector polarity matches. LiPo cells ship with both polarities and reversing one destroys the board. State the check explicitly in the build guide.

Also search:LCSCAdafruitSparkFun

On a Solo build with no radio, the buzzer is the only recovery aid there is. It earns its mass. Piezo rather than magnetic, and that is a wiring decision as much as an acoustic one. A piezo element is capacitive: it draws single-digit milliamps, produces no back-EMF, and a microcontroller pin can drive it directly. A magnetic buzzer is a coil, which means tens of milliamps, a transistor to carry them, and a flyback diode to catch the spike when the pin turns off. That is three more parts and one more failure mode on the one output the whole recovery story depends on. Externally driven rather than self-oscillating, which is the other half of the same choice. A self-driving buzzer makes one note for as long as it has power. This one is silent until the firmware plays it, so the beacon pattern, the arm confirmation and the fault codes are all the same part making different sounds. Needs hardware: if it is not loud enough, the next move is a second pin driving the other terminal in antiphase, which doubles the voltage across the element for the cost of one pin and no parts. That is worth measuring before it is worth building.

Unverified: not the datasheet sound pressure level, but the distance at which the beacon pattern is findable in tall grass on a windy day. Somebody hides an active unit in a field and the search is timed. Then weigh and price it with the rest.

Also search:LCSCAdafruitSparkFun

Three ordinary LEDs in one package, driven by three pins through three resistors, rather than an addressable part driven by one. This was specified as an addressable RGB LED, and that is wrong for this board. The WS2812 family and its clones want a supply above what this payload has: the only rail here is 3V3 and those parts specify a minimum higher than that. Running one under its minimum gives an LED that works on the bench for the person who tested it and does something else cold, or at the bottom of a discharge. The related trap is worth writing down because it is the one people meet coming the other way: an addressable LED on 5 V needs its data line above 0.7 of its supply, which a 3V3 pin does not reach. Neither problem exists once the part is three plain LEDs. The cost is two more pins and two more resistors. The microcontroller has pins to spare, and the firmware loses a timing-critical bit-banged protocol, which on a payload that is busy during boost is a gain. Arm state has to be readable from a few metres while the rocket is on the pad and you are walking back. That is the whole requirement.

Unverified: select a specific part and confirm it is readable in daylight from several metres, which is the only test that matters for an arm indicator. Then set the three series resistors from its per-colour forward voltages, which differ, and are the reason the three values may not come out the same.

One pulls the arming input up so it reads as a level rather than as noise, because an input that reads as noise arms a rocket at random. The other two divide the cell voltage into the ADC's range: a single cell reaches 4.2 V, which is above the 3V3 rail, and the packet format transmits a battery voltage that nothing on the board could otherwise measure.

Unverified: size the battery sense divider against the microcontroller's ADC input impedance and its acceptable source impedance, and decide whether it needs switching off between readings so it does not drain the cell through a long pad wait. 100k is a starting point, not a result.