NTP Server Gets Time From Space

Cheap GPS units are readily available nowadays, which is great if you have something that needs to be very precisely located. Finding the position of things is one of many uses for GPS, though. There are plenty of ways to take advantage of some of the ancillary tools that the GPS uses to determine location. In this case it’s using the precise timekeeping abilities of the satellites to build a microsecond-accurate network time protocol (NTP) server.

GPS works by triangulating position between a receiver and a number of satellites, but since the satellites are constantly moving an incredibly precise timing signal is needed in order to accurately determine location from all of these variables. This build simply teases out that time information from the satellite network and ignores the location data. There are only two parts to this build, a cheap GPS receiver and a Raspberry Pi, but [Austin] goes into great detail about how to set up the software side as well including installing PPS, GPSd, and then setting up the actual NTP server on the Pi.

While this is an excellent way to self-host your own NTP server if you don’t have Internet access (or just want to do it yourself), [Austin] does note that this is probably overkill on timekeeping as far as accuracy goes. On the other hand, the Raspberry Pi has no built-in real time clock of its own, so this might actually be a cost-competitive way of timekeeping even when compared to something more traditional like a DS3231 RTC module.

30 thoughts on “NTP Server Gets Time From Space

    1. Almost certain that the geometry is the pair of points where three spheres intersect. Those points in space are far apart, so it should be easy to tell which one is valid.

    2. technically, it measures the signal doppler shift between a number of satellites, the rest is a bunch of math, a table with the orbit parameters and epoch and very accurate time keeping.

      1. GPS does not measure Doppler shift per se. It measures time of flight from the (known) positions of at least three satellites. A fourth satellite is required to completely solve for (x, y, z, time). More satellites can reduce uncertainty, and only three satellites are required if one of the unknowns is assumed (typically altitude – you make the assumption that the receiver is at the model ground level).

        The orbital parameters of the satellites are given by the ephemeris that is regularly updated from ground stations and continuously broadcast by all satellites. The satellite positions are calculated by the receiver using the current time. So it goes like: capture signal from multiple satellites, find current time, receive ephemeris (or use a recent cached version), compute positions of satellites, measure the exact time the signal is received from each, compute time of flight from each, then compute your location.

        1. My receivers do measure Doppler shift. I suspect most do because it’s helpful for satellite acquisition, but not so much for position determination. One could use the Doppler for positioning, as was done with the Transit system and still is with DORIS, but I can’t see any reason to do so with GPS. Timing-code positioning is faster and more accurate than Doppler.

          The receiver’s clock’s time bias is solved for as a fourth unknown in the multilateration process. In other words, the mathematical description of the problem allows formulating the unknown time bias as if it were a spatial unknown, which is possible due to the constant speed of light in a vacuum.

          1. Some use carrier phase tracking it in combination with a stationary base station to get very true measurements. I believe some use carrier phase tracking for sensor fusion to get more stable measurements as well, but I’m not sure about this.

            It is truly an impressive system. A source of error are tropospheric delays where local humidity conditions affect propagation delay from each satellite. Fun fact is that GLONASS is more affected by propagation delay error since each satellite use a different frequency whereas all GPS satellites use the same frequency

  1. GPS uses trilateration (based on distance) rather than triangulation (based on angles). Or multilateration, ideally.

    I realise that “triangulation” is being used loosely here, and I normally wouldn’t quibble, but given that the article is specifically about the use of the time signal, which is the basis for trilateration, it seems pertinent to mention the correct term.

  2. GPS works by triangulating position between a receiver and a number of satellites

    Technically it is not triangulation (measuring angles) but multilateration (measuring (pseudo)ranges).

  3. Fantastic project! I love these GPS receiver modules. I use one in my homebrew Amateur Radio HF transceiver project [ http://www.remmepark.com/circuit6040/ZX-SSB-II/zx_ssb_ii.html ] to provide local/UTC time to the front panel display as well as to gate the integrated 50MHz frequency counter used to calibrate the Si5351 VFO/BFO (controlled by an Arduino MEGA256). It’s absolutely mind-blowing what you can buy these days with so little money. It’s the kind of stuff I could only dream about in 1969 when I first started building electronic projects. What a wonderful time to still be alive! Thank You!

  4. I doubt this is microsecond “accurate”, probably only microsecond “precise”.

    The reason why “real” GPS based NTP servers are expensive, is because you need to account for the processing time to be “accurate”.

    The time information available in the GPS signal is valid at the moment it was sent from the satellite.
    Reception delay varies based on the distance (i.e.: the position of the satellite relative to the receiver). There is also time needed for decoding the GPS signal (in the GPS chipset), there is time needed to receive it from the hardware (Serial over USB in this case), time needed to do something with the data in software, time needed to feed the data it into NTP, etc…

    For time critical applications, you need a GPS chipset that accounts for satelite distance (time of flight) of the time data. These chipsets also output a high frequency PPS signal to keep everything in sync between the absolute time mesages that are outputed serially. The chipset used in this project (GT-U7) is only capable of 1 PPS, which is way to low for high accuracy timekeeping and there is no data regarding the actual internal delays. This last part alone makes it already unsuitable for use while simultaneously making accuracy claims.

    If you want to forward time information into another component, you also need to minimize delay in your data processing, or to ensure a constant delay and account for this delay.

    That’s were the specialized and expensive hardware comes into the picture, or, in case of software, you need to use a realtime O.S. to ensure time delays caused by software processing are constant.)

    To me, it is highly unlikeable this “accuracy”, not “precision”, can be reached with a simple Raspberry Pi and a $12 GPS receiver connected over USB…

    1. I beg to differ, most GNSS receiver with PPS output have jitter in the 10ns range of and are accurate within 100ns, in timekeeping server the way its done is to trim a local high accuracy oscillator (like OCXO or maser clock) from the GNSS PPS very slowly, in order to achieve low drift master clock when reception is lost.
      Obviously you will want something else than NTP if such accuracy is needed if over ethernet like PTP1588 or IRGB and 10Mhz if over other medium.

      1. J_B is talking about the difference between precision and accuracy. A cheap GPS+RPi system can be very *precise*, but might not be *accurate*. They’re two slightly different concepts.
        Precision, in this case, is how well the system can measure time, eg, after 24 hours a precise clock has measured exactly 24 hrs, 00 minutes, 00 seconds, 00 milliseconds etc. An imprecise clock might read 23:59:59.9998 one day and 00:00:01.0123 the next.
        Accuracy is how close the time reported by the system is to the ‘correct’ time. So in this example if the system reports that is is 13:52:34.00234 that time might not be exactly the same time as reported on the GPS satellite due to the delay between the GPS sat transmitting the time, and the system receiving and processing that time signal.

        Of course, then there’s the whole separate question about what is the ‘correct’ time? Because at this level of precision, the Earth does not take *exactly* 24:00:00.00000 to rotate each day, so maybe you have to start adding or removing ‘leap seconds’ to keep your clock in step with the Earth’s rotation, or maybe you want to just keep time, in which case the Earth’s rotation will slowly drift out of step with your clock.

      2. Inside of the chipset there is indeed a very high accuracy of timing information available. The problem is getting it out.

        In order to know the absolute time, you need to read the serial output. This runs generally at 9600 bps or even slower.
        Assume it runs at 10.000 bps to make the calculation below easier.
        Also assume (and this is already incorrect), the time information given in the output is valid at the exact moment the bitstream starts. (At the first bit of the message.)
        At 10.000bps, the time between bits is 0.1ms, so the accuracy you can output time information to “sync” with is at 0.1ms intervals, which is 100x less accurate than 1 µs.
        In practice you don’t even know exactly when the absolute timeinformation was correct, except when you use a GPS chipset that can give you some guarantees.

        For keeping time in sync, you generally use the PPS output, which is indeed capable to achieving a very high accuracy, but only if you can keep the rising/falling signal edges steep/straight. This normaly means you need to use COAX cabling. (50 Ohm is a standard for PPS.)
        However, you also need some hardware to interface with this and, together with the length of cable, it will introduce delays. If done correctly, you can ensure this delay is always constant and not changing with temperature, etc…
        Once you know this signal delay, you can (need to) insert it in the NTP configuration file in order to account for it.

        I can assure you you will not get constant delays with a serial over USB interface.
        If you don’t believe me, try to use an old serial programmer to program a microcontroller and connect it with a USB to serial interface. It will not work, or unreliable at best, because the delays are not constant. (I’m not talking about a USB programmer with a built in CPU as buffer “fix” the jitter.)

    2. Without too much thinking:

      If a GPS module can calculate it’s position accurate to within let’s say 10 meters, then it also has to be able to resolve time to a resolution and accuracy for the distance light speed in those 10 meters. (Or better, the RF signal, (and it’s speed changes with atmospheric conditions) I have an ((in?) correct?) memory, of changing atmospheric conditons could resul in an location error of more then 100 meters if it were not corrected for.

      All GPS modules have to figure out the time at their current location to be able to use the time difference between between the “satellite time” and their “local time” to calculate the distance to the satellite.

      I think the hardest part is to verify whether all those decimals of resolution rolling out of your GPS module are actually correct. You need another reference to do that.

      High prices for such equipment are usually because of low volume production of specialized equipment, and high reliability demanded by customers. Prices can easily quadruple just because it’s not a mass produced consumer item.

    3. For high time stability, You probably dont even want an OS at all, RTOS or not running on the platform. Probably best to run your code on the bare metal such as with a micro controller. I have an ESP32 + GPS receiver NTP server here at home. Built off some pre existing code out there on the net. Built it years ago, so can’t exactly remember where the code was sourced from, some googling will probably turn it up. I don’t fool myself into thinking it’s as accurate as one of those very expensive commercial products, but it’s accurate enough for my purposes, updating time on my PCs and some self built clocks that update their time from NTP around the house. It’s just cool to be pulling time off GPS sats for all the clocks around the house. Those commercial GPS NTP servers don’t have a whole ton more hardware in them than what would be in something self built. Most of the extra expense probably goes into the R&D to have figured out all the delays and either work out as much of the delays as possible from the code and to build in code to adjust for those delays where they can’t be worked out. And then the extensive testing and certification that it is actually accurate

  5. NTP provides time accurate enough for most purposes. I use the chrony package to keep my RPi in line but it has some slight errors. These show up occasionally in the data I collect on time as transmitted by local TV stations. A couple actually do a good enough job that I can see errors in my local time. http://davesrocketworks.com/electronics/atsc/tdata/9.png (Slight blips due to the heat coming on in the morning.)

    If enough of the stations ever bother to do a good job I will switch to using GPS time but until then, the effort isn’t worth it.

    1. Regular chrony should be able to keep you synchronized to internet NTP time to within +/- 10 milliseconds very easily. You’re at +/- 500 milliseconds with that 1 second sync jump. Not clear that chrony is working correctly for you. What servers are you using?

  6. > For best stability, the CPU should be running at a constant frequency (i.e. disabled power saving and performance boosting).

    Modern processors dynamically increase the frequency of the clock used by the CPU’s under high load and lower it under low loads.
    In an ideal world one CPU core should be dedicated for NTP and NTP only (ref: “taskset”) and “dynamic clocking” should be disabled by locking the CPU to run at one frequency and one frequency only. (ref: https://elinux.org/RPiconfig#Overclocking ). To reduce heat (and extend the usable lifetime of the hardware) under clocking may be more desirable then over clocking. If the heat generated is low enough then the device and be thermally isolated, which will help with clock stability (ref: https://en.wikipedia.org/wiki/R-value_(insulation)#Typical_R-values ).

    1. Truth > one core, reduce heat
      That’s why a dedicated Pi as a time server. That’s its only job.

      As bseige says, insulation helps buffer temperature (and resulting time swings). Else something as simple as walking past it can swirl enough air to change temperature enough to affect the timing. I found that to be true for both the Pi and my non-hat GPS module, so both are separately insulated. The GPS module was also more consistent once it & insulation were put inside of a Faraday cage (Al beer bottle), using its external antenna.

      There’s a program one can run on the Pi as an intentional load so it generates more heat, for a more consistent temperature, hence a more consistent response, and fine tuning heat for fine tuning. Like more serious time sources, adding thermal mass inside of the thermal insulation is said to provide even more stability, but I haven’t gone there yet.

  7. A trap to watch out for when using GPS time is that GPS time is continuous without any leap seconds, this means that it is diverging from UTC over time.

    In many applications this is of course desired, but if you aren’t aware of it you can run in to some unexpected issues.

Leave a Reply to PaulCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.