delay between GPS PPS output and actual time standard - Page 1
Forum section: electronics / general

author: NiHaoMike
author_rank: Super Contributor
timestamp: August 29, 2025, 04:22:17 am
content: About how much time difference is there between the PPS output of a GPS receiver (for example, the popular Ublox modules) and the actual master time standard? Does the receiver compensate for the time delay between the satellites and the receiver itself or does it assume that the 60ms or so lag from actual time is rarely an issue in most applications?

author: ksjh
author_rank: Regular Contributor
timestamp: August 29, 2025, 05:52:22 am
content: The whole idea of GPS is that it measures differences in propagation delays between the signals sent from different satellites to the receiver to calculate the position of the receiver. In the calculations, it also uses some corrections for varying parts of the delays like ionospheric errors. Some delay components are not that easy to estimate and correct for, e.g., topospheric delays. But the in theory, the PPS signal is aligend exactly to the start of the second of respective time system besides these small remaining errors. In practice, the PPS signal is unusally generated from a local oscillator with limited frequency, therefore, there often remains a clock granularity error (jitter). Better (timing) GPS receivers can output messages with an estimation for this clock granularity error for each PPS pulse. So, in the end, you know how much each PPS pulse was off. GNSS chipset datasheets often specify the remaining deviation of PPS pulses, see, for example,https://www.u-blox.com/sites/default/files/documents/NEO-F10T_DataSheet_UBX-22022576.pdfwhere the PPS jitter is specified to be +/- 8 ns.

author: ksjh
author_rank: Regular Contributor
timestamp: August 29, 2025, 06:01:24 am
content: Errors in the measurement of the delay components usually result in positiong errors, and can lead to PPS pulses being somewhat off. Timing recivers usually also have a timing mode where you can fix the position of the receiver, since most timing nodes are stationary (e.g., stratum-1 NTP servers). When you know the receiver position exactly, you can optimize the calculations in the receiver for timing. Timing recievers usually offer a survey-in mode where they average over a number of position fixes and then enter fixed-position mode once the "exact" position has been calculated.All of these calculations require to know the exact position of each satellite, but this is information is also broadcast from the satellites.

author: David Hess
author_rank: Super Contributor
timestamp: August 31, 2025, 01:25:09 am
content: Quote from: ksjh on August 29, 2025, 05:52:22 amI have seen three methods:1. Most common is send a correction value with each pulse because of the granularity of the PPS output.2. Compensate for the granularity with a variable delay.3. Phase lock the processor clock to GPS time, essentially making a GPSDO. I do not know why this method is not used more.With (1) above, if you carefully monitor the error from granularity, the exact processor clock frequency can be determined and used as a temperature sensor. I had a Garmin GPS 18x where I was able to do this until a squirrel chewed the cable and ran off with it.

author: mendip_discovery
author_rank: Super Contributor
timestamp: August 31, 2025, 07:59:38 pm
content: Take a read ofhttps://www.researchgate.net/publication/320798359_Evaluating_the_Frequency_and_Time_Uncertainty_of_GPS_Disciplined_Oscillators_and_ClocksSection 7 onwards deals with accounting for delays in cables etc.Look up stuff from Michael A. Lombardi as he seems to be the man that knows a thing or two about freq and time.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: September 01, 2025, 07:07:46 am
content: Ublox typically uses threeuser configureddelays to allow customers to compensate for external factors:Antenna cable delayRF group delayUser-configurable time pulse delayGranularity is ns.Actual GPS time at thelocation of the phase centre of antennais part of the navigation solution.Compensation for the internal software processing delay is accounted for internally - you don't have to worry about that.Leo

author: jfet
author_rank: Contributor
timestamp: September 02, 2025, 03:18:27 am
content: What Leo listed is important. But usually the 1 PPS output is aligned to the internal clock of the GPS receiver, which is a on board crystal oscillator. The receiver, thru DSP, aligns its regenerated 1 PPS to sync to the GPS digital code.A timing receiver also has to be placed in the "position hold" mode. In Position-Hold mode, the receiver creates satellite observations but the navigation solution computed from those observations only adjusts the receiver timing rather than creates a new position fix. If the receiver is not in a known position hold, timing may be at the microsecond level. This is why a lot of receivers go into a survey mode when the are first initialized. After the unit has surveyed its position, its usually stored temporarily and if you don't move it, it will come up without doing a survey again.The elder Motorola Oncore VP was within +/- 52 nanoseconds of UTC ( it used a clock of 9.54 Mhz). The Motorola M12+ was within +/- 13 nanoseconds (it used a clock of 40 mhz). Ublox LEA6T was within +/-3 nanoseconds and I can't find its clock info at the moment (I think it was 48 Mhz). There are also offsets/bias introduced when you add any transistor or IC to buffer the 1PPS output, that has to be considered. I have not checked on the newer Ublox M8T, I am sure its an significant improvement over the LEA-6T.A quick reference on this is the papers from CNS Systems, look for any of the papers; Tow-Time - Low Cost, High Accuracy GPS Timing