MultiNav Pro+ sensors module - barometric altitude vs GNSS altitude, which to trust?

Yeah that 8-10m gap is pretty normal honestly - GNSS altitude is notoriously the weakest axis of a GPS fix (vertical DOP is usually way worse than horizontal), and baro has its own drift with temperature and weather. For UAV work most people end up fusing both with a complementary or Kalman filter rather than trusting either one solo, baro handles short-term relative altitude pretty well and GNSS keeps the long-term drift honest. If you're not doing sensor fusion yet that's probably where I'd focus next.

@James Gonzalez yeah this is one of those things that trips up a lot of UAV builders and the answer is basically: trust neither one alone, but understand what each is actually measuring.

 

GNSS altitude is ellipsoidal height — it's measuring your distance from a mathematical model of the earth's shape, not from sea level or the ground. Barometric altitude is derived from pressure, which is affected by temperature, weather, and your local reference pressure setting. Those two things measuring different things is exactly why they disagree, and 8-10 meters is actually pretty normal — you can see 10-20m offset depending on temperature gradient and how far your local pressure deviates from standard atmosphere.

 

For a UAV telemetry setup, the usual approach is to use baro as your primary altitude reference for flight control (it's faster, more stable moment-to-moment, doesn't have the vertical accuracy issues GNSS has), and use GNSS altitude as a sanity check or for absolute positioning context. The trick is to calibrate your baro on the ground before takeoff using a known pressure reference — if you have accurate ground-level QNH from a nearby weather station, you can dramatically tighten that offset. You can also fuse the two with a complementary filter or Kalman filter, which is what most autopilots do — baro handles the high-frequency altitude changes, GNSS slowly corrects for drift over time.

 

Worth knowing: the RFOXiA GNSS module runs at 18Hz which gives you plenty of update rate for fusion if you want to go that route, and the air pressure sensor on the sensors module should give you solid baro data as long as you're not mounting it somewhere it's going to get prop wash or heat soak from electronics. Placement matters a lot more than people expect.

James nailed it - the complementary filter approach is honestly the easiest starting point, something like baro_filtered = alpha * (baro_filtered + delta_baro) + (1 - alpha) * gnss_alt where you tune alpha to taste. I ran something similar on a build last year and it cleaned up the jitter a lot, just make sure you're correcting your baro reading for temperature if the sensors module gives you that data, otherwise you'll see extra drift on cold days.

One thing worth adding - make sure you're recalculating your sea level pressure reference (QNH) whenever you get a confident GNSS fix, otherwise your baro baseline can just silently wander and the fusion won't save you. I do a rolling update every 30s or so when HDOP is looking good and it keeps things a lot more stable than a one-time calibration at boot.

Thomas that rolling QNH update trick is underrated - I'd also add that if your sensors module is exposed to any prop wash or airframe vibration you'll want to make sure you're averaging the baro readings over a decent window before feeding them into the fusion, raw samples off a vibrating board can look really noisy and throw off your alpha tuning. Took me an embarrassing amount of time to figure out why my filter was behaving weird on one build before I caught that.

Really good thread - one thing I'd add on top of Mary's point about prop wash is that if the sensors module has any kind of pressure port or vent opening, even the orientation of the board relative to airflow can induce a static pressure error (Bernoulli effect basically), so worth experimenting with placement/shielding if your baro readings seem consistently biased in flight vs on the bench. Took me a while to realize my numbers were cleaner when I tucked the board more into the airframe rather than leaving it exposed.

All of this is solid advice - one thing I'd stack on top of Elizabeth's shielding point is that even foam tape underneath the sensors module can make a noticeable difference in dampening both vibration noise and direct pressure artifacts, basically kills two birds at once. Spent way too long tuning filters on a build before someone told me to just stick the board down properly and half my problems went away lol.

Solid thread - one thing I'd throw in on top of all this is that baro is almost always going to win for short-term vertical rate (it's faster and less noisy than GNSS altitude which can jump around even on a good fix), but GNSS is what keeps your absolute altitude honest over time, so a complementary filter where baro handles the dynamics and GNSS slowly corrects the baseline is really the move rather than trying to pick one or the other. The 8-10m disagreement you're seeing is honestly pretty normal, GNSS altitude is the weakest axis of a fix geometry-wise and that error can be double or worse your horizontal accuracy.

John nailed it - just want to reinforce that the vertical dilution of precision (VDOP) on a typical GNSS fix is noticeably worse than horizontal, so that 8-10m gap isn't a sign anything's broken, it's just the geometry of how satellites are distributed overhead. Complementary filter is the right call, and once you get the time constants dialed in for your specific airframe it really does feel like you get the best of both worlds.

One thing worth adding to the complementary filter approach - if your sensors module gives you temperature data too, its worth using that to compensate the baro reading since pressure sensors drift with temp and on a UAV you'll see real temperature swings between ground idle and altitude that'll shift your baseline. Makes the GNSS correction job a lot easier when the baro isn't also fighting thermal drift on top of everything else.

James's point on temp comp is crucial and honestly undersold - I'd go one step further and say if you can log the temp coefficient behavior on the ground before flight (warm up the board, watch the baro drift, characterize it) you can bake a pretty solid correction curve in before you even lean on the GNSS to clean it up. Saved me a lot of headache on a long-endurance build where the thermal swing from takeoff to cruise altitude was wrecking my baro baseline before the complementary filter could even catch up.