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.
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
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.
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.
TCAS[1] doesn't rely on GPS though, it builds a picture of the airspace around it through triangulation and radar-style ranging - I believe it only relies on altitude to be reported by the other aircraft, which is generally very accurate.
I suppose anything is possible, but I've never heard of it actually getting plane positions wrong due to sensor malfunctions. Far more likely is pilots not following, or improperly following, its warnings. It's not capable of assuming control over the plane, as far as I know...
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.
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.
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.
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.
Dropping INS is short-sighted, as GPS can be jammed.
Russia has been jamming GPS signals in northern Norway during different military exercises [1]. Russia has denied this, but the foreign ministry has started to share the proof of this with them, [2, Norwegian only]
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.
It does have a bearing on the overall editorial quality of the paper, unless as a reader you can figure out a predictable reason for editorial quality to drop for only one specific topic. It means that a poorly researched article can get out of the door without being flagged.
Individual articles of clothing, food, and other products coming out of a company are inspected by different people. But when I go to Wendy's and buy some fries, I don't know which people are inspecting and preparing my food, and know who was preparing my food wouldn't be useful unless I already knew a lot about that person. If I went to a restaurant and my fries had mold on them, it would probably be the fault of a small percentage of the workers there. But I would still be justified in distrusting the rest of my food, even if I thought the rest of the food on my plate was probably prepared by different people.
I don't know enough about the individual staff members of my local newspaper or their individual contributions to each article to make an educated distinction between them. If I see evidence that my overall newspaper is willing to publish badly researched articles, it seems very logical to me to conclude, "hey, when you see an article in a subject you're not familiar with, remember that it might be one of the duds. If you see an article by a reporter you're not already familiar with, remember that they were hired by a newspaper that occasionally hires bad reporters."
While this is true, it is often also the case that the people writing about certain areas are not necessarily experts in those areas. I have personal experience with this phenomenon as I used to write for and edit a number of IT-related magazines. In that capacity I went to a lot of press meetings, conferences and other similar gatherings where I mingled with my colleagues from other publications. It was striking to notice how little knowledge many of them actually possessed about the - often deeply technical - subjects being discussed and even more striking to see that they nevertheless wrote articles full of mumbo-jumbo which got published in their outlets which' readers can be assumed to have turned to those with the intent of being informed on those subjects.
Being able to write a fluent story is a skill in itself and not necessarily linked to deep knowledge about the subjects the story touches. News publications work off deadlines where it can be - no, strike that, is - most important to have something, anything to publish. Those who can reliably produce the required few paragraphs will rise higher than those who put accuracy above timeliness.
it is often also the case that the people writing about certain areas are not necessarily experts in those areas.
This is not a secret. It's basic journalism. Beat reporting hasn't been common since the 1970's. Almost all journalists are expected to be generalists. Today it's a car crash. Tomorrow it's a labor strike. It's the nature of the business.
Daily news isn't for in-depth research. That's what books, documentaries, and other slow media is for. The daily news is for reporting the news of the day.
> Daily news isn't for in-depth research. That's what books, documentaries, and other slow media is for. The daily news is for reporting the news of the day.
...but what about weekly and monthly news? That was the publishing frequency for most of the publications in this area. Those were the magazines those people wrote for, often not hindered by any deep knowledge about the subject matter but gifted with a quick pen - not to mention the advertising department which wanted to keep their clients happy.
> 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.
Then couple hours or days later you get an article on a different topic from the same $NEWS_SOURCE, and you read it like gospel.
What changed over past decades is the way we consume news - it's "unbundled" now; much like we consume movies per-title and not per-channel, we consume news per-story, not per-newspaper. But this didn't improve news quality.
Gell-Mann amnesia exists at scale, it's one of the most trivial things to verify - you just need to talk with people. With your family, friends, or with folks on any social media site / on-line bulletin board. You'll see countless of examples of people who suffer from this amnesia, who can't perform the most obvious generalization from observation - to conclude that, since for any topic they know anything about every news article is utter bullshit, and since their friends report the same observations for their domains, the news on the topics they're not experts on must be bullshit too.
Well, as the wikipedia article states, it is somewhat tongue-in-cheek, and yet seems intuitively correct to me. I've certainly recognised the phenomenon in my own behaviour.
Instead of as a hard fact to be evidenced and justified, I think a better way of thinking about it might be as a kind of parable - a reminder to keep an open mind and not just blindly accept everything you see in the newspaper, or anywhere else.
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.
I don't understand the downvotes of the poster above correctly highlighting that GPS does not use UTC.
GPS does not use UTC, it uses GPS time [1], which is at a constant offset to International Atomic Time, TAI [2], which was in sync back in 1958 with Universal Time [3], on which UTC is based. GPS, TAI, and UTC use SI seconds, while UT1 doesn't (a UT1 second is 1/86400 of a complete rotation of earth).
Of course they are all related, but, hey, all time scales are somewhat related and "track each other", given some (time-dependent) offset. Fact is that GPS doesn't run on UTC.
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...
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.).
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.
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.
If you want this straight from the spec, grab a copy of IS-GPS-200J (it's free, just google it), look at section 3.3.1.1, which talks about the carrier frequencies of the various signals. From that:
"The carrier frequencies for the L1 and L2 signals shall be coherently derived from a common frequency source within the SV. The nominal frequency of this source -- as it appears to an observer on the ground -- is 10.23 MHz. The SV carrier frequency and clock rates -- as they would appear to an observer located in the SV -- are offset to compensate for relativistic effects. The clock rates are offset by (delta f)/f = -4.4647E-10, equivalent to a change in the P-code chipping rate of 10.23 MHz offset by (delta)f = -4.5674E-3 Hz. This is equal to 10.2299999954326 MHz. The nominal carrier frequencies (f0) shall be 1575.42 MHz, and 1227.6 MHz for L1 and L2, respectively."
In this context, "SV" is "Space Vehicle", a.k.a. a GPS satellite.
You also have to make a relativistic adjustment in the user segment (aka "your GPS"). You can see an example of doing this correction in open-source software GPS receivers, for example https://github.com/jks-prv/Beagle_SDR_GPS/blob/de895035e93ba... . This adjustment is documented in the above spec, in section 20.3.3.3.3.1 (which you'll see is almost verbatim copied into the the code linked above)
Not op and maybe I'm misunderstanding, but the correction is part of the spec in satellite design, not something that can be kept secret[1]. The timing code that is translated into navigational data, however, is encoded and encrypted, which have some well-known keys, and that used to prevent high accuracy. My understanding is that the us government can change those to prevent GPS usage or to limit accuracy. [2]
Having worked on gps chipsets, one of the corrections that need to be applied is for relativistic effects,those calculations are happening in every GPS chipset as it needs to iterate down to a very precise position estimation of the satellites in order to produce an estimation of your position.
There is no magic involved, relativity/time-dilation is not a disputed effect.
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.
The articles I read made it sound like they continued to have nav and comm issues after rebooting, and that things could've been worse if they hadn't been able to follow their tankers home.
I'll admit that I don't know the details, but I'll point out that they would not have been so far from land without tankers. If they were closer to a base or had longer range, a complete navigational failure would be far less of a problem as there are still pilots on board who know roughly where they are and what the heading is and where to find emergency airfields. They can make decisions and come up with a plan to get out of the situation. Perhaps, I'll claim that as the third error in doom predictions. When any real problems do come up, there are intelligent people working the problem.
My local airfield is at -19ft and the landed altitude reported by Mode-S varies from -25ft ( GNSS sourced ) to -275ft ( pressure based on 1013hPa ). Hence why asking for the local air pressure QFE is essential.
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.)
The GPS unit needs to figure out the locations of all the satellites before it can use them to figure out your positions. The satellite positions are expressed as a function of time, and the times used are measured in seconds within the current GPS week[1].
This is the mechanism that I'd expect someone messed up. I'd expect location errors more than time errors, but because you can get time out of GPS then someone probably has.
The week number is (somewhat) used for navigation, but the way it is used is not affected in any way by the rollover, and there's not really a way (even taking into account bugs) that not knowing what the current GPS epoch is could affect navigation. This is purely a matter of an issue with the time that's output for human consumption, the GPS functionality itself doesn't care in the least.
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.
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.