Troubleshooting

“The barometer never appears on the bus”

1. 01
   Reflow the sensor's ground pad

   On small packages the ground pad is the joint most likely to look fine and not be. It is also the one that makes the whole part invisible when it fails, rather than making it behave oddly.

2. 02
   Check for a short between the two bus lines
3. 03
   Confirm the I2C pull-up resistors are present, and only once

   The barometer is the only part on the I2C bus, so there should be one pull-up pair on SDA and SCL. On the Modules path the breakout brings a pair of its own, which duplicates any pair already fitted on the carrier, and two pairs in parallel can load the bus enough to stop it working. No pull-ups at all stops it working too. This presents as intermittent dropouts more often than as total absence, but it can do both.

4. 04
   Confirm the part is powered

   3V3 at the sensor's supply pin, measured at the pin, not at the regulator.

See also sensors drop out intermittently

“Sensors drop out intermittently”

1. 01
   Count the I2C pull-ups

   Only the barometer sits on I2C, so exactly one pull-up pair belongs on SDA and SCL. On the Modules path the breakout's own pair duplicates any pair already on the carrier, and two in parallel can pull the bus harder than the parts can drive it. Remove one set, or cut the jumper the breakout provides for exactly this. Removing both leaves the bus with no pull-ups and it will not work either.

2. 02
   Check the SPI chip selects

   The IMU and the high-g accelerometer share SCK, MOSI and MISO, and each needs a chip select line of its own. Two parts on one chip select drive MISO against each other whenever the bus is read, which reads as one part working and the other appearing and disappearing.

3. 03
   Shorten the wiring

   Long unshielded jumpers on a fast bus pick up noise from the radio.

4. 04
   Check for a cold joint by flexing the board gently while watching the console

   If it drops out when you flex it, it is mechanical, and you have just learned something important about how it will behave under boost.

“My altitude reads negative”

1. 01
   Check whether it is a small negative number after landing

   This is not a fault. Barometric altitude is measured against a pressure reference taken on the pad. If atmospheric pressure rises during the flight, or the rocket lands lower than the pad, the reading goes negative and it is correct. oApogee does not clamp it at zero, because clamping would hide a real measurement.

2. 02
   Check whether it went negative during the flight

   A negative excursion during boost usually means the static ports are badly placed and are seeing dynamic pressure rather than static.

3. 03
   Check whether it starts at a large negative value

   That means the pressure reference was taken somewhere other than the pad, most often because the payload was armed indoors or the settling window was interrupted.

See also the altitude is wildly wrong, or flat, or enormous

“The altitude is wildly wrong, or flat, or enormous”

1. 01
   Check the static ports are opencritical

   A sealed tube produces a smooth, confident, entirely fictional altitude curve. Look for paint, glue, tape, and swarf left from drilling.

2. 02
   Check port placement relative to the sensor

   Ports too close to the nose cone shoulder or a fin root see pressure disturbed by the airframe rather than ambient.

3. 03
   Deburr the port holes

   A raised lip around a drilled hole disturbs the airflow over it, which is the thing the port exists to avoid.

4. 04
   Compare against the raw pressure column in the log

   The log stores raw pressure alongside fused altitude precisely so this is answerable. If pressure looks sane and altitude does not, the problem is the reference or the fusion. If pressure looks wrong, it is the port or the sensor.

“The acceleration trace is a flat plateau during boost”

1. 01
   Check whether the plateau sits at the IMU's full-scale limit

   Then it is not a plateau, it is saturation. An accelerometer past full scale reports its maximum rather than an error, so real acceleration above the limit comes back as a constant. Compare the flat value against the configured full-scale range rather than against a remembered figure. TODO(verify): state 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.

2. 02
   Check whether the high-g accelerometer is fitted and healthy

   The HIGH_G flag in the log and in the telemetry says whether the value came from the dedicated part or from the IMU. If it came from the IMU, the boost phase is not measurable with what is on the board. The high-g accelerometer is specified at Link and above, so on a Solo build there is no dedicated part to fall back to. TODO(confirm): the 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.

“It never detects launch”

1. 01
   Confirm it was armed, not merely powered on

   A powered payload sits in PAD_IDLE and records nothing. Launch detection only runs from ARMED.

2. 02
   Check the orientation the payload was mounted in

   Launch detection looks for sustained acceleration along the vehicle axis. A payload mounted sideways in the pod sees the boost on a different axis than the firmware expects.

3. 03
   Check the motor class

   The detection threshold has to be high enough that bumping the rail does not trigger it. A very small motor in a heavy airframe may not clear it.

4. 04
   Check the log for the pre-arm ring buffer contents

   If the buffer shows the acceleration event but the state never changed, the threshold is the problem rather than the sensor.

See also there is no log file after the flight

“There is no log file after the flight”

1. 01
   Check whether storage was full

   The LOG_FULL flag is set when it is. A full filesystem stops logging silently, which is why clearing it is on the preflight checklist.

2. 02
   Check whether a flight directory exists with only a manifest in it

   That means it armed and created the flight, then never wrote records. Look at the state in the manifest.

3. 03
   Check whether it armed at all

See also the log stops partway through the flight

