MultiNav Pro+ GNSS 18Hz fix rate — anyone actually pushing this in a high-speed drone application?

Been running MultiNav Pro+ on a similar fixed-wing setup and yeah, 18Hz sounds great on paper but you'll want to watch your UART baud rate — if you're not running at least 115200 you'll start seeing buffer lag that looks exactly like the jitter you're describing, the fix rate outpaces the data throughput. Also worth checking if your flight controller is actually timestamping on receive vs. when the NMEA sentence completes parsing, that gap adds up fast at speed.

Julie nailed the baud rate thing — I'd also double-check that you're using the binary output protocol instead of NMEA if the module supports it, the sentence overhead on NMEA is brutal at 18Hz and you're basically wasting half your bandwidth on ASCII formatting. Switched to binary on my last build and the jitter basically disappeared overnight.

Both good points above — I'll add that if you're on the binary protocol and still seeing jitter, double-check your antenna placement relative to your IMU, because at 18Hz the GNSS position updates can start fighting your sensor fusion if the phase center offset isn't accounted for in your EKF config. Took me an embarrassing amount of time to figure that one out on a previous build.

Charles that antenna phase center offset thing burned me too on an earlier build — one thing I'd add is that if you're running an EKF make sure your GNSS timestamp is actually synced to your IMU clock domain and not just being tagged on arrival, because even a few milliseconds of systematic offset will show up as velocity estimation drift at speed that looks a lot like jitter but won't go away no matter how much you tune the covariance matrices.

Tanya's clock sync point is huge and honestly underrated — I spent way too long chasing what I thought was an antenna problem before I realized my GNSS timestamps were being tagged on UART receive instead of using the module's PPS signal as the reference, once I wired PPS into a hardware interrupt and used that to anchor the IMU/GNSS time alignment the velocity jitter basically vanished. If the MultiNav Pro+ has a PPS output (check the datasheet, pretty sure it does) def worth setting that up before you go deeper on the EKF tuning rabbit hole.

Revital's right, PPS is the move — once you've got that wired to a hardware interrupt the whole timing picture just snaps into place. One thing to double check once you're there: make sure your flight controller is actually latching the interrupt edge correctly and not introducing any software debounce delay, because I've seen that eat like 2-3ms of your hard-won timing accuracy right back up.

Quick add to what Charles L said about interrupt latching — if you're on an STM32-based FC, make sure the PPS interrupt is on a proper EXTI line and not accidentally sharing priority with your UART DMA or you'll get occasional priority inversion that shows up as exactly the kind of random 1-2ms timing glitch that'll drive you insane to debug. Burned a weekend on that one.

Curtis that EXTI priority thing is such a sneaky one — I'd also throw in that if you're logging timestamps for debugging, make sure you're not accidentally capturing them inside an ISR that itself gets preempted, because the timestamp you think is the PPS edge might actually be a few µs late depending on your NVIC config.

All solid points on the NVIC config — one thing I'll add from our side since we work closely with the MultiNav Pro+ team: the module's PPS jitter spec is sub-microsecond but that budget evaporates fast if your pull-up resistor on the PPS line is too weak and you're getting a slow rise time into the interrupt pin, so double check you're not running more than 10k there. Seen a few builds where the signal looked fine on a logic analyzer but the edge was mushy enough to shift the latch point by a few µs under load.

Alicia that pull-up thing is such a gotcha — I had a very similar issue on a previous build and ended up going down a whole rabbit hole before I finally just scoped the actual pin on the MCU side (not at the module) and saw the rise time was way softer than expected. 4.7k sorted it immediately, been solid ever since.