# Synchronization to GPS Time

Posted by on Mar 28, 2013 in Blog, Simulcast, Tutorial | 0 comments

In the science side of my blog, I have frequently introduced concepts from special relativity that speak to limitations in synchronizing clocks that are separated by appreciable distances. In practice, the speed of light is about 1 foot per nanosecond. This seems rather odd then, in the context of metropolitan area paging networks that cover regions as large as San Diego to northern greater Los Angeles on a side and with distances between sites of tens to hundreds of miles. In what way can such systems be said to “simulcast” if simulcasting means “broadcasting simultaneously.” Doesn’t this challenge the very notion of simultaneity? To claim that paging, and other wireless, sites are synchronized to GPS time to within some fraction of a microsecond doesn’t seem to help; such a claim just makes one wonder about what GPS time synchronization means in and of itself. It is an answer to that question to which I turn my attention now.

## The imaginary GPS master clock

The first step in figuring out GPS time is to imagine that there is a master clock fixed to the center of the Earth. Of course, there is no real clock down there; but that’s the imaginary game that GPS is playing at. Such a clock is called “Earth-centered, Earth-fixed” or ECEF. So, the GPS time is derived from a pretend ECEF clock:

ECEF clock

Imagine that such a clock could broadcast radio signals from the center of the earth to the surface. Ignoring for a moment that the Earth is not quite spherical and that it has some bumps on the surface, we could send time pulses that would arrive at the surface at the same time. If the radius of this hypothetical spherical Earth is $R_E$, then the proper time difference between the ECEF clock and the surface would be just $\Delta \tau = R_E/ c$ where $c$ is the speed of light. Given that the real Earth is an oblate spheroid and that there are some big bumps (Colorado, where I live, for example, has a few) if one knew where one was, one could perform certain compensations to the time to adjust for these factors as necessary. Luckily, with GPS, one also gets information about one’s location on the surface of the planet, so this information comes along for free; or at least, an index into a possible database of surface elevations comes along for free. But that’s a different story; back to the time part of the puzzle.

Of course, there is no ECEF clock; but the ground segment of the GPS network fakes one out. Among other things, this ground segment of the practical GPS network includes a system of atomic clocks that are synchronized together to simulate the arrival of an imaginary ECEF clock at each of a number of satellite uplinks placed around the planet. If there were a real ECEF clock, these ground satellite stations could simply relay this signal out into space; and that’s just what they do. So, if there’s a satellite relay station high on a mountain, it sends its signal along at a later time than that from a satellite relay station right at sea level.

You could then imagine that these ground stations have obtained a signal from an ECEF clock and they are just boosting its time signal out into space for use out there. Well, there may be some value in getting time pulses out into space, but most of us use GPS here on Earth. We don’t get our GPS signals from these relay stations directly; we get them from the GPS satellites. Roughly speaking, there is a constellation of 24 of these satellites that orbit the Earth twice a day. Twelve of these would be above the northern hemisphere and the other twelve above the southern hemisphere at any instant. About 8 would be visible at any point on the ground at any time.

The radius of the Earth is roughly 6,400 kilometers. The proper time delay of an ECEF clock pulse would be around 21 milliseconds. The GPS satellites have an altitude of about 20,500 km, which implies that their radius from the imaginary ECEF clock is roughly 27,000 km. This places them on a shell with a proper time delay of roughly 90 milliseconds from the ECEF clock. When each satellite receives its signal from the ground station, it reflects that signal back towards the surface of the Earth. Each satellite is not over any given ground station; in fact, its position varies with respect to the ground stations. So, the specific ground station that any satellite is relaying depends upon its orbital path and the time of day. However, the actual position of any given satellite is very well-known; and it is possible to compensate for its actual position at any given time. So as far as the ECEF clock is concerned, you can visualize the entire constellation as a reflective shell centered on the location of the ECEF clock and reflecting its pulses back to the Earth.

The correct time delay for a time pulse from the ECEF clock would be about 21 milliseconds for locations on the surface of the Earth. The actual time delay is 90 ms + 90 ms – 21 ms = 159 ms, since the faked-out pulse from the ground stations would have to be backed off to arrive at the GPS constellation at a 90 ms delay, and the return path takes 90 ms less the 21 ms time to reflect all the way back to the Earth’s center. To complete the fake-out of the ECEF clock, the GPS network winds the clock back by this 159 ms to account for the extra proper time delay through the network. This explains some rather odd language in the jargon of GPS which explains how time is reversed effectively on the down-link from satellites to mobile receivers.

The following image shows these “pretend” paths and the ground network in some more detail.

GPS-network

There is, of course, a feedback path in the system. Any ground station will have both its local fake ECEF time and the “backed out” time obtained from the satellites overhead. There are a number of possible sources of error that may need to be corrected in a system as complex as this. These include effects like deviations of any satellite from its predicted orbit, time delay variations due to atmospheric effects, and so forth. The ground segment corrects for this sort of thing in real time using a variety of different methods that aren’t of interest to me here and now.

## Synchronizing networks

Rather, I now want to go back to the idea of synchronizing wireless simulcasting base station to GPS time. Any given base station (BS) can obtain GPS clock time locally, which implies a local copy of the ECEF clock adjusted for the actual proper time delay of the BS from the Earth’s center. So, a GPS clock running on a high mountain site would have more delay than one at sea level, which presents some interesting issues for simulcasting in a market like Los Angeles for example. Of course, simulcasting implies the coordination of the arrival of signals from various BSs at points within the served market. Hence, correcting a high mountain BS for service in its immediate vicinity is less relevant than adjusting a time offset at the site so that signals arrive at an appropriate time in the region of the market at the base of the mountain.

Practical simulcast systems are adjusted with time offsets at each BS to minimize the delay spread of signals from each visible site, and these offsets include adjustments to the local GPS time that may involve BS elevation as well as antenna elevation above the transmitter itself and any group delay through the transmission electronics.

Generally, each site in a simulcasting network will receive the data that is intended to be sent with some time advance. The data will include a time stamp as to when it is to be transmitted. Each transmitter will have a tuned time offset programmed into it, which is likely to be the consequence of prior engineering surveys and fine-tuning in the field. The data is then launched at the time indicated by the data’s time stamp together with the offset defined at the site in question.

The good old WebLink network was adjusted using a simulated annealing method to solve the non-linear optimization problem defined by minimizing the most extreme delay spread in each served market as weighted by a measure of the density of subscribers. A full description is beyond the scope of this post, but I’ll come back to a proper definition of the problem and various solution approaches in later posts.