UBLOX Hot Fix Times

0 votes

I recently carried out some tests on a UBLOX 8 (M8030 based) to see the variation in hot fix times over a 24 hour period. The project involved an Arduino waking up from sleep every 10 minutes and waiting till the GPS got a new fix, transmitting the fix and fix time information over a LoRa link and then going back to sleep. The GPS hot fix times were collected on a remote receiver which recorded the data on an SD card in CSV format so the data could be graphed. The result for a 24 hour period was;



The overall performance was OK, an average of 11.63 seconds fix time, so a considerable power saving over running the GPS continuously.

Although a lot of the fixes are under 5 seconds (good!) there is clearly a cyclic nature, approximatly once per hour the fix time is 32 seconds, which is very close to the cold fix time.

Is this variation in hot fix time normal, and if not is there anything that can be done to reduce the hot fix time average ?


by srnet asked Jan 10
0 votes
The long TTFF is inherent in GNSS. Sateliites rise into view then disappear from view. Ephemeris data is only valid for up to four hours then must be refreshed.
 For GPS, the receiver needs 18 to 36 seconds to download ephemeris from newly risen satellites and refresh from some satellites  in order to achieve a position fix.
You can avoid that long TTFF only if you provide aiding data from an external source.  Read up on A-GNSS, AssistNow Online, AssistNow Offline.
by grampy answered Jan 10
by afremont selected Jan 10
Best answer
What an excellent and very prompt answer, I suspected as much.

As a side issue, I presume the Empheris data for each of the GPS satellites is dynamic, as in constantly changing, so its not possible to have a catalog of fixed data loaded for all possible satellites ?
You are correct; ephemeris minutia are constantly changing because the satellite is subject to a variety of perturbing forces.
The GNSS system needs to offer cm-level accuracy of each satellite's position at a nanosecond  scale  
The closest you get to a preset table is from the synthesized/predicted  almanac and/or ephemerides within AssistNow Offline and AssistNow Autonomous features. And those also require constant refreshes as well.

And thank you for the excellent experiment/study and graph. Your graph should be a reference illustration for those who are trying to understand the tradeoffs in optimizing battery life with the power on/power off cycles for their GNSS application
website banner