Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Any actions to take with GPS rollover?

+1
−0

For those of you who haven't noticed, your GPS may have become a time traveler this week.

Background

The GPS system was invented in the 1980s and uses an epoch of Jan 1, 1980 as the starting point for calculating dates. Many computers represent dates as a 32-bit count of seconds, which rolls over in 2038, but work is happening to extend the range before that happens.

The GPS system uses a 10-bit field for the week number. 10 bits can express a number from 0 to 1023, which is 19.6 years.

Jan 1 1980 plus 19.6 years = August 1999. We have had one rollover event.

Various companies dealt with this in various ways, much like we handled the year 2000 debacle.

The usual way to deal with this is to write a kludge into the firmware saying, "add 1024 to the week number received from the satellite".

You can see the problem with this particular trick: It only works after the rollover.

If you are shipping a unit that is going to span the roll over period, you write a hack like this: "if week number less than 950, add 1024 to it" The number 950 would allow you to ship units about 1.5 years before the rollover, and not get caught.

This is what DeLorme did, I think with an 8 month lead.

I don't know what DeLorme models were affected. My PN-60w is one of the affected ones. It started time traveling last summer.

Addendum: After two hours under an open sky it has not been able to get a fix

Addendum 2: It was going to sleep before getting a fix. Told it to not go to sleep while immobile, and it locked in a few minutes.

I don't know how this affects SPOT devices.

In the intervening years, DeLorme was bought by Garmin.

On another forum, I found someone who contacted Garmin, and basically was told, "Sucks to be you, we're not giving support on a discontinued brand" They phased it more politely than that.

To be sure: This does NOT affect the accuracy of the GPS location. But recorded tracks will be transfered to your computer 19.6 years older than reality.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://outdoors.stackexchange.com/q/21942. It is licensed under CC BY-SA 4.0.

0 comment threads

2 answers

+0
−0

Original answer below. Apparently I'm not the only one incensed by Garmin's behaviour. Garmin has a firmware update for the PN-60 series version 3.7 that was NOT present on their website last time I looked for it. Could be I used the wrong search terms. Anyway the 3.7 update works.

If this took a week longer, I would say, "squeaky wheels get greased" As it is, I suspect that this was in the works, and it's release today is coincidence.

The link to firmware version 3.7 still does not come up in Google. For others who have a Delorme PN-60 series. The instructions and link to Firmware 3.7 can be found at the link below.

https://support.garmin.com/en-US/?faq=dXCDWk3aIZ3A0Ly9z8uym5&productID=585533&searchQuery=firmware&tab=topics

Original Answer: At this point there isn't a great answer.

Convert dates manually.

Below is a simple spreadsheet used to convert GPS dates from before the rollover to current dates. If you need dates on the trip, print this up small, and tape a copy to the inside of your map case.

Rollover conversion in spreadsheet

Most of us don't actually need dates on the trip. (I did a trip last summer and didn't notice that my GPS was doing this. But it may affect archival records of tracks and so on. The same trick can be used there:

  • Import your track.
  • Convert to a spreadsheet
  • At 1024 weeks to the date in an extra column
  • Copy modified date, paste values only to original date
  • Save.

Update your mapping software.

You will need to contact your vendor. Put in a feature request to add a 'rollover' parameter to imported data. This should be a per GPS value so that you can set it so that data imported from your Delorme adds 7*1024 to dates, while your Brand New Sparkly Garmin doesn't.

Hack your GPS.

If you are a techno wizard, download the firmware from Garmin's site (they still allow Delorme downloads) and reverse engineer it. Since Delorme's worked after the first rollover, they already are adding 1024 to the week counter. Just need to find that and change it to 2048. (Just ... Right. While the change is trivial, finding where to put is not.

Put pressure on Garmin.

  • Complain to Garmin. Do so by chat, by phone call and by email. Waste enough of their time that it's cheaper to publish a fix.

  • Go in to where you bought it. Tell them you want the problem fixed.

  • Contact online vendors that used to sell DeLorme. Ask them.

  • Wallet pressure. Alas this one won't work at present. Normally if a company gives bad service, you buy a competitor's product. As far as I can tell, Garmin owns the hand held GPS market right now.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

This post was sourced from https://outdoors.stackexchange.com/a/21943. It is licensed under CC BY-SA 4.0.

0 comment threads

+0
−0

GPS track logs can be shifted in time using GPSBabel's track filter:

Example 4.8. Time-shifting a track with the track filter

The following command line will shift all tracks to be one hour later.

gpsbabel -t -i gpx -f in.gpx -x track,move=+1h -o gpx -F out.gpx

I expect it will work to add 1024 weeks to the timestamps (it may need to be written as move=+7168d if "weeks" is not an accepted unit)..

History
Why does this post require moderator attention?
You might want to add some details to your flag.

This post was sourced from https://outdoors.stackexchange.com/a/21949. It is licensed under CC BY-SA 4.0.

0 comment threads

Sign up to answer this question »