Skip to content
oapogeev0.1 design stage

Status

What is written, what has been reviewed, and how much of this site is still unmeasured.

oApogee never publishes a number it has not measured or sourced. That rule only means something if the gaps are countable, so this page counts them, from the content files rather than from a list somebody maintains by hand.

Pages live
21 of 21
Pages verified
0
Needs a source
79
Needs hardware
22

What each status means

draft
Written. Nobody has checked it. Read the primary sources it links to.
needs-review
The author believes it is right and wants a second opinion.
verified
A human with the relevant expertise checked every number and every step on real hardware. Nothing reaches this while it still has open markers.
generated
Rendered from structured data rather than written prose. Its accuracy is the data file’s, and the build fails if the data stops resolving.

Every page

PageStatusOpen markersUpdated
Home
/ . data/tiers.yaml, data/flight-phases.yaml
generated..
About
/about . content/about.md
draft12026-08-11
Bill of materials
/bom . data/bom.yaml, data/system.yaml
generated..
Build guide
/build . content/build.md
draft82026-08-11
Changelog
/changelog . CHANGELOG.md
generated..
Reading your data
/data . content/reading-your-data.md
draft32026-08-11
FAQ
/faq . content/faq.md
draft12026-08-11
Firmware
/firmware . content/firmware.md
draft102026-08-11
Flight log
/flights . data/flights.yaml
generated..
Glossary
/glossary . data/glossary.yaml
generated..
Ground station
/ground-station . content/ground-station.md
draft52026-08-11
Mounting
/mounting . content/mounting.md
draft62026-08-11
Preflight checklist
/preflight . data/preflight.yaml
generated..
Reference
/reference . content/reference.md
draft52026-08-11
Log format spec
/reference/log-format . docs/spec/log-format.md
draft52026-08-11
Schematic
/reference/schematic . hardware/oapogee.tsx
generated..
Telemetry packet spec
/reference/telemetry-packet . docs/spec/telemetry-packet.md
draft32026-08-11
Safety and rules
/safety . content/safety.md
draft112026-08-11
Start here
/start . content/start-here.md
draft12026-08-11
Status
/status . every page in this table
generated..
Troubleshooting
/troubleshooting . data/troubleshooting.yaml
generated..

Why so much is missing

The hardware is a design on paper. Nothing has been fabricated, assembled, weighed, priced, or flown. Each of the 110 markers below is a place where a specific number was deliberately left out rather than guessed at, and each records what evidence would close it.

This list is read from the content files when the site is built, so it cannot go stale. Closing one means doing the measurement, not editing an index.

Every open question

Needs a source or a measurement

A number, price, link, or claim that is absent rather than guessed. Each says what evidence would close it.

content/build.md
  • L34say how long this build actually takes, and whether it is realistically one sitting or two, once `build_time_estimate` in `data/tiers.yaml` is filled from timing people who have soldered before. The brief's "an evening" is a target, not a measurement.
  • L167state the acceptable voltage range at this checkpoint, from the chosen regulator's datasheet.
content/faq.md
  • L88two separate ceilings, and readers will conflate them. The barometer has a usable pressure range that corresponds to some altitude, and the radio has a practical range that is usually the lower limit in practice. Both need stating with their conditions.
content/firmware.md
  • L99state the settling window duration, and state the altitude error you get if you arm and walk away immediately.
  • L178choose the confirmation count from measured barometer noise, and publish the resulting lag in milliseconds.
  • L196measure the beacon endurance from landing detect to cell cutoff, per tier, on a fully charged cell after a full flight. That is the number that decides whether a payload is still findable the next morning.
  • L217confirm the specific configuration messages required, and confirm by flight that lock is retained through boost once they are applied.
content/ground-station.md
  • L96compare a quarter wave whip against a small directional antenna, measured, and publish both ranges so a reader can decide whether carrying the directional one is worth it.
  • L102the entire range claim. This is the number readers most want and the number most often exaggerated in this hobby, so it gets measured or it does not get published.
