Your GPS Devices May Stop Working On April 6 If You Don't Or Can't Update Firmware (theregister.co.uk) 149
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.
Thans for the forewarning (Score:3)
Going to ask our hardware supplier about this as soon as I arrive st work.
Re: (Score:2)
Re: (Score:1)
I was there. Your name came up several times.
Re: (Score:3)
Well, sorry for that. Writing on a mobile phone while standing in a moving train is somewhat difficult.
Re: (Score:2)
We need American Sign Language-keyboard translators when a GPS-enabled device determines that our coordinates are variable in three dimensions.
210 (Score:2)
Only after reading the original article I understood the connection between 210 and 1024. Copy-paste is so wonderful.
Re:210 (Score:5, Informative)
for the poor souls who don't want to go to the article, it's supposed to be 2^10
Re: (Score:2)
Ah, thank you! I was trying to figure out what that was all about!
It sounds like the new format will still have a similar problem, but by adding 3 bits, now it will still happen, but 8x less often. So what, every 160 years instead of 20 after the protocol changes?
Feh. Don't hash dates!! What is it with these people? /seinfeld
Re: (Score:2)
The way I see it, in 160 years we won't need to write software any more. Either the computers will be writing software for us, or we won't have computers at all.
Re: (Score:1)
Things that are overly'styled' should disappear.
Me, I think the eighth bit should be stripped from chars on Slashdot. (Also control-g should sound the bell.)
Seriously? (Score:2)
The last time this happened was while the world was in a complete panic over the Y2K doomsday prophecies, and you're telling me that new GPS units made since then STILL do not have a way of handling this?!
Re: (Score:2)
that was designed by competent enough people
Ah, I see what the problem is, thank you.
Re: (Score:2)
13 Bit ? really ? (Score:1)
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 ?
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:3)
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?
Re: (Score:2)
We're sorry, but in the US most school zones, in addition to limiting speeds, provide penalties for sextanting while driving.
Re: (Score:2)
I got a ticket for that once. Then I had to register as a sextant offender. All the sailing ship captains are now shunning me.
Re: (Score:2)
You insensitive clod.
DO NOT BE FUDDIER THAN ME.
Well played. :)
Re: (Score:2)
The Sun and its planets and their satellites move around the center of the Milky Way, which is moving through the universe.
The current topology works better because it has less moving parts.
The problem lies not in our stars ...
Re: (Score:2)
Great. A system that I can disable with a hand flair.
Re: (Score:2)
13 bits of week numbers is about 137 years... Shouldn't it be good for at least a century? Presumably they moved the epoch for the new field as well.
Re: (Score:2)
No we're getting somewhere.
The Mysterious 137 [feynman.com]
If you have ever read Cargo Cult Science by Richard Feynman, you know that he believed that there were still many things that experts, or in this case, physicists, did not know. One of these ‘unknowns’ that he pointed out often to all of his colleagues was the mysterious number 137.
Re: (Score:2)
13 bits of week numbers is about 137 years... Shouldn't it be good for at least a century? Presumably they moved the epoch for the new field as well.
Yeah, that was a typo, I should have typed "2137". I noticed it after I posted, didn't think anyone else would so didn't bother posted a followup. If only there was some web technology allowed one to edit posts.
Delayed failures (Score:5, Informative)
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.
Comment removed (Score:5, Interesting)
Re: (Score:2)
Could also be a rollover of days since some time in 1923 (16 bit signed int). 1923 is a popular epoch as that was when it was decided to settle on the modern calendar and dates before then can be ambiguous. It's also possible that it's just an overflow in the calculation using that value, that wasn't tested when it gets very large.
Either way, I wouldn't rely on it working after April 6th. There doesn't appear to be a firmware fix either.
Re: (Score:2)
1923 is also when US copyright expiration was held up for two decades on account of Gershwin and Disney.
Re: (Score:2)
Just built a new panel for my Glider, bought new Borgelt B800 vario and 7” tablet and only needed to replace 80mm altimeter with 57mm Winter. With the Borgelt vario I got a Bluetooth combiner, which combine FLARM and B800 outputs and makes them available to the tablet, which has its own GPS, baro altitude and accelerometers. Given my DG200-17C has a very small panel, it shouldn’t be they hard to do other gliders. I carry a Sony Z3 android phone in the side pocket as a fully independent backup.
Mo
Bingo (Score:2)
Re: (Score:2)
Fair comment. :)
Re: (Score:2)
Deja vu? (Score:5, Funny)
Oh no, it's Y2K all over again!
Re: (Score:3)
on April 6, planes will fall out of the sky!
elevators won't know if they need to go up or down!
Re: (Score:2)
Each and every goddam entity, be it a small business providing cupcakes or enterprises manufacturing the muffin pans will be sending compliance letters to each other 1.) demanding that suppliers better not mess up and that 2.) the author of the demand will do its best to be in compliance, but no promises, and no liability for failures beyond their control.
Re: (Score:2)
The one difference was that Y2K gave us an army of COBOL programmers with not much other skills, but still fixable in programming. Whereas, in this case, I forsee the manufacturers feigning an inability to patch in order to drive sales. I think my newest Garmin is 10yrs old. I am sure they wished we replaced them as fast as cell phones.
I have thought about getting a new one, I was just waiting to see if some needed features ever got incorporated. I have never liked the touchpad interface on these.
Re: (Score:2)
Re: Deja vu? (Score:1)
Re: (Score:2)
13 bits of weeks = 157.5 years. It's safe to assume there will be entirely new navigation systems by the year 2175.
Re:They went backwards... (Score:5, Interesting)
Re: (Score:1)
Re: (Score:2)
Never worked in a shop that makes commercial hardware have you? The pencil pushers driving those guys are still clawing back every bit they can in order to use a chip that is one copper penny cheaper.
Re: (Score:2)
At this point there is no reason any system should be using anything less than a 64bit value for time moving forward.
So you're saying it should take over a second to transmit the time? GPS has 50 bps data rate (100 bps in some configurations) according to table #1 at https://gssc.esa.int/navipedia... [esa.int]. I'm pretty sure there are other circumstances such as communicating with Mars or further or a submarine deep down with low bit rates as well.
Although making one integer smaller is not going to save you anything measurable even on a system from the 70's. Its one integer.
In 1984, Apple released the ProDos disk operating system which packed day, month and year into 2 bytes to save room. I'd guess going further back that packing more then the date into an
Re: (Score:2)
Early computers were designed with the same mentality. "The year 2000 is WAY off."
Good, this is when we attack (Score:5, Funny)
Re: (Score:3, Funny)
Re: Good, this is when we attack (Score:1)
Re: (Score:2)
Is there an app for locating the bunker I built out in an abandoned oil field in Lufkin, Texas back in 1955?
Asking for a friend.
Re: (Score:2)
The 13-bit week number is in a completely different message format broadcast using different modulation. Using that signal will require completely new hardware, not just a firmware update. But they're likely to keep the current '70s-style signal around for a couple of decades yet.
Google Maps (Score:2)
I can only hope the date string is interpreted by Google Maps itself, and not handled by Android or the handset hardware.
Imagine you GPS functionality becoming useless because you're not getting an Android update since the handset manufacturer considers your phone EOL.
Re: Google Maps (Score:1)
Re: (Score:1)
The problem is you're assuming GPS uses geostationary orbits and it doesn't. When you first start up a GPS receiver, that first fix can take a while. This is because it needs to download an almanac. This almanac basically calculates where the birds are in the sky. Then based off of timing signals, combined with the satellite location information, you can figure out exactly where you are. If you think it's 1999, rather than 2019, you're location calculation will be based on where those satellites were i
Re: (Score:3)
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
The 13-bit week number is actually a bug IMHO (Score:5, Informative)
I have been a member of the NTP Hackers [ntp.org] 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
Re: (Score:1)
until it comes back to bite everyone in 2137. :-(
The satellites will not be operating by that time. Why do you think this is a bug?
In addition, lets say for some reason they boost the orbits of all the GPS satellites by that time so they don't degrade to unusability or death....if they can do that for 1000s of satellites in the 22nd centure, why wouldn't we have the technology to work around a few 130+ year old servers who spit out the bad time?????
This is seriously the craziest comment I've heard from someone who seems relatively intelligent in a LONG T
Re: (Score:3, Interesting)
This isn't about hardware (satellites), but the protocol. Whenever new satellites are launched, they should work with the existing devices and new devices have to work with the existing satellites. This means we can easily be stuck with the same protocol for many generations of hardware. Think about IPv4 vs IPv6.
The Roman empire had really dirty roads and in order to cross them without getting wet/dirty, they made pedestrian crossings, which were a row of stone blocks, which were raised. For wagons to pass
Re: (Score:2)
You sound awesome enough for an interview.
Do you want to be on a stellar engineering team?
You do realize that entire tale about railroad gauges being the same width as Roman roads is apocryphal and contradicted by the evidence, right? Around the world there have been more than 90 different narrow gauges deployed and more than 40 broad gauges. Many of them enjoyed widespread usage for decades. Hell, so-called "standard gauge" is only used by 55% of the railroads in the world today. Even the original horse drawn railways in England in the late 1700s had widely varying gauges, from under 4 feet
Re: (Score:2)
So let me get this straight (Score:2)
After the widely publicised Y2K debacle, avoiding a similar scenario wasn't considered by GPS manufacturers at about the same time?
Re: (Score:3)
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.
Re: (Score:2)
They should work fine for navigation and positioning, but the date/time displayed may be incorrect.
In that case, everything is fine. Now I only have to worry about my neo6m GPS modules, one of which I actually want to use as a time source. It's got a PPM output. But it's probably also counterfeit because I'm cheap :p
Why though? (Score:2)
Re: (Score:2)
It's part of the time, which is actually date and time.
Re: (Score:2)
My understanding is that it's to do with the way the almanac data describing the satellite orbits is transmitted. They send data for one point in time and the receiver extrapolates from there for the next 7 days. So the week number is associated with almanac data packages, and there is one package per week.
The data rate is extremely low (50 bps) so this trades some accuracy (as the predictions are never perfect and the error increases over time) for the ability to receive the data for all the satellites in
Re: (Score:2)
I'm really scared.
I used to have a straight day job, 9-5.
I'm planning to embrace the gig economy and the week will be unpredictable.
car manufacturers may charge $250-$500 for update (Score:3)
car manufacturers / dealers may charge $250-$500 for update
Comparing sizes (Score:2)
"10 bits should be enough for anyone" - US DOD
Re: (Score:1)
Re:Stupid n1gger GPASS (Score:5, Informative)
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 [wikipedia.org] should be far enough in the future.
Re:Stupid n1gger GPASS (Score:5, Interesting)
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.
Re: (Score:1)
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.
They didn't pick 32 bits they picked 31.
Re: (Score:2)
Signed int is 32 bits. They went with signed because it makes it possible to detect overflows because the number goes negative, although interestingly that's not actually guaranteed by the C spec which says it is technically undefined.
Re: (Score:2)
Signed int is 32 bits.
Relevance?
Y2038 exists because people elected to use only 31-bits to address time.
Using 32-bits to address time delays run out until 2106.
They went with signed because it makes it possible to detect overflows because the number goes negative
This line of thought was a bad idea then. Today it amounts to nothing short of willful negligence.
Re: (Score:2)
They originally used this format for file timestamps, so it was unlikely to ever have file's created or modified before 1970... It was after this point that people started wanting to use this format for all sorts of uses for which it was not suitable. Ie, I worked on a medical device that initially used this signed 32-bit time format for medical records; but that was a problem since you couldn't express some patient's date of birth, whoops.
Much of the problems come from blind reliance on third party librar
Re: (Score:2)
32 bits works even longer if you make it unsigned. For uses where you don't have to worry about things in the distant past, this is fine and trivial to implement. This is really helpful for the hordes of 16-and 32-bit embedded systems out there. Certainly 64-bits would be better for newer products, or anything between 33 and 64 bits (say you're on an 8bit cpu and would prefer 5 bytes instead of 8). You can also tweak the epoch start time to not be 1/1/1970 as well, if you know your time format will only
Re: The Issues With Unsigned Time (Score:1)
Re: (Score:2)
I made the date of birth comment... But for some products it doesn't matter. I'm working on one where time means "right now", and unsigned long works great for most of that. Some security layers are using 64-bit time. If I had designed the thing, I'd probably make sure that any external view of time was done in signed 64-bit; internally signed time would get rid of some pesky typecasts but otherwise there's no need for 64-bits there.
You sound as if you just want one format for all time uses. Except that
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Floating point for time (Score:2)
NeXTstep (and by extension OS X) uses a double float seconds since 1970 in its NSDate class. This not only avoids the Y2038 (and Y10000) problem, but gives you microsecond accuracy for dates that are inside the current era. There is also no floating-point round-off error for any whole number of seconds because they are the base unit.
The problem with using floating point for time is that the precision varies with distance from the epoch. Over the course of a century, this comes to 100 * 365 = 36500 or over 15 bits for representing (say) the number of days, which reduces the precision for fractions of a day by the same amount.
Conversely, if you want ns precision, 64 bits will only give you ~20,000 days, which is less than a century. But 128 bits will give you ~10^20 years at ns precision. Which should cover the big bang to the effective
Re: (Score:2)
precision varies with distance from the epoch
We got ~68 years from 32 bits. Start with a 64-bit float, take 8 bits for the exponent, and you have 24 bits left for the fractional accuracy. 2^10 is about 1024, that's about a microsecond near the epoch, with 4 bits left over, so you get microsecond accuracy for another 64 years x 15, or 960 years. I'm going to guess that even millisecond precision is still sufficient as a general timestamp format. This is supposed to replace a timestamp of whole seconds, after all. The fractional part would be scaled fro
Re: (Score:2)
Say I take a timestamp and add one nanosecond to it. That will increment the timestamp if I test near the start of the epoch. But eventually it will be far enough from the epoch that one nanosecond falls off the end of the mantissa and now this fails.
Re: (Score:2)
I don't think the time formats had a lack of foresight. They were used for particular uses where it made sense. What broke was when people took the original signed 32-bit file time format to use for other purposes. Ie, purposes other than the file time on a specific PDP filesystem implementation. But it slowly got standardized in many file systems, the function calls dealing with time got standardized, and the file timestamp format started being used for things other than file timestamps. The original Uni
Re: (Score:2)
And lo and behold unix time was updated to 64 bits years ago, so 2038 isn't an issue. The only unix things that will hit that wall are things that are either not dynamic (scripting language) or can't be recompiled with the 64 bit time_t size.
Some have addressed the problem long ago. For example Microsoft fixed visual studio over a dozen years previous to have time_t be 64 bit for 32-bit and 64-bit software.
Others have elected to do nothing. time_t is still 32 bit in present day 32-bit Linux systems.
Not perceived as fundamental limets (Score:2)
In the case here, assumption was that GPS firmware would know which window of 20 years would make most sense. A GPS designed to be remotely viable over a large timespan would generally have to have persistent writable storage for map data, so storing the current general 20 year window should be feasible.
Similarly, I seem to recall some man page back in the day defining the timestamp as being in terms of the 'current' epoch and explictly saying the epoch would change. Of course I don't think any agreement
Re: Stupid n1gger GPASS (Score:1)
Re: Trigonometry, anyone? (Score:2, Informative)
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.