256-Week Leap Second Bug

27 November 2003

Yes, there was a leap second bug today. Not with GPS itself; but with several models of GPS timing receivers.

Following is a SCPI trace from a HP 59551A SmartClock; no bugs here.

scpi > syst:date?;time?
+2003,+11,+27;+23,+59,+56
scpi > syst:date?;time?
+2003,+11,+27;+23,+59,+57
scpi > syst:date?;time?
+2003,+11,+27;+23,+59,+58
scpi > syst:date?;time?
+2003,+11,+27;+23,+59,+59
scpi > syst:date?;time?
+2003,+11,+28;+0,+0,+0
scpi > syst:date?;time?
+2003,+11,+28;+0,+0,+1
scpi > syst:date?;time?
+2003,+11,+28;+0,+0,+2
scpi > syst:date?;time?
+2003,+11,+28;+0,+0,+3

But as predicted, the Motorola Oncore VP receiver has the bug! Here is what I first saw, using LIST on the raw log of @@Bl and 1 Hz @@Ba messages:

In the hex trace note that 11/27/2003 23:59:59 in hexadecimal is 0B/1B/07D3 17:3B:3B and 11/28/2003 00:00:00 in hexadecimal is 0B/1C/07D3 00:00:00:

0B5100                                      40 40 42 61
0B5110  0B 1B 07 D3 17 3B 3B 00 0D F3 95 0A 34 3C FE E5  [11/27/2003 23:59:59]
0B5120  CA AC 1C 00 00 6D 95 00 00 74 C4 00 03 00 00 00
0B5130  2F 00 06 05 05 08 5E A0 18 08 3E A0 04 08 4B A0
0B5140  1E 00 66 00 07 08 29 A0 00 00 00 00 20 DB 0D 0A
0B5150  40 40 42 61 0B 1D 07 D3 3E 1C 0F 00 0E 27 FA 0A  [11/29/2003 62:28:15]
0B5160  34 3C FF E5 CA AC 1D 00 00 6D A5 00 00 74 D4 00
0B5170  0B 00 83 00 2F 00 06 05 05 08 60 A0 18 08 3E A0
0B5180  04 08 4A A0 1E 00 69 00 07 08 29 A0 00 00 00 00
0B5190  20 C4 0D 0A 40 40 42 61 0B 1C 07 D3 00 00 00 00  [11/28/2003 00:00:00]
0B51A0  0E 5C 5A 0A 34 3C FF E5 CA AC 20 00 00 6D BD 00
0B51B0  00 74 EC 00 13 02 82 00 2F 00 06 05 05 08 5E A0
0B51C0  18 08 3C A0 04 08 4C A0 1E 00 61 00 07 08 2A A0
0B51D0  00 00 00 00 20 04 0D 0A

Here all the @@Ba position messages around UTC midnight have been partially decoded, showing the date/time:

@@Ba 0b1b07d3173b37000d22030a343cfbe5caac1b... 11/27/2003 23/59/55.000860675
@@Ba 0b1b07d3173b38000d566a0a343cfae5caac1a... 11/27/2003 23/59/56.000874090
@@Ba 0b1b07d3173b39000d8ace0a343cfde5caac1a... 11/27/2003 23/59/57.000887502
@@Ba 0b1b07d3173b3a000dbf300a343cfde5caac1b... 11/27/2003 23/59/58.000900912
@@Ba 0b1b07d3173b3b000df3950a343cfee5caac1c... 11/27/2003 23/59/59.000914325
@@Ba 0b1d07d33e1c0f000e27fa0a343cffe5caac1d... 11/29/2003 62/28/15.000927738
@@Ba 0b1c07d3000000000e5c5a0a343cffe5caac20... 11/28/2003 00/00/00.000941146
@@Ba 0b1c07d3000001000e90bc0a343d00e5caac22... 11/28/2003 00/00/01.000954556
@@Ba 0b1c07d3000002000ec51f0a343cffe5caac23... 11/28/2003 00/00/02.000967967
@@Ba 0b1c07d3000003000ef98d0a343cfbe5caac26... 11/28/2003 00/00/03.000981389
@@Ba 0b1c07d3000004000f2e240a343cfae5caac26... 11/28/2003 00/00/04.000994852

The previous Motorola announcement predicted the incorrect date. But the very incorrect time is a surprise.

February 2003 Announcement

We all understood why Y2K was a problem for some software and with some reading you can understand why many old GPS receivers stopped working at the August 21, 1999 WNRO (week number roll-over) event. But this one really takes the cake: everyone's favorite GPS timing receiver, the Motorola Oncore VP, will have a short hiccup on November 27, 2003. Why? Because it's been too long since the last leap second!

----- Original Message -----
From: Tom Van Baak
To: Richard M. Hambly
Cc: 'Doug Hogarth' ; 'Tom Clark' ; 'Jim Jaeger' ; 'Demetrios Matsakis'
Sent: Saturday, February 08, 2003 04:12
Subject: Re: VP/UT Anomaly, GPS leap second bug

Hi Rick,
 
I think I figured it out. This will happen to a Motorola Oncore anytime leap seconds are more than 256 weeks apart.
 
