MultiNav Pro+ GNSS 18Hz fix rate - anyone actually hitting that in practice?

Omar Johnson•June 12, 2026

Hey all, been working on a drone tracking project and I picked up the MultiNav Pro+ GNSS module partly because of that 18Hz fix rate. On paper that's insane for this price range, most of the modules I've used before top out at 10Hz and you really feel it when you're trying to log fast movement. But I'm only seeing somewhere around 12-14Hz consistently in my tests and I can't figure out if I'm doing something wrong on the config side or if there's some condition that needs to be met to actually unlock the full rate.

💬 6 replies👍 0 likes👁 0 views

Replies

Joel Sanchez•June 12, 2026

Yeah 18Hz is the ceiling under basically ideal conditions - open sky, low satellite constellation load, and you need to make sure you're not bottlenecked on the UART baud rate (a lot of people leave it at 9600 and wonder why they're dropping frames). Bump it to 115200 and double-check your NMEA sentence output isn't cluttered with sentences you don't need, trimming that down freed up a solid 3-4Hz for me on a similar setup.

Peter•June 12, 2026

Seconding what Joel said on the baud rate - that got me too the first time. Also worth checking if you have GLONASS + GPS both enabled, running dual constellation adds processing overhead and can shave a couple Hz off your ceiling depending on satellite count at the time, so if you don't need GLONASS for your use case just turn it off and see if that bumps you closer to the top end.

Curtis Elliott•June 12, 2026

Both solid tips above - one more thing I'd add is that temperature can actually play into this too, I noticed my unit would throttle a bit when it got warm sitting in direct sun during outdoor tests. Threw a small heatsink on the RF shield and it stayed closer to 16-17Hz through longer sessions.

Omar Johnson•June 12, 2026

All good tips in this thread - one thing nobody mentioned yet is double checking your fix rate config is actually being written to flash and not just RAM, because if you're cycling power between tests the module might be reverting to defaults and you'd be chasing ghosts. Use the CFG-CFG save command after you set everything up and see if your numbers get more consistent across sessions.

Jason Lambert•June 12, 2026

Omar's point about the flash save is huge and I've been burned by that exact thing more times than I want to admit - also worth checking is whether your host MCU is accidentally sending any init strings on power-up that reset the module config back to defaults before your app even starts running.

Amber Bowman•June 12, 2026

Jumping in late but another thing worth checking - if you're on the default 9600 baud you're almost definitely leaving Hz on the table since the serial throughput literally can't keep up with the data volume at 18Hz, bump it to 115200 and you'll probably see an immediate jump. Also +1 on the flash save thing Omar mentioned, that one is such a time sink when you don't know to look for it.