[time-nuts] Another "atomic" clock question

Thu Mar 6 17:40:06 EST 2014

Hi

In modern GPS modules the sawtooth error is no longer truncated at the 1 ns level. The have been giving you far more resolution than that for 10 years now.  The resolution is not just useless bits. If you compare the result to a cesium standard they do improve the GPS.

Bob

On Mar 6, 2014, at 1:30 AM, Mike at febo.com wrote:

> 
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.