Hi 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. Bob > On Jan 11, 2015, at 9:02 AM, Tom Van Baak <t...@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. > > /tvb > _______________________________________________ > 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. _______________________________________________ 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.
