[time-nuts] Some results of PRS10 and Trimble Resolution
stephan at rrsg.ee.uct.ac.za
Wed Jun 28 12:22:58 EDT 2006
A few questions regarding Delay line vs. Software correction:
Before asking the question let me check if I understood you correctly.
Noting that you have a resolution of 6.66ns, I presume you are running at a
150MHz clock speed. In other words you delay the 1PPS by some integer number
of clock cycles (e.g. n times 6.66ns). This is done by rounding the sawtooth
error provided by the GPS (typically something between -128ns and +128ns for
the M12+T) to the nearest 6.66ns. Now the random sawtooth jitter of the 1PPS
signal and the slight drift on your 150MHz clock adds out of phase (most of
the time), or put otherwise - it is sometimes less, and sometimes more -
which averages to a nice final resolution of 3.33ns.
Now, the question:
I'm primarily interested in relative time stability between two or more
identical GPSDO devices. If I use a delay line it will add an absolute
offset (+- a few ns) plus some jitter (the Maxim/Dallas datasheets doesn't
specify the added jitter) to each GPSDO. The absolute offset doesn't really
worry me since I'm only interested in relative stability (Maybe I'm to
calibrate the "+- few ns" out first using the method you suggested e.g.
cable delay function). It is the jitter that worries me. If I try correct
for a 2ns sawtooth error with the delay adding jitter of that same order it
really defies the purpose.
On the other hand, if I delay it in software (which I had in mind in the
first place) I have to go for a high frequency clock oscillator. Nothing
wrong with that, I guess you could go as high as your processor can handle.
However, the EMI generated (radiated EM, ground bounce, power supply noise
etc.) by such a high speed clock worries me. For digital stuff it is not as
bad I guess, but the DACs, VRefs and FS will suffer due to this.
My gut tells me that if the EMI is going to be a problem I would rather go
for the delay line option with a much lower clock speed say 64MHz (capture
resolution of 15.625ns). However, no I'm back where I started since now I
make a new sawtooth error of 15.625ns!
So, the only option is to go for a higher clock speed. What are your
experiences with the resulting EMI? Is it a problem? How do you combat it?
Date: Tue, 27 Jun 2006 21:38:02 EDT
From: SAIDJACK at aol.com
Subject: Re: [time-nuts] Some results of PRS10 and Trimble Resolution
To: tvb at leapsecond.com, time-nuts at febo.com
Message-ID: <521.1f4ff74.31d3377a at aol.com>
Content-Type: text/plain; charset="US-ASCII"
We approached the sawtooth correction on the software side: we sample the
1PPS with 6.66ns resolution in our new Fury GPSDO and apply software
sawtooth correction (post-capture), and this yields an easily visible, very
significant reduction in the 1PPS capture noise with the Motorola M12+
receivers. You can really see the difference second-to-second when the
turned on/off. This yields an average sampling quantization noise of
The physical sawtooth on the 1PPS signal is actually helpfull in this setup
as you mention since it dithers the LSB quantization noise, and thus
improves the quantization resolution over time (with simple averaging low
pass filtering of the captured data). This trick is called dithering in
Using delay lines may be tricky and expensive, they usually are temperature
sensitive, and only yield good results if the capture of the 1PPS is done
fast enough (<10ns capture resolution). But if your capture is fast enough
anyways, there is no need to use a delay line since the correction can be
Delay lines also have another disadvantage: the 1PPS correction from the
can be positive or negative in time, so in theory you would need a negative
time delay (Einstein would be happy :). So for the delay line to work
correctly, you have to set the 0ns delay tap equivalent to the most negative
all other pulses will incur more than 0ns delay. You are now effectively
delaying the average 1PPS by 1/2 the spread of the pulses. Thus the output
delay line is always late (by about 30ns for commercial receivers) on
average for standard GPS receivers. This error will have to be subtracted
One trick when using Motorola GPS's is to set the cable delay to an
30ns to make the GPS receiver itself compensate for this delay by issuing
1PPS output 30ns "too fast".
An interesting effect of sampling at +-3.33ns is that the GPS errors such
multipath, atmospheric, and GPS crystal temperature related issues become
clearly visible with this kind of resolution...
More information about the time-nuts