GPS Week Number Rollover

(Hier ist eine deutsche Version dieses Textes)

The GPS system time is based on week numbers since an epoch, and seconds of the current week. Unfortunately most GPS satellites send the GPS week number encoded in 10 bits only, covering a range of 1024 weeks (week numbers 0 through 1023), and after week 1023 the week number transmitted by the satellites rolls over to 0. This behavior is intentional and has been clearly specified in the GPS Interface Control Document IS_GPS_200J.pdf (paragraph 20.3.3.3.1.1).

The “start date” of the GPS system time is Sunday, 6th January 1980. The first GPS week number rollover occured 1024 weeks later, on Saturday, 21st August 1999, and the next rollover occured another 1024 weeks later, on Saturday, 6th April 2019.

For pure navigational receivers this doesn't matter much since they work based on time differences only, but GPS receivers used for time synchronization have to properly account for these rollovers to determine the correct calendar date.

All Meinberg devices with integrated GPS or GNSS receivers handle the week number rollovers without problems.

A more detailed explanation follows below.

There are 3rd party GPS receivers out there which take a very simply approach with a fixed week number limit, e.g.:

“If the transmitted week number is below 860 we assume a rollover has already occurred, and thus add 1024 to get a full week number. If the week number is above 860 we assume a rollover has not yet occurred.”

This approach is similar to extending a 2 digit year number to a full 4 digit year number. If you take 90 as a limit the resulting range would be 1990..2089.

For the GPS week number example this results in a valid range like 860 .. 1884 for the extended week number, but after real week number 1884 the calculation yields a number in the range 0..860, thus a wrong date 1024 weeks in the past.

The worst thing with this approach is that this switchback doesn't occur at the same time as the scheduled week number rollover in the satellite data. Instead, it can occur at an arbitrary weekend when the number reaches the threshold determined by the firmware developers.

This has happened with some 3rd party GPS receivers in February 2016, and some other 3rd party GPS receivers are expected to have problems after July, 2016. The exact time at which these kind of problems will occur depends on the GPS receiver model and firmware version, and is not related to the GPS system-specific rollover dates mentioned above.

When Meinberg started to develop their first own GPS receivers in the 1990s, care was taken right from the beginning that those receivers could handle GPS week number rollovers properly. The firmware uses a 16 bit week number internally, and the week number is simply incremented at the end of each week, so when the week number sent by the satellites first rolled over from 1023 to 0 in August 1999 the internal week number just rolled over from 1023 to 1024, at the next rollover in April 2019 it was incremented from 2047 to 2048, and so on. The extended week number is used for all kinds of computation, and even the earliest receivers already handled the first GPS week number rollover in August 1999 and the next one in April 2019 properly.

Current models as well as older models of the GPS receivers manufactured by Meinberg use the 16 bit extended week number internally, and thus can handle the week number rollovers properly, regardless of the firmware version. Tests have been run to verify that this still works as expected.

The initial extended week number is computed after power-up from the date kept in the battery-buffered real time clock chip (RTC).

Only if the device's backup battery has failed and thus the RTC has no valid time and date the epoch number is unknown, so the receiver may start with the wrong epoch, resulting in date in the the range 1980..1999, or 1999..2019, or later, depending on the receiver's firmware version. However, once the correct date has been set via the user interface the firmware computes the correct extended week number and continues working normally with the correct date, which is kept in the RTC as long as the battery is OK.

Please note that the Meinberg approach explained above applies only to all Meinberg GPS receivers, i.e. receiver modules with GPS in the module name, e.g. GPS16x, GPS17x, or GPS18x.

There are some newer modules with can in addition receive the signals from the GLONASS or Galileo satellite systems. These modules have GLN, GRC, or GNS in their name, e.g. GLN170, GRC180 or GNS181. These devices use 3rd party core modules internally.

The firmware maintainers at Meinberg have run a couple of tests and can confirm that the 3rd party GNSS receivers used within Meinberg device will not cause any problems due to the GPS week number rollover in April 2019, and don't suffer from the simple week number conversion mentioned above.

