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





On Mar 5, 2014, at 6:48 PM, Tom Van Baak <t...@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.
> 
> 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.
> 
> /tvb
> 
> ----- Original Message ----- 
> From: "Bob Camp" <li...@rtty.us>
> To: "Discussion of precise time and frequency measurement" 
> <time-nuts@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
> 
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Reply via email to