GPS uses 10 bits to store the week. That means it runs out... oh heck – April 6, 2019

The Register ^ | Feb 12, 2019 | Shaun Nichols

[Buckeye McFrog]

the Garmin-you-bought-on-eBay planned obsolescence plan.

[jimtorr]

We keep shooting ourselves in the foot over stuff like this.

Right you are. As things stand, manufacturers seem to go for the cheapest solution possible. Intelligent software developers are usually aware of the potential problems. My computer science professor in 1973 was already teaching solutions to the Y2K problem.

[freeandfreezing]

Actually it is more like 117180000000000 miles away for a roll over from 1023 to 0. But not to worry,the garage will still be there.

[rockrr]

Or an Explorer that doesn’t, well, you know...

[Fellow Traveler]

It's been 30 years since my college job where I worked on the first generation of these things but this is what I remember. The GPS signal emitted by the satellites is actually two different types of signals. The "CA" code which is what we use in everyday GPS technology. Originally this was meant as only a guide for the receiver so it could pick up and interpret the "P" code which was military/government only. The "CA" code was designed to only be accurate for civilian use down to about 100 meters. Later some mathematicians and other bright people figured out how to use it to get down to a few feet. Pres Clinton, in one of the few things he did right signed a document allowing the "CA" code to be non degraded thus all civilians could have fairly accurate GPS positioning to within a few feet.

The military "P" code is accurate to within fractions of a millimeter. It however is encoded. The encoding algorithm works on a week by week basis. There were 37 different algorithms created thus you could have 37 different weeks. This allowed for a full constellation of 24 satellites and a handful of ground stations.

Now you may ask why does this affect the non military "CA" code receivers. It has to do with time keeping in the ephemeris file. Each satellite sends out an ephemeris block of data. The ephemeris data block details how the satellites orbit varies from the ideal orbit it should be in. All satellites are affected by things like Solar wind and cosmic radiation. Thus they are not exactly where the should be. The week is broadcast along with other data in the ephemeris file and your receiver gets that information and uses it to calculate time as well as position. Hope this helps.

[Buckeye McFrog]

As things stand, manufacturers seem to go for the cheapest solution possible.

An Indian guy who bought a fake diploma who spends all day on WhatsApp asking buddies to send lines of code to him?

[DaxtonBrown]

“But how many cars are out there with vehicular GPS units with firmware older than that??? “

I hope my 57 Bel Air isn’t affected. Up til now, it seems to take me right where I want to go.

[dayglored]

> any mfg site so you can see if your GPS works after April of this year?

I would find out the mfr based on the device's internal nameplate or other internal markings. The likelihood is high that the "brand name" on the outside is just a re-branding of a device made elsewhere.

[dayglored]

> Why does the “week” affect GPS location?

I'm not exactly sure how the GPS specs require that the time be stored, but apparently the week is part of that data structure.

[dayglored]

> This alreay happened once before in August of1999. The world didn’t end then, either.

That's entirely true. But far more GPS-enabled vehicles, devices, and other IoT thingies were manufactured -after- Aug 1999 than before that date. The effect in 1999 was far less severe or widespread than what it might be these days.

A lot will depend on whether the device firmware was done before or after the GPS spec changed to require a longer date field.

[dayglored]

> If it can’t handle dates 10,000 years into the future, it should be a non-starter.

Hell yes, although to be honest I'd probably settle for 1000 years. But clearly, 100 years is not enough -- witness the Unix Epoch at ~68 years. Some of our technology will survive over 100 years.

I hope to live long enough to see Unix 32-bit rollover (I'll be 86). May it be the last of the big rollovers.

[Bloody Sam Roberts]

So my old Garmin Nuvi will be a brick? Who cares. I haven’t used it in ages.

[mwilli20]

... packets could arrive with a time difference more than a few seconds.

That sounds like a lot... Quick back-of-napkin calculation: The maximum distance difference between you and 2 satellites is approx. 1 Earth radius, or 6000km. Radio waves travel at 300000km/s (ignoring atmosphere slow down) so the max packet delta time between 2 satellites is roughly 20ms.

[zeugma]

If I had my way noone would use less than 56-bit date fields, and preferrably 64-bits. That gives you as much precision as anyone would want, and even lets you use a bit or 2 for CRC or other purposes, yet it’s not going to expire in anyone’s lifetime. The current Unix time is a 32-bit number, so a change to 56-bits would be 16,777,216 times as long. A 64-bit number is 4,294,967,296 times as long as can be stored in 32-bits. I figure those wanting nanosecond accuracy and maximum longevity should specify a 128-bit timestamp, which would encompass the expected lifespan of the universe.

[ConservativeMind]

I thank you both for that.

[Yaelle]

Cut to the chase, are we all gonna die again or what?

[TexasGator]

Read the article

[editor-surveyor]

.
Shades of the millenium bug...
.

[editor-surveyor]

.
So you’re saying that a “Samsung” is not necessarily a samsung?
.

[Anti-Bubba182]

That is what I thought! Y2K was expected to be an Armageddon. It wasn’t.