Important notice about the 2019 GPS Week-Number Roll-Over problem
The details in this announcement are believed correct at the time of writing (April 9th, 2019) but there have been a number of recent, unexpected developments. Because of this, there may be further updates to come.
April 30th 2019 Update: The NMEA analysis technique described below only works well when the GPS receiver under test has a 3D fix. The text below has been modified accordingly.
May 3rd 2019 Updates:
A new firmware build is available for most DM24 Mk3 digitisers, DM24SxEAM data acquisition units and all digital instruments (*TD, *TDE) which incorporate DM24 Mk3s. This firmware can correct timestamps from affected receivers. Details are given in the "Mitigation" section, below.
A new receiver identification tool is available for use with DM24SxEAM data acquisition units in cylindrical casings and *TDE instruments. Click here for information about this tool.
Güralp have been advised that problems will arise with the Trimble Lassen GPS receiver modules used in Güralp receivers supplied between 2003 and 2015. Both Lassen iQ modules and Lasssen SQ modules are affected.
Guralp Systems have used four suppliers of GPS equipment to date: Garmin, Motorola, Trimble and u-blox. Garmin and Motorola receivers (which were sold before 2003) cannot be supported and their status with respect to the Week Number Roll Over Problem is unknown.
In general, older and larger GPS units contain Motorola or Garmin receivers. Trimble receivers were used in the more compact GPS receivers. In the pictures below, the Trimble-based units are the two to the far right. The body diameter of the Trimble-based units is 55 mm compared to 95 mm for the Garmin model.
|Trimble chip-sets were used in the compact GPS type, as seen in the far right.|
More recent GPS receivers use u-blox modules. U-blox have confirmed in an official Compliance Statement that “… the following u-blox GNSS chips and modules have been tested and can handle the year 2019 GPS week number rollover without issue: u-blox 7, u-blox 8, and u-blox M8 products.” A copy of this statement can be found here.
- All black GPS receivers incorporate u-blox chip-sets and are unaffected.
- All white GPS receivers with serial numbers beginning G3 (e.g. G30123) incorporate u-blox chip-sets and are unaffected. These units were sold from the 1st of February 2015 onwards.
Identifying affected GPS receivers
There are a number of basic methods which can be used to identify affected receivers; each detailed in a section below:
Supply dateAny GPS receivers shipped before the 1st of March, 2010, are one of three types: Motorola, Garmin or Trimble SQ. Receivers based on Motorola and Garmin chip-sets can no longer be supported. Receivers based on Trimble SQ units should be upgraded to avoid problems.
Look first at the bottom of the receiver. There is normally a small, white engraved plate giving the serial number. In this example, the serial number is G16096.
- If your serial number begins G3…, you have a u-blox receiver and will be unaffected by the roll-over.
- If your serial number begins G1… or G2… (or your unit does not have a serial number plate attached), you may have a Trimble-based receiver.
If you suspect that you may have a Trimble-based unit, the top of the GPS receiver can be unscrewed to reveal the antenna, processor and associated electronics. This is easiest if you brace the receiver's spike and connector against the top edge of a desk:
Compare your unit to the photographs below, paying particular attention to the antenna, which is the uppermost component and is identified by its silver top:
Lassen SQ module
Lassen iQ module
In addition, receivers based on u-blox chip-sets have only one PCB assembly while those based on Lassen chip-sets have two or three, stacked above each other. In the illustration below, the receiver on the left uses a u-blox chip-set while the receiver on the right uses a Trimble Lassen chip-set. Receivers based on the u-blox chip-set, like that on the left, will be unaffected.
In some cases, it is possible to directly interrogate the receiver to discover the firmware release that it is running. This is possible on DM24SxEAM data acquisition units in cylindrical casings and *TDE instruments. Please see the Receiver Identification Tool web-page for information about this technique.
If physical access is inconvenient, receivers can often be identified by subtle differences in the NMEA messages that they produce as output.
Guralp Systems’ Trimble Lassen GPS receivers can be distinguished from earlier types by their use of the GPZDA NMEA sentence in their output stream. Earlier types used the GPRMC sentence instead. There are also differences in the output between Lassen iQ models and Lassen SQ models which can sometimes be seen in the NMEA data.
You can access the NMEA in a number of ways. (The simplest way is to connect the receiver directly to a PC running terminal emulator software. A standard Güralp grey/blue power/data cable (CAB-BDA-0036) can be used for this purpose and the emulator should be set to 4800 Baud, 8N1 with no flow control. We shall ignore this option for now because a visual inspection is quicker if you have physical access.)
There are methods which can capture NMEA from a receiver while it is still in use. Each involves reconfiguring the attached digitiser temporarily, so that it copies the incoming NMEA from the GPS receiver directly into its status stream, from where it can be inspected.
If you are using a Guralp DM24 or CD24 digitiser, either stand-alone, combined with an EAM or as part of a 3TD, 3ESPD, 40TD or 3ESPCD or any *TDE instrument, instruct it to output NMEA sentences as follows:
Open a connection to the command line of the digitiser:
- If you are using Scream, right-click on the digitiser icon in the source tree and select from the context menu.
- If you are using the web interface of an EAM, DM24SxEAM or *TDE instrument, choose from the left-hand menu.
- If you are using the command line of an EAM, DM24SxEAM or *TDE instrument, run the command data-terminal and choose the correct digitiser from the list.
Type OK-1 and press enter to enable the extended command set.
Type 2 MON ! (2_space_MON_space_exclamation-mark; the space before the last character is important) and press enter. Now wait:
- For a DM24, wait for 20 seconds.
- For a CD24, wait for 10 minutes.
Type 1 MON ! (1_space_MON_space_exclamation-mark) and press enter.
Type FLUSH-STATUS and press enter.
Type [SEAL] and press enter.
Leave command mode by closing the terminal window or issuing GO.
The following screen-shots show the procedure being caried out in (a) Scream, (b) an EAM's command line and (c) and EAM's web interface.
Now look at the status stream produced by the digitiser:
If you are using Scream, open the main window, select the digitiser in the source tree (the left-hand list) and then double-click the status stream (the one with an ID ending 00) in the right-hand window.
If you are using the EAM's web interface, navigate to the main status display using the top entry on the left-hand menu. Tick the "Show hidden values" check-box at the bottom of the resulting screen. Select the tab for your digitiser: the NMEA strings will be displayed among the status messages here. If you do not see the NMEA, wait a few minutes and then refresh the page.
If you are using the command line of an EAM, type the commandgrep NMEA /var/log/messages | less
and then use spacebar to scroll through the output, page by page.
Whilst 2 MON ! was active, the digitiser will have copied all of the NMEA sentences it received — several every second for a DM24, several each minute for a CD24 — into the status stream.
You can recognise NMEA from its similarity to the sample below. Each NMEA sentence begins $G and ends with an asterisk (*) folowed by two hexadecimal digits.
Look out for the sentences beginning $GPGSA. These sentences should continue $GPGSA,A,3, as shown above. This means that the receiver has an automatic 3D fix, which is necessary for this technique to work. If these sentences begin $GPGSA,M,, $GPGSA,A,1, or $GPGSA,A,2,, check that the receiver has a good view of the sky and, if necessary, wait until you see $GPGSA,A,3, before proceeding.
Once you are satisified that the receiver has a 3D fix, copy a sample of
the NMEA output sentences into
our on-line analyser in order to identify the model of your receiver.
- stand-alone DM24 digitisers;
- DM24 Mk3 and DM24 Mk2 digitisers integrated into 3TD, 3ESPCD and 40TD instruments;
- DM24 Mk3 and DM24 Mk2 digitisers integrated into data acquisition systems, such as the DM24S3EAM; and
- CD24 digitisers integrated into 6TD, 3ESPCD and 3ESPCDE instruments.
DM24 Mk1 digitisers can no longer be supported.
Users of other Güralp digitisers and instruments should contact for advice.
- If you have a Lassen SQ, you should take remedial action before the 28th of July, 2019.
- If you have a Lassen iQ, you should take remedial action before the 29th of May, 2021.
- If you have a u-blox, no remedial action is required: your receiver will not be affected by the 2019 WNRO. If you are using it in conjunction with a DM24 Mk3 digitiser, a digitiser firmware upgrade is recommended. See below for details.
If you need to take remedial action, the following options are available:
- The entire receiver can be replaced with a new model which is unaffected by the WRNO problem.
- Güralp can upgrade your receiver with a new PCB assembly. This will involve returning your receiver to the factory.
- Your local distributor may be able to upgrade your receiver with a new PCB assembly. This will involve returning your receiver to your distributor. Please contact your distributor to see whether they offer this service.
- You can purchase a "field upgrade kit" for your receiver, which will allow you to replace its existing PCB assembly with a new one which is immune to the WNRO problem. The procedure is straightforward and requires only a few standard tools. You can browse the GPS receiver upgrade procedure in an on-line HTML version or download a PDF copy version.
In addition to upgrading the hardware, a firmware upgrade for DM24 Mk3 digitisers is available which should be applied in most cases. The upgrade allows the manual setting of a "pivot date". If a connected GPS receiver reports a date earlier than the configured pivot date, the firmware will add 1024 weeks to the reported date - possibly repeatedly - until the resulting date is later than the pivot date. This upgrade allows the DM24 to handle all future GPS WNRO events.
Although this upgrade addresses the problems anticipated over the next few months and years, we still recommend performing the hardware upgrade as well.
The new receivers offer the following advantages:
Improved leap-second support. With older receivers, the digitiser should be manually notified in advance of each leap-second. The new receivers do this automatically using a custom NMEA sentence.
Field upgradeable. The operation of the GPS system and the receiver chip-set are beyond our control and there have already been unpredicted problems, such as the GPS WNRO issue and the Trimble leap-second bug. The supervisory processor can be reprogrammed in the field to adapt the receiver should any new problems appear, offering a high degree of future-proofing.
Lower power consumption: reduced by >50% for ten-pin units with a 15 V supply and by >30% for six-pin units from a 5 V supply (as provided by a CD24).
Interchangeability. Unlike earlier receivers, the CD24 and DM24 models of the new receivers are identical other than the connector, allowing inventories to be simplified by the use of adapter cables.
No lithium cell. Earlier receivers relied on built-in lithium cells to maintain settings when powered down. Degraded cells could corrupt the configuration or leak and damage the receiver.
More channels. The new receivers support 56 channels, compared to 12 for the Trimble iQ or 8 for the Trimble SQ modules.
Faster start-ups. The new receivers can obtain a fix in a fraction of the time taken by the older models.
A list of applicable systems, a detailed description of the upgrade procedure and a link from which to download the new firmware are available at the WNRO firmware update web page. For more information, please contact or for further advice.
Although the GPS system can be used to determine the date and time with extreme accuracy, the GPS satellite constellation does not actually transmit the full date to GPS receivers. Instead, a ten-bit value called "Week Number" is transmitted every thirty seconds, as part of each subframe of the "Navigation Message". It is the responsibility of the receiver to calculate the date from this value. (The time within the week is transmitted as the number of seconds since midnight on Saturday/Sunday.)
GPS week zero started at the beginning of 00:00:00 UTC on January the 6th, 1980. A ten-bit field can only hold 1024 different values so this system was never going to last forever. Indeed, week 1023 was first reached on August the 15th, 1999. The following week, the GPS satellites populated the Week Number field with a value of 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 21st.)
The next roll-over will occur on April the 6th, 2019, when the Week Number field will again change from 1023 to zero.
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 "WNRO" problem. Many manufacturers had to update their receiver firmware as a result but some of these solutions were time-limited, leading to the current problems.
Predictability and notice
Given that the week-number roll-over was entirely predictable, it is reasonable to ask why we were unable to alert customers to this issue any earlier than we did.
Güralp Systems researched this issue last year and we saw a published technical specification manual that indicated that there would not be a problem. There was no other public information available at that time. This was the evidence behind the first version of this web page.
However, on the 27th March this year, a customer from Germany told us that they had just seen unpublished supplier documents that indicated that there could, in fact, be a problem. We investigated again and, on the 1st of April, we also saw – for the first time – unpublished supplier documents that showed that there would be a problem. These documents were updated on both the 2nd and 3rd of April, with some additional information and some changed information.
Since then, we have been trying both to understand the issue and to keep our customers updated. We sent out our first messages on Friday the 5th and Monday the 8th of April.
Accurate information is still emerging slowly; we have given as much warning as we were able to and will continue to update our distributors and customers as we know more.