Tom Van Baak wrote:
I haven't looked at the raw data, but using the windows apps:
a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not.
lady heather is not
Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361)
Hi Hal,
It's not that simple. There are many different levels of leap second
notification.
1) IERS updates their ftp site (for bots) and sends email (for humans)
indicating when the next leap second will occur. Days or weeks (and sometimes
months) later,
2) GPS ground control uploads almanac information to the satellites with
updated UTC parameters. Four values in page 18 of subframe 4 give the current
UTC leap second delta and also an optional future UTC delta, with a GPS week
(LS_f) and day number (DN) when that future delta will be current. By
definition the leap second will occur at the end of a UTC (not GPS) day.
In this way GPS can provide up to 256 weeks (~4.9 years) of advanced
leap second information and support positive or negative leap
seconds.
Yes, and since the GPS UTC parameters just provide the difference to GPS
time (in seconds) before and after the leap event time, they could even
announce a leap event where more than 1 second is inserted or deleted at
once. ;-)
I'm not aware of any other timing system that could handle this, though.
Note there is no "leap second warning" *bit* in the GPS
spec, per se.
3) Starting up to 12.5 minutes later, GPS receivers will see page 18 of
subframe 4 from some or all SV and thus know not only the current UTC offset,
bit when/if a different UTC offset will be valid in the distant future. Prior
to this (e.g., cold start) there is no certainty of either the UTC offset or
leap second state.
4a) Since UTC and leap seconds are not needed for navigation, some GPS
receivers do not bother to tell the user about leap seconds at all.
4b) Some GPS receivers only give the user a leap second warning and so they
must wait until the month in which the leap second is to be applied before they
issue the warning. That means they may sit on the internal leap second
information for many months.
4c) Other GPS receivers give the future date of the next leap second (if any).
This is not a warning bit, but just the date/time of the next leap second.
4d) Especially dangerous are any GPS receivers that report only a leap second
warning bit, but don't tell you which month it will occur.
5) Host software (e.g., GPSDO firmware, operating system, drivers, or apps)
take this information and must only operate on it at the end of the appropriate
UTC month. Hardcoded rules for June and December are frowned upon.
It would be nice if we pooled together our resources and made a list of which
GPS/GNSS receivers are 4a, 4b, 4c, or 4d.
It also depends on *how* the leap second warning is made available. If
an application can read the GPS UTC parameter set then it can compute it
as soon as the sats start to broadcast it.
There are formats of time string output by GPS receivers which only
include the leap second warning 1 hour or 1 day before the event.
NMEA sentences don't include it at all, AFAIK. Binary messages may,
depending on the manufacturer.
IRIG time code signals also don't provide a leap second *warning* flag,
except the IEEE codes 1344 and C37.118, which only output this 10
seconds or 1 minute (don't remember exactly without looking) before the
event.
Martin
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
