Jump to content
Sign in to follow this  
Followers 4
ecanderson

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.

 

 

Share this post


Link to post

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.

Share this post


Link to post

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!

Share this post


Link to post
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

Share this post


Link to post
11 minutes ago, HHL said:

Google my friend: time rollover 2038

Duh.... LMGTFY!

 

Gonna need to make another pot of coffee!

 

 

Share this post


Link to post
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

Share this post


Link to post

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?

Share this post


Link to post
23 hours ago, The A-Team said:

 

Thanks for that.  :)

The part immediately drawn to was, "  In effect this means that older GPS receivers will operate normally for almost 20 years before problems begin to occur".

 - I think maybe I got my monies worth outta my 13yr old GPSr.   :D 

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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. 

Share this post


Link to post
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:

Share this post


Link to post

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

Share this post


Link to post

Gack.  What a Catch 22 that one was.

 

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.

 

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

Share this post


Link to post
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...

 

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
Followers 4

×