Since the rollover occurs in the week number included in the data stream received from the satellites, you'd need a GPS simulator to run a real test. The simulator has to provide the GPS receiver with a simulated GPS satellite signal where the week number rolls over, so you can watch the output to make sure the outgoing date, time and hardware signals continue normally when the week number rollover occurs.

However, care must be taken if tests are run and the receiver date is changed across several epochs. The reason is that the navigational data received from the satellites (almanac, ephemeris, clock correction, …) or simulator are also stored internally with the extended week number. So if the receiver first operates with a date after a week number rollover, and then the date is changed to some date before the rollover, or vice versa, the stored navigational data have a reference time 1024 weeks in the future or past, which certainly yields wrong results.

So when playing around with changing dates across large ranges be sure to set the receiver to COLD BOOT mode after the date was changed, as explained below.

For example, if you run a test today and operate a Meinberg receiver with real antenna, i.e. current week number from GPS is 873, day number 4:

If you manually set the date on a Meinberg receiver to some date before 1999 then the firmware assumes epoch 0 and thus converts wn 873 day 4 to Oct 3, 1996.

If you manually set the date on a Meinberg receiver to some date after 1999 then the firmware assumes epoch 1 and thus converts wn 1897 day 4 to May 19, 2016.

To yield the correct date after the second rollover the on-board date should be set to the current date, or at least to a date after April 7, 2019.

As explained in the previous sections (here and here), if the date was changed to a different week number epoch, it is important to first set the receiver's on-board date correctly, and then force the receiver to Cold Boot mode, so all GPS data stored in the receiver is deleted, then re-collected from the satellites, and finally saved with a correct extended week number.

This takes about 12 minutes of continuous reception since the full data set is only sent repeatedly once every 12 minutes. After this time, the receiver has consistent data and therefore returns correct results.

This procedure is also required if for some reason the on-board battery had been discharged or removed, the on-board real time clock has lost information on current date and time, and therefore the receiver doesn't know the week number epoch associated with the current date.

Most standalone GPS/GNSS receivers have a label with the name on it, or the name printed in copper on the board. However, for many devices it's also possible to determine the receiver type via software.

On LANTIME devices the type of the built-in GPS receiver can be determined via the web user interface. Information below is for LANTIMEs running firmware v6.x. For LANTIMEs running firmware v5.x see the next chapter.

On the LANTIME's web page, click on the Clock tab, then expand the Receiver Information topic and look at the Model: entry.

One of the screenshots below shows an entry GPS180, with GPS in the model name, so it's a native Meinberg device. The model name in the second screenshot is GRC180, which indicates the device uses a 3rd party GPS receiver.

On LANTIME devices running the older firmware v5.x the web user interface looks completely differently than on devices running firmware v6.x devices running firmware v6.x.

First click on the Local button at the top of the page, then on List detailed version information, as shown in the first screenshot below. The displayed information contains the type of GPS/GNSS receiver as highlighted on the second screenshot.

On Windows the monitor program shipped with the driver package for Windows can be used to identify the device type:

In the screenshot above, the highlighted part of the device name is GPS, so the device is a native Meinberg GPS receiver.

On Linux, FreeBSD, etc. you can run the mbgstatus command to show some information on the receiver, including the device type.

Here's the output for a GPS180PEX PCI Express card which is a native Meinberg GPS receiver:

GPS180PEX 029511026220 (FW 2.14, ASIC 8.06) at port 0xE000, irq 16
Normal Operation, 7 GPS sats tracked, 13 expected to be visible
…

An older GPS170PCI card also has GPS in its name, so it is also a native Meinberg GPS receiver:

GPS170PCI 028210999960 (FW 1.15, ASIC 1.00) at port 0xD000, irq 16
Normal Operation, 8 GPS sats tracked, 13 expected to be visible
…

The output below has GNS in the device name, so it uses a 3rd party GNSS receiver:

GNS181PEX 011411000360 (FW 2.31, ASIC 12.00) at port 0xDE00, irq 18
Normal Operation:
…

— Martin Burnicki martin.burnicki@meinberg.de 2024-07-10