8

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.

  • Interesting. Do you know what the history is for using 10-bit weeks rather than 32-bit seconds? – topshot Apr 9 at 20:16
  • Related: space.stackexchange.com/q/35362/30051 – Darren Apr 11 at 18:52
  • @topshot I think two things; lack of foresight, and limited bandwidth availabe in the data channel. Newer satellites also broadcase a 13-bit week number that receivers can be designed to take advantage of. – Darren Apr 12 at 10:28
6

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.

  • 2
    Good info, but parts of this answer, especially toward the end, read like a rant. Please consider removing or rephrasing this, and keep it "just the facts." – cobaltduck Apr 8 at 20:49
  • @cobaltduck I do think all of it addresses the question and is relevant. While a certain, in my opinion very justified, annoyance with the supplier of the GPS is evident from the tone, I'd definitely not call it a rant. – imsodin Apr 9 at 12:35
  • Hi Sherwood! This is a really thorough answer! I want to add that the link you gave warns against installing that software. It says "This update is provided as a courtesy by Garmin and should be considered beta firmware. Other than the directions given below no technical support will be given for any issues that may occur due to its installation. Given the beta status of this firmware, it is possible that your device may be inoperable following installation." That's important to know! – Sue Apr 14 at 20:12
4

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)..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.