Can UBX-MGA-INI-TIME_UTC be used to provide leap seconds when GPS is the best time source?

0 votes
78 views
Hello,

What I am trying to achieve is to avoid a discontinuity in time between systems with the same pre-loaded leap second value but it is unknown whether they happened to receive the updated leap seconds in the short amount of time they were powered on. In all cases, the UBLOX MAX-8Q is being used as the best time source on board.

I would be able to keep track of leap seconds separately on a microcontroller but would not know the time until the GPS gets a time fix and is outputting a pulse-per-second. The UBX-MGA-INI-TIME_UTC message seems like it is intended to prime the ublox receiver with the time before it can obtain a fix so I am not sure what the behavior would be if I used it just to set the leap seconds. For example, the time source can either be upon receipt of message or on a pulse provided to EXTINT. Unfortunately I do not have EXTINT connected so would having the source set to none make the timing worse for some period of time? Or would it quickly correct itself given that it has a fix and just maintain the updated leap seconds? Has anyone tried to connect TIMEPULSE to EXTINT and use that to tell the receiver what time it is based on what time it just said it was + updated leap seconds?

Additionally, could I simply specify an accuracy to no better than within a second and send this message immediately after receiving the time from the GPS and expect the GPS to update it's leap second value and proceed with sending the correct time? So the flow would essentially be:

1. Pulse-per-second triggers interrupt

2. Issue $PUBX,04 to get time

3. Issue UBX-MGA-INI-TIME_UTC to update leap seconds with a value stored in non-volatile memory

4. Enable RMC,ZDA, etc. messages expecting the time values to reflect the updated leap second value.

Surely someone must have some experience with doing this or something similar. Any suggestions or experiences you can offer to share would be greatly appreciated.
asked Jun 19 by dgiaya

1 Answer

0 votes
Best answer
As you know leap second is broadcast once every 12.5 min and receiver will update time once it receives this info.  Leap second has no effect on timepulse as it is just a pulse at 1 Hz (by default).  UTC time is the one that would change.  Receiver does report UTC time as well as info on leap second in NAV-TIMEGPS or PUBX,04 messages.  You can simply wait for leap second value to be set by the receiver or you could use UBX-MGA-GPS-UTC message to send current leap second info to the receiver.

Hardware pins can't be used to set leap second or to "expedite" leap second reception.  EXTINT could be used to provide time sync to help with faster TTFF but that will not change leap second reception.
answered Jun 19 by grumpy Senior Principal Expert
selected Jun 19 by dgiaya
My mention of the timepulse and hardware pins was as a method of sending the MGA-INI-TIME_UTC message referenced to a known time because that message also contains a field for leap second offset but I was under the impression I would have to send a completely valid time. I realize that the synchronization of the time is a separate issue from updating leap seconds and one I would prefer to avoid.

The UBX-MGA-GPS-UTC message contains several fields such as parameters of the UTC polynomial and the day/week of scheduled leap second change that I would not be able to provide until the GPS received ephemeris. Is it possible to send this message with all fields blank except for the "Delta time due to current leap seconds" field without any adverse effects?

Thanks for the prompt and helpful reply
I don't see any leap second specific flags in the message so I would suggest sending time and leap second info but setting "source" to 0 and specifying accuracy.  Since receiver will have time actual accuracy of provided time should not be critical.
This seems like a reasonable way to proceed. Thanks