Chris Farrow

GPS WEEK ROLLOVER

So, what's the problem? It's sometimes referred to as the "millennium bug of GPS" but what exactly is it?

The GPS System provides navigation & timing by using synchronised messages sent from a constellation of satellites orbiting the earth to a user's receiver - whether that be a dedicated navigation receiver (i.e. "Sat Nav") or a specialised timing receiver. The synchronised messages contain a time code, using a timescale known as "GPSTIME" that is encoded in its own unique way. So here comes the problem; within that encoding system the week number can only be represented by 1024 unique values.... so, every 1024 weeks the code repeats. The opportunity for a problem occurs when the week number changes from 1023 back to zero, or "rolls over". This has happened before, on 21st Aug 1999 as GPS "week zero" originally started 6th Jan 1980. So, the next one's coming pretty soon... 6th April 2019 to be precise.

So what might happen? Well, older receivers might get confused and think it's 1999 again... or worse 1980! As this has happened once already the GPS industry as a whole should be prepared for it, and many receivers will carry on working correctly without issue. You should only be concerned if you have a receiver that has been in continuous operation for more than ~10 years without any firmware update or if your receiver forms part of a critical system - can you afford to just wait and see?
First port of call should be the GPS receiver's manufacturer (or their service/support representatives) to see what they have to say, for example if the receiver and its software have been tested to handle the rollover without issue. If that's not possible then you may have to resort to performing provocative testing with GPS simulators that can provide the exact conditions that will occur in a week rollover scenario.

How any failure will manifest itself is difficult to say; as it's a software bug it depends on so many other things unique to each manufacturer's implementation... some receivers may carry on apparently unaffected apart from the wrong date, some may reboot/restart and sort themselves out whilst others may just fail and not recover.


For more information:

Chronos test solutions:
https://www.gps-world.biz/products/test-a-measurement/labsat-3-gnss-simulators

GNSS Vulnerabilities linkedin group:
Chris Farrow

Introduction to Timing and Synchronisation

Timing dependent applications rely on their clocks being correct within the set tolerances required by that technology.In order to achieve this, timing is transferred between clocks using various methods that enable time or frequency, phase or time of the required quality to be available to the application.The activity of transferring time between clocks is known as synchronisation. ​

Timing and synchronisation quality can be described by two factors:accuracy and stability.Accuracy is the measure of how closely the clock compares to a reference or target value; this can be a global standard for time such as UTC or a desired frequency such as 10MHz; stability is the measure of the variance of the clock when observed over a period of time.

In order to quantify the quality of timing and synchronisation, many different timing metrics exist.These are specifically designed for the timing technologies they are measuring and the characteristics of the signal that are of interest.Measurements must be made against another clock of known and dependable quality during relevant network or environmental conditions and over a period of time long enough to fully characterise the measured clock.