On 2017-02-06 06:30 PM, Tom Van Baak wrote:
I'm not a GPS expert. IS-GPS-200G is dense. The TAI-UTC value is
signaled, but how its encoded is complicated, and when its updated is
unclear to me. See 20.3.3.5.2.4 Coordinated Universal Time (UTC). Can
anyone speak to that and this topic? What does GPS do? Is it clear? Or
does it actually suffer from this same ambiguity we are discussing?
Remember, the alleged ambiguity is only about the what / when of time scale
integer offsets. There's no ambiguity in TAI or UTC or GPS time stamps
themselves. GPS receivers tend not to output anything like an offset, so they
are immune from this discussion.
Sure, GPS navigation relies on GPS time, not UTC. That's the whole point
of its primary timescale; ignoring UTC for that purpose. PTP does the
same - UTC is treated as a second class citizen.
Most commercial GPS timing receivers tend to output GPS time or UTC; there are
internal configuration commands. Their UTC rolls over as one would expect and
they output 23:59:60 appropriately.
That's where my question is. A GPS receiver would read the UTC metadata
supplied in the GPS signal to generate UTC 23:59:60 from the primary GPS
time, right?
We see from this discussion there are several ways folks use to
calculate this conversion, but what method to use may depend on the
organization of the metadata.
How is the UTC metadata handled in a GPS receiver? IS-GPS-200G,
20.3.3.5.2.4 Coordinated Universal Time (UTC) explains a lot, but its
pretty complicated how the various metadata components are encoded and
updated. My question is, after decoding and adjusting the GPS data, when
is the TAI-UTC portion of the metadata updated? At the beginning of, or
the end of, the Leap Second?
To get TAI one just adds 19 to GPS time. So no worries either way.
Right, but I am still a little worried.
If I were building a GPS-to-PTP receiver/generator, how would I read the
GPS UTC metadata to populate the PTP UTC metadata? In particular, when
should timePropertiesDS.currentUtcOffset be incremented? This has
critical significance to the device receiving the PTP signal if accurate
UTC is a requirement.
Some cheaper GPS receivers output UTC date and time only, via easy-to-use NMEA
sentences. In addition, by design, they avoid a 23:59:60 time stamp, which
would upset upstream instruments. So during a leap second they either output
23:59:59 twice, or output 00:00:00 twice, or stutter and reset and stumble into
the next day.
"Stutter and stumble" is not the sort of behavior we're seeking, I hope. :-)
This goes back round to the question of how UTC is mapped into
86400-second-day systems, such as POSIX time. Does the Leap Second map
to 23:59:59>23:59:59 (freeze), or 00:00:00>00:00:00 (rollover and reset)?
David Wells says NTP does the first, and POSIX time does the second:
The NTP Timescale and Leap Seconds
https://www.eecis.udel.edu/~mills/leap.html
And, back round to the first question, section 5. How NTP Implements
Leap Seconds says quite clearly TAI-UTC increments *after* the Leap Second.
-Brooks
Also, NIST Special Publication 250-67 NIST Time and Frequency Radio
Stations:
WWV, WWVH, and WWVB
Yes, there is a bit to indicate a pending leap second at the end of the current
month. The sign of DUT1 is used to distinguish a positive from a negative leap.
The data frames used by WWV and WWVB are 60 seconds long.
For a positive leap second a blank second occurs between the last minute of
2016 and the first minute of 2017. The blank second is definitely not part of
the 2017 minute. You could argue it's not really part of the 2016 minute
either; it's just extra second. Again, there's no concept of transmitting a TAI
offset, so no worries here either.
/tvb
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
