Open main menu

Important notice about the 2019 GPS Week-Number Roll-Over problem

This page is retained for historical reference only. All Trimble Lassen-based receivers will either have been replacead or upgraded by now or they will fail on the 29th of May, 2021. Advice concerning receivers yet to fail is provided on the GPS WNRO 2021 page.

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:

  1. 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.

  2. 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 Equipment

April 2019

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.

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 date

Any 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.

Physical inspection

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 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
Antenna has a cream casing

Lassen iQ module
Antenna has a black casing

u-blox module
Antenna has a brown casing and is significantly smaller than the Lassen antennæ

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.

Receiver interrogation

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.

NMEA analysis

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.

These techniques require that the GPS receiver under test has a 3D fix, so that the NMEA sentences being analysed are fully populated. If you are using this technique to test a number of receivers using a single digitiser, please ensure that each receiver has a good view of the sky and allow a few minutes for it to achieve a fix before capturing the NMEA output.

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:

  1. 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 Terminal from the context menu.
    • If you are using the web interface of an EAM, DM24SxEAM or *TDE instrument, choose FORTH terminal access 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.
  2. Type OK-1 and press enter to enable the extended command set.

  3. 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.
  4. Type 1 MON ! (1_space_MON_space_exclamation-mark) and press enter.

  5. Type FLUSH-STATUS and press enter.

  6. Type [SEAL] and press enter.

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

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.

The NMEA you see may have extra information at the beginning of each line, depending on the technique you used to view it. This does not cause any problems.
$GPZDA,110432.48,17,08,2005,,*66 $GPGGA,110432.00,5121.6536,N,00109.8180,W,1,06,1.83,00125,M,047,M,,*7A $GPGSA,A,3,21,10,28,08,26,29,,,,,,,2.55,1.83,1.78*0B $GPGSV,2,1,08,27,39,059,31,21,16,322,36,10,72,211,45,28,29,138,36*78 $GPGSV,2,2,08,02,07,208,,08,72,084,39,26,33,280,41,29,49,284,43*71 $GPZDA,110433.47,17,08,2005,,*68 $GPGGA,110433.00,5121.6536,N,00109.8180,W,1,06,1.83,00125,M,047,M,,*7B $GPGSA,A,3,21,10,28,08,26,29,,,,,,,2.55,1.83,1.78*0B $GPGSV,2,1,08,27,39,059,32,21,16,322,35,10,72,211,45,28,29,138,36*78 $GPGSV,2,2,08,02,07,208,,08,72,084,38,26,33,280,41,29,49,284,43*70

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.


This information applies to users of:

DM24 Mk1 digitisers can no longer be supported.

Users of other Güralp digitisers and instruments should contact for advice.

If you need to take remedial action, the following options are available:

CD24 digitisers, including those embedded in instruments such as the 6TD, will need to be running the latest firmware before they can use the new receivers. If your CD24 requires a firmware upgrade, please see the WNRO CD24 firmware upgrade page.

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.

We are not able to provide an equivalent firmware update for CD24 digitisers, DM24 Mk2 digitisers or the corresponding integrated instruments. For these types of systems,a GPS receiver hardware upgrade is the only solution.

The new receivers offer the following advantages:

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.

Background information

The use of the term "GPS" in this document refers to the US-operated NavStar/GPS Global Navigation Satellite System (GNSS). Other GNSSs, such as GLONASS, Galileo or BeiDou, are not affected by the problem described in this article.

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.

Historic problems

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.