GPS for time synchronization

GPS positioning works based on how much time the radio signal takes from the source satellite to the destination, your device. As you may know radio signals speed in the void is the speed of the light (which is also an electromagnetic wave, just at different frequencies). Speed of the light is 300’000 km/s (more or less), so in 1 ms (0.001 seconds) the radio signal travels for 300 km. GPS need accuracy in the order of meters, let’s say 10 meters, the light takes 33 ns (0.000000033 seconds) to cover 10m.

Now you just guessed why GPS need REALLY accurate clocks. Each GPS satellite has 4 atomic clocks on-boarded, the type of clock depend on the generation of the satellite: average lifetime of a GPS satellite is like 12 years, so they keep replacing them, and the newer the better clocks are installed.

The time is SO important that relativistic correction must be taken in consideration, clocks on orbit provides slightly different time than identical clock on the surface. This demonstrated again that Einstein was right, the correction correspond exactly as his theory formulated. Time slow down due to Special Relativity effect, because of the speed of the satellite by 7 microseconds each day. At the same time gravitational effect predicted by the General Relativity make it faster by like 46 microseconds / day. This imply an average of like +39 microseconds per day, which traduce approximately in 0.000039 s * 300000 km/s = 12 km of errors in a single day! (https://en.wikipedia.org/wiki/Error_analysis_for_the_Global_Positioning_System#Relativity ).


There are 32 satellites orbiting currently, a minimum of 24 working satellites are needed in order to always cover the service allover the world.
Here you have an up to date status of the constellation: https://www.navcen.uscg.gov/?Do=constellationStatus .
The orbit is not geostationary, since they need to be on a lower orbit for the weak signal to reach our receivers (GPS need to work while the antenna moves, so we cannot place a parabolic reflector to gather more signal). Not true, reason is a lot more complex, it will not be covered here.
Approximately each satellite completes two orbits in one day.

There are several signals served by the GPS satellites, I will not bother you with the details (some data are encrypted and only available by the military and blah blah blah), but the minimum required is:

  • the time of when the signal was sent
  • the ephemeris, meaning precise orbital information of the transmitting satellite
  • the almanac, approximate orbital information for every satellite

Now, since we got the timestamp and the ephemeris of the satellites we can calculate its position.

For the moment let’s assume our receiver also has an atomic clock (we will get back on this later).

Knowing the time it took for the signal to reach us (the difference between the timestamp on the signal and our precise current time) and the speed of the signal, we know the distance from the satellite and our receiver. Since we also know the position of that satellite we can deduce that our position is placed on a sphere with the center on the satellite and the radius equals the calculated distance.
Adding info from a second satellite we get a second sphere, since both satellites tell the truth, our position must be in the intersection of those two spheres. That makes a circle (in a 3D space of course).
Let’s add one more satellite and we get a new sphere intersecting that circle, this reduce the possibilities of our position on two points.
We need a 4th satellite to have our current location.
This technic is called trilateration, to not be confused with triangulation (reference: https://gisgeography.com/trilateration-triangulation-gps/ )

The things are more complex, since the positions have some accuracy errors to take in consideration:

  • clocks are good but not perfect;
  • signal travels partially in the void of the space and partially in the atmosphere, the signal speed in the atmosphere depends on several dynamic factors;
  • when transiting between the void and the atmosphere, an effect called refraction happens, this deviate the trajectory of the signal. This effect is almost null at the Zenit but become important as the angle increase;
  • satellites do not orbit around the geometric center of the planet, they orbit around its barycenter, and its mass is not homogeneously spread;
  • our planet is not a sphere, GPS receivers does approximation using an ellipsoid but still, this introduce big errors, that’s why GPS calculate position using ECEF (Earth-Centered, Earth-Fixed ) coordinate system ( https://en.wikipedia.org/wiki/ECEF ), then your receiver can translate those x, y and z coordinates in latitude/longitude/elevation using a mathematical ellipsoid model, which provides good enough information about latitude/longitude, the more relevant errors are in the elevation. Basically you will have a HAE (Height Above Ellipsoid) information which may be wrong even by 50 meters. In order to have a more accurate altitude another conversion is done, using a geoid, to make it easy it’s a table with map information on the difference between the ellipsoid and “real” MSL (Mean Sea Level). But again, not so simple:
    • there are several geoid models, with each model using different “vertical datum” as 0 meters (MSL);
    • the “sea level” is something really theoretical, it depends on earth’s gravity, which is not uniform, it’s also influenced by gravity of the sun and the moon, by the earth rotation, and more;
    • the tectonics plates keep moving, so differences between 2 Geoid systems keep changing;
    • here you have a good explanation of this concept: https://eos-gnss.com/elevation-for-beginners .

This makes the calculation quite complex, but it’s out of the scope of this post, since I have no idea about the details 🙂

“Wait we don’t have a fucking atomic clock on our receiver”.

That’s correct mate, we don’t.
If you take the trilateration concept from a pure mathematical perspective, time is just one of the variables of the system of equations, we have 4 variables (3 spatial coordinates plus the time) so we need 4 equations to solve it, that’s why we need 4 satellites: each satellite provides an equation.
Since there are some accuracy errors, the more equations we have, the more accurate our position will be calculated.
That means after a bit our device will solve the system and get accurate time information, it’s like having a free atomic clock in your pocket!

Notes:

  • GPS time differs from UTC time, since UTC time keeps being updated adding or removing “leap seconds” ( https://en.wikipedia.org/wiki/Leap_second ), GPS do not, instead it provides this information in the signal. Your device will make the correction. BTW: please do not confuse UTC with GMT, UTC is a time standard, GMT is a time zone ( https://www.timeanddate.com/time/gmt-utc-time.html );
  • If we use the receiver in a known fixed position, 1 satellite is enough. Some GPS/NTP appliances have the possibility to set this mode, basically when you setup the appliance, the system gather its position, then it will work even when only 1 satellite is received. There’s a method of post processing which can be used to calculate Precise Point Position (PPP), once you have your precise position your calculated time will be more accurate. More on this on an upcoming post, I am waiting my roof antenna 🙂
  • there are others GNSS (Global Navigation Satellite Systems), for example the Russian GLONASS and the European Galileo: https://en.wikipedia.org/wiki/Satellite_navigation

I built a cheap NTP server using a GPS receiver module and a Raspberry Pi, I spent less than $100 (google it if you want to build your own, you will find good tutorials, I suggest https://blog.webernetz.net/ntp-server-via-gps-on-a-raspberry-pi/ ). Estimated error is 208ns (0.000000208 seconds). NMEA entry is for approximate time estimation then Pulse Per Second (PPS) signal is used. The reason NMEA is needed is PPS only provide information on when the second triggers, it has no idea about minutes and such. Others entries are there just for comparison, their clocks are WAY better than mine, but with NTP over TCP/IP you cannot achieve accuracy better than some 1/10th of milliseconds. Also I guess the estimated error is a worst case scenario. For more accuracy you should use Precise Time Protocol (PTP) that is not supported by most “normal” network devices ( https://en.wikipedia.org/wiki/Precision_Time_Protocol).

root@time0:~# chronyc sources -v
210 Number of sources = 7

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#? NMEA                          0   4   377    16  +5186us[+5187us] +/-  333us
#* PPS                           0   4   377    16   +460ns[+1653ns] +/-  208ns
^- time1.ethz.ch                 1  10   377    63   -162us[ -161us] +/- 5614us
^- time2.ethz.ch                 1  10   377   239   -447us[ -446us] +/- 5752us
^- metasntp11.admin.ch           1  10   377   226   -786us[ -784us] +/- 8676us
^- metasntp12.admin.ch           1  10   377   658   -660us[ -661us] +/- 8441us
^- metasntp13.admin.ch           1  10   377   709   -887us[ -891us] +/- 8506us

Here is my chrony conf:

root@time0:~# cat /etc/chrony/chrony.conf

# gpsd clock via shm
refclock SHM 0 offset 0.137 delay 0.000 refid NMEA noselect

# pps-gpio /dev/pps0
refclock PPS /dev/pps0 lock NMEA refid PPS

server time1.ethz.ch iburst minpoll 8
server time2.ethz.ch iburst minpoll 8
server metasntp11.admin.ch iburst minpoll 7
server metasntp12.admin.ch iburst minpoll 7
server metasntp13.admin.ch iburst minpoll 7

0.137 seconds delay is my estimated offset of the NMEA signal over the serial port, it’s not really needed since we have PPS.

I use chrony daemon instead of ntpd since it’s more accurate when you have bad hardware clocks, or when you are using a virtual machine.

3 thoughts on “GPS for time synchronization

  1. Reply
    Anonymous - 2022-04-04

    xxx

  2. Reply
    hot shot bald cop - 2022-05-17

    Wonderful views on that!

  3. Reply
    Charmain - 2022-05-22

    I was just telling my friend about that.

Leave a Reply to hot shot bald cop Cancel reply

Your email address will not be published. Required fields are marked *

Scroll to top
Click to access the login or register cheese