GPS 1PPS timing using inexpensive Keysight scope - Page 1
Forum section: electronics / testgear

author: bb1
author_rank: Regular Contributor
timestamp: November 27, 2020, 02:27:35 pm
content: One Pulse Per Second (1PPS) timing accuracy often is limited by few tens of nanoseconds. Forexample, MediaTek MT3329 specifies it as +/-50ns (RMS).RMS is a good measure of uncertainty for gaussian distribution, otherwise it may hide big rarespikes. It is interesting to find out how actual spacing between rising edges of 1PPS pulseschanges in time.

author: jjoonathan
author_rank: Frequent Contributor
timestamp: November 27, 2020, 03:26:20 pm
content: My impression was that +/-50ns doesn't come from instability in the local clock or its phase lock, but rather as an approximation that covers typical GPS path length variation (e.g. one of the satellite signals bounces off a tree before reaching your receiver, the receiver assumes it doesn't, and the result is a 10ft spatial inaccurancy). Does anyone with deeper knowledge know if that's true?In any case, it seems to me that there are a couple potential difficulties with your methodology as it stands:1. If the +/-50ns does indeed come from path length effects, you'll never see it by measuring a single 1PPS receiver. You won't even see it if you measure two side-by-side receivers against each other. In order to see a 10s of ns offset, you'd have to make sure that their antennae were spaced to achieve appropriate macrodiversity and then you'd need to trim out any variation in length from the 1PPS->scope connections.2. Oscilloscopes aren't known for the stability of their timebases. If you measure a high-stability device using a low-stability device, the low-stability device actually measures itself, and I fear that's what we see here.

author: bb1
author_rank: Regular Contributor
timestamp: November 27, 2020, 04:22:22 pm
content: 1) All spikes have the same amplitude of about 60 ns.This is confirmed by another plot, taken years after initial plot, which is attached here.Obviously, this identical spikes are caused by something like (1/60ns) which is about 17 MHz clock of the GPS chip which is not in sync with true GPS time.2) Both previous and current plot clearly show slow drift of the scope sampling clock, which is derived from some crystal. Crystals do have slow drift, but their short term stability is excellent. I clearly stated that absolute accuracy of the scope clock is not very high, a few ppm. But I did not use absolute accuracy, only relative one, to observe jumps in positions of the 1PPs pulses.

author: David Hess
author_rank: Super Contributor
timestamp: November 27, 2020, 04:47:45 pm
content: Quote from: jjoonathan on November 27, 2020, 03:26:20 pmThe GPS solution accuracy produces a variation but the specification they give includes jitter caused by the quantization of the pulse per second output by the local receiver clock when it is commonly not phase locked to the GPS signal. Some (very rare) timing receivers do phase lock their local clock and do not have this error.I ran tests a couple years ago on a Garmin GPS18X and the jitter from the local clock made for a pretty good remote temperature gauge.QuoteDSO timebase accuracy is at least two orders of magnitude better than needed to measure the pulse per second output jitter produced by the receiver clock. (1) Analog oscilloscopes which support digitally delayed sweep can also measure this. A frequency counter which supports 1 nanosecond time interval measurement can also observe this.(1) At least if the DSO supports true delayed sweep or segmented memory. Otherwise it requires a huge record length, like 100s of millions of points to get enough resolution to see the jitter.

author: jjoonathan
author_rank: Frequent Contributor
timestamp: November 27, 2020, 04:57:39 pm
content: Yikes, I really overestimated the cheap receivers. Unfortunate. Good to know, though.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: November 27, 2020, 05:43:09 pm
content: Just because the scope reports picoseconds, doesn't mean those figures are actually meaningful, and will be limited by the scope's internal timebase and measurement uncertainties

author: bb1
author_rank: Regular Contributor
timestamp: November 27, 2020, 06:01:46 pm
content: Of course, picoseconds, claimed by Keysight, are very suspicious. But the plots, with exception of 60 ns spikes, are smooth, with the visible noise of few nanoseconds.If there would be arbitrary random noise due to actual lack of accuracy, it would be visible on the plots. No clear trend of the plots would be visible.

