[time-nuts] Another "atomic" clock question

Thu Mar 6 06:30:17 UTC 2014

Wow! One post and I've got the two top heavyweights against me! Let
me introduce myself.

I am a retired electronics engineer with over 50 years of experience
in instrumentation and metrology. Here is my patent list:

http://www.pst.netii.net/patents.htm

Among the  achievements  listed,   I   claim  credit  for  the first
disclosure of the now universal dual-d phase-frequency detector, and
for the technique called "Phase Margin Analysis" as applied  to hard
disk bdrive   it   error   analysis.   The   technology  has evolved
tremendously since  the 1970's, but this was the first to  show that
rapid bit  error  analysis was possible. The internet  would  not be
possible without  this  basic  technique,   since  it  would  not be
possible to manufacture hard disks fast enough.

Another significant  invention is Binary Sampling. I will  talk more
about this later, but some information is on my web site at

http://www.pst.netii.net/sampler/index.htm

also starting on page 6 of

http://www.pst.netii.net/pdfs/tdrpaper.pdf

One of  the  significant  advantages of the  Binary  Sampler  is the
elimination of Gaussian and Impulse noise. Unlike conventional diode
bridge samplers,   the   performance   improves   as   the frequency
increases.

After working with the Binary Sampler, I am always dismayed  to view
the noisy graphs presented in time-nuts and other forums.  The noise
is hiding  the interesting stuff and making it  virtually impossible
to understand what is actually going on. I Think the  Binary Sampler
can do a lot to help unravel the issues.

I now intersperse replies:

> Hi(

> While you  see  a lot of pretty plots in GPS  spec  sheets showing
> clean looking  sawtooth  sort of offsets marching  down  the page,
> that?s not  what  I see on a real receiver.  The  real  data, even
> compared to  a 5071A is much more random. It  will  indeed ?hang?,
> but it  also  will  reverse far more often  than  the  pretty data
> sheets suggest.  A  simple model would be to add  the  sawtooth to
> some sort of random process. The sawtooth comes from the TCXO, the
> random looking stuff comes from the GPS solution.

> The oscillator in most timing modules is one form or another  of a
> TCXO. Often  they have digital compensation (one way  or another).
> Their frequency versus temperature curves are not the simple third
> order curve you would expect from a bare crystal. They have a much
> higher order frequency versus temperature curve (6th, 8th ?). That
> makes even  the  simple ?frequency goes down  when  temp  goes up?
> decision pretty  tough.  If  they  are  doing  some  sort  of auto
> correction TCXO based on the GPS it would get even more  crazy. In
> that case the curve would be changing real time.

> Since the  sawtooth changes multiple ?runs? per minute  in  a room
> that holds  2C  / 30 minutes, you could guess  that  a  control of
> 0.01C would  be needed to have any luck  steering  the oscillator.
> It?s nowhere near that simple, so that?s not even up to  the ?wild
> guess? level of confidence. If it?s close, that?s not going  to be
> very easy all by it?s self. A double loop control is likely  to be
> needed.

> Combine the  random jitter with the  (possibly)  tough temperature
> control problem,  and frequency reversals - this is a real  can of
> worms.

> ???????????

> Way lots easier approach:

> 1) You already need a CPU to set up the GPS, read the sawtooth data stream and do a control loop. It?s free / same with either approach.
> 2) Rip a VCTCXO out of something (or buy one cheap).
> 3) PWM control the TCXO, use it as your CPU clock
> 4) Generate a PPS with a timer output on the CPU.
> 5) Do a cheap / simple / easy TDC on the GPS pps, it will cost less that what ever was going to drive the heater.

> Now you have a GPSDO with a much lower jitter PPS output. You need
> to write  from scratch code for the CPU either way.  The  code for
> the GPSDO  is probably simpler than the temperature  control code.
> It?s certainly  no more difficult. This way you have an  output at
> what ever the TCXO frequency is for ?other stuff?.

> Bob

Thanks, Bob.  I don't propose using temperature to  control  the GPS
clock. I  plan  to  use   a   AD9912  DDS  (1GHz  48Bit  4uHz 0.19ps
$59 at Newark.)

> On Mar  5,  2014, at 6:48 PM,  Tom  Van  Baak <tvb at LeapSecond.com>
> wrote:

>> I agree with Bob.

>> For casual  use,  "hanging  bridges" are  not  really  a problem,
>> statistically speaking -- so don't worry.

>> Yes, you  can  apply various techniques  to  reduce/eliminate the
>> rare effect: forced temperature change, forced Vcc change, 2 or 3
>> or more  shared-antenna receivers,  modulating  phase, frequency,
>> voltage, temperature,  etc.  But  as   you  spend  too  much time
>> engineering this uncertain hack you maybe start to wonder  if the
>> real solution  is   just   to   apply   known  digital, numerical
>> correction instead  of wishful analog cover-up. Been  there, done
>> that.

>> For more  serious use, at the tens or unit nanosecond  level, the
>> robust solution is simply to apply 1PPS sawtooth  correction from
>> the receiver.

The sawtooth  error data is truncated at 1 ns. I would  like  to get
far below that error.

>> This issue  comes  up  every now  and  then  as  people gradually
>> transition from casual to serious use. I welcome any hard data or
>> plots that demonstrate the difference among all approaches. There
>> *is* a  slight  difference for sure. It's just  that  most people
>> throw in the towel and use sawtooth corrections instead of trying
>> to avoid them and cover up with less deterministic methods.

Tom,

Thanks for your reply. The sawtooth error correction is described in
"Timing for VLBI", by Tom Clark and Rick Hambly, at

http://www.cnssys.com/files/tow-time2011.pdf

John Ackermann  shows  graphs  that   compare  the  results  in "GPS
Pulse-per-Second Comparative Noise", at

https://www.febo.com/pages/gps_pps/

It appears  the  implementation  of  the  sawtooth  error correction
severely degrades the performance of the system. There could be many
reasons, which  is why it is important to nail down as  many  of the
error sources as possible.

>> /tvb

> ----- Original Message -----
> From: "Bob Camp" <lists at rtty.us>
> To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
> Sent: Wednesday, March 05, 2014 3:03 PM
> Subject: Re: [time-nuts] Another "atomic" clock question

> Hi

> If you  are going to decode and use the sawtooth data  out  of the
> receiver, there?s  no need to eliminate the  hanging  bridges. The
> sawtooth data does that for you already. Put another  way, heating
> the receiver is *harder* than just using the decoded data?.

> Bob

Thanks, Bob.  I  am not planning on heating the crystal.  I  want to
replace it with a precision DDS.

The sawtooth data is truncated at 1ns. I want to do much better.

Again, this  is not intended as a quick-and-dirty fix. I  would like
to separate  out  the error sources in a GPSDO and see  what  can be
done to improve the results.

Thanks,

Mike