“The log stops partway through the flight”

1. 01
   Check where it stops

   Stopping at or shortly after the deployment jolt usually means power was interrupted by the shock. Check that the cell cannot move inside the pod and that the connector is retained.

2. 02
   Check for LOG_FULL in the last records
3. 03
   Check the cell voltage in the final records

   A cell that sagged under the radio's transmit current can brown out the board. This is more likely on Link and Track, and more likely with a small or old cell.

A truncated log is still a valid log. A partial trailing record is normal and every conforming reader truncates to whole records rather than failing.

“The apogee number looks too low”

1. 01
   Check whether the pressure reference was taken properly

   Every altitude is measured against it. The manifest records the reference pressure and how many samples went into it.

2. 02
   Check the static ports

   Under-reading is a classic symptom of a partially blocked port.

3. 03
   Compare against the raw pressure column

   Recompute altitude from raw pressure yourself. If your number and the payload's number agree, the sensor and the reference are consistent and the flight really was that low.

4. 04
   Re-check your simulation

   A payload adds mass, and mass costs altitude. The flight may be correct and the expectation wrong.

“The radio drops out at short range”

1. 01
   Check the antenna is connected and correctly tuned for your bandcritical

   A 902 to 928 MHz antenna on an 868 MHz module, or the reverse, will appear to work at a few metres and fail at any real distance. This is the most common cause and the easiest to overlook.

2. 02
   Check the antenna is not coiled inside the airframe or against carbon fibre

   A conductive airframe blocks the link. So does an antenna wrapped around itself to make it fit.

3. 03
   Check the ground station antenna and its orientation

   Two antennas at right angles to each other are cross-polarised and lose a large fraction of the link budget for free.

4. 04
   Check the spreading factor

   A low spreading factor buys update rate and costs range. If range matters more than rate for your flying site, trade the other way.

Range on the ground after landing is dramatically worse than range in the air, because the antenna is lying in grass rather than in clear line of sight. That is not a fault, it is the physics of the recovery case.

“The ground station receives nothing at all”

1. 01
   Confirm both ends are on the same band and the same radio settings

   Frequency, bandwidth, spreading factor and coding rate all have to match. One mismatch and the link is silent rather than degraded.

2. 02
   Confirm the payload is transmitting

   The status LED indicates transmission. If it is not transmitting, the problem is the payload, not the link.

3. 03
   Check the browser

   The ground station display uses WebSerial, which is not supported in Safari or on iOS. Use a Chromium-based browser on a desktop, or the plain serial terminal fallback.

4. 04
   Check whether another application is holding the serial port

   Only one thing can have the port open at a time.

“Packets arrive but most fail the CRC”

1. 01
   Check for a nearby transmitter

   The 902 to 928 MHz band is busy, and a Part 15 device has to accept interference. A high CRC failure rate at close range often means somebody else is talking.

2. 02
   Move the ground station away from the laptop and from USB 3 ports

   USB 3 is a well-known source of broadband noise in this region.

3. 03
   Check the receiver module's own wiring

   The application CRC covers the serial link between the module and the host, so a bad connection there produces exactly this symptom.

“GNSS loses lock during the flight”

1. 01
   Confirm the airborne dynamic platform model is configuredcritical

   u-blox receivers default to a model that assumes ground vehicle dynamics and will reject position solutions under rocket acceleration. It must be set explicitly at every boot, or saved to the receiver's configuration. This is the single most common reason a GNSS-equipped model rocket payload comes back with no track.

2. 02
   Check the antenna's view of the sky

   Inside a body tube with the antenna facing the wrong way, the receiver is looking at the ground for most of the flight.

3. 03
   Check for interference from the radio

   A LoRa transmitter next to a GNSS receiver can desensitise it. Physical separation and antenna orientation both help.

Losing lock under boost and regaining it during coast is normal and expected. The valuable fix is the last one before landing, not a continuous track.

“It takes a very long time to get a first fix”

1. 01
   Get the fix before you close the airframe and before you queue

   A cold start with no almanac takes far longer than a warm one. The pad is the worst place to be waiting.

2. 02
   Check the antenna and its ground plane
3. 03
   Check that it is not being reset between attempts

   A receiver that loses power between attempts starts cold every time.

“My tool cannot read the binary log”

1. 01
   Read the layout from meta.json rather than hardcoding it

   The manifest states every field, its offset, its type and its scaling. A reader built on the manifest keeps working across format versions.

2. 02
   Truncate to whole records

   A trailing partial record is normal. Use floor(file_size / record_bytes) rather than failing.

3. 03
   Check your byte order

   Everything is little-endian.

“The GNSS altitude and the barometric altitude disagree”

1. 01
   Use the barometric column

   They are different measurements. GNSS altitude is referenced to an ellipsoid rather than to the launch pad, and it is considerably less precise for this application. The GNSS altitude is stored because disagreement is diagnostically useful, not because it is a better number.

“A bench test looks like a real flight in my archive”

1. 01
   Check the simulated field in the manifest, and the SIM flag in the packets

   Both exist for exactly this. A bench run produces a complete, plausible log, and without checking that field an archive will eventually publish one as a flight.