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

+1 vote

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.
by dgiaya asked Jun 19, 2017
0 votes
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.
by grumpy answered Jun 19, 2017
by dgiaya selected Jun 19, 2017
Best answer
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

Old thread...(does less than 1 year count?)

I also try to ensure the latest leap second capture, but I see differences in PPS behavior between SPG 2.01 and SPG 3.01 with a MAX-M8W.

On 2.01 leap second validity doesn't seem to have a severe impact on PPS accuracy. Whereas on 3.01 the PPS will not come into alignment until leap second is acquired (that is, the PPS is off about 20mS-200mS despite reporting 3D lock).

dgiaya, have you seen anything similar?
grumpy, any comments?

Thanks in advance for your time!
I think on 2.01 time pulse was set to GPS time and on 3.01 it is set to UTC.  That means that on 3.01 timepulse is not output until UTC is correct = has leap second info.  Set timepulse to GPS time on 3.01 and should be the same as 2.01.
Don't think the accuracy has anything to do with it - it's a full second difference....
Thanks for the reply grumpy!

Just an FYI for others....The Protocol Spec default settings for UBX-CFG-TP5 show:
SPG2.xx - flags-gridUtcGps = 0 (UTC)
SPG3.xx - flags-gridUtcGnss = 0 (UTC)
SPG3.01 added ability to change to GLOSNASS and other timepulse grids. 2.01 could only select UTC or GPS.

Grumpy: I agree that according to the spec they should only be 100's of nS apart at most, but I personally seeing issues of the timepulse being misaligned to non-integer number (not full second) of difference between 2.01 and 3.01. This is using UTC setting.

However, when using the GPS setting the 3.01 FW act more correctly despite not having the latest LS value or running on default. I'm still looking into understanding why. Thanks for your help, you might have, at least, given me a working around!