What is ERR Subsys=18 ECode=2 in an ArduPilot log?

Subsys 18 is the barometer and ECode 2 is BARO_GLITCH. The firmware writes this line when it detects an inconsistent pressure reading; an ECode 0 on the same subsystem afterwards means the glitch resolved. The full subsystem and code enumeration lives in libraries/AP_Logger/AP_Logger.h in the ArduPilot source.

Is SIM_BARO_GLITCH something I should monitor?

No. SIM_BARO_GLITCH is a SITL-only parameter that lets developers inject fake glitches into a simulated barometer for testing the autopilot's response. It does not exist on production hardware and will not appear in any real-flight log. If you read it suggested elsewhere as something to watch, that source is wrong.

How do I tell a real BARO glitch from EKF rejection?

A real glitch shows up in BARO.Alt and BARO.Press directly, often with a coincident BARO.Temp jump and a BARO.H drop to 0. An EKF rejection shows up as CTUN.Alt diverging from a clean BARO.Alt, usually with a corresponding NKF4 or XKF4 innovation spike. Both events can look identical in altitude-hold behaviour, but only the first needs a hardware fix.

What does BARO.H = 0 mean and how worried should I be?

BARO.H is the driver health flag. A drop to 0 means the autopilot stopped trusting that sensor instance for at least one update cycle. A momentary drop with auto-recovery is usually fine; a sustained drop (hundreds of milliseconds) means flying with that primary baro is unsafe until the cause is fixed.

Will increasing EK3_ALT_M_NSE fix the underlying glitch?

No. EK3_ALT_M_NSE tells the EKF how much noise to expect from the barometer; raising it makes the EKF discount baro updates so altitude estimates rely more heavily on GPS and accelerometers. It is a mitigation that helps tolerate a noisy environment, not a fix for a sensor that is genuinely failing or being heated by the sun. Treat it as a backstop, not a cure.

Can vibration alone cause what looks like a barometer glitch?

Yes, frequently. MEMS pressure sensors share a die with mechanical structures that vibration can excite directly. If VIBE.VibeZ exceeds 30 m/s² around the time of the apparent glitch, the barometer reading is a symptom of the vibration problem, not the cause. Fix the vibration first; the baro complaints usually disappear with it.

Diagnosing BARO Glitch Events in ArduPilot .bin Logs

TL;DR: A barometer glitch shows up in an ArduPilot dataflash log as ERR Subsys=18 ECode=2, a sharp divergence between BARO.Alt and CTUN.Alt, or BARO.H dropping to 0. The three causes we see most often are direct sunlight on an unfoamed sensor, prop wash hitting the barometer port on a VTOL, and severe vibration (VIBE.VibeZ > 30 m/s²) corrupting MEMS pressure readings. Foam the sensor, relocate it away from prop wash, and raise EK3_ALT_M_NSE from the default 1.0 to 3–5 if the environment is genuinely noisy.

What a BARO glitch actually is in the log

ArduPilot writes barometer telemetry to a message called BARO each time the sensor is sampled by the driver (typically 25–50 Hz on Pixhawk-class hardware). The fields you care about are:

BARO  TimeUS  I  Alt  AltAMSL  Press  Temp  CRt  SMS  Offset  GndTemp  H  CPress

Key fields when diagnosing a glitch:

Alt — altitude derived from Press, in metres, relative to the pre-arm reference.
Press — raw atmospheric pressure in Pa. A real glitch shows up here first.
Temp — sensor temperature. A sudden 5–15°C jump on a small frame in still air is almost always sunlight hitting the sensor.
H — health flag, 1 when the driver considers the sensor reliable, 0 when it has been flagged unhealthy.
I — instance number. Most modern flight controllers have two or three barometers; you may glitch on one and not the others.

When the autopilot detects a glitch, it also writes a separate ERR message with Subsys = 18 (BARO) and ECode = 2 (BARO_GLITCH). The ERR line is the cleanest indicator that the firmware itself agreed something was wrong — if it isn’t there, you may be looking at noise that the EKF absorbed without complaining.

Confirming it in Mission Planner

Open the .bin log via Flight Data → DataFlash Logs → Review a Log, then plot:

BARO.Alt versus CTUN.Alt. CTUN.Alt is the EKF’s fused altitude. A divergence in the tens of metres while the drone was visually steady is the smoking gun.
BARO.H. Even one drop to 0 during flight is worth investigating.
The Errors tab in the Log Browser will list every ERR line with a translated subsystem name, so you don’t have to remember that 18 means barometer.

