RFOXiA LogoRFOXiA Club
← Back to DevHub

MultiNav Pro+ GNSS 1-second first fix - is that cold start or warm?

Tanya ParrishJune 12, 2026
Hey everyone, been integrating the MultiNav Pro+ GNSS module into a wildlife tracking collar I've been building and I keep coming back to one spec that I can't find a clear answer on in the docs - the "first fix in 1 second" claim. Is that a warm start time (i.e. it already has ephemeris data cached) or are we actually talking cold start from a completely unpowered state? Because those are very different numbers in the real world and it changes how I design my power cycling logic pretty significantly.
💬 6 replies👍 0 likes👁 0 views

💬 Want to join this discussion?

Join the Community on RFOXiA Club →

Replies

Cody MurphyJune 12, 2026
That 1-second figure is warm start - cold start on the MultiNav Pro+ is more like 26-30 seconds in my testing, so definitely factor that into your power cycling logic or you'll burn way more battery than you expect waiting for a fix after a full power-down. If you're doing deep sleep cycles on the collar I'd look into keeping the backup supply line alive to preserve the ephemeris cache, makes a huge difference.
Samuel ScottJune 12, 2026
Cody's right, and I'll add that on our wildlife collar builds we keep a small supercap on the backup line specifically for this - even if the main battery dies completely the ephemeris stays cached long enough that the next boot still gets that fast warm start fix. Saved us a ton of headache with the power budget.
Jake SantosJune 12, 2026
Both solid approaches - one thing I'd add is that ephemeris data typically goes stale after ~2 hours anyway, so even with the supercap trick you'll eventually hit that cold start window if the collar's been off long enough, worth building in some tolerance for that 26-30s worst case in your fix-acquisition logic rather than assuming warm start every time.
Jeffrey HutchinsonJune 12, 2026
Jake makes a good point on the 2hr stale window - we actually log a timestamp on power-down and check it on boot so the firmware knows upfront whether to expect a warm or cold fix and can set the timeout accordingly, saves you from a situation where the collar just sits there "waiting" when it should've already moved on.
Julia ChavezJune 12, 2026
Jeffrey's timestamp approach is really clean, we do something similar but also pair it with an HDOP threshold so if we're not getting a decent fix within the expected window we flag it in the log and bump the retry interval rather than hammering away at it. Saves a lot of confusion when you're pulling data back from the field and trying to figure out why position accuracy tanked on a particular day.
Shannon VazquezJune 12, 2026
Really solid thread - the timestamp + HDOP combo Julia mentioned is basically what we settled on too, and honestly the stale ephemeris cutoff is the thing that bites people most when they're only testing indoors with short power cycles and then wonder why field performance looks so different. To directly answer the original question though, that 1s spec is warm start, cold start on the MultiNav Pro+ is more like 26-30s in open sky conditions per the datasheet appendix (easy to miss, it's buried in the acquisition timing table).

💬 Want to join this discussion?

Join the Community on RFOXiA Club →