GPS Week Rollover - Update

[+Atlas Cached]

As it has been discussed in many places recently that some older GPSr may be in danger of becoming obsolete/disfunctional in April 2019 due to a 'GPS Week Rollover' issue, I believe the Garmin GPS 72H may be the first unit (that I am aware of) to receive a firmware update to correct this very issue, more than nine years after initial introduction. That's pretty good support from Garmin, as many, if not most of their units that old (in some cases, much  newer) no longer receive support/updates.

 

I wonder how many more GPSr (all brands) are going to receive similar updates? How many will become paper weights?

[+dprovan]

Paperweight? Is there a functional impact of the rollover fail that I don't know about yet? My PN-60 thinks it's 1999, and that's very annoying for several reasons, but so far, at least, it hasn't had any trouble showing me where I am and where I'm going.

 

(Alas, I don't need to wonder about my PN-60's firmware ever being upgraded. I'm not sure DeLorne knew where the firmware sources were even before Garmin bought them.)

[+Mineral2]

It shouldn't really, as long as proper service with the satellites either doesn't require the devices to have a time sync, or that the time is simply synced with the 10-digit digital counter. When you mark a cache as found and upload the field note, does it record the correct date/time, or the date it thinks it is in 1999? I suppose that could be the only drawback.

[robertlipe]

We talked about this a little at https://forums.geocaching.com/GC/index.php?/topic/349353-april-6-2019-week-rollover-issue Guessing how software will break can be a fool's game. Maybe some code wasn't prepared for time to go backwards. code like 
start_time = get_time();
do_something_slowly;
time_taken = get_time() - start_time;
is extremely common and if time happens to go "backward" while you're doing something in that "slowly" chunk, time_taken will be wrong if you're lucky and potentially negative which is almost certainly unexpected.

So if something bad happens and it's "just" in the user interface code, that would be merely unfortunate. (It would also be ironic. Every one of those satellites is one of the more precise time pieces ever built and in the navigation message packet that they transmit, it's the very time of week field that's rolling over. Where it would really suck, potentially bricking the unit if they really screwed it up, is that if the time used to index into the almanac is so wacked that it can't resynchronized the coarse acquisitions (C/A) for enough of the satellites to correlate to the precise times (P-codes)  to figure out location. More modern units with lots of receiver channels and lots of correlators have a better chance of recovering from even a moderate programmer face-plant than the older ones do. There WERE units that turned to bricks the last time this happened. Remember that not all GPSes are sitting on your car or even have a screen; it's the ones sitting on a tower in a field controlling some process-control device that were more in danger as they're less likely to be attached to something to get updates.

There's some nerdy math on this page, but even if you skip the math, this page does a good job explaining what the chips are working with https://en.wikipedia.org/wiki/GPS_signals

 

[+Capt. Bob]

16 hours ago, dprovan said:

Paperweight? Is there a functional impact of the rollover fail that I don't know about yet? My PN-60 thinks it's 1999, and that's very annoying for several reasons, but so far, at least, it hasn't had any trouble showing me where I am and where I'm going.

 

(Alas, I don't need to wonder about my PN-60's firmware ever being upgraded. I'm not sure DeLorne knew where the firmware sources were even before Garmin bought them.)

I found my Delorme PN-60w will still generate accurate coordinates if used often.  However, if not used for several days it will fail to find some satellites and a large estimated positional errors (EPE) will occur.  In that case it needs a Non Volatile Memory (NVM) reboot to acquire all the available satellites. 

According to this excellent article of the End of Week (EOW) rollover problem (http://www2.unb.ca/gge/Resources/gpsworld.november98.pdf) the satellite acquisition issue may get worse over time or even totally fail.   It will be interesting to see what other non-compliant GPSr’s will fail in the April 2019 EOW rollover.

[+Red90]

I have a cache that forces the finders to us a GPS38.  It will be interesting to see how it behaves after the roll over.

[+hzoi]

13 minutes ago, Red90 said:

I have a cache that forces the finders to us a GPS38.  It will be interesting to see how it behaves after the roll over.

 

Interesting cache.  Until I read the description, I was wondering how exactly one could force seekers to use a specific GPSr - but it all makes sense.  I sort of wish I still had my old GPS12 so I could steal the idea, but alas, I've no idea where that old brick has gone.

[+Red90]

Actually I see from a little Google that there is an EOW update for it.  I probably already installed it.  Who knows.  I'll probably pull it at some point and try again.  Now to locate the cable for it....

[+dprovan]

23 hours ago, Mineral2 said:

It shouldn't really, as long as proper service with the satellites either doesn't require the devices to have a time sync, or that the time is simply synced with the 10-digit digital counter. When you mark a cache as found and upload the field note, does it record the correct date/time, or the date it thinks it is in 1999? I suppose that could be the only drawback.

Yep, my PN-60's date is wrong, so recorded times are wrong, too. I don't use field notes, so not important to me, but that is the problem people were more focused on in the previous thread. For me, the big problem is that the sun, moon, and tides weren't the same in March, 1999 as they are in December, 2018. A somewhat lesser annoyance is that when the PQ files get written back to memory, they get 1999 timestamps.

 

7 hours ago, Capt. Bob said:

I found my Delorme PN-60w will still generate accurate coordinates if used often.  However, if not used for several days it will fail to find some satellites and a large estimated positional errors (EPE) will occur.  In that case it needs a Non Volatile Memory (NVM) reboot to acquire all the available satellites. 

Thanks for the warning! I thought I'd left my PN-60w turned off for several days at a time lately, but fortunately haven't seen this yet.

[+Mineral2]

3 hours ago, Red90 said:

I have a cache that forces the finders to us a GPS38.  It will be interesting to see how it behaves after the roll over.

What cache is that. And how many visitors does that cache get? Rather, I'm curious what features the GPS38 has that excludes cachers from using a modern GPS.

[+Atlas Cached]

15 minutes ago, Mineral2 said:

What cache is that. And how many visitors does that cache get? Rather, I'm curious what features the GPS38 has that excludes cachers from using a modern GPS.

Read the posts above, Mineral.

 

Cache is linked.

 

When you read cache page, all questions are answered!

[+Mineral2]

Ah... you know, those old units were really meant to be used alongside a map and compass.

[+Red90]

12 minutes ago, Mineral2 said:

Ah... you know, those old units were really meant to be used alongside a map and compass.

 

Not at all.  It works perfectly fine on its own.  Update rate is a bit slow, but it zeros out as well as anything else.