author: bb1
author_rank: Regular Contributor
timestamp: November 27, 2020, 07:53:27 pm
content: While Keysight segment mode allows to see slow drift of the scope sampling frequency, other scopes with reasonable clock stability permit to see that there are 2 durations of the GPS 1PPS pulses, with about 60 ns difference between these durations. Attached Rigol screenshot taken in infinite persistence mode shows 1PPS rising edges concentrated in 2 groups, with 60 ns time difference between the group positions. Here rising edges are captured at about 1 second after the trigger. Uncertainty in rising edge positions inside each of the two groups can be attributed to not perfect sampling clock of the scope. Delay of 999.987722 ms, visible on the screenshot, is different from 1 second due to 12 ppm Rigol sampling clock error.While Rigol also has segment mode, the accuracy of the trigger times, reported by Rigol, unlike Keysight accuracy, is very poor, about 0.1ms, and is not suitable for measuring GPS pulses.

author: David Hess
author_rank: Super Contributor
timestamp: November 27, 2020, 09:18:45 pm
content: Quote from: mikeselectricstuff on November 27, 2020, 05:43:09 pmThe oscilloscope needs to distinguish 10s of nanoseconds over a time interval of 1 second, which is trivial unless your DSO lacks all of delayed sweep, segmented memory, or a record length of 100s of millions of points. The pulse per second signal typically has a clock jitter in increments of 20 to 60 nanoseconds indicating clocks from 50 to 16 MHz.Quote from: bb1 on November 27, 2020, 07:53:27 pmSo the clock generating the pulses is 16MHz.QuoteWow, that is good to know. Up until now I assumed all DSOs which supported segmented memory accurately reported the trigger times.Quote from: bb1 on November 27, 2020, 07:53:27 pmI would be really wary of that. The logic which generates the pulse per second output might have that much clock jitter, and I would consider any DSO which displays that much sampling jitter, 10 nanoseconds over 1 second, to be defective or broken. With only 100 MHz of bandwidth and a 5 nanoseconds per division display, the sampling jitter should just barely increases the width of the trace.The DSO performance could be tested with any common 10 MHz crystal clock source or oscillator.

author: bb1
author_rank: Regular Contributor
timestamp: November 28, 2020, 12:02:01 am
content: 1) In my second message I said that" identical spikes are caused by something like (1/60ns) which is about 17 MHz clock of the GPS chip which is not in sync with true GPS time."2) The Rigol scope is a little bit better than you assumed. It has about 300MHz bandwidth and 1ns/div.Still, on my Keysight inter-pulse timing plots the drift is slow and monotonic (with couple of ns noise) (excluding 60 ns spikes).I observed delayed 1PPs Rising edges on Rigol screen for minutes using infinite persistence. Unfortunately, drift of their positions was not so monotonic.I have 2 Rigol devices: the scope and the waveform generator. While very pleasant to work with, they have bugs of all kinds.Instead of fixing the bugs, they just make new models, with new bugs.

author: nctnico
author_rank: Super Contributor
timestamp: November 28, 2020, 12:31:37 am
content: Quote from: mikeselectricstuff on November 27, 2020, 05:43:09 pmNot only that. GPS receivers also have their flaws. You can get data (I think it is called EOP data but correct me if I'm wrong) from which you can determine the actual time for a GPS receiver based on the positions of the satellites. This data is compiled afterwards so if you have GPS based timestamped information you can apply the EOP data to it to get a more accurate timestamp.

author: bb1
author_rank: Regular Contributor
timestamp: November 30, 2020, 06:55:18 pm
content: Accuracy of my Keysight scope data does not permit to distinguish between 16 and 17 MHz. Documentation for my GPS module does not specify clock frequency. However, datasheet of some other module with the same chipset talks about 16.368 MHz TCXO.