My Garmin Etrex 10 working fine.
73, Alfred, OE5AKM
My Garmin Etrex 10 working fine.
73, Alfred, OE5AKM
This is what Garmin had to say about it when I asked…
What is the GPS Week Number Rollover (WNRO)?
The GPS system is world renowned for its ability to provide accurate and reliable positioning and timing information worldwide. The GPS satellites transmit to users the date and time accurate to nanoseconds. However, back in 1980, when the GPS system first began to keep track of time, the date and time was represented by a counter that could only count forward to a maximum of 1024 weeks, or about 19.7 years. After 1024 weeks had elapsed, this counter “rolled over” to zero, and GPS time started counting forward again. This first rollover occurred in August of 1999. The second rollover will occur on April 6, 2019.
Is My Device Affected?
For many years, Garmin has anticipated and prepared for this event. Regardless, Garmin has been performing exhaustive testing of current and legacy devices to determine if they will be affected by the GPS week number rollover. Our testing shows the vast majority of Garmin GPS devices will handle the WNRO without issues.
What is the Effect of a GPS Week Number Rollover Issue?
For GPS devices that are affected, after the rollover occurs, an incorrect date and time will be displayed. This incorrect time will also be used to timestamp track logs, compute sunrise and sunset, and other functions that rely upon the correct date and time. However, the positioning accuracy will not be affected. The device will continue to deliver the same positioning performance as before the rollover.
My own findings - post rollover-2:
Garmin GPS12 - Software 4.59/ 1996-2001:
Working normally inc time, position and date.
Garmin GPS12XL - Software 4.60/ 1996-2003 & Europe City Database 2.01/ 1998:
Working normally for time & position but DATE displayed today (08-04-19) is 23-August-1999!! This seems to have gone back to the date of the second rollover in August-99. (Due to non-charging internally, I have had to add an external 2032 memory battery which has to be renewed annually so there’s little lost here).
Garmin GEKO-301 (Two units) with ‘final’ software:
Working normally inc. time, position and date.
(Third unit not tested).
Very relieved that my GEKO’s are still good. I no longer use the 12 and 12XL.
Someone got caught out…
I was surprised to read that several airliners were grounded because of this. For example:
Honeywell, for example, notified its users in time about the how to test and fix the instruments as probably did other manufacturers, so this particular case is to be blamed on sloppy maintenance. But it still baffles me that this is still the issue at all. B787 is fairly new aircraft type with first flight in 2009. I expected that by that time aircraft instruments manufacturers implemented needed mechanisms to avoid these issues since first rollover happened in 1999 and this is a well known issue.
I guess this is the consequence of saving the costs, either by avoiding the certifications by the manufacturers, or by not doing needed upgrades by the airlines, similar to the current B737 max thriller.
Meanwhile, my consumer grade GPS devices and modules are just fine.
Due to too much time spent at ham radio flea markets and yard sales, I have a small collection of aging handheld GPS units, which I tested with these results:
Garmin etrex Legend, 2003 firmware: date and time are correct
Garmin GPSmap60cs: date and time are correct
Garmin GPSmap62s: date and time are correct
Delorme PN60: date and time incorrectly reverted back to 1999_before_ the April 6 rollover, and remained in 1999 after the rollover. Too bad.
Ironically, the Delorme PN60 was the only one of the bunch that I bought new and paid real money for. It was a good unit for several years, and included comprehensive 1:24,000 North America maps. However, it could use only Delorme maps (unlike Garmin units that can use OpenStreetMaps or its derivatives) and Delorme had no offerings for detailed maps outside of North America. The death knell sounded when Garmin bought Delorme to get the InReach technology; Garmin not only stopped selling the Delorme-brand GPS units, they even took down the extensive user forum with its valuable information. Now the PN60 seems to provide reliable navigation, but any function requiring a time stamp is wrong.
The SOTA Reflector is kept open so that anyone can read posts not just members. Occasionally a Google search suggests a topic to someone outside the SOTA community. On behalf of just such a person I am posting his comments and questions. He will of course be able to read any responses.
I have the Vista Cx as well and I haven’t used it in a few months, but after starting it up recently I noticed the date and time were way off. I let it soak with a GPS signal for a while and eventually the time corrected itself, but the date was still off. I gave up, but the next day I turned it on both the time and date were correct. I thought it was just a matter of me not using the GPS in a while and the problem was fixed; however, after turning it on the following day the date and time were off again.
So that has been my experience so far and is mostly repeatable. If I let it soak for a while and then restart the unit, everything is correct. But another restart (even just quick power cycle) and the date is wrong.
I messaged Garmin and they seemed to confirm it was a result of the rollover and there is nothing that can be done about it. I use the GPS for all my hiking/mountaineering/skiing adventures and always save my tracks so I can reference them when planning future trips (time of day, trip duration, etc), so the timestamp data is important to me. I was already considering upgrading to the eTrex 30x for the better antenna, but couldn’t quite justify it because the Vista Cx has worked just fine all these years. This rollover issue may have just made up my mind for me.
Martyn M1MAJ, I am curious if your Vista Cx retains the correct time/date when you power it up in the future. Just wondering if it is like mine and will show a bad time/date on a future power cycle.
I’ve just tried mine again and indeed the date went wrong again. 2038-11-27 today. Second power cycle 2058-07-13. For the moment it seems to have stuck on that and hasn’t gone right again.
It’s interesting that it is showing this cyclic behaviour and warping into the future rather than simply showing a date 1024 weeks in the past. This feels like a bungled attempt to get it right rather than simply ignoring the problem!
Well it obviously could be fixed with firmware update, but Garmin clearly don’t want to. They may have “lost” the ability to make firmware updates by now.
In my youth I might have had a go at reverse engineering the firmware and patching it, but I’m getting a bit past that kind of game now!
Me too. But an incorrect date is not the end of the world. GPX files are plain text, and the format of the timestamps is perfectly transparent, e.g.
You can change the date with any convenient text editing software; I used a trivial Perl script but any text editor with search and replace facilities will do the job.
It’s weird they have tried and failed. I worked for a company that had a GPS chipset solution and we had a big simulation program that could generate all kinds of received data sets so you could test for this. So either they didn’t test for it or they don’t have rollover support and this is some maths code overflowing.
Jory has asked me to post this on his behalf.
Martyn, @M1MAJ thanks for your response. I did a little experimenting over the weekend to understand the behavior more and thought I would share. I did this all on Saturday, 2017-04-13. I would turn on the GPS, wait until I got a lock, wait 5-10 minutes, turn off the unit, and repeat. Here is the pattern I found:
State1) Date: 2020-07-22, Time: ~5 hours off (DST off). I’m considering this the beginning of the cycle. Every time the GPS starts in this state, it is a complete cold start, regardless if there was a GPS lock before a restart. After the unit searches for satellites and gets a lock, the date and time are updated to the correct date/time.
State 2) Date 2038-11-27, Time: correct (DST off). Hot start - quick lock on GPS. This date is 1024 weeks into the future. The date is never updated even after a good soak with a GPS lock.
State 3) Date 2078-02-26, Time: correct (DST off). Hot start - quick lock on GPS. This date is 3072 weeks into the future (3 x 1024). The date is never updated even after a good soak with a GPS lock.
State 1) Date: 2020-07-22, Time: ~5 hours off (DST off). Cold start. Date/time corrected after lock.
This is the pattern I see when I restart the GPS immediately after each state. It is weird I am missing the +2048 week date (2058-07-13) in this pattern; however, I did see that date pop up at one point in the past when I first noticed the issue. Perhaps it may show up during a warm start from one of those states, I just didn’t leave the GPS unit off long enough to see. Anyways, this at least shows the pattern is predictable. I had thought about modifying the .gpx file before when I first noticed the problem, but it sounded like too much of a hassle because the dates seemed random and I didn’t want to keep track of dates every time I logged a track. After this exercise and knowing the dates are off by multiples of 1024 weeks, it will be simple to correct the date in the .gpx file by just subtracting 1024, 2048, or 3072 weeks (whichever one makes sense) and then correcting for DST. So I’ll be able to make do for now, at least until I talk myself into buying a new unit (a better antenna would be nice, especially for moving in dense trees).
Just dug out my ancient Etrex Vista HCx and fired it up after 4 years of idleness, date and time seem fine