[time-nuts] Some results of PRS10 and Trimble Resolution

Stephan Sandenbergh stephan at rrsg.ee.uct.ac.za
Wed Jun 28 12:22:58 EDT 2006

Hi Said,

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?


Stephan Sandenbergh 	


Said wrote:

Message: 10
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"

Hello Tom,
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
correction is 
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
in software.
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
of  the 
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 mailing list