Confirming it in MAVExplorer

If you prefer the MAVProxy toolchain, this overlay gives you the same picture in one command:

MAV> graph BARO.Alt CTUN.Alt POS.Alt VIBE.VibeZ
MAV> messages ERR

Watching POS.Alt (GPS altitude) and VIBE.VibeZ alongside the barometer trace is what separates real glitches from secondary symptoms. If POS.Alt and BARO.Alt agree but CTUN.Alt drifts, you have an EKF problem, not a baro problem. If VIBE.VibeZ exceeds 30 m/s² right where BARO.Alt spikes, the “glitch” is really a vibration issue corrupting the MEMS pressure cell — the fix lives in our VIBE message guide, not here.

Why it happened — ranked by what we see most often

Direct sunlight on an exposed barometer. The MS5611, BMP388 and DPS310 dies are MEMS diaphragms a few millimetres across. They warm rapidly when sun lands on them, the membrane shifts, and you read an altitude that’s tens of metres off. Almost always shows up with a coincident BARO.Temp jump.
Prop wash on a VTOL or QuadPlane. If the barometer sits where a transitioning prop pushes air over it, you get a dynamic pressure spike that looks identical to a real altitude change. ArduPilot also logs a BARD message with DynPrX/Y/Z — non-zero values during steady flight are a tell.
Vibration above 30 m/s² on the Z axis. A failing motor mount or out-of-balance prop will saturate the MEMS pressure sensor before it saturates the IMU. The cure is mechanical, not baro-side.
Rapid altitude change beyond the baro’s response time. Aggressive dive recoveries can transiently look like a glitch. If the “glitch” matches a real manoeuvre and self-resolves within a second or two, it isn’t one.
Sensor degradation. A sensor that has lived through a few crashes will eventually show a persistent offset drift — BARO.Offset climbing over multiple flights with no obvious environmental cause. Replacement is the only honest fix.

Fixing it

Foam the barometer. Open-cell foam, dark colour, covering the chip without sealing the port. This single change has resolved more glitch complaints on the ArduPilot Discourse than any parameter tweak.
Relocate if it’s a prop-wash problem. On QuadPlanes, mount the flight controller (or at least its external baro) below the wing chord, not in the transition airflow.
Calibrate the ground reference. Mission Planner → Setup → Mandatory Hardware → Accel Calibration → Calibrate Level. The first arming after a power cycle uses the ground temperature and pressure to anchor altitude, so a bad calibration becomes a permanent offset.
Raise EK3_ALT_M_NSE. Default is 1.0. Raising it to 3.0–5.0 tells the EKF to weight baro measurements less, which is appropriate if you fly in known-noisy environments (high vibration airframes, sun-baked rooftops). It is not a substitute for actually fixing the hardware. This Discourse thread walks through the trade-offs in detail.
If you have a working RTK GPS, switch source. EK3_SRC1_POSZ = 3 (GPS) lets the EKF fall back on RTK altitude instead of barometric. Only do this if your GPS reliably reports vertical accuracy under 0.5 m — non-RTK GPS altitude is worse than even a glitchy baro.
Use redundancy. If you have multiple barometers, set BARO_PRIMARY to the instance that isn’t exposed to sun or airflow.

When this is not actually a barometer problem

Three patterns we see misdiagnosed as barometer glitches:

EKF lane switch. CTUN.Alt jumps but BARO.Alt and POS.Alt stay clean — the autopilot switched IMU/EKF cores and re-anchored. Different problem entirely.
Compass-induced position drift. The drone climbed unexpectedly because the EKF’s heading was wrong, not because the baro lied. Look at MAG.MagX/Y/Z and NKF1.IYAW innovations.
Power module sag. Brown-outs cause logs to end mid-flight, which can look like the baro “stopped reporting”. Check POWR.Vcc for dips below 4.7 V.

When LogHat helps — and when it doesn’t

Drop the .bin into LogHat and we’ll flag ERR Subsys=18 ECode=2 events automatically, overlay BARO.Alt against the fused altitude in the 3D replay, and correlate against vibration so you don’t chase the wrong root cause. What we can’t do is tell you whether the sun was on the sensor at the moment of glitch — that requires you to remember the flight conditions and check the airframe. The log gets you to a confident diagnosis; the fix still belongs to the engineer with the screwdriver.