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.
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!
|
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:
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. |