GPS ROLLOVER: IMPORTANT!

[Rapido925M]

Just had this email from TomTom: it may require YOUR attention!

Your satnav has always been there to guide you, now it needs your help.
On 6 April 2019, the GPS Week Number Rollover may impact your satnav. We are here to help you check and guide you through next steps. Get started below.

Mine was OK - Gordon

The GPS Week Number Rollover (WNRO) occurs every 19 years, with the next roll over taking place on 6 April 2019. Similar to odometers in older cars rolling over from 99,999 km to 0, the GPS WNRO is the resetting of the GPS calendar back to 0.

When the calendar resets, it can cause a miscommunication between GPS satellites and GPS receiver chips. As a result, some chips in satnavs will lose the ability to process certain functions.

 

[SpeedyDux]

Does this also affect Garmin satnavs?

My brief interwebby search hasn't provided a definitive answer.

 

[ChrisL]

It will affect all GPS systems, however some will have had upgrades to their firmware to resolve the issue or their may be an upgrade available. I would send Garmin an email referencing your model number and asking if you will need to do anything.
It seems to me this issue is similar to the millenium bug in that there does not seem to be a method of counting the rollovers in some older units. I got a few years work back in the day fixing date routines to cope with century changes.

 

[charliesgrandad]

From Tom Tom website if your sat nav is built in !!

If your TomTom satnav is not listed here, it is not impacted and no further action is needed.

RENAULTCarminat


RENAULTR-Link


SMARTMedia System

 

[pappajohn]

Year 2000 millenium bug ring any bells?

Computers the world over were going to crash at midnight 31/12/1999.

Nothing happened.

^{_{Subscribers  do not see these advertisements}}

 

[Lot lover]

@pappajohn - largely because people like us were paid daft amounts of money to make sure all went well.

 

[charliesgrandad]

Just checked my Trucker 6000

Good news! Your TomTom satnav will not be impacted on 6 April 2019 and no further action is required. Thanks for taking the time to check your device. Nothing left to do but drive on

 

[Cheshirecat57]

@pappajohn - largely because people like us were paid daft amounts of money to make sure all went well.

No you probably sat on M40 on quadruple time waiting for the chaos that never came
( and well done for the biggest con ever in IT)

 

[Deneb]

As I understand it, if you have a basic satnav intended to just get you from A to B and it's less than 20 years old, you would be unlikely to notice any impact, at least straight away:

"This won’t affect a receiver’s ability to navigate and/or calculate precise time from the day level down to the microsecond level. But it will create week, month and year timestamps that are wildly wrong, which could seriously impact any systems and applications that rely on GPS data at that level.

(To give just one example, GPS trackers employed in a fleet management system to track deliveries could cause system errors or even a crash if they suddenly start to output location data timestamped with a date 20 years in the past.)

Any impact won’t necessarily be felt on rollover day itself. In fact, it’s much more likely that an affected receiver won’t start outputting erroneous data until long after the 6 April 2019.

That’s because many receiver manufacturers have sought to maximise the default lifespan of their receivers by implementing the 1,024-week limit from the date the firmware was compiled, rather than from the date the current GPS epoch began.

In effect this means that older GPS receivers will operate normally for almost 20 years before problems begin to occur – and if firmware is implemented in this manner, no issue is likely to be seen when the GPS epoch changes.

For example, while the second GPS epoch began on 26 August 1999, a receiver manufactured in January 2005 may have a “pivot date” of January 2005 + 1,024 weeks coded into its firmware – meaning it will function smoothly until August 2025."

So unless you have a standalone satnav that is more than 20 years old, or one of the built in models indicated by Tom Tom (which are usually pretty poor in comparison anyway) I wouldn't worry too much!

 

[ChrisL]

No you probably sat on M40 on quadruple time waiting for the chaos that never came
( and well done for the biggest con ever in IT)

It certainly was not a Con the only reason everything went smoothly was because of the thousands of hours that went into analysis, code changes and testing. No business would invest the kind of money required to do that if there was not a real threat to their organisation.

^{_{Subscribers  do not see these advertisements}}

 

[Riverbankannie]

It certainly was not a Con the only reason everything went smoothly was because of the thousands of hours that went into analysis, code changes and testing. No business would invest the kind of money required to do that if there was not a real threat to their organisation.

Absolutely! It was a lot of work.

 

[Lot lover]

@Cheshirecat57 - sadly I was only on a daily rate and nowhere near the M40, I travelled on the southern bit of the M 25.

 

[pappajohn]

It certainly was not a Con the only reason everything went smoothly was because of the thousands of hours that went into analysis, code changes and testing. No business would invest the kind of money required to do that if there was not a real threat to their organisation.

