Slashdot Mirror
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.
Going to ask our hardware supplier about this as soon as I arrive st work.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
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.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
for the poor souls who don't want to go to the article, it's supposed to be 2^10
Oh no, it's Y2K all over again!
They couldn't just go to a 16 bit number they had to save 3 freaking bits ? and for what to have an odd length numeric ?
When you're sending data at 50 bits/second over an unreliable transport that makes retransmissions likely, every bit counts.
But in the updated CNAV block, they increased the week number to 13 bits, which will extend the next time to zero to 2037
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.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Hope you have a bunker and supplies.
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.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I wonder if instead of doing that again, they'll just decide that something less susceptible to jamming, that's easier to deploy than a satellite constellation, might be better for positioning. Say, some self-calibrating optical system using image recognition, a high-res camera sensor, and maths, that looks at the position of the stars and combines that with an onboard clock to determine latitude and longitude. An auto-sextant, if you will, far more precise than one operated with eye and hand.
Isn't that system easily jammed by smoke screens, clouds, and daylight?
You don't know the angle to the satellites. What you know is the run time difference of the signal. You have to compute the distance from that, compensate for things like the impact of gravity and after all that, you can do compute the intersection of the spheres.
Some programmers are STILL designing stuff with the assumption something won't still be there 40 years later. The DVB standard has a roll-over date in 2038 (that's a project created in 1992 no less!) and Go has UnixNano which has a rollover date in 2262 (because of course the graybeards that gave us the original 2038 bug and unsafe arrays couldn't build a decent language the third time). BTW you don't need a 64-bit number to have dates that go beyond 2038. You may need 2 or 3 32-bit numbers too It's all a matter of formatting. All these time storage bug were a result of massive lack of foresight. Also, Go uses a single 64-bit value to count nanoseconds from epoch (*sigh*). Now that's some lack of foresight that you don't see every day.
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
"almost all programming can be viewed as an exercise in caching"
car manufacturers / dealers may charge $250-$500 for update
My Garmin GPS 12 units predate Y2K substantially, you insensitive clod! And they're my only standalone GPS-without-map units. The last firmware update was in 2003. I presume they're about to be rendered useless, which is sad to me because they're reasonably sensitive, have serial output, and support DGPS.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Each satellite transmits its location (ephemeris) as well as the exact time in each 30 second message. This means that the GPS device does not need to calculate the location. Though the ephemeris updates every 2 hours, a value is considered valid for 4 hours.
The Almanac, a list of the status and rough location for each satellite, is also part of the message and takes over 12 minutes for complete transmission (25 messages). It is used to help determine which satellites to look for on acquisition amongst other things, though this is not essential with modern equipment.
This means that the date is not used to adjust the position information as that is part of the message itself. The alert is nothing to do with general GPS stopping working, but rather anything that depends upon the GPS signal to get the UTC time being at risk (an operation requiring the Almanac).
The information is from the Navigation Message section of the Wikipedia article on GPS Signals (https://en.wikipedia.org/wiki/GPS_signals#Navigation_message), which is very detailed.
Gamma Testing - Where testing is extended to the full user community (AKA Shipping the Program)