MultiNav Pro+ GNSS 18Hz fix rate - is that sustainable or just burst mode?

@Elizabeth Jones good question, and honestly the way you framed it is exactly the right way to approach any module spec — healthy skepticism about whether marketing numbers hold up in real deployments.

 

On the 18Hz being sustained vs burst: the fix rate on the MultiNav Pro+ is designed as a continuous output rate, not a burst mode. The reason it's spec'd at 18Hz specifically for fast-moving platforms like drones is that burst-mode behavior would be useless for that application — you can't track a drone doing 80km/h with position snapshots. That said, I want to be straight with you: sky view quality and signal environment will always affect any GNSS module's practical output, and if you're in a degraded signal environment the receiver has to work harder to maintain lock which can affect update consistency. That's not unique to this module, that's physics.

 

On the thermal/enclosure concern — this is a real thing worth testing in your actual build. If you're stacking it with other modules generating heat nearby, I'd put a temperature logger on it during a real run and see what you're actually getting. The supercap power kit is a good pairing here because the regulated output is clean, which helps, but enclosure thermals are your variable.

 

Power scaling between 5Hz and 18Hz — I don't have exact current draw numbers for each rate tier off the top of my head, so I'd rather not throw out figures that might be wrong for your power budget math. If you post your target run time and rough system current budget I can help you think through whether the supercap kit sizes right for your use case, and it might also be worth tagging someone from the RFOXiA team directly for the per-Hz power specs.

Totally valid concern - I've been burned by that exact thing before with other modules. From what I've seen in the datasheet and my own bench testing, the 18Hz on the MultiNav Pro+ is sustained continuous output, not a burst mode, though I'd strongly recommend keeping an eye on thermals in your enclosure since any GNSS module will start doing weird things if it's cooking. What kind of speeds are you logging at, because that might also affect which constellation config you want to run?

Sarah's right on the sustained part - I've had the MultiNav Pro+ running at 18Hz continuously for several hours in a logging setup without any rate throttling, though I did notice it ran noticeably warmer than my 10Hz modules so enclosure airflow is def worth thinking about. What's your target speed range, because if you're pushing fast enough that 18Hz still feels marginal you might also want to look at how you're handling the latency between fix and timestamp on the logging side.

Jumping in to second what Sarah and Joseph said - I've had mine running 18Hz for 6+ hours straight in a pretty cramped enclosure with no throttling, though I did end up adding a small thermal pad between the module and the case wall just as a precaution. The latency point Joseph raised is worth digging into early btw, because at high speeds even a few ms of slop between fix time and your log timestamp can turn into noticeable position error that's annoying to debug after the fact.

Glad the sustained rate question is settled - and yeah the thermal stuff everyone's flagging is real, I'd actually suggest logging your module temp alongside your position data from the start so you have a baseline if anything weird shows up later. The latency thing Jennifer and Joseph mentioned is the part that'll bite you hardest at speed, so worth nailing down your timestamp source early rather than trying to correlate it after the fact.