Jump to content

April 6, 2019 "Week Rollover" Issue


Recommended Posts

Dragging this old topic back to the fore since we're going to see this again in April of 2019.  There's a technical issue looming in the future, and I have no idea whether it will be an issue for some of my Garmin units or not.  It all has to do with the 10 bit 'week counter' that runs only 0-1023, and we hit week 1024 again on 6 April of next year. since the last reset/rollover of the system was August  '99

 

I dare not assume that Garmin continued to look forward another 19.7 years when cleaning up their code for the August 1999 situation, so does anyone with any inside knowledge of their development  know if there will be issues with some or all of their older (EOL) units in 2019?  One would think they've coded since then to handle this gracefully, but I'm assuming nothing of the sort for the time being.

 

 

Link to comment

On the GPSBabel list a week or two ago, we had someone with an older model Garmin seeing a failure that realized he was N weeks before the rollover and his unit was reporting that it was N weeks after the rollover, but resulting in it being 19.7 years off. This meant his unit was reporting a time that was after the "4.2 billion microseconds since 1/1/1970" epoch rollover time in 2038 so he was getting on overflow when he ran a 32-bit OS, but a different (still wrong) behavior on a 64-bit build of the same OS. He was able to find a very similar failure on a Legend (an even older serial model) that had a similar weird stuck time, but it was stuck at the first rollover in '99.

We weren't able to help him. Even after a factory reset, it remained stuck a few decades in the future. Somehow he connected the amount it was wrong to the 10-bit week overflow next year but it's entirely possible that it's numerology and his GPS is just slightly broken.

We've definitely seen GPSes handling things like this badly in the past and I'm sure we'll see devices failing in some way this time, too. Time wraparounds and overflow and underflow are things that programmers just tend to handle poorly because they're hard.

  • Upvote 1
Link to comment
1 hour ago, Atlas Cached said:

I have a couple old serial legend GPSr. Can someone explain in a little more detail exactly what this failure is and how I would identify it on my GPSr?

 

Thank You!

Google my friend: time rollover 2038

Link to comment
9 hours ago, HHL said:

Google my friend: time rollover 2038

Which doesn't help at all, because that isn't the same issue. Telling people to Google "time rollover 2019" would have been slightly more useful, because it would get you to results like these, which explain what the issue is, how it relates to GPS, and how it would affect GPS receivers:

GPS Week Roll Over Issue - GPS.gov

The GPS Week Number Rollover problem

  • Upvote 1
Link to comment
53 minutes ago, noncentric said:

So really, the core question is whether our specific GPSr uses 10-bit or 13-bit encoding of the week number.  If the former, then there could be a problem next year.  If the latter, then nothing to worry about.

Is that right?

I think that's right. I get the sense that pretty much any GPSr made since 1999 should be fine unless the manufacturer had some really lazy/oblivious/boneheaded designers, but I don't know if there's any way for us to check whether our own GPSr is fine or not.

Link to comment

Indeed, it would require 'inside knowledge' of whether each manufacturer has properly planned for this event in their code.

Just wondering/hoping if Garmin learned their lesson the first time and applied the fix to subsequent models or assumed many would be EOL before anyone cared.  I still prefer my old Oregon 450 for what I do, and would be disappointed if it 'broke' next year.

Link to comment

I'd be surprised if any Oregon-class device totally "broke". There might be some interesting things in the industry going on in the moment that it wraps, like programmers forgetting to mask on a carry or subtracting time without expecting it to go "backward". I'd expect at least a few drones or robots to jitter, a few tracks to have weird things, some systems need reboots, etc. I doubt that any modern device will be bricked or even need a firmware update. Probably. If they're fixed by a reboot, they can wait another 19 years. :-)

