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