What does ERR Subsys=11 ECode=2 mean in ArduPilot?

Subsystem 11 is GPS and ECode 2 is GPS_GLITCH. The firmware writes this line when the GPS glitch detector decides the receiver's reported position is inconsistent with the EKF's velocity prediction. Resolution is logged as ECode 0 on the same subsystem.

Is HDop = 2 safe to fly?

It's the boundary. ArduPilot's default GPS_HDOP_GOOD is 1.4 — the EKF treats HDop above that as degraded. For autonomous modes (Loiter, RTL, Auto), you want HDop steadily below 1.2 on takeoff. For manual modes, HDop is informational; the EKF will reject bad updates either way, you'll just see more position innovations.

Does a GPS glitch always cause the EKF to fail too?

No. The EKF has a gate (EK3_POS_I_GATE) that rejects implausible GPS updates without losing confidence. A single glitch typically shows up as a position innovation spike that the EKF absorbs. Repeated glitches in close succession exhaust the EKF's tolerance and that's when you get a lane switch or failsafe.

How many satellites should I have before takeoff?

12 or more for a confident takeoff in open sky, and don't take off if NSats has been dropping rather than climbing in the last 30 seconds — that's a sign of poor antenna placement or RFI that will get worse once motors start.

Does multi-constellation actually help in urban areas?

Yes, materially. GPS-only loses fixes in dense buildings far more often than GPS + GLONASS + Galileo + BeiDou. The downside is that some constellations have weaker error characteristics, so HDop can be a worse predictor of accuracy. The trade is almost always worth it for urban flights.

How do I tell a real GPS glitch from compass-induced position drift?

GPS-side problems show up in GPS.NSats and GPS.HDop changing. Compass-side problems leave the GPS message clean but produce growing XKF3.IMX/IMY/IMZ innovations and a heading that doesn't match the EKF's flight track. If the receiver looks healthy in the log but the position estimate drifts, you're chasing the magnetometer, not the GPS.

Diagnosing GPS Glitches in ArduPilot .bin Logs

TL;DR: A GPS glitch in ArduPilot shows up as ERR Subsys=11 ECode=2, a GPS.Status drop below 3, or a sudden dip in GPS.NSats with GPS.HDop spiking past 2. The causes we see most often are urban-canyon multipath, RFI from the airframe (ESCs and video transmitters), and a marginal antenna pattern blocked by the body of the drone. Move the antenna up and clear of metal, enable multi-constellation, and gate flights on NSats > 12 with HDop < 1.2.

What ArduPilot logs about GPS

The GPS message records once per fix update from each receiver:

GPS  TimeUS  I  Status  GMS  GWk  NSats  HDop  Lat  Lng  Alt  Spd  GCrs  VZ  Yaw  U

The fields that diagnose a glitch:

Status — fix type, enumerated as AP_GPS_FixType: 0=NO_GPS, 1=NO_FIX, 2=FIX_2D, 3=FIX_3D, 4=DGPS, 5=RTK_FLOAT, 6=RTK_FIXED, 7=STATIC, 8=PPP.
NSats — satellites tracked. Solid lock is ≥12 in open sky; under 10 in cruise is a yellow flag.
HDop — horizontal dilution of precision × 100 in the log. So a logged value of 150 is HDop 1.5. Below 100 is excellent, 100–200 acceptable, above 200 is glitch territory.
U — whether this GPS instance is the one currently feeding the EKF. Matters on dual-GPS builds.

When the autopilot's glitch detector trips, it also writes ERR Subsys=11 ECode=2. That line is the cleanest "firmware agreed" indicator.

Confirming it in Mission Planner

Plot GPS.NSats, GPS.HDop, and GPS.Status on one chart. Add POS.Lat and POS.Lng so you can see whether the fused position jumped at the moment HDop spiked. The Errors tab will list every Subsys=11 line with the GPS subsystem name decoded.

Confirming it in MAVExplorer

MAV> graph GPS.NSats GPS.HDop GPS.Status
MAV> messages ERR

If you have a second receiver, overlay GPS2.HDop against GPS.HDop. Antenna or routing issues usually affect one GPS more than the other; common-mode RFI affects both at the same time. That distinction alone narrows the cause from "the GPS subsystem" to "this one antenna".

Why it happened — ranked by what we see most often

Urban canyon multipath. Buildings reflect satellite signals; the receiver gets two copies of the same signal at different delays and computes the wrong range. HDop rises while NSats often stays high — that combination is the giveaway.
Onboard RFI. ESCs, video transmitters, and underslung payload power leads radiate into the GPS L1 band. Moving the GPS onto a mast above a copper ground plate fixes a surprising fraction of glitches in 5.8 GHz FPV builds.
Antenna shadowing. Carbon-fibre frames and metal-can payloads block sky view in specific orientations. The glitch follows the drone's heading — an east-facing antenna with a metal canopy on the west side loses fixes when you yaw west.
Marginal cold start. Within 90 seconds of power-on, ephemeris data isn't fully downloaded; the first 3D fix can be coarse. Arming gated only on NSats > 10 doesn't always catch this — HDop is the better gate.
Jamming. Real GNSS jammers exist near military and government installations. NSats falls to single digits across all constellations simultaneously, often with a clean cliff edge.

Fixing it

Get the antenna above the airframe. A 50 mm mast separating the GPS from the flight controller and ESCs solves most onboard RFI.
Enable multi-constellation. GPS_GNSS_MODE = 65 on most modern u-blox receivers enables GPS + GLONASS + Galileo + BeiDou. More birds visible, faster recovery from local outages.
Use the EKF arming gate. ARMING_CHECK bits for GPS and Position are enabled by default; do not disable them. GPS_HDOP_GOOD sets the HDop ceiling for the EKF to consider a receiver healthy.
Dual-GPS configuration. Set GPS_AUTO_SWITCH = 1 and ArduPilot will switch to the better receiver automatically. Combined with GPS_BLEND_MASK, you can fuse both into a noise-resistant solution.
Investigate persistent HDop above 1.5 in clear sky. If a clear-sky flight reads HDop near 2, the antenna or its ground plane is wrong — replace the antenna or move it.
For RTK rigs, watch demotion paths. GPS.Status=5 (RTK_FLOAT) demoting to 4 (DGPS) or 3 (FIX_3D) is a centimetre-precision-to-metre-precision degradation that your altitude controller will react to. Log analysis should always reconcile against the base station's correction stream availability.

When this is not actually GPS

Compass-induced position drift. A bad EKF heading makes the predicted-vs-measured position diverge, which the firmware sometimes blames on GPS. Check MAG.MagX/Y/Z and XKF3.IMX/IMY/IMZ to rule the compass in or out.
EKF lane switch. A position discontinuity can be the symptom of the EKF re-picking a primary core, not a receiver problem.
Antenna disconnect. NSats drops to 0 abruptly mid-flight rather than degrading. Usually a connector problem — the receiver is fine, the cable isn't.

When LogHat helps — and when it doesn't

LogHat surfaces Subsys=11 events automatically and overlays GPS.NSats, GPS.HDop, and GPS.Status against the EKF position innovations. What we can't do is tell you whether you were under a tree or near a transmitter at the moment of glitch — that ground-truth context belongs in your flight log notes, not the .bin. The log gets you to a confident receiver-side diagnosis; the physical context is still yours to provide.