I did muddy the conversation somewhat by mixing what presents itself in GPSBabel as a Y2038 problem when the reality is the Garmin just presents a whacked out time. See
https://sourceforge.net/p/gpsbabel/mailman/gpsbabel-misc/thread/20180715114005.6aac7ca4%40raspberrypi/#msg36368348 (Libusb and Pi turn out to be red herrings. Packet analysis begins at the message with GPS_COMMAND_GET_TIME - In the next message he says   "The Garmin is indeed showing the wrong date: today it is 1-MAR-2038". We didn't really tie it to the 2019 issue being discussed, but we did notice it's "about 19.7 years" off, which is about the period for that problem, too. Numerology? Maybe. You can tell from the tea leaf reading that I'm kind of used to that.

We've seen it on original Vista https://sourceforge.net/p/gpsbabel/mailman/message/10805638/ and Forerunner 201: https://sourceforge.net/p/gpsbabel/mailman/message/21304913/ and I know we've seen it in others.

As for boneheaded designers, we've seen them hardcode things like the WAAS SV's in the firmware instead of using the ones in the almanac (remember patching the hex files and reprogramming Meridians?) we've seen devices report GPS time instead of UTC even though the offset between them is broadcast in the almanac and not made visible to the host. (This is why there's some stupid data logger where we have to patch GPSBabel every time there's a leap second introduced...yeah, we should fetch it from a network server somewhere.) We've seen devices that have access to some of the most magnificent time keeping devices we've ever built display human-readable time very, very wrong (see Map330, Meridian, aforementioned time-traveling Garmins). So, yeah, there'll be *someone* in the GPS biz that gets this wrong.

Edited by robertlipe
More wordy words
  • Upvote 1
Link to comment

I note your comment with a chuckle...

I agree the error handling in this path is atrocious and the code path in
question is not year 2038 ready on 32-bit systems where time_t is an int.
(I pray that these glorified serial Garmins will finally be out of my life
by 2038...)

Well, we'll see what comes of it next year. 

Link to comment
4 hours ago, ecanderson said:

(I pray that these glorified serial Garmins will finally be out of my life by 2038...)

Legacy stuff never seems to go away. I fully expect that someone in 2038 will be trying to transfer data from their Musk 28x Neural-interface Data Processing Unit to their ancient yellow eTrex and complaining that it doesn't work. :laughing:

Link to comment

Those guys running a 32-bit OS in 2038 will have way bigger problems on their hands than trying to find a USB 6 adapter for their Musk 28x NIDP for their Garmin. :-)  But as a fun task, I did check. All the serial Garmins and some of the older USB ones are going to have problems with waypoint times (little used) and track times in the year 2038.

I looked in the GPSBabel source, and all the time handling in Garmin protocol looks approximately like this. In layman terms, they read 4 bytes (that's the GetUint and +=4 stuff) and then shove it by a constant to adjust from GPS Time (1980) to time_t time (1-1-1970) - that's the GPS_Math_Gtime_To_Utime() stuff. There are many types of Garmin serial packets, but that's in the code for D110's which is the newest of the lot. You can find similar code in the D30[123] path for tracks - it's all still 32 bits for time.  So, yes, the serial Garmins will, at best, start reporting times of 1970 starting in the year 2038. This would also include the ones that smuggled Garmin serial protocol over USB which would include the 60 and 76 series, StreetPilot, i3, Rino, Quest, Legend HC, Legend Cx, and so on. If your Garmin doesn't show up as a USB disk drive with GPX files for waypoints when you plug it in, it's affected. "New" units, like Nuvi, Oregon, Colorado, and such that use GPX throughout wouldn't be affected by this - they may very well have their own issues, but they won't have the issue where it's impossible to represent the current time in the protocol on the wire. So all the devices (and probably more) that aren't footnote 2 at https://www.gpsbabel.org/htmldoc-development/fmt_garmin.html will likely start returning tracks in 1970, for example. To be clear, this is a 2038 problem and not a 2019 GPS almanac wrap issue.

But you guys are largely right. The inertia of the the installed base can be surprising. Somewhere there'll be a classroom with textbooks in Nheengatu that'll include screenshots of this exact model of device and that has a hundred of them, so someone will need it to work and the cost of replacing them with something "better" will be ridiculously high. A large portion of the consulting industry in tech is dedicated to "solving" (or passive-aggressively making...) problems like this.

If you find my writing in code entertaining, ecanderson, see some of my Garmin USB  grief. :-) 