Funny, I invested nothing but my PC and both laptops continued to work unaffected by the alleged chaos.
I'm sure there were thousands of small companies who also couldn't afford to invest in IT specialists who also carried on as normal.

 

[ctc]

@pappajohn - largely because people like us were paid daft amounts of money to make sure all went well.

I made pots of money out of it, didn't have a clue what I was doing.

 

[tonyl]

I was involved in the Y2K stuff at work in 1998/9 (defence company, so taken seriously). Most of our equipment didn't know what day of the week it was (much like upper management), never mind having any problem at the rollover. However, one of the things we uncovered as the work progressed was that there was a lot more date sensitive stuff around which would have a rollover at some point. I moved on from that project later in 2000 and the team was more or less disbanded but I do hope someone kept an eye on the dates. There is a big one on Unix systems to come in a few years (it's 2038, as I've just looked it up, though I would be surprised if there's much around then using 32 bit Unix).

Everyone at the time of Y2K had a view as to whether we were wasting time and money (and obviously they still do, reading the comments above) but if the whole thing did nothing but highlight issues that designers hadn't thought about, I reckon it was worthwhile. As with almost everything involved in engineering, there is a large amount of risk management involved. Bury your head in the sand and hope nothing happens or carry out some analysis? How would the 'bury the head in the sand' approach sound if you were trying to justify it to a judge or a coroner? Defence, medical devices, transport, banking - could any of them afford to ignore it?

The GPS rollover has happened before, so it's likely that most manufacturers will have anticipated its impact in their products but the number of devices which now have a GPS chipset inside is enormous compared with the last time it happened (1999), so I bet there will be some impact. Having a quick read, some manufacturers have used an offset in their firmware, so the impact may be felt 20 years after design rather than on the day itself.

^{_{Subscribers  do not see these advertisements}}

 

[Reallyretired]

I was also involved in the year 2000 thing. Quite a lot of work and a lot of equipment had to be replaced or updated. As a result of preparedness not much went wrong, just part of our hospital switchboard, the only bit that hadn't been replaced. It was not a false alarm, certainly stopped me seeing the new year in.

 

[Cheshirecat57]

But you will never know if the “old” stuff would have failed if you hadnt replaced it with new stuff....given lots didnt change stuff and it didn’t fail

 

[Jaws]

But you will never know if the “old” stuff would have failed if you hadnt replaced it with new stuff....given lots didnt change stuff and it didn’t fail

you, and many others who simply do not grasp what was going on, seem to base your fairly insulting views on home PC's
The biggest issues were not with hardware but the software which ran industrial plants and the like.
At the time I was with SSL.
All the servers were done, the mail chuckers done, even the printer servers were done ( some had been running Windows 3.x still ! ) and ready.
The sunspark machine did not give a toss and all the production line machines were sorted.. New years eve still had me biting my nails, and paying one of my team quadruple time + bonus to stay over night and monitor as much as possible.
Jan 1st 2000 saw myself and all the people under me in to work at 7am running checks.
We did get it all right apart from one testing machine.. It had come on line and was doing repeat tests ad infinitum on a non-existent subject...

 

[Guigsy]

Apparently a fix was put in the GPS receiving specification in 2010 to allow for more digits so the roll-over doesn't happen until some time around when the world ends. So anything built after that date should be fine... although that requires people to follow the spec.

The next big roll-over is in 2038 when unix/linux systems run out of digits in their date. This is already in the process of being resolved, but some code hangs around a looooong time.

 

[Jaws]

Thanks for the heads up on the issue.. My TT Camper Go CR52 did need updating....appreciate it @Rapido925M

^{_{Subscribers  do not see these advertisements}}

 

[scotzsue]

Not had any notification about our Toms so will check thanks for the heads up.

 

[DJA]

Here is the information from Tomtom


The GPS Week Number Roll-over (WNRO) is a result of how the Global Positioning System was originally set up and occurs every 19.7 years. The range of week numbers is limited to 1024 in total, and we will reach this maximum on 6 April 2019.

• None of our Nav4 devices are affected.
• Nav3 and Nav2 devices may experience some of the following issues:
  • No time
  • Frequent loss of GPS signal
  • No GPS signal at all - navigation impossible

We have already started rolling out fixes for this last year.

To get as many affected users to install the fixes before April we plan to send emails encouraging users to update their device.

• None of our Sports and Action devices are affected.

 

[PeteH]

Out of curiosity, I checked on the old T-T XL we bought in Walmart many years back and which navigated us all over the USA for 5 years!. although now unsupported, It still gets some updates via "Home", and it is current. So watch this space, as they say.

 

[pappajohn]

