▲ 80 points
back
75 comments
Most GPS devices made at least after 1999 implement an unwrapping algorithm that has an epoch at some random date set by the maker in the firmware.
Essentially the firmware knows that the day is later than say, July 4th 2004 because that's when it was built. If the GPS date is less than that date, it adds 1024 weeks repeated until its greater than the hardcoded date.
This means that the exact wrap date will depend on the receiver, though some will wrap on April 6th
Fortunately GPS rollover doesn't normally get in the way of positioning. The only way it would is if the 'wrong' dates triggered some other bug.
Apparently it did cause positioning issues last time around. One major problem was that GPS receivers calculate which satellites they expect to see in the sky based on the current time and the almanac+ephemeris data, and at the wraparound some receivers started expecting all the satellites to be where they would've been 1024 weeks ago and completely lost lock. I think there were some problems caused by individual satellites wrapping their counts slightly before the actual GPS time too. Receivers which are started up after the 6th should be fine though.
Wrong almanac means a somewhat longer time for first fix.
Ok so just to be clear this isn’t the first time a gps time rollover has occurred. The only real difference between this time and last time is that god technology is widely deployed at the consumer level.
As for the risk to flights:
* this has happened before, and I don’t recall any plane accidents then
* I assume pilots would notice if they’re suddenly substantially off course - it’s not a gradual drifting change, it’s a big kachunk change if software isn’t handling it correctly.
* there are many other (non-gps) signals including radio that are used to track where an aircraft is.
If anything I’d be more concerned about drivers getting lost in their cars
Also, earlier this year the military was messing with the GPS too, apparently they do it pretty often: https://news.ycombinator.com/item?id=16244298
Planes can use GPS as a navigation aid, but they definitely do not rely on it as the only source of information.
god technology
Damn you autocorrect!
God tech made me smile and think of "Any sufficiently advanced technology is indistinguishable from magic." :) With a subtle pun in the clouds somewhere.
> this has happened before, and I don’t recall any plane accidents then
ADSB (the "non-gps" radio signals you mention) broadcasts the planes location... sourced from GPS. Because of deployment requirements there are tons of sub-$2000 ADSB out boxes on the market now that didn't exist in 1999, and hardware wise they are a race to the bottom. (Edit: I also just realized the software could have been written by someone who wasn't alive in 1999).
I don't think anything is going to happen. But I also don't like saying nothing is going to happen, because that is when you get a complex failure.
I think parent was talking about navigation more than surveillance, so VORs and similar. Between that and inertial navigation, there's plenty of other location sources if your GPS receiver does fail.
Though if we're feeling pessimistic, we can guess at how a failure might occur. Let's say that your GPS receiver is poorly written enough that it just starts returning wrong location data on week rollover. Let's also say that that receiver is the aircraft's main time provider. Since the inertial navigation system also needs an accurate time source, it could be hooked up to this same time source. Hopefully it wouldn't be, but we're assuming the aircraft in question here is all-around subtly defective. The INS doesnt't include handling for bogus time jumps, so its speed and location tracking is also corrupted. So, you and your unfortunate copilot could find yourselves without your two main navigation sources a few hours into a trans-pacific flight, and assumedly the GPS-coupled autopilot had pointed you well off course before you'd noticed. In this situation you'd have to get yourselves reoriented based off your compass and best guess of a location. Hopefully you have enough fuel reserves after you little diversion to find land search for an airfield.
So that would be a pretty bad situation. I wouldn't worry though, aircraft systems are generally better isolated than that.
I think the parent meant radio beacons on the ground. These give an angle or distance to a known location.
ADSB does broadcast the planes location. But this is only used in a very limited fashion. ATC use radar as the main source of information.
ADSB is how planes see each other without relying on ATC, and feeds collision avoidance systems. The FAA instructs pilots to believe these systems over ATC because it updates faster than radar.
In a very hypothetical worst case scenario, a malfunctioning ADSB transmitter could suddenly put itself right in the path of a large commercial aircraft, forcing it to make dangerous maneuvers to avoid a collision.
Lots of smaller airports use only secondary radar - adsb
Yeah, but now ports load and unload containers automatically using GPS to guide the cranes, which obviously means they're going to swing wildly about and whack planes out of the sky.
Not GPS related, but the day I am really worried about is January 19th 2038 3:14:07AM... Unix time will roll over if stored in a signed four byte integer field.
Or slightly later the use of a 2-digit year in x509 certificates. The standard assumes that dates with year <50 are 20xx, and >=50 are 19xx. It doesn't help that this is one of the best designed, most understandable, and well-thought-out parts of the x509 standard.
We’re already seeing problems from that. It will be handled, probably without the financial bonanza of 2k, but as such will probably cause more problems.
What he is pertaining to is WNRO, the 10-bit binary counter representing the GPS Week Number, a key piece of the date and time information. Every 19.7 years this week number counter reaches its limit and rolls back to zero. [0]
In the US at least I’m not aware of a single certified aircraft that relies on GPS as the primary and only means of navigation. Even brand new Airbus 320/321s and Boeing 737-700/800/900s have INS installed and is considered primary. GPS and radio based navigation add correction and cross checking to the INS derived position. GPS is necessary for RNP but RNP procedures are not yet widespread enough to cause major disruption to the national airspace system.
As we move closer and closer to primarily an RNP system a GPS outage may become more disruptive but for at least several more decades the infrastructure and equipment to navigate using INS and radio based means such as VORs will provide a proven and safe backup.
> So that this doesn't happen again any time soon, GPS devices made in the past decade use 13 bits for the week counter, yielding a total of 8,192 weeks or 157 years. Those devices will not have to restart time until 2137, by which time our descendants will have created a whole new set of technological problems.
I love the snarky final sarcasm.
For the majority of us, probably the only thing that will happen is some power outages in some areas. Charge some portable batteries and buy some bottled water (mains pumps maybe?). It won't be a problem for more than about a day.
I think you commented on the wrong article? Why would gps-derived date issues cause problems with electrical generation and distribution?
Gps timestamped electrical measurements are sent over fiber optic cables between substations on either end of transmission lines to make sure current in is the same as current out, roughly. Also for measuring and controlling power flows.
https://www.smartgrid.gov/recovery_act/program_impacts/appli...
Interesting! Thanks for the link.
He probably won't fly April 5, or April 7, either.
> Universal Time Code (UTC)
Uh, Coordinated Universal Time [0]?
I can't be the only one who, upon seeing little things like this, immediately has doubts about the accuracy of everything else in the article.
[0]: https://en.wikipedia.org/wiki/Coordinated_Universal_Time
That and the fact that GPS is not a primary navigation source for commercial aviation.
Just shows that being an expert in one domain means that ... you're an expert in one domain.
It is. For a majority of the fleet RNP1 and RNAV5 use GPS as the primary means of navigation with INS as a backup for a limited amount of time if GPS is unavailable.
INS is much more than a backup. In the days before GPS it was the primary source of navigation crossing large bodies of water. Of course this meant aircraft coasted in a few miles off of there actual course. It can generally be updated using DME-DME fixes and from VOR fixes, all of which it does automatically. I believe some short haul operators are now specing there aircraft without INS but as far as I know that's an exception rather than the rule.
Except that if you know anything about how newspapers work, the Gell-Mann theory falls apart.
It only works if every article in a newspaper is written by the same person with the same level of knowledge and ignorance of every topic published. This simply isn’t the case, as newspapers are written by dozens or hundreds of different people working for many different companies and with many different backgrounds.
For example, a new reporter who bones a story about a local car factory has absolutely no bearing on the accuracy of the work of a seasoned reporter for a wire service covering politics in the nation’s capitol a thousand miles away.
That keeps getting quoted but with no evidence that it exists on a large scale.
If I read a $NEWS_SOURCE article and they get something wildly incorrect I don't just proceed to the next article, I close the tab / newspaper.
Also GPS does NOT use UTC at all.
The GPS broadcast navigation message includes the offset between GPS system time and UTC, which is specified to be an integer number of seconds plus or minus a microsecond. The integers are the running total number of leap seconds since 1980. GPS system time doesn't perform leap seconds, but the clock offsets are calculated so that the system tracks UTC. So I am not certain what you mean.
Don't many chips now support all major constellations: GPS (US), GLONASS (Russia), Beidou (China), Galileo (Europe), etc.? I wonder how heavily they test failover...
Off topic: Does anyone know why Coordinated Universal Time is abbreviated in this order - UTC? None of the languages seems to have that order.
It's in the Wikipedia page linked here, under Etymology:
> The official abbreviation for Coordinated Universal Time is UTC. This abbreviation arose from a desire by the International Telecommunication Union and the International Astronomical Union to use the same abbreviation in all languages. English speakers originally proposed CUT (for "coordinated universal time"), while French speakers proposed TUC (for "temps universel coordonné"). The compromise that emerged was UTC, which conforms to the pattern for the abbreviations of the variants of Universal Time (UT0, UT1, UT2, UT1R, etc.).
See also the linked citation: https://www.nist.gov/pml/time-and-frequency-division/nist-ti...
The French proposed TUC (temps universel coordonné) and UTC was the "compromise" with CUT.
Can someone sensible with expertise comment on this please?
Sure, gps geek and time-nut here.
The rollover problem is a hard one to fix, because there's no reasonable way for a GPS (at least one using LNAV (legacy) signals -- pretty much all of them, though I don't know what modern passenger jets use) to know which GPS "epoch" they're in. If you don't know what epoch you're in, you don't know what the date is.
Some GPSs solve this by recording the week number of their firmware build, and if the signals they get indicate the week number is less than that, they assume they're in the next epoch and update accordingly. Still means you run out of time, but you get a full ~19 years of life first (and then fail at some random GPS week). Some use fuses to record when an epoch has passed. Some use out of band information. Some store the current epoch in flash or battery-backed RAM. Some just never address the problem.
Thing is, though -- the only effect this has, is that it makes the GPS return the wrong date. That's it. The week rollover has no effect on navigation unless there's some significant bugs in the unit, or something external to the GPS relies on the date being output and doesn't deal well with the date suddenly going back in time. That's it.
I'd be kinda shocked if airplanes were just jam-syncing the clocks of their nav computers to the output of a GPS, and then had those nav systems be dependent on that time. But then again, I work in the tech industry, and I've seen the kinda code that goes into most products, so maybe I wouldn't be that shocked.
(I also can't imagine that GPS units used in aircraft aren't directly tested for their behavior during the week rollover. It's a well known and understood problem, and even if some random GPS manufacturer drops the ball, stuff that goes into aircraft has to go through certification for a reason...)
> I'd be kinda shocked if airplanes were just jam-syncing the clocks of their nav computers to the output of a GPS, and then had those nav systems be dependent on that time
Obligatory not an aircraft software engineer, but I can say with some certainty that this is not the case. Aviation software, despite the recent issues with the 737 MAX, is generally designed and implemented to very high level of redundancy and SPOF-avoidance.
From an airbus manual, to give you some idea:
A300-600s, A310s, A320s, A330s and A340s with GPS PRIMARY
The navigation system of these aircraft consists of 2 FMS, 3 IRS, 2 GPS and radio navaid sensors. The GPS position is primarily used for FM position updates, however if GPS PRIMARY is lost, FM reverts to radio updates or to IRS ONLY navigation when outside radio navaid coverage.
FM(S) = Flight Management (System). IRS = inertial reference system (THREE of them). If GPS is lost or malfunctioning, the FMS falls back to that - which is periodically updated by reference to RNAV ground-based radio beacons. GPS could simply switch off worldwide and aircraft would be fine, just like they were pre-GPS.
There is no conceivable reason the navigation system would especially care about the time being received from its GPS units, let alone perform some critical calculation based upon it. This article is pretty uninformed fear-mongering.
The trouble with fuses is that if a receiver is tricked by a bogus or incorrectly received signal into moving into the next (sub)epoch then you can never get it to move back, unless there's a manual override, which is an option you didn't mention: not possible in some embedded applications, perhaps, but many consumer GPS devices already force the user to answer several questions whenever the device is rebooted.
Another option is trying to guess the epoch from the TAI-UTC offset, which, of course, can't be known in advance and to some extent depends on political decisions so that's more of an "interesting" option than a good or practical one.
> gps geek and time-nut here.
This is off topic, but since you describe yourself as "gps geek" I thought I ask. Is it possible to gain access to the actual operational code where GPS operators correct for General Relativity? I'm not disputing GR, I just want to find out if this is a myth or true. Thanks.
It's like Daylight Savings time or Y2K. In theory, it could wreak all kinds of havoc on buggy software. However this isn't a surprise. It's a known thing that happens every 1024 weeks. I would be astounded if GPS receivers used for aviation purposes don't test for this. On the other hand, I was astounded when I heard that F-22s stopped working after flying across the international date line.
And I was slightly less asounded when the Nexus S phones spat out broken GPS NMEA sentences on leap years
On the other hand, I was astounded when I heard that F-22s stopped working after flying across the international date line.
It's a pretty big oops, but they rebooted the computers, and the planes kept flying. That's the second place where these disaster predictions fall down. These systems are rarely designed with a single point of failure.
> On the other hand, I was astounded when I heard that F-22s stopped working after flying across the international date line.
As was I, when I learned about taking off from the Dead Sea:
GPS provides the time (hour, minute, seconds) and date (day, month, year) over the NMEA messages. It also provides a week counter. This wraps around at 1024. The last time was about year 1999.
With most of the things I have used NMEA for (time sync), I did not use the weeks counter. However if there is any software that does use it, it needs to be able to handle the rollover.
This is where you have to dig a little deeper. Your receiver outputs the date in the NMEA messages, but the satellite doesn't actually transmit year/month/day. The satellite transmits the week number and the number of seconds that have passed since the start of the week. In your case, the receiver could potentially output incorrect dates in the NMEA output when the week number wraps around.
There's an edge case in the GPS spec that only comes up every 20 years. It's well-documented and everything, but it only comes up every 20 years and software is terrible, so not every GPS unit is going to handle it well. Last time this happened, GPS wasn't nearly as widely used.
I would expect some percent of phones to flip out (try force restarting, or waiting a day and restarting). Which ones are a mystery - the GPS chip in a phone isn't even consistent for a particular model.
I wouldn't expect planes to fall out of the sky. I wouldn't be surprised by flight delays though; just because the safety critical stuff is well tested doesn't mean the rest is.
And the errors aren't going to be confined to April 6th. We're talking about software bugs here, and it's dealing with a number that counts in weeks. So while bugs should center on the 6th, anything within a week of that is pretty plausible too.
(I wrote the GPS tracking algorithm used for navigation in Google Maps. Nothing above is based on Google-specific knowledge. It's still just someone's opinion.)
Why would phones use the GPS date over the cellular-provided date?
I asked the same question above but since you actually wrote GPS code I thought I ask you too. Is it possible for me to find the actual line of code operators use to correct for General Relativity? I'm curious to know if this is a myth or if it is true. Thanks.