Edited by robertlipe
8 bits, 32 bits, whatever
  • Upvote 2
Link to comment
10 hours ago, ecanderson said:

Gack.  What a Catch 22 that one was.


I really don't think the GPS-using public of that era understands the engineering chops that went into that stuff.  My day job at that time was developing the USB stack for a large operating system, so I happened to have the USB protocol relatively committed to memory at the time as well as access to the specs and protocol analyzers and such. I helped Apple identify a bug in the Garmins that crashed the Mac OS USB stack just because the Garmins were built to do what the Windows USB stack did (always respond with 10 bytes or something) instead of doing what the spec said (read the two bytes containing the size and then maybe read bytes) in the early days. The early USB Garmins were such a total mess. I don't miss those days at all. 

 

10 hours ago, ecanderson said:

I do get a chuckle out of reading other writers' source, especially when it's in non-corporate environments where a person is free to do a bit of editorializing.

 

It is a bit cathartic when your day job has all the individuality sucked out of it and you have thousands of people protecting developers from end users - and vice versa - to have a constant little "behind the scenes" show. :-)

 

 

10 hours ago, ecanderson said:

 

What installed base inertia?  I'm running XP on this machine, not Win 95!


Don't worry. In the time it took you down to download and install the service pack, your machine was already 0wned.  :-)

But it's actually somewhat of an interesting comparison. Think about how many more GPSes are in use right now than there were in 1999 when the last rollover happened. There's a whole lot of equipment that's never battle-tested this case on anything but simulation and unit-test. There's a tech bulletin from ublox (more popular in embedded cases more than the kind of GPS we deal with in geocaching) describing how they handle the gps week rollover and at a blush it seems reasonable. But, just like that Windows XP system that's controlling the MRI in your doctor's office that you pray is never connected to the internet at large and never sees a firmware update for better or worse, how many cases are there marine or aviation panel mounts that go 20 years without a firmware update?  Are there units on the neck of an elephant (fun fact: one of those elephants is named for my boss for his outreach work with them...) or measuring glacier movement or other cases beyond finding pizza with your cell phone that'll never see any firmware update? Certainly. Bugs in some of those will happen and bugs that happen once every twenty years aren't exactly likely to show up in casual testing. I *think* most of the bugs will be somewhat quickly self-correcting and will show as glitches like tracks ending before they started and not total navigation failure where we have emergency vehicle dispatch paralyzed and planes flying into Null Island.  Recall that GPS has uses beyond navigation; it's a key part of global time synchronization. A world-wide database where time runs backwards for some connected nodes - and not others - even for a short time is likely to expose all kinds of entertainment.

It'll be an interesting industry spectacle to watch...for the, like, five of us that watch such things.  We probably won't get Dick Clark counting down a dropping Space Vehicle dropping to zero for this.

Maybe we should start a petition...

 

  • Upvote 1
Link to comment

Yes. See e.g. https://www.spirent.com/Blogs/Positioning/2018/January/GPS-Rollover-Week for an accessible discussion.

It's quite possible that you won't notice a difference looking at your receivers. It's more likely that the NMEA data or the track times during and after that time will act funny, so unless your event is prepared to gather tracks during a walk at that tie and capture and analyzer captured traces, you may never notice.

  • Upvote 1
Link to comment

Weird.  Even my Garmin 38 does not have an issue.  Assuming the device is not corrupt and has connected to a satellite in the last twenty years, there should be no reason for it to be confused as to whether it is today or twenty years from today.  The last connected location and time is always stored to non volatile memory and since the next connection must be in the future, it is not rocket science to do the coding...

Link to comment

I'm not taking any chances.  In very early April (the ground should be thawed by then), I'm going to take my three 60CSx units slowly (to avoid disturbing the dust) into the backyard, and bury them under half a metre of mineral soil.

 

Let some future archaeologist fire them up - assuming they can find AA batteries - and worry about what happens next.

Link to comment
24 minutes ago, rickrich said:

 

