# How do GPS satellites refresh their clocks

How do GPS satellites keep their on board clocks accurate? I assume that they need to get update from a base station. But how do you make sure that after the update all the satellites are synchronized, i.e. there isn't any phase shift.

You have your base station on earth, and assume that all the satellites you want to update are in line of sight. You send an update command. But, each satellite is a different distance from the base station. There will also be a delay from receiving the command, to updating the internal clock. Some satellites may have newer hardware, which is faster.

If you update the satellites separately, you would need to ensure that your timings of the commands that you send are very accurate. This seems like a difficult thing to get right. Is there a better method that is used in practice?

I guess what I am interested in is say you have a clock at location A. How do you synchronize it with a clock at location B, which is far away from A? You have the message flight time delay, processing delay in B etc.

• They use atomic clocks. The drift is rather due to relativism, the satellite is travelling at high speed, so there is a time shift. By the way, the base station knows exactly the position of satellite, so the distance is known. – Marko Buršič Nov 28 '16 at 9:37
• Another solution would be querying the satellite: what is your clock? Then you compute the error and send: Make a shift +/- xxxx ns. – Marko Buršič Nov 28 '16 at 9:40
• Some relevant similar questions on Space.SE, for example, this one, also some on gis.SE, for example, this one. – Roger Rowland Nov 28 '16 at 9:48
• "This seems like a difficult thing to get right." indeed it is a very difficult thing to get right, and the equipment used is not cheap, but you only have to do it at a few places. Its simply part of the cost of running such a system. – PlasmaHH Nov 28 '16 at 9:54
• @RogerRowland oh, sorry. Didn't mean to come out as rude. Just pointing out why I asked this specific question. – user110971 Nov 28 '16 at 9:59

Clock errors are not corrected, they are compensated in two steps.

## 1. Error determination

The GPS control segment uses reference receivers in well known locations to determine the actual orbital elements and the clock error of space vehicles. The reference for position is the WGS84 reference frame, for time it is the international atomic time. Even the smallest effects like continental drift and relativistic time dilatation are taken into account.

## 2. Error Compensation

The onboard clock (in fact, the SV Z-Count, see IS-GPS-200 3.3.4) is not tuned, slewed or reset to compensate for the error. Citing IS-GPS, 20.3.4.2:

Each SV operates on its own SV time

Instead, the offset between UTC and this spacecraft's clock ("GPS-Time") is broadcast in the navigation message (see IS-GPS 20.3.3.3.1.8). This does not only include the current offset, but also different forecasts ("fit intervals", 20.3.4.4). Normally, only the highly precise short term forecast is relevant, the others would be used if the control segment is inoperable and no uplink is possible.

Likewise, the position error (deviation from nominal orbit) is left uncorrected (this would deplete precious fuel), but is broadcast to receivers by uploading ephemeris data (orbital elements) to the spacecraft.

Time of flight is no issue for the uplink, as the new fit interval data has already been determined in the previous step.

The actual compensation is then done in the receiver (user segment). It applies corrections when relating the observed signal/code phase of different SV.

## Exceptional situations

Sometimes, old spacecraft behave in unexpected ways, for example their clocks begin to drift unpredictably. AGI has a website with performance data of onboard clocks. You can see, that USA-151s clock (sending PRN28) is a little bit shaky and needs frequent compensations.

If a clock goes wild or a powered maneuver makes the SV unusable for navigation the SV sends an "inoperable flag" in its navigation message and is ignored by end users' receivers.

• @user110971 The satellites clocks are not adjusted. Instead, their offset (to atomic time) is monitored, predicted and broadcast in the navigation message. Receivers compensate for the offset, not only for their own, but also for the spacecrafts offset. Sounds funny, but has the advantage, that the GPS signals phase has no jerks or outages. (deleted my previous comment which was not helpful) – Andreas Nov 28 '16 at 11:05
• @JanDvorak GPS satellites do not actually send a full timestamp. Instead, part of the timestamp is determined by the phase of the signal itself: messages always start at 30 second increments. So to correct the timing, the satellite would have to shorten or lengthen a message, which would cause receivers to lose synchronization and need to reacquire signal. – jpa Nov 28 '16 at 13:54
• @jpa +1, this is somehow true. But: tracking loop bandwidth is often choosen as 18Hz for old-style COTS devices, a compromise between receiver dynamics and loop stability. You would need a huge correction to cause loss os lock in the receiver. Clock errors typically only have DOP-equivalent of several meters, receiver motion and atmospheric scintillation are absolutely dominant. – Andreas Nov 28 '16 at 15:43
• @JanDvorak One major consideration is that a "correction" would have to be dealt with at a very low level of the stack (potentially even at the analog hardware level), where the side effects of a correction could be complicated. If instead they send an uncorrected clock plus correction data, the side effects of that correction can be dealt with at a higher level (such as software). Subtractions are very easy for modern processors! It also makes it very clear where the change came from. A receiver receiving a sudden correction may distrust their own hardware and assume it was a mistake! – Cort Ammon Nov 28 '16 at 16:40
• You also have to remember that this method was chosen a long time ago and it allowed the satellites to be much simpler, acting much like tape recorders playing back a signal. – David Schwartz Nov 28 '16 at 18:44

say you have a clock at location A. How do you synchronize it with a clock at location B, which is far away from A?

You can do what NTP does. Roughly speaking,

• send a request for current time at the moment $t_0$
• the server receives your request at $t_1$ and sends you a reply at $t_2$
• receive the reply $T$ at the moment $t_3$
• set your time to $T+\delta$:

Note that this is not what GPS does because there is no point: satellite second is shorter that Earth's second due to gravity, so it's impossible to keep clocks in sync.

• You get a point for getting the point of relativity, unlike the mess in the question's comments. – Stop Harming Monica Nov 29 '16 at 14:49
• Is delta the roundtrip time or the one way time? If one way, how does the client measure that? – Tejas Kale Nov 29 '16 at 16:28
• @TejasKale $\delta=(t_3-t_0+t_1-t_2)/2$. Basically, roundtrip time divided by two, with correction. – Dmitry Grigoryev Nov 29 '16 at 16:45

The constellation of GPS satellites is constantly monitored by several fixed ground stations positioned around the globe. These ground stations monitor all the satellites and send correction factors if any drift is detected.

The GPS control segment consists of a global network of ground facilities that track the GPS satellites, monitor their transmissions, perform analyses, and send commands and data to the constellation.

The current operational control segment includes a master control station, an alternate master control station, 11 command and control antennas, and 15 monitoring sites.