Open source rocket telemetry
A small, cheap sensor package that tells you exactly what your model rocket did.
oApogee records altitude, acceleration and orientation through the whole flight, logs it onboard, and can send it live to a receiver on the ground. It attaches to a rocket you already own.
Armed
The ground reference settles, the ring buffer runs, and the payload waits for motion. The status LED and buzzer say so from several metres away.
Diagram of the flight state machine, not recorded data.
Everything you need is here
The hardware is commodity. The documentation is the product, and it is written to be followed start to finish by somebody who has soldered before and never written firmware.
Every step, with an observable checkpoint and a link to the failure branch when a checkpoint does not pass.
Every part, by tier and by build path, with why each was chosen and what substitutes for it.
The circuit as code. Drawing, netlist, circuit JSON and a KiCad schematic, all from one source.
The packet and log formats, specified well enough to write your own receiver against.
Printable, one action per line, ordered by when it happens rather than by subsystem.
Organised by what you saw, not by which component failed, because that is what you know.
Nothing has been fabricated or flown yet, so the site carries no prices, masses or ranges: those are measurements and they have not been taken. The PCB is laid out and routed, and its fabrication package is held back while the board has an open blocker. What is open.
The whole payload, one sheet
Four sensors onto one microcontroller, the log written to flash that is soldered down rather than to a card that can shake loose, and one connector for power, charging, configuration and offload. The circuit, in full.
Three tiers, one board
Every tier is the same PCB, the same firmware, and the same enclosure. Moving up a tier means populating footprints that were already there, not building a new payload. Nobody who starts with Solo has to start over.
Needs hardware: this is currently a design intention, not a demonstrated fact. It is only true if the Solo build populates every shared footprint and leaves the radio and GNSS sections genuinely optional, including their supply decoupling and any shared bus pull-ups. Confirm on the first fabricated board by populating a Solo, flying it, then upgrading that same physical unit to Link and flying it again. Until that has happened, the site states this as an intention.
oApogee Solo
Barometer, IMU, onboard logging. No radio.
A first build, a classroom set, and anyone who wants a flight profile rather than a live readout.
oApogee Link
Live telemetry downlink to a ground station.
Club flights where people want to watch the number climb, and any flight where losing the payload would mean losing the data.
A Link payload is not usable on its own. Budget for the ground station, which is a separate build and a separate bill of materials.
oApogee Track
GNSS position for long walkaway recovery.
Big fields, windy days, tall crops, and anything with a long descent.
What it will not do
oApogee is a passive instrumentation payload. It watches the flight and records it. It does not act on the rocket. Deployment control is the domain of certified high power rocketry, it carries a completely different set of failure consequences, and it is out of scope. If a payload that fires charges is what you need, oApogee is not that and will not become that.
Safety and rules