Paragraph 20.3.3.5.2.4 of ICD-200 (http://www.navcen.uscg.gov/pubs/gps/icd200/default.htm) explains how leap seconds are implemented.
 
Pending UTC leap second information is sent in page 18 of subframe 4. The WN sub t and WN sub LSF parameters are 8-bits implying it is not possible to announce a leap second more than 256 weeks in advance (1792 days, just short of 5 years). This is no big deal; a month or two is adequate. In fact, a bug was exposed in HP SmartClock's some years ago when USNO had GPS announce a leap second more than 3 months in advance. But the 8-bit nature of these fields also permits GPS receiver firmware that isn't careful about wrap-around to confuse "now" with 5 years from now or 5 years ago. That's my guess at least. Look at the math:
 
The last leap second was at the end of the day 1998-12-31 (MJD 51178). This was near the end of day 5 of GPS week 990, which is 1998-12-31. Now add 256 GPS weeks to that and you get the end of day 5 of GPS week 990+256 = 1246, which is 2003-11-27 (MJD 52970). Bingo.
 
Just as a leap second is the 86401th second of the day, the Oncore glitch occurs on the 86401th second of 2003-11-27. Odd that the time is correct but the date is off by one. Nice that it corrects itself by the next second. Is the 1 PPS affected? Do you think any GPSDO's using the Oncore will notice?
 
What a bizarre bug. Who found it? And are these models of Oncore the only receivers to have the bug? What does an armed JDAM do if it discovers it is suddenly a day late to the party?
 
I guess you know what I'll be doing with my Oncores on 11/27!
 
/tvb
 
----- Original Message -----
From: "Richard M. Hambly"
To: "'Tom Van Baak'"
Cc: "'Doug Hogarth'" ; "Tom Clark"; "Jim Jaeger"
Sent: Friday, February 07, 2003 07:32
Subject: RE: VP/UT Anomaly

> Tom,
>
> Your guess is as good as mine. If I learn more I'll let you know.
>
> Rick
>
> -----Original Message-----
> From: Tom Van Baak
> Sent: Friday, February 07, 2003 10:17 AM
> To: Richard M. Hambly
> Cc: 'Doug Hogarth'; 'Tom Clark'; 'Jim Jaeger'
> Subject: Re: VP/UT Anomaly
>
>
> Rick,
>
> That's amazing. Did they give you any idea what
> the cause was?
>
> The date looks so innocent. It's in the middle of
> GPS week 1246. That's not the end of a month.
> Nor the end of a calendar week. Nor the end of
> a GPS week. Mjd 52970/1 - nothing special about
> that. 8728th day of GPS time - nothing magic
> about that number, either.
>
> Wait, 11/27/2003 is 1792 days since the most
> recent leap second (12/31/1998). 1792 is 256
> times 7, exactly. Does that have something to
> do with  it?
>
> /tvb
>
> ----- Original Message -----
> From: "Richard M. Hambly"
> To: "'Tom Van Baak'"; "'Doug Hogarth'"; "Tom Clark"; "'Jim Jaeger'"
> Sent: Friday, February 07, 2003 06:56
> Subject: VP/UT Anomaly
>
>
> > All,
> >
> > I received this information from Motorola.  It came as a surprise to
> > me. Ring any bells with you guys?
> >
> > "We've completed our testing of the VP as you requested. The VP will
> > exhibit the same behavior as the UT this next November given that
> > there will likely not be another leap second event before then. On
> > November 27th, the time/date output from VP and UT receivers will
> > follow this pattern :
> >
> > 11/27/2003 23:59:58
> > 11/27/2003 23:59:59
> > 11/29/2003 00:00:00
> > 11/28/2003 00:00:01
> > 11/28/2003 00:00:02
> >
> > As we've previously discussed, the date will be incorrect for 1 second
> > right at midnight."
> >
> > Rick
> > W2GPS

July 2003 Announcement

ONCORE TECHNICAL APPLICATION NOTE

Upcoming Incorrect Application of Leap Second

Motorola Oncore GPS receivers have the capability of reporting time and date referenced to GPS system time or UTC (Universal Time Coordinated). The difference between the two time systems (currently 13 seconds) is broadcast in the GPS satellite navigation message as a set of UTC correction parameters. These parameters define the current difference between GPS and UTC time, and information on the next scheduled leap second event. These parameters are used by the Oncore firmware to convert GPS time to UTC time and to account for the leap second at the proper time. The output format for the time of insertion or deletion of the future leap second is GPS week number and day number within the GPS week. The GPS week number parameter in the UTC correction parameter set is 8 bits long, which allows for 256 weeks of unambiguous time calculation. The current GPS satellite navigation message broadcast of UTC data still contains the week number corresponding to that last leap second event. Currently, there is no leap second event scheduled prior to the end of the 256-week cycle on November 27, 2003. This unanticipated long duration between leap second events will cause a brief one-second anomaly in the time reported from Motorola Oncore receivers with software versions listed below on midnight of November 28, 2003. 

The time/date output at that time will follow this pattern:
Correct UTC Time/Date UTC Time/Date reported
by the Oncore Receiver
11/27/2003 23:59:58 11/27/2003 23:59:58
11/27/2003 23:59:59 11/27/2003 23:59:59
11/28/2003 00:00:00 11/29/2003 00:00:00 Wrong date reported for one second, time is correct
11/28/2003 00:00:01 11/28/2003 00:00:01 Date is corrected the next second, time is still correct 
11/28/2003 00:00:02 11/28/2003 00:00:02

This one-second anomaly will not affect any other operation of the receiver including the accuracy of the 1PPS pulse, satellite tracking performance, or position accuracy. 

Affected products lines are: 
VP Oncore 
UT Oncore 
GT Oncore 
M12 Oncore

This anomaly will not occur on any version of the M12+ Oncore Timing receivers. 

 


Return to LeapSecond.com home page.
Comments/questions to tvb.
27-Nov-2003