[ntp:questions] Re: Z3801 Leapsecond bug - Sep 30?

Martin Burnicki martin.burnicki at meinberg.de
Thu Sep 1 22:31:52 UTC 2005


Tim,

shoppa at trailing-edge.com wrote:

> Martin -
>   I do not believe that this leap second bug is the same as the
> 256-week "bug" that has occured before.

Not the same, but similar.
 
>   I believe that this bug comes about because the firmware writers
> "knew" that leap seconds come on March 31, June 30, September 30, or
> December 31.  So they assumed a leapsecond announcement in August must
> mean that the leapsecond occures on September 30.

That would have been incredibly silly by the firmware programmers. The GPS
satellites don't just send a flag to announce a leap second, they send the
exact time when the leap second has to be inserted, though the week number
is truncated to 8 bits. 

This is specified in the GPS interface control document which I've read
carefully since I've written large parts of the original decoding routines
used by the Meinberg GPS receivers.

> I have not actually 
> disassembled the Oncore or Z3801A firmware so I don't know this for a
> fact, but it's a better match to my observations that the 256-week bug
> which also afflicts some of the involved firmware :-).
> 
> You are welcome to correct me if I'm misunderstanding how the 256-week
> rollover contributes to this problem.  It certainly could be a factor
> but I don't see it as necessary.

You know the GPS time is counted in week numbers since the GPS system has
started, and seconds of the week, i.e. 0..604799. The current full week
number is 1338 (0x53A). 

The highest resolution to transmit the week number in the satellite's data
stream is 10 bits, so the current week number which is actually transmitted
by the satellites is (1338 % 1024) = 314, and the so called week number
rollover was 314 weeks, or about 6 years, ago. 
In hex notation the week number truncation to 10 bits reads:
0x53A & 0x3FF = 0x13A = 314

If a GPS receiver computes the date from the GPS time, it must untruncate
the 10 bit week number, i.e. currently compute 314 + 1024 = 1338 to get the
correct result, and add the number of days in the week, i.e. seconds of
week modulo 86400, the number of the seconds per day.

The time the leap second must be inserted is specified by the week number
which is unfortunately truncated to 8 bits, and the day number at the end
of which the leap second must be inserted.

The week number in which the next leap second shall be inserted is 1355
(0x54B), and the day number is 7. This refers to the end of December 31,
2005. The week number which is actually sent by the satellites is 1355 %
256 = 75, or in hex notation:
0x54B & 0xFF = 0x04B

The 8 bit week number allows for an ambiguity of +/-128 weeks, since the
date of leap second insertion may also be in the past (this will be the
case in January 2006).

Now the firmware has again to untruncate the 8 bit week number to the full
week number. First it must be related to the 10 bit week number which is
elsewhere in the satellites' data stream, then it must be expanded to the
full week number which can be converted to a human readable date.

Please note that the last step which converts to the full week number is not
necessary for navigation since thos algorithms just work with delta times.
However, it's significant if the receiver has to compute the real date as
required in timing applications.
 
Believe me, there are enough potential sources for errors in the bit
mangling for those conversions, especially since the thime of the last leap
second insertion is so long ago.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list