[time-nuts] June 30 2015 leap second
kb8tq at n1k.org
Sun Jan 11 10:06:00 EST 2015
If section 4 is going to turn in to a list of suspects to investigate and tabulate, I would add:
4 e) CDMA runs on GPS (not UTC) time. A “pure CDMA” GPSDO may be coded to ignore leap second data altogether. The ones I’m thinking about are the GPSTM boxes that put out very CDMA specific timing (pulse very other second not pps and all the rest).
4 f) GPS gizmos that report the leap second correctly and then handle it incorrectly (in a variety of ways..) when it occurs. Each time we have a leap second the net explodes with reports of these bugs.
Yes, the second one opens a whole other can of worms. It’s pretty well documented already that different firmware rev’s have different issues. Since the Motorola Oncore modules have been around the longest, they seem to have the most information about these bugs. There is an old Motorola notification on the VP, UT, GT and M12 issues (notification_oncore.pdf). It’s no longer on the Motorola site, but its hopefully out on the net somewhere.
> On Jan 11, 2015, at 9:02 AM, Tom Van Baak <tvb at LeapSecond.com> 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. 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.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts