Inside the DM24
zero. (Because GPS time does not recognise leap-seconds, the "roll-over" from week
1023 to week zero actually took place at the end of 23:59:47 UTC on August the 21
st
.)
Manufacturers of GPS receivers must each choose a way to determine the correct
date from the GPS Week Number. If the chosen method fails, the announced date
will be 1024 weeks - about 19.7 years - in the past or, possibly, the future. One
common method uses the date of the version of the firmware as a hint, which works
well if the receiver is new or regularly updated. A significant problem with this
method arises when the firmware is not updated: the receiver can start producing
incorrect dates at the 1024-week anniversary of the firmware date. This means that
problems can actually appear at any time, irrespective of the actual roll-over date.
Many significant problems were reported after the 1999 roll-over and this became
known as the GPS "week-number roll-over" or "
" problem. Many
manufacturers had to update their receiver firmware as a result but some of these
solutions were time-limited, leading to continuing problems around the April, 2019
roll-over.
The DM24 can automatically correct for receivers which report historical times as a
result of this problem. If the
setWNROpivot
command (see section 6.4.6 on page 62)
is used to set a "pivot date", any dates reported by a GPS receiver which are
earlier
than the pivot date will be modified by repeatedly adding 1024 weeks to the reported
date until a date
later
than the pivot date is reached. This will then be the date used
for time-stamping data. Because you can set the pivot date yourself, this technique
should be able to correct for any problems encountered both before and after the
next roll-over, in 2038.
The following extract of a status stream shows the technique in action:
2019 7 27 23:59:00 o/s= -10263 drift= -1636 pwm= 8315 Auto 3D
2019 7 28 00:00:00 GPS Date/Time 12/12/99 00:00:00
2019 7 28 00:00:00 o/s= -9497 drift= 766 pwm= 8342 Auto 3D
2019 7 28 00:00:00 Auto 3D SV#'s 28 2 18 21 23 25 26 ( 7 )
2019 7 28 00:00:00 Lat 51'21.8502N Long 001'09.9228W Height 6m
Note how the third line starts by reporting that the system data is July 28
th
, 2019 but
then reports that the GPS Date is December 12
th
, 1999. These two dates are exactly
1024 weeks apart because of the WRNO correction.
7.2.4 Multiple re-synchronisation events
In an ideal world, the digitiser would synchronise to GPS shortly after power-up and
then sit happily, training its clock to GPS time with a few tiny adjustments to the
VCXO control voltage to compensate for, say, thermal variations.
It would be very unusual for the GPS receiver to suddenly report a radically different
time. If it does happen, the digitiser becomes sceptical and waits a whole minute,
monitoring the situation without changing the internal clock. It increments an
internal counter - the resync counter - to record the event and prints a message like
Clock check 1 0 Not sync'd
101
Issue U - December, 2021
