Posted on 02/14/2019 10:35:24 AM PST by dayglored
Nav gadgets will be Gah, Properly Screwed if you don't or can't update firmware
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.
"GPS devices with a poorly implemented GPS Time-to-UTC conversion algorithm may provide incorrect UTC following a week number rollover," US Homeland Security explained in its write-up (PDF) of the issue this week.
"Additionally, some GPS devices that calculate the week number value from a device-specific date rather than the start of the current GPS Time Epoch may provide incorrect UTC at some other device-specific date."
As the Reg reader who tipped us off to the shortcoming noted, this could be a significant headache for data centers that use GPS timing for synchronization.
"Decent vendors should have patches. But who has been thinking about this?" our tipster told us. "This could be a low-key Y2K style bug all over again, but with companies doing less preparation."
Fortunately, devices on sale right now should be prepared for this rollover and handle it gracefully. Uncle Sam's GPS nerve-center GPS.gov says (PDF) receivers that follow the ICD-200/IS-GPS-200 specification should be able to deal with the week number overflow. This basically means newer receivers built after, say, 2010 should be fine, provided they follow the specs and notice the rollover.
To put it another way, if your gadget goes haywire in April, it's probably because of this. If it works as normal: brilliant, it's not affected. Consider yourself forewarned.
GPS.gov also notes that the new CNAV and MNAV message formats will use a 13-bit week number to solve the epoch migraine right up until the planet becomes uninhabitable via climate change or we all blow ourselves up.
For devices unprepared for the counter overflow, a firmware upgrade will be necessary to keep the things working properly. GPS.gov recommends those unsure about their readiness for the turnover, particularly enterprises, should consult the manufacturer of their equipment to make sure they have the proper updates in place. ®
the Garmin-you-bought-on-eBay planned obsolescence plan.
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.
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.
Or an Explorer that doesn’t, well, you know...
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.
“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.
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.
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.
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.
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.
So my old Garmin Nuvi will be a brick? Who cares. I haven’t used it in ages.
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.
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.
I thank you both for that.
Cut to the chase, are we all gonna die again or what?
Read the article
.
Shades of the millenium bug...
.
.
So you’re saying that a “Samsung” is not necessarily a samsung?
.
That is what I thought! Y2K was expected to be an Armageddon. It wasn’t.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.