[time-nuts] Another "atomic" clock question
Bob Camp
lists at rtty.us
Thu Mar 6 22:40:06 UTC 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.
More information about the Time-nuts_lists.febo.com
mailing list