you, and many others who simply do not grasp what was going on, seem to base your fairly insulting views on home PC's
The biggest issues were not with hardware but the software which ran industrial plants and the like.
At the time I was with SSL.
All the servers were done, the mail chuckers done, even the printer servers were done ( some had been running Windows 3.x still ! ) and ready.
The sunspark machine did not give a toss and all the production line machines were sorted.. New years eve still had me biting my nails, and paying one of my team quadruple time + bonus to stay over night and monitor as much as possible.
Jan 1st 2000 saw myself and all the people under me in to work at 7am running checks.
We did get it all right apart from one testing machine.. It had come on line and was doing repeat tests ad infinitum on a non-existent subject...

So what your saying is all these very highly paid designers and writers who wrote the original software didn't think for one minute..... Hang on, what's going to happen at midnight on 31st Dec 1999....and include some script in the software to cover the eventuality at the time of writing the program.
And surely the programs use the computers processor clock which brings us back to the computer, not the software.

 

[Guigsy]

So what your saying is all these very highly paid designers and writers who wrote the original software didn't think for one minute..... Hang on, what's going to happen at midnight on 31st Dec 1999....and include some script in the software to cover the eventuality at the time of writing the program.
And surely the programs use the computers processor clock which brings us back to the computer, not the software.

At the time the code for these systems was written, computers were very much slower and had very little memory and storage. Allocating the extra bytes of data to something that isn't going to change for more than a decade just seemed inefficient and a waste of resources at the time. Then there's the fact that many of these systems grew organically way beyond their original design (which still happens) so you don't always know what assumptions your coding predecessors made...

Even now, time related bugs cause lots of issues in code. Daylight savings changeovers, dealing with different time zones and even differences in the way different operating systems report time are all problems that coders are often bad at considering in their designs.

^{_{Subscribers  do not see these advertisements}}

 

[tonyl]

So what your saying is all these very highly paid designers and writers who wrote the original software didn't think for one minute..... Hang on, what's going to happen at midnight on 31st Dec 1999....and include some script in the software to cover the eventuality at the time of writing the program.
And surely the programs use the computers processor clock which brings us back to the computer, not the software.

Of course they didn't! If it wasn't in the spec provided to them, it wouldn't (even shouldn't) have appeared in the code. My opinion of software engineers wasn't always high but in many ways they were the most process-driven people in an organisation. A specification was broken down into a set of 'shall' statements, which would be implemented in the final product in either software or hardware terms. If there had been a requirement which said that the item must work before during and after the rollover, including all aspects of its communication with other items, they would have considered it. Therefore, stuff with requirements written after the issue began to be discussed may have been OK but things designed before that would have potential failure points.

Even with all the preparations in this country, the US and around the world, some issues were still experienced and maybe we were lucky they were on the whole inconvenient rather than dangerous. I've found a list of some at https://www.lgcplus.com/kpmg-record...orld-wide-during-january-2000/1390385.article

Hardware did play its part as well because some shortcuts had been taken in the past. Hard coding in of 19 at the start of a date display is an example of that.

 

[Neil Bedwin]

I worked for IBM for 30 years. In 1999 we spent an loooong time updating firmware so that the extra digits were added to the date. Every machine in the data centre, of $20million of computing equipment. With that sort of investment they were not going to take the chance that the computer would think it was 1900 not 2000.

We already had high availability cluster multi-processing, dual routers, dual NAS, ups etc etc......

 

[MyrtleGuru]

@pappajohn - largely because people like us were paid daft amounts of money to make sure all went well.

Sadly I didn't get the daft money :-( But I did have to re-code some business critical applications that would otherwise not have survived into the 21st century.

Here's the techies' take on the GPS thing:

https://www.theregister.co.uk/2019/02/12/current_gps_epoch_ends/

 

[rod_vw]

Year 2000 millenium bug ring any bells?

Computers the world over were going to crash at midnight 31/12/1999.

Nothing happened.

Don't you believe it. I worked for BT in 1999/2000 and we were having to update voice mail systems to account for the millennium change. I know of one customer who refused to have theirs updated then wondered why it failed after January 1st!

 

[Jaws]

So what your saying is all these very highly paid designers and writers who wrote the original software didn't think for one minute..... Hang on, what's going to happen at midnight on 31st Dec 1999....and include some script in the software to cover the eventuality at the time of writing the program.
And surely the programs use the computers processor clock which brings us back to the computer, not the software.

As others have said
Most of the stuff affected was quite old.
Things then were much as today, with no one envisaging there work lasting more than few years without being moved on for something better.
But.... most of the stuff we are talking about was programmed so well it it did not need changing.
So what was probably designed with a five year life span was still in use come the millennium when it was rightly expected to be obsolete years before the event ....

^{_{Subscribers  do not see these advertisements}}