Thanks, but some reason that link keeps redirecting me to a Geko.201.  I didn't know anyone used those to cache.  

 - We put two in caches as FTF prizes a few years ago.  :)

They do say, " all functions not dependent on date and/or time will continue to work normally. Due to the age of the device we have determined we will not fix this issue"  though.   I'd think that's probably standard for most the long-discontinued.

Haven't had any issue with our (two) also-outdated 60CSx - yet. 

 

Similar to The A-Team, turned 'em on at 0015, minor celebration (and with a coffee),  and all's ok...  so far...       :D

Link to comment

Fired up both the Magellan Explorist 100 and the original Etrex yellow out of storage today.  Once they locked in to the satellites, the dates were correct April 6th, 2019 but both were off by an hour, probably due to the old daylight savings time.   So no problems on those two units. 

Link to comment

Garmin GPS V (circa 2001) OK...for now.

 

As Spirent’s Guy Buesnel writes, that means “the 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.”

Link to comment

My eTrex 20 seems to be fine.  The date showed April 5th when I first turned it on, but corrected itself to current date once it connected to satellites.  However, the time was not correct.  The unit showed a time that's 7 hours ahead of current time in PST.  I had Setup -> Time -> Time Zone = "Automatic".  Once I changed it to "US - Pacific" then the correct time displayed.

 

I don't recall setting the Time Zone to "Automatic", but it seems like it would automatically know what time zone to use since it knows where I am based on my GPS coords.  Not sure if the setting changed to "Automatic" by itself, or if I always had it that way.

Link to comment
9 hours ago, noncentric said:

I don't recall setting the Time Zone to "Automatic", but it seems like it would automatically know what time zone to use since it knows where I am based on my GPS coords.  Not sure if the setting changed to "Automatic" by itself, or if I always had it that way.

They come factory set on Automatic, and for the most part, Automatic works well. When crossing a time zone line, the GPS will update the time almost instantly.

Link to comment
46 minutes ago, Mineral2 said:

They come factory set on Automatic, and for the most part, Automatic works well. When crossing a time zone line, the GPS will update the time almost instantly.

I guess I just never changed it to PST then.  Odd that it was set to Automatic and showed GMT time (7:30am) when I turned on the unit this morning (12:30am).  It had always shown the correct time before, when it was presumably still set to Automatic.  Oh well, it's hardset to PST now.

Link to comment
2 hours ago, noncentric said:

I guess I just never changed it to PST then.  Odd that it was set to Automatic and showed GMT time (7:30am) when I turned on the unit this morning (12:30am).  It had always shown the correct time before, when it was presumably still set to Automatic.  Oh well, it's hardset to PST now.

My Oregon 600 sometimes turns on with the wrong time until it acquires a position fix. Then all is well. Careful hardsetting it to PST. Should you travel across time zones, you're going to have to remember to change it.

Link to comment

I ran a little test.

Oregon600, as expected, no issues.

Colorado 300. It's now August 23rd 1999. Time is correct and location is correct.

GPS12XL, took a lot of time to get satellite lock but location is correct and time is correct too. I will try to get the old COM port working via USB and see NMEA output.

TomTom One XL, once it booted after a long time not being used it locked on the satellites and showed exact time (not checked if I can see a date on that one).

Garmin Nuvi 2597, had to wait for a lock (GPS was last used in Iceland, 2000Km away) but also OK on time and location.

 

Link to comment
7 minutes ago, Mineral2 said:

My Oregon 600 sometimes turns on with the wrong time until it acquires a position fix. Then all is well. Careful hardsetting it to PST. Should you travel across time zones, you're going to have to remember to change it.

Yeah, the date was on April 5th when I turned it on.  Then it got the satellite connections and the date corrected itself to April 8th, but the time didn't correct.  I'd think it would know what time zone to use, based on where it recognizes me as being - and the icon on the map screen did correctly show me in PST, but oh well.  I just turned it on again, it correctly says 2:15pm, when I change the time zone to Automatic it says 9:15pm, so I'll just have to remember to keep checking the setting. I don't cross time zones often, so not too much of a hassle.

 