content/mounting.md
  • L48measure the altitude penalty of the pod against the same rocket and motor flown without it, several times each, and publish both the mean and the spread. This is the number that decides whether the pod is worth it and it should come from flights rather than from simulation alone.
  • L91publish the port diameter and count oApogee recommends, along with the reasoning that produced them. The rule of thumb in hobby rocketry relates total vent area to the enclosed volume, and this site should state the specific rule it is using, cite where it comes from, and show the arithmetic for the standard sled and pod volumes rather than quoting a number with no derivation. Then confirm it by flying the same rocket with two different port configurations and comparing.
  • L129state the caliber margin oApogee recommends, quoted from NAR or Tripoli guidance with a citation rather than asserted from memory. This is a safety number and it does not get a rule of thumb from an anonymous website.
  • L135work a complete example. Take a named, commonly available kit, state its published stability margin unloaded on a specific motor, then show the same rocket in OpenRocket with an oApogee pod at two different positions, one sensible and one badly chosen, with the resulting margins and what each means. Include the OpenRocket file so a reader can open it rather than trusting a screenshot.
  • L147publish a table of apogee against payload mass for A, B, C, D and E motors on a representative airframe, generated from OpenRocket and checked against at least one real flight per motor class. A reader deciding between Solo and Track deserves to see what the extra mass costs them before they order.
content/reading-your-data.md
  • L55this section needs a real flight. It is written as the structure of the walkthrough, with each feature described in terms of what causes it, and it must be replaced by an annotated plot of an actual oApogee flight with each feature marked on the real curve. A synthetic illustration would defeat the purpose of the page.
  • L180a complete walkthrough of one real oApogee flight, with the actual data file published alongside so a reader can follow along in their own tools. Every feature above marked on the real curve. This page is not finished until that exists, and it will not be faked in the meantime.
content/reference.md
  • L50every threshold marked N above is unset. They must come from measured sensor noise on real hardware, not from intuition, and each carries its own verification note in `data/flight-phases.yaml`.
