Tom Van Baak wrote:
The truncated week numbers are a good source for potential errors
I agree, but...
If the current week number is off by more than +-127 then this is ambiguous.
No, it's not ambiguous, it was just a Motorola bug. The wrap is in the spec and
there's no problem with that. In fact, in 2003 everyone got it right except for
one(?) model of Motorola GPS timing receiver. So the spec is fine, GPS is fine,
wrapping is fine. But yes, it is a source for errors, and one engineer at
Motorola fell for it.
What I mean with "ambiguous" is that you can't even *display* the
correct leap second date if there has been no leap second for more than
the number of weeks covered by the 8 bit week number.
For example, IIRC the GPS satellites sent the same 8 bit WNlsf number of
the last leap date for seven years when no leap second was scheduled for
that long time, and after some years you had no chance to expand these 8
bits unambiguously to 10 or more bits to convert this to the real date
of the last leap second event.
Of course, if you only evaluate WNlsf and DNt if tls and tlsf differ
(i.e. a leap second is actually scheduled) then everything is fine since
the numbers have been updated accordingly. Of course this can still fail
if you evaluate this in a wrong way, which is probably the problem with
the GPS receivers in fact doing it wrong.
The only limitation of using an 7- or 8-bit WN field like this is that it
prevents GPS from announcing a leap second more than 2.5 or 5 years in advance.
That's not much of a limitation.
Or display the correct date of a leap second more than 2.5 or 5 years in
the past. ;-)
Martin
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
