ArduPilot PreArm Error Messages — Reference Library and Fixes

TL;DR: ArduPilot’s PreArm checks block arming when sensor calibration, configuration, or safety state isn’t flight-ready. The error text names the specific failing check — for example, PreArm: Logging failed means the SD card isn’t writeable, PreArm: CrashDump data detected means a previous flight rebooted via watchdog, PreArm: EKF3 Yaw inconsistent means the compass and the EKF’s motion-derived heading disagree. This post lists the ten messages we see most often, with the underlying cause and the fix for each. Never just disable a PreArm check — resolve the underlying state.

The general rule: never bypass PreArm

The ARMING_CHECK parameter lets you disable individual PreArm checks. The ArduPilot wiki is explicit: never disable arming checks except for bench testing. The checks exist because their failure modes have caused crashes; bypassing them removes the only protection the autopilot offers before the propeller spins.

Every PreArm message has a fix that doesn’t require disabling the check. The fixes below are listed in order of likelihood — try the first one before reaching for the second.

1. PreArm: Logging failed — SD card isn’t writeable

Cause: The autopilot couldn’t open or write to the dataflash log file. Either the SD card is missing, write-protected, full, or formatted in a way the autopilot doesn’t recognise.

Fix:

• Remove the SD card and confirm it’s seated in the slot. Re-power the autopilot.
• Check the card on a computer for filesystem corruption. Format FAT32 if in doubt.
• Use a known-good SD card — cheap cards die unpredictably. Industrial-grade cards (Sandisk Industrial, Kingston Industrial) are worth the premium on production builds.
• If MAVLink-streamed logging is configured (LOG_BACKEND_TYPE = 2 or 3), confirm the receiving GCS is actually capturing.

2. PreArm: CrashDump data detected — previous boot was unexpected

Cause: The autopilot detected a previous boot that ended via watchdog reset, hardware fault, or similar. The flight controller keeps a crash dump from that event and refuses to fly until the dump is cleared, on the assumption that you want to investigate the cause.

Fix:

• Read the crash dump if possible — Mission Planner → Help → Read Crash Dump. The information helps the ArduPilot developers diagnose the cause.
• Report it via ArduPilot’s Internal Error reporting page with the firmware version and log.
• Clear the dump (Mission Planner has the option). If it returns on the next boot, you have a recurring hardware fault — usually a slow SD card stalling the logger thread, but sometimes an actual firmware bug.

3. PreArm: EKF3 Yaw inconsistent — compass and motion disagree on heading

Cause: The EKF’s internal yaw estimate (built from gyro integration + compass) disagrees with what the compass currently reads by more than the configured threshold. Often happens shortly after power-up before the EKF converges; persistent through a 30-second wait means a real disagreement.

Fix:

• Wait 30 seconds after boot before testing — the EKF is still aligning.
• Verify compass calibration. Re-calibrate in an open area away from metal if calibration is older than a few months or you’ve changed wiring.
• Check COMPASS_PRIMARY — an internal compass mounted next to the FC almost always has CompassMot issues. Use an external module.
• If you fly indoors or on rebar-heavy structures, the external magnetic environment can produce this. Move outdoors and re-test.

4. PreArm: Internal errors (0x800) — logger thread stuck

Cause: The autopilot’s internal error bitmask has bit 0x800 set, which usually means the AP_Logger background thread got stuck writing — almost always a slow or failing SD card.

Fix:

• Replace the SD card with a known-good industrial-grade card.
• Reformat to FAT32 on a computer before installing.
• If the error returns immediately, suspect I²C bus problems with peripherals (some external GPS+compass modules can wedge the autopilot via the I²C bus). Disconnect non-essential peripherals one at a time.

5. PreArm: AHRS: waiting for home — EKF has no home position yet

Cause: The EKF needs to anchor its position estimate to a home location. It can’t until it has a 3D GPS fix that’s stable enough to trust.

Fix:

• Wait for GPS lock. GPS.NSats ≥ 12 in open sky is the usual threshold.
• Check GPS.HDop is below 1.2.
• If the wait is persistent (over 5 minutes outdoors), the GPS or antenna has a problem. See our GPS glitch post.

6. PreArm: GPS Glitch — GPS reporting inconsistent position

Cause: The GPS receiver is reporting positions that the autopilot’s glitch detector doesn’t trust — usually multipath, RFI, or marginal antenna.

Fix:

• Move to an open area away from buildings and metal structures.
• Power-cycle the GPS receiver; cold-start ephemeris download takes a couple of minutes.
• For chronic issues, see our GPS glitch post for antenna placement and multi-constellation setup.

7. PreArm: Compass Offsets High — calibration produced large biases

Cause: One of COMPASS_OFS_X, COMPASS_OFS_Y, or COMPASS_OFS_Z exceeds the warning threshold (typically 600 milligauss). The calibration absorbed too much external bias.

Fix:

• Re-run compass calibration in an open area away from metal structures.
• If offsets remain high after a clean calibration, the compass is too close to a magnetic source on the airframe. Move the compass external to a mast.
• Check for steel hardware near the compass — swap to brass or stainless within 50 mm of the sensor.

8. PreArm: Bad Battery Failsafe Voltage — thresholds inconsistent

Cause: BATT_LOW_VOLT and BATT_CRT_VOLT are set such that they don’t make sense — critical higher than low, or both at impossible values for the configured cell count.

Fix:

• Verify BATT_LOW_VOLT is above BATT_CRT_VOLT.
• Verify both values are sensible for your cell count (e.g. 21.0 V low + 19.5 V critical for a 6S LiPo).
• Check BATT_VOLT_NUM_CELLS matches your physical pack.

9. PreArm: Hardware Safety Switch — safety switch not pressed

Cause: The hardware safety switch on the autopilot or carrier board hasn’t been pressed. ArduPilot’s safety switch protects against accidental motor spin during ground handling.

Fix:

• Press and hold the safety switch (usually 2 seconds). The LED should change colour to indicate the switch is in the “armed-state-allowed” mode.
• If the switch is broken or not connected, set BRD_SAFETY_DEFLT = 0 to default the autopilot to the safety-off state at boot (only on bench builds without a switch).

10. PreArm: gyros still settling — gyro readings haven’t converged

Cause: The IMU’s gyroscopes haven’t finished their startup zero-point calibration. The autopilot needs a stable, motionless airframe for a few seconds after power-up.

Fix:

• Don’t move the airframe for 5–10 seconds after powering up.
• If the message persists after a minute, the gyros are seeing real vibration even at idle — check whether the FC is loose in its mount, or whether something nearby is vibrating the airframe.
• In extreme cases, replace the IMU or the entire flight controller.

When you can’t identify the message

ArduPilot has more PreArm checks than the ten above. If the message doesn’t match anything here:

• The text usually names the subsystem (Compass, Battery, GPS, AHRS). Start at the subsystem’s usual cause.
• The ArduPilot wiki’s Pre-Arm Safety Checks page lists every check with the canonical fix.
• The Mission Planner STATUSTEXT stream and the dataflash MSG entries capture the exact text for searching against the wiki or Discourse.

When LogHat helps — and when it doesn’t

If a PreArm error fired during a flight attempt (the autopilot armed briefly and disarmed), LogHat shows the surrounding MSG entries and named PreArm text in the analysis. For purely pre-flight refusals where no flight log was written, LogHat doesn’t help — the resolution lives in Mission Planner or QGC during ground handling, not post-flight.