[time-nuts] Z3801A leap second bug coming up

Tim Shoppa shoppa at trailing-edge.com
Sat Oct 1 07:26:03 EDT 2005

> As I recall it self-corrects the prediction within a
> second

Not what I saw last night.  This is what I logged for time codes:

scpi > T22005093023595830+0047
scpi > T22005093023595930+0048
scpi > T22005093023596030+0040
scpi > T22005100100000030+001D
scpi > T2200510010000013000023
scpi > T2200510010000023000024
scpi > T2200510010000033000025
scpi > T2200510010000043000026
scpi > T2200510010000053000027
scpi > T2200510010000063000028
scpi > T2200510010000073000029
scpi > T220051001000008300002A
scpi > T220051001000009300002B
scpi > T2200510010000103000023
scpi > T2200510010000113000024
scpi > T2200510010000123000025
scpi > T2200510010000133000026
scpi > T2200510010000143000027
scpi > T2200510010000153000028
scpi > T2200510010000163000029
scpi > T220051001000018300102C
scpi > T220051001000019300102D
scpi > T2200510010000203001025

In other words, there were 16 seconds where it was wrong by
a second, and then it realized that something was horribly wrong,
jerked the GPS-UTC offset back by a second, and then raised
the "request for service summary bit" in the status byte register
(That's the "1" that appears as the fourth to last character)
to say that something was FUBAR.

Only hours later did it realize that another leap second was coming.


More information about the time-nuts mailing list