What is ERR Subsys=24 in an ArduPilot log?

Subsystem 24 is EKF_PRIMARY. ECode 1 on the same line means the autopilot switched the primary EKF core mid-flight. The new primary index is in the matching MSG line and in XKF4.PI just after the transition.

How is an EKF primary change different from an EKF failsafe?

A primary change is the autopilot promoting a healthier core while continuing to fly normally. An EKF failsafe (ERR Subsys=17 ECode=1) is the autopilot declaring that no core is trustworthy and forcing a mode change to Land or AltHold. Primary changes are routine safety mechanics; failsafes mean you've run out of redundancy.

Is one EKF primary change per flight worrying?

Not necessarily. A single switch during an aggressive manoeuvre or a brief GPS multipath event is the autopilot working correctly. Worry when switches repeat (three or more per minute), when they precede an EKF failsafe, or when the same airframe shows them on every flight — that's an unfixed root cause, not a transient.

Why does my drone always switch cores at the same point in the mission?

Because the trigger is environmental and consistent at that location. Most often: a structure causing GPS multipath, a corner of the flight path where prop wash hits the barometer differently, or a yaw orientation that puts the antenna in shadow. Walk the flight path on Google Maps with the timestamps in hand and the cause usually identifies itself.

Should I disable extra EKF cores to stop primary changes?

No. The cores are there to give the autopilot somewhere to switch when a sensor degrades. Disabling them only removes the safety net — the underlying problem still exists, and now there's no escape valve. Fix the sensor cause; keep the cores.

How do I tell which sensor caused the primary change?

Plot XKF4.SV, SP, SH, and SM on the losing core just before the switch. The measurement test ratio that crossed 1.0 is the one the EKF rejected. SV/SP point to GPS; SH points to barometer; SM points to magnetometer. Our EKF innovation post walks through the per-sensor diagnostic chain from there.

What Causes EKF Primary Change in ArduPilot — A Log-Based Analysis

TL;DR: An EKF primary change is ArduPilot's safety mechanism for navigation continuity. Multiple EKF cores run in parallel; when the current primary's error score climbs past the secondary's, the autopilot switches lanes. The change is logged as ERR Subsys=24 and visible as XKF4.PI flipping between 0 and 1. The trigger is almost always GPS multipath, magnetometer interference, or vibration corrupting one core's predictions — not the EKF itself.

What "EKF primary" actually means

ArduPilot's EKF3 implementation runs two or three filter cores in parallel, each using slightly different sensor sources or update strategies. Only one is active for navigation at a time — the primary. The others run in shadow, ready to take over if their error scores stay healthier than the primary's. XKF4.PI in the log tells you which core is currently primary; a transition is a lane switch.

The redundancy exists because individual sensors can degrade transiently (GPS multipath, a momentary compass spike, an IMU clip from prop strike) without the whole filter being broken. Switching to a healthier core preserves navigation continuity.

The log signature

Three artefacts confirm a primary change:

XKF4.PI changing value — 0 to 1, or 1 to 0, mid-flight.
ERR Subsys=24 ECode=1 — the autopilot wrote "EKF primary changed" to the error stream.
MSG line "EKF Primary Changed to N" with the new core index.

One lane switch in a long flight is informational. Three or more switches within a minute is the EKF struggling to find a trustworthy core — the precursor to EKF failsafe (ERR Subsys=17 ECode=1).

What drives the primary change — ranked

GPS-driven position disagreement. Multipath or RFI causes the GPS-using core to accumulate position innovations (XKF3.IPN/IPE). If the alternative core has a different source weighting, it stays healthier and the autopilot switches. See our GPS glitch post.
Vibration corrupting IMU integration. VIBE.VibeZ above 30 m/s² degrades one IMU more than the others. The EKF core using the noisy IMU loses confidence first; the autopilot promotes a different core. See our VIBE message guide.
Magnetometer interference. High-current peaks bias the compass; one core's heading-using path diverges from the others. XKF3.IMX/IMY/IMZ growing on the core that loses primary is the indicator.
Barometer drift. Sun on the unshielded baro or prop wash on a QuadPlane biases altitude. XKF4.SH climbs on the core using the affected baro; the autopilot picks the other.
Aggressive manoeuvre. Sharp pitches or extreme angles momentarily stress one core's predictions. A single lane switch followed by stability is a normal autopilot recovery.

Reading XKF3 and XKF4 to find the cause

The core that lost primary status is the one whose error score climbed. XKF3.ErSc gives a consolidated number per core; XKF4.SV/SP/SH give the per-measurement test ratios that fed into it. Plot the affected core's traces:

MAV> graph XKF3.ErSc XKF4.PI
MAV> graph XKF4.SV XKF4.SP XKF4.SH

The measurement test ratio that crossed 1 just before the lane switch tells you which sensor family the EKF rejected. From there, our EKF innovation post walks through the per-sensor diagnostic path.

Confirming in Mission Planner

Open the log, navigate to the Errors tab, and filter for Subsys=24. Each line names the timestamp of the change. Cross-reference with XKF4.PI on the main plot to confirm the lane that the autopilot landed on.

Preventing repeated primary changes

If you see lane switches on every flight, the root cause is not random and the EKF is doing its job. Fix the underlying sensor problem:

GPS: elevate the antenna, enable multi-constellation (GPS_GNSS_MODE = 65), consider dual GPS with GPS_AUTO_SWITCH = 1.
Vibration: mechanical fix — balance props, soft-mount the FC, check motor bearings.
Compass: physical separation from current-carrying wires; run COMPASSMOT calibration; consider an external compass on a mast.
Barometer: foam the sensor against sun and airflow; cross-check our BARO glitch post.

Do not raise gates (EK3_*_I_GATE) to suppress switches. The gates are a backstop, not a fix — raising them lets bad measurements through.

When this is fine and when it isn't

One primary change in a 30-minute mission, with the secondary core in good health and no following failsafes, means the EKF caught a transient and recovered cleanly. That's the system working as designed.

Three or more primary changes in a row, an ERR Subsys=17 ECode=1 following the changes, or a MODE change to LAND or AltHold with Rsn=6 are the autopilot telling you it ran out of healthy cores. From that point, your safety margin is gone.

When LogHat helps — and when it doesn't

LogHat annotates every XKF4.PI transition in the 3D replay and surfaces the dominant innovation source at the moment of switch. The Vector AI cross-references the primary-change pattern against known sensor-failure signatures, so a repeated mid-flight switch with rising XKF3.IMX is flagged as a compass problem. What we can't do is tell you which specific sensor module on your build is failing — that needs a bench swap to confirm.