MultiNav Pro+ GNSS 18Hz fix rate - anyone actually pushing it that fast?

Christina Scott•June 12, 2026

🐛 Bug Report📱 Mobile App

Hey all, been working on a drone telemetry logger using the MultiNav Pro+ GNSS module and I'm trying to squeeze every bit of performance out of the 18Hz fix rate. In my current setup I'm getting solid locks but I'm only seeing around 10-12Hz consistently coming through on the UART output. Not sure if I'm hitting some kind of bottleneck on my baud rate config or if there's an initialization sequence I'm missing to actually unlock the full 18Hz. The 1-second first fix is definitely real though, that part impressed me.

💬 7 replies👍 0 likes👁 0 views

Replies

Brittany Thompson•June 12, 2026

Yeah I ran into the exact same wall - turns out the 18Hz mode needs you to explicitly set the update rate via the proprietary PMTK command (PMTK220 with 56ms interval) AND bump your baud to at least 115200, otherwise the module just kinda silently throttles itself back down. Double check your UART config first bc that was my culprit before I even got to the init sequence stuff.

Michael Hawkins•June 12, 2026

Brittany's right on the baud rate thing, and I'd add that you also want to make sure you're disabling any NMEA sentences you don't actually need - every extra sentence you're streaming eats into your bandwidth budget and the module will quietly cap the rate to stay within it. On my setup I stripped it down to just GGA and RMC and that alone got me from ~11Hz to stable 17.5Hz before I even touched PMTK220.

Rajesh Malik•June 12, 2026

Yep, all of the above is solid advice - one more thing I'd add is double check that your UART RX buffer isn't overflowing and causing silent drops, because I had a situation where everything looked configured correctly but I was losing fixes intermittently and it turned out my MCU side buffer was way too small for the burst at 18Hz. Bumped it up and suddenly I was seeing clean 18Hz with no gaps.

Amanda Crawford•June 12, 2026

All three of these are spot on and honestly that combo - baud rate + PMTK220 + stripping unnecessary sentences + RX buffer - is basically the full checklist, so if you work through all of them in order you should get there. One thing I'd add from my own experience is that the 18Hz mode also seems a bit picky about antenna quality/sky view, so if you're still seeing occasional dropouts after fixing the config side, worth ruling out that your fix quality is dipping and the module is compensating by slowing the rate.

Kenneth Hill•June 12, 2026

Thread's basically solved at this point but one thing I'll throw in from my own drone builds - at 18Hz you're also going to want to watch your parse timing on the MCU side, because if your main loop is doing anything blocking (even briefly) you'll start seeing the buffer pile up and Rajesh's symptom creeps back in even with a big buffer. Learned that one the hard way chasing a "mystery" dropout issue for like two days.

Donald•June 12, 2026

Solid thread, basically everything I'd have said is already covered - but just to put a number on Kenneth's point, at 18Hz you've got ~55ms between fixes so any blocking call over even 20-30ms starts stacking up fast. If you're on an STM32 or similar, moving your NMEA parsing to a UART idle interrupt instead of polling in the main loop made a huge difference for me.

Michelle Riggs•June 12, 2026

Late to this thread but just want to +1 the idle interrupt approach Donald mentioned - that change alone cleaned up like 80% of the weirdness I was seeing on my own build before I'd even touched the baud rate config. Once you go interrupt-driven for NMEA you'll never go back to polling.