GPS: Effect of doing a database dump/restore on lock times?

0 votes

Hi All -

I'm trying to utilize an external uC to save the internal state of the GPS.  To this effect, I'm utilizing the following messages at startup:

  1. UBX-MGA-INI-TIME_GNSS (restored to GPS time)
  2. Series of UBX-MGA-DBD commands saved from previous shutdown of GPS
  3. UBX-MGA-INI-POS_LLH - Saved position from previous shutdown of GPS

Should this behave similarly to a hot start for short periods of time if implemented correctly?

I'm getting much faster hot start times (less than a second) than I am with the saving and restoration of the state of the module which is not expected, but I also do not see any documentation on what the expected time for these circumstances are.  One thing that surprised me is that the PPS coming out of the GPS does not align with the pushed GPS time right away, but still waits until the actual GPS lock although other messages coming out of the GPS indicate to me that it did indeed take in the time.

I'm syncing the clock to and from the GPS module with the uC utilizing the UBX-TIM-TP and UBX-MGA-INI-TIME_GNSS both configured to save GPS time and utilize a rising edge on their respective electrical signals.  With an oscilloscope, I can see that the edges between the two (GPS generated edge vs uC generated edge) are within 1 RTC clock tick on the 32.768kHz clock - within approximately 31uS.  (I'm also calibrating the RTC in our uC from the PPS signal to avoid drifting.)

(If it matters, we're using the EVA-M8M.)



by SomeCallMeTim asked Feb 28, 2017
by SomeCallMeTim edited Feb 28, 2017
0 votes
The following is generic GNSS, not necessarily how u-blox products work.
 Only implementation of hardware-based precise time aiding (within about 100us of TRUTH) can help achieve very short TTFF.
Otherwise, coarse time aiding only gets you close. If the RTC drifts compared to satellite truth, regardless of whether the M8's or MCU RTC, the system must then search for unambiguous lock to satellite signal reference  bit edge based on decoding data frames.
The receiver needs to achieve precise time lock based on received satellite signals before 1PPS is synched. This TTFF can take 6 to 12 seconds or more with good signal levels if RTC has not been calibrated and allow precise synch.
Note that RTC crystals can change frequency very easily hence can drift out of phase with satellite signals quickly.
by grampy answered Feb 28, 2017
by grampy edited Feb 28, 2017
0 votes
I am not sure what you are doing exactly.  If you have V_BCKP connected then receiver will keep time and ephemeris and perform a hot start as long as time off is less than 2-4 hours.

If you do not have V_BCKP connected then DBD command could be used to save ephemeris.  Then providing time should be sufficient.

if you want to use AssistNow Autonomous - has to be enabled, then DBD command would save the data as well.

Receiver description has nice sections describing how to implement assistance data for different options.
by grumpy answered Mar 8, 2017
website banner