content/safety.md
  • L82state the specific storage voltage per cell that oApogee recommends, sourced from the cell manufacturer's documentation rather than from hobby folklore, and state how to reach it with the hardware in this project.
  • L146once hardware exists, establish whether the drop test is representative by instrumenting an actual landing and comparing peak accelerations. If a real landing is far harsher, say so and change the test.
  • L184a full worked example, with a named common kit, its published stability margin unloaded, the same rocket with an oApogee pod at two different positions, and the resulting margins from OpenRocket. Include the caliber margin to aim for, quoted from NAR or Tripoli guidance rather than asserted.
  • L221transcribe the specific power and antenna limits that apply to oApogee's configuration in 902 to 928 MHz from the current text of Part 15, subpart C, and state them here with the section number. Do not paraphrase them from memory or from a forum post. Separately, verify whether any provision restricts airborne operation of Part 15 devices in this band, and state the answer either way, because "nobody mentioned it" is not a finding.
  • L237document the EU and UK rules properly rather than gesturing at them. Specifically: which sub-bands within 863 to 870 MHz are usable, the duty cycle limits that apply to each, the relevant ETSI harmonised standard, the UK interface requirement document, and, critically, whether airborne use is permitted, because several national administrations restrict it. Cite the primary documents. If the answer is that oApogee cannot be flown legally in a given country, the site says so.
  • L278state the station identification interval and the specific rule sections for identification and for the encryption prohibition, transcribed from the current text. Then, separately, decide and document whether oApogee firmware will support a Part 97 mode at all in v1, because shipping a half-built compliance feature is worse than shipping none.
  • L312transcribe the Class 1 criteria from the current text of Part 101 Subpart C, with the section number, including the propellant mass limit, the total weight limit, and the construction requirements. State them as a quotation with a retrieval date rather than a paraphrase. Then state plainly where the boundary into Class 2 sits and what that entails, so a reader scaling up knows what changes.
  • L319confirm whether a transmitter in the payload has any bearing on airspace notification requirements. The expected answer is no at Class 1, but expected is not verified.
  • L358` above is a place where a specific number or rule section has been deliberately left out rather than guessed at.
content/start-here.md
  • L130fill this section in with measured figures. It should carry, per tier and per build path, the actual price of a real cart from a US distributor at quantity one, the measured mass of an assembled unit including cell, and the median and slowest build times from timing several people who have soldered before. The targets in the project brief are under $60 for the full build, under 25 g flying mass, and an evening of work, but a target is not a measurement and this site does not publish targets as though they were.
data/bom.yaml
  • L63price a real cart for the Modules path and the Board path separately, at quantity 1 and quantity 10, from a US distributor. The brief's "under $30 entry build" is a target, not a measurement.
  • L68weigh an assembled Solo including a 150 mAh cell on a 0.1 g scale, three units, report the mean. The brief's "under 25 g" is a target.
  • L74as Solo. Note that Link is not complete without a ground station, which is a second bill of materials, and the site must not quote a Link price that silently excludes it.
  • L79weigh an assembled Link including cell and antenna.
  • L84as Solo. The brief's "under $60 full build" is a target.
  • L87weigh an assembled Track including cell, antenna, and GNSS antenna.
  • L115unit price at qty 1 and qty 100 from an authorised distributor, and confirm the package variant (RP2350A is the 30-GPIO QFN-60 part; RP2350B has more IO in a larger package and is not needed here).
  • L146select one canonical module and one alternate. Candidates to evaluate, none confirmed: Raspberry Pi Pico 2, Seeed XIAO RP2350, Adafruit Feather RP2040. Selection criteria in priority order: mass, whether the castellated or through-hole footprint suits a beginner, whether onboard QSPI flash is accessible to LittleFS, presence of a LiPo charger, and USB-C rather than micro-B. Weigh each candidate before choosing.
  • L171confirm the density actually required by measuring a full flight log at the intended sample rates, then size the part to that with margin rather than defaulting to 16 MB. Also confirm the specific part suffix, which encodes package and voltage.
  • L203quote the RMS noise in Pa at the oversampling and output data rate oApogee actually configures, from the datasheet, and convert it to metres of altitude noise at sea level. Do not quote the headline "0.5 m" style figure from marketing material without stating the configuration it assumes. Also state the usable pressure range and what altitude that corresponds to.
  • L227produce that comparison from both datasheets.
  • L232identify a currently-stocked BMP390 breakout and record its supplier part number, price, mass, and whether its I2C 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. Adafruit and SparkFun both list BMP390 boards; neither product number is confirmed here.
  • L248confirm the selectable full-scale ranges and the gyro noise density from the datasheet, and state which range oApogee configures.
  • L271identify a currently-stocked ICM-42688-P breakout and record whether it exposes the SPI interface and a usable chip select pin. The Board path puts this part on SPI. If no SPI-capable breakout can be sourced, the Modules path does not share the Board path's bus assignment, and the "Same electrical design, two ways to fabricate it" note at the head of this file must be amended rather than quietly left standing.
  • L288confirm the ADXL375 full-scale range and bandwidth from the datasheet, with the table cited, and state the full-scale range oApogee configures on the ICM-42688-P, also quoted from its datasheet. Then, separately, produce the number that justifies this part: the peak acceleration of a representative loaded airframe on a C, D, and E motor, taken from OpenRocket simulation, so the motor class at which the 6-axis IMU saturates is derived rather than asserted. Both halves are needed. A full-scale range with no simulated peaks says nothing about which motors exceed it, and simulated peaks with no range say nothing about which part clips first.
  • L322compare the noise floors.
  • L327identify a currently-stocked ADXL375 breakout and record whether it exposes the SPI interface and a usable chip select pin. The Board path puts this part on SPI sharing the IMU's bus. If no SPI-capable breakout can be sourced, the Modules path does not share the Board path's bus assignment, and the "Same electrical design, two ways to fabricate it" note at the head of this file must be amended rather than quietly left standing.
  • L346the entire range claim. Range is the number readers will most want and the number most often lied about in this hobby. It must come from a measured ground test and a measured flight, with the antenna type, orientation, spreading factor, bandwidth, transmit power, and terrain all stated. Publish the disappointing numbers too, specifically the range with the rocket on the ground in tall grass after landing, which is the case that actually matters for recovery.
  • L377select a canonical SX1262 module for the Modules path. Candidates to evaluate, none confirmed: Ebyte E22-900M22S, Waveshare Core1262, Seeed Wio-SX1262, Ai-Thinker Ra-01SH. Criteria: FCC modular approval status, whether the module includes a PA and at what output, antenna connector type, mass, and whether the vendor publishes a real datasheet rather than a two-page flyer. Modular approval matters: a pre-certified module is the difference between Part 15 compliance being inherited and being the builder's problem.
  • L402choose between a tuned wire monopole cut to a quarter wavelength and a flexible PCB antenna, and measure the difference. Publish the wire length as a measured, trimmed figure with the ground plane it assumes, not as a textbook calculation, because the calculation is not what works in a body tube. Also determine whether a carbon fibre or metallic airframe blocks the link, and say so plainly if it does.
  • L429cold start and hot start time to first fix, measured, not quoted, because the number that matters is time to fix on a launch rail after the pad wait, not the datasheet best case. Also measure whether lock is retained through boost once the airborne dynamic model is configured.
  • L454compare mass and measured time to first fix against MAX-M10S with a chip antenna.
  • L469measure the actual current draw of each tier in each flight state, then size the cell from that rather than from the brief's assumed range. Report endurance as pad-idle hours plus post-landing beacon hours, because those are the two numbers a flier needs. Confirm the cell ships with a protection circuit; unprotected cells are common and must not be recommended.
  • L496set the charge current programming resistor from the chosen cell capacity and state the resulting rate, and confirm thermal behaviour in the pod, which is a small sealed plastic volume.
  • L524a single LiPo cell runs from about 4.2 V down to about 3.0 V, which crosses 3.3 V partway through. A plain buck regulator browns out at the bottom of the discharge and a plain LDO wastes headroom at the top, so the part is a buck-boost. Select one, then measure quiescent current, because on a payload that sits armed on a pad and then beacons after landing, idle draw sets endurance more than active draw does.
  • L550choose a specific receptacle with through-hole mounting tabs. Surface-mount-only USB connectors tear off boards, and this one gets handled every flight day.
  • L571confirm 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.
  • L594select a part and then measure what actually matters, which is not the datasheet sound pressure level but the distance at which the beacon pattern is findable in tall grass on a windy day. Test it by having someone hide an active unit in a field. Report that distance.
  • L619choose between an addressable part, which costs one GPIO total, and discrete LEDs, which cost one GPIO each but are visible in direct sunlight at the pad if driven hard. Sunlight visibility is the requirement that decides this, and it needs testing outdoors, not at a desk.
  • L673the ground antenna is where link budget is cheapest to buy, because mass does not matter on the ground. Compare a quarter wave whip against a small yagi and publish both measured ranges, so a reader can decide whether the yagi is worth carrying.
  • L682print time and filament mass once the model exists.
  • L729confirm PLA survives a black airframe sitting on a pad in summer sun, and if it does not, say so and recommend PETG.
data/flight-phases.yaml
  • L69state the settling window duration from measured barometer noise on real hardware, and state the altitude error incurred if the operator walks away before the window completes. The duration itself is owned by content/firmware.md and data/preflight.yaml; this file records only that the window starts on arming.
  • L80choose the acceleration threshold and the sample count from measured pad noise on real hardware, including a deliberately clumsy rail knock, and state both numbers with the motor class they were tuned against.
  • L97state the full-scale range oApogee configures on the 6-axis IMU, quoted from the datasheet, and the peak acceleration of a representative loaded airframe on a C, D, and E motor from OpenRocket, so the motor class at which the IMU saturates is derived rather than asserted. Tracked on the high-g entry in data/bom.yaml.
  • L110confirm whether burnout detection needs hysteresis to avoid chattering on a rough burn, and if so, state the band.
  • L131set the confirmation count from measured barometer noise at the configured output data rate. State the resulting detection lag in milliseconds, because that lag is an error in the recorded apogee time and the reader is entitled to know its size.
  • L172a rocket hanging in a tree is stationary and is not on the ground. Determine what the landing detector does in that case and state it, because the honest answer may be that it cannot tell, and a reader searching a treeline needs to know which behaviour to expect.
  • L195measure beacon endurance from landing detect to cell cutoff, for each tier, on a fully charged cell after a full flight. This is the number that decides whether a payload is findable the next morning.
data/glossary.yaml
  • L212state the caliber margin oApogee recommends aiming for, with a source. The commonly cited range in model rocketry is well known, but it should be quoted from NAR or Tripoli guidance rather than from memory, because this is a safety number.
data/preflight.yaml
  • L166state the settling window in seconds once the firmware defines it, and state what the altitude error is if you leave early.
data/tiers.yaml
  • L67time three people who have soldered before, from opening the parts bag to a first successful bench log. The brief's "under two hours" is a target. Report the median and the slowest, not the fastest.
  • L98as Solo, and time the ground station separately.
  • L128as Solo.
  • L164state the usable altitude ceiling from the barometer's pressure range, and separately state the practical ceiling from radio range. These are different numbers and readers will conflate them.
  • L175state where an oApogee-equipped low power rocket actually sits relative to Class 1. Closing this needs two things that do not exist yet. First, the Class 1 criteria transcribed from the current text of Part 101 Subpart C with the section number and a retrieval date, including the construction requirements, which is tracked on content/safety.md. Second, a weighed payload mass, which is open in data/bom.yaml where every target_mass_g is null. Until both exist this file states the direction of travel and not a conformity conclusion.
data/troubleshooting.yaml
  • L205state the full-scale range oApogee configures on the 6-axis IMU, quoted from the datasheet, so this check has a number to compare against. Tracked on the high-g entry in the bill of materials.
docs/spec/log-format.md
  • L241state the gyro full-scale range oApogee configures, which is the same open question recorded against the `imu` part in `data/bom.yaml`, and compare it against the 327.67 deg/s this encoding can hold.
  • L256the actual per-phase log rates have not been chosen. Once they are, publish the resulting file size for a representative flight and use it to size the flash part, rather than defaulting to 16 MB because it is the reflexive choice.
  • L409confirm that LittleFS on the chosen flash part actually survives power loss mid-write in practice, by testing it: write continuously and cut power repeatedly, then check that every completed record is intact. This is the assumption the whole storage design rests on and it should be demonstrated rather than trusted.
docs/spec/telemetry-packet.md
  • L252state the detection lag in milliseconds once the confirmation sample count is chosen from measured barometer noise. A reader is entitled to know the size of the error in the recorded apogee time.
  • L339publish the actual intervals for each state at the shipped radio configuration, measured, along with the resulting duty cycle, so that anyone checking regional duty cycle limits can do the arithmetic. This matters for EU and UK builds in particular.

Needs the physical hardware

Procedures written out but never performed on a real board. No page containing one can be marked verified.

content/build.md
  • L81the specific module has not been selected. This stage cannot be written concretely until it is. See the verify note on `mcu_module` in the bill of materials for the selection criteria.
  • L116this guide does not rank the Modules-path failure modes by how often they happen, because ranking them needs reports from builds that have actually happened.
  • L154this entire path depends on a fabricated PCB. Nothing below can be written concretely until boards exist, and none of it has been performed.
  • L223document the LED behaviour for charging, charge complete, and charge fault, once that behaviour is implemented.
content/firmware.md
  • L33describe the actual LED indication and the boot banner text once the firmware exists.
  • L41no firmware has been written and no release exists. When one does, publish per-tier builds, a changelog entry for every release, and the git commit each build came from, so a flight log can record exactly what was flying.
  • L51document the toolchain, the checkout, the build command, and the output path, once the firmware repository exists. Include the exact toolchain versions the published releases are built with, because "it builds on my machine" is not a build instruction.
  • L66publish the full configuration reference once the firmware defines it. It must cover, at minimum:
  • L118document the procedure once it exists. It will involve holding the board still in several orientations, and it needs to state what "still" means and how the procedure tells you it has enough data.
content/ground-station.md
  • L43the ground station has not been built. The parts are listed in the [bill of materials](/bom); the assembly steps below are the structure, not a tested procedure.
  • L134define and document that text format. It should be one line per packet, fixed field order, easy to grep and easy to paste into a message when asking for help.
content/mounting.md
  • L55the models do not exist yet. When they do, publish the parametric source rather than only exported STLs, in a format that can be opened and edited without a commercial licence. The pod is parametric on tube diameter, so a builder with an unusual airframe changes one number rather than asking for a new file.
content/reading-your-data.md
  • L36the offload tool does not exist. Document the actual invocation once it does, for all three operating systems.
content/reference.md
  • L77the KiCad project does not exist. When it does, publish the project itself rather than a PDF export, along with Gerbers, a pick and place file, and the assembly bill of materials.
  • L83the pin assignment is not fixed. It cannot be published until the schematic exists, and publishing a provisional one would guarantee that somebody builds against it.
  • L89board outline, mounting hole positions and diameters, connector positions, and the maximum component height on each side. Also the sled and pod models, published as parametric source rather than only as exported STLs.
  • L96configuration file reference, serial command reference, and the self-test output format.
content/safety.md
  • L92describe the LED behaviour during charge, at charge complete, and on a fault, once the hardware exists and that behaviour is implemented.
  • L122document the exact procedure for simulating launch detection on the bench, including whether it is a firmware test mode or a physical motion, once the firmware exists.
data/bom.yaml
  • L50the PCB is a paper design. No Gerbers have been produced, nothing has been fabricated, and nothing has flown.
data/tiers.yaml
  • L19this 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.
docs/spec/log-format.md
  • L245record the peak roll rate on a flight. If either that figure or the configured range exceeds 327.67 deg/s, widen this field before anything depends on `spec_version` 1, because `flight.bin` is a fixed-width record and changing it afterwards is a format break.

Needs a decision

Open design questions, waiting on a maintainer call rather than on evidence.

content/about.md
  • L164whether to formally register the mark. The policy above stands either way; registration decides how enforceable it is.
content/firmware.md
  • L160decide between a complementary filter and a Kalman filter, and document the choice with its reasoning. A complementary filter is far simpler to implement, to explain, and to verify by hand, which on a project whose product is its documentation is a real argument. A Kalman filter is better behaved if the noise characteristics are known, and they are not yet, because nothing has flown.
content/ground-station.md
  • L37the brief asks for confirmation of this approach before building it out. The recommendation is WebSerial with the requirement stated prominently, plus the terminal fallback.
data/bom.yaml
  • L649the brief asks for confirmation of the WebSerial approach before this is built out. The tradeoff to decide: WebSerial needs no installation, which is the right answer for a club field where six people want to watch, but it is not supported in Safari or on iOS, which rules out a large share of phones. The alternative is a native app per platform, which nobody will install. A third option is a small local server the user runs once. Recommend WebSerial with an explicit, prominently stated browser requirement, and a plain serial terminal fallback documented for everyone else.
data/troubleshooting.yaml
  • L215the open questions page asks whether this part should be gated by motor class rather than by tier. Resolve that before the site tells anyone which motor class requires it.
docs/spec/log-format.md
  • L402decide whether to store a rolling CRC per block in `flight.bin`. The argument for is that flash bit rot and a partial-page write on power loss can corrupt a record in the middle of a file undetectably. The argument against is that it breaks the flat-array property that makes this format one line to load. A separate sidecar of block checksums would keep both, at the cost of a third file.
docs/spec/telemetry-packet.md
  • L489decide whether a `SIM` packet should use a distinct packet type rather than a flag. A flag is cheaper and a type is harder to ignore by accident. The argument for the flag is that every field means the same thing in both cases; the argument for the type is that it makes the mistake impossible.

Needs a photograph

Image slots, each describing what the photograph has to show.

content/build.md
  • L55the full parts layout for a Track build on the Modules path, top down, every part labelled, on a plain background. This is the photo people screenshot to check their order arrived complete.
  • L189a completed board, top and bottom, at high enough resolution to check joint quality against.