I just thought it was odd that it happened around this week rollover timeframe.  Doesn't seem like it would be related though.

Link to comment
26 minutes ago, noncentric said:

Yeah, the date was on April 5th when I turned it on.  Then it got the satellite connections and the date corrected itself to April 8th, but the time didn't correct.  I'd think it would know what time zone to use, based on where it recognizes me as being - and the icon on the map screen did correctly show me in PST, but oh well.  I just turned it on again, it correctly says 2:15pm, when I change the time zone to Automatic it says 9:15pm, so I'll just have to remember to keep checking the setting. I don't cross time zones often, so not too much of a hassle.

 

I just thought it was odd that it happened around this week rollover timeframe.  Doesn't seem like it would be related though.

 

I wonder if there is a Time Zone map update for your Oregon?

Link to comment

A user in a different forum had reported several weeks ago that his nuvi 550 had the date issue where the date was stuck at 1999 which sounded like the week rollover issue. He contacted Garmin support and they said his nuvi would require a software fix and they did not commit to a fix but offered to "buy back" his 550 for replacement with a newer device. However, Garmin has not issued any firmware updates on the nuvi 5x0 series, so I am wondering if this issue was something else or if this user was just incorrect in his understanding of the problem. Are there any nuvi 5x0 users here, and if so are the devices still working with a correct date now that the date rollover has passed?. 

Edited by alandb
Link to comment

alandb says " re there any nuvi 5x0 users here, and if so are the devices still working with a correct date now that the date rollover has passed?."

 

I've got an old Nuvi 255W (ca. Mar 2008) which fired up with correct time/date/year.  Strange that the 550 (ca. Jul 2008) does not.

Link to comment
11 minutes ago, jimlarkey said:

alandb says " re there any nuvi 5x0 users here, and if so are the devices still working with a correct date now that the date rollover has passed?."

 

I've got an old Nuvi 255W (ca. Mar 2008) which fired up with correct time/date/year.  Strange that the 550 (ca. Jul 2008) does not.

 

I'm pretty sure the problem is GPS chip based.  In other words, the coding error is not Garmin coding, but that of the chip manufacturer.  Thus is will be more tied to which chip is in which device and not the age.  Garmin knew of the issue in 1999 and made sure all of their models at the time did not have the problem.  You can search and read discussions about it directly from the programmers at Garmin.  This is the problem with the change to sub vendors for the GPS chips.

Link to comment

I have a nuvi 200W which is even older and also a nuvi 1310, and both are still working as of today. They both have recent maps from OpenStreetMap data but once a month they complain about the preinstalled closed-source Garmin map being more than a year out of date :)

 

Also I have a TomTom XL, of a similar vintage to the 200W, and this also managed to get a GPS lock with the correct date, time and coordinates, just now, after the usual 3 minutes or so. I was recently experimenting with Navit and OSM maps on the satnav (TomTom's native map format is still a closely guarded trade secret). I hadn't used the XL for a few years but about three weeks ago I fired it up to try using Navit. On that occasion TomTom Home offered an update to speed up acquiring a GPS position but also informed me that the satnav is out of support, and TomTom's website was also very vague on whether updates were needed. It seems that no update was, in fact, needed. So it's good to know the XL isn't yet just a paperweight...

 

 

Edited by and1969
disambiguation
Link to comment
11 hours ago, phlemicus said:

Have 2 identical Garmin Nuvis, bought at the same time for 2 different work vans and neither can find a satellite.  Friday was OK, Monday nothin'....

 

Well, that really narrows it down! Garmin only made a few nuvi models...

 

All the same, to make it easier for everyone else, Which nuvi model do you have two of?

 

Regardless, I doubt the satellite acquisition symptom you describe is related to the week rollover issue:

 

39 minutes ago, jimlarkey said:

phlemicus: strange again that the rollover would have that effect.

 

Garmin's published statement: " the positioning accuracy will not be affected. The device will continue to deliver the same positioning performance as before the rollover. "

 

Garmin GPS Week Number Rollover Statement

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...