Your GPS Devices May Stop Working On April 6 If You Don't Or Can't Update Firmware (theregister.co.uk)

Zorro shares a report from The Register: Older satnavs and such devices won't be able to use America's Global Positioning System properly after April 6 unless they've been suitably updated or designed to handle a looming epoch rollover. GPS signals from satellites include a timestamp, needed in part to calculate one's location, that stores the week number using ten binary bits. That means the week number can have 210 or 1,024 integer values, counting from zero to 1,023 in this case. Every 1,024 weeks, or roughly every 20 years, the counter rolls over from 1,023 to zero. The first Saturday in April will mark the end of the 1,024th week, after which the counter will spill over from 1,023 to zero. The last time the week number overflowed like this was in 1999, nearly two decades on from the first epoch in January 1980. You can see where this is going. If devices in use today are not designed or patched to handle this latest rollover, they will revert to an earlier year after that 1,024th week in April, causing attempts to calculate position to potentially fail. System and navigation data could even be corrupted, we're warned. U.S. Homeland Security explained the issue in a write-up this week. GPS.gov also notes that the new CNAV and MNAV message formats will use a 13-bit week number, so this issue shouldn't happen again anytime soon. The site recommend users consult the manufacturer of their equipment to make sure they have the proper updates in place.

Comments

Delayed failures

[cpt kangarooski]

Another thing to watch out for are delayed failures caused by date windowing. Basically, some developers of devices using GPS-derived time were aware of the problem, and put in a pivot so that dates from before the device was made are treated as being in the future. (e.g. a device built in 2009, ten years after the last time this happened with GPS might treat dates from the 1999-2008 time period as being in 2019-2028, since that's when the device would first encounter them)

So this may be causing random failures of devices for years.

Re:Delayed failures

[muecksteiner]

Right, thanks a lot for this piece of information, which probably solves an issue that has been puzzling to me for years.

In my free time, I fly gliders. These things are very simple craft, but usually still have some sort of on-board computer which is used for basic navigation tasks (such as "given our glide capabilities, can we still reach airfield X from where we are right now?"). And as part of that, these on-board computers of course have to use GPS. As they are permanently installed in the cockpit, these devices tend to be quite rugged, and usually are kept around for many, many years: replacements are costly, and changing something in the panel of an aircraft, no matter how small, is a major PITA (what with the necessary regulatory paperwork, and all that). So a lot of gliders fly around with positively antique - but functional - electronics on their dashboards.

In my particular glider, which is not exactly a new plane, this function is provided by a slightly ancient device from the early 90ies: a Filser DX50, which has been in the plane since it was built. And few years ago, this thing developed the classical sort of "GPS dementia" which is typical for devices that can't handle a roll-over. For my purposes (purely recreational flying), this is not a big issue: I don't care that the thing thinks it's 1995 all over again, as long as the position is correct. Which it, interestingly, still is.

The only thing about the failure which was (and still is) a bit of a head-scratcher was that it occurred far away from any actual GPS decade roll-over: as far as I remember, it croaked during the change-over from 2014 to 2015. But your explanation might be the answer: when they created the device, they probably assumed "no one will use this device beyond 20 or 22 years after manufacture", and only patched the loop-around for that long.

Re:210

[Racemaniac]

for the poor souls who don't want to go to the article, it's supposed to be 2^10

Deja vu?

[Superdarion]

Oh no, it's Y2K all over again!

Re:Stupid n1gger GPASS

[Rosco P. Coltrane]

Before posting judgmental crap like that, you should know your history: the Global Positioning System project was launched in 1973, and the first satellite went up in 1978. The design was done sometime in-between.

Well guess what: in the mid-seventies, EVERYBODY was coding stuff without thinking it'd still be there 40 years later, saving bits and CPU cycles everywhere they could thinking X or Y weeks / years / kilobytes / megahertz should be enough. Even the long-term thinking Unix people thought 2038 should be far enough in the future.

Good, this is when we attack

[Gabest]

Hope you have a bunker and supplies.

Re:They went backwards...

[Sique]

That's what the developers in 1978 also assumed. There is an old saying in engineering: Nothing stays around as long as an interim solution.

Re:Stupid n1gger GPASS

[AmiMoJo]

With Unix they didn't really pick 32 bits as being "good enough", it was just the largest they could easily handle at the time.

With GPS they probably just assumed that the military would update or replace receivers when necessary. Civilian use wasn't a major concern, and due to the cost of the equipment they probably didn't consider the use-case where every cheap $10 smart device from China has a GPS receiver in it.

The 13-bit week number is actually a bug IMHO

[Terje Mathisen]

I have been a member of the NTP Hackers team for 25+ years: As many of you probably know most reference clocks on the Internet are based on GPS timing receivers. The last time we had a week rollover a small percentage of Stratum 1 servers went temporarily offline, or they were marked as "falsetickers" due to announcing a date which was nearly 20 years wrong. Most servers were either unaffected or got back online shortly after.

The key here is that 1024 weeks is a short enough time span that most competent developers will realize that their (embedded or otherwise) product might still be in operation during the next rollover so they have to handle this, while a 13-bit week counter is so long (8192 weeks or 157.5 years) that it is likely that many will simply forget about the issue until it comes back to bite everyone in 2137. :-(

BTW, there are _many_ ways to handle rollovers like this, the easiest is probably to compile in the build date in your firmware and then simply make sure that the date calculated from the week number is greater than this, adding blocks of 1024 (or 8192) weeks if needed. Another option, if you have any kind of non-volatile memory, is to write the current date to permanent storage regularly, like once a month or once a year.

Terje