[time-nuts] GPS Phase locked Local Oscillator experiment

[Peter Schmelcher]

>Message: 1
>Date: Sun, 11 Mar 2007 02:04:17 +0100 (CET)
>From: Magnus Danielson <cfmd at bredband.net>
>Subject: Re: [time-nuts] GPS Phase locked Local Oscillator experiment
>To: time-nuts at febo.com, nebula at telus.net
>Message-ID: <20070311.020417.-925721003.cfmd at bredband.net>
>Content-Type: Text/Plain; charset=us-ascii
>
>From: Peter Schmelcher <nebula at telus.net>
>Subject: Re: [time-nuts] GPS Phase locked Local Oscillator experiment
>Date: Sat, 10 Mar 2007 16:42:09 -0800
>Message-ID: <5.2.1.1.2.20070310163253.02abc6b0 at pop.telus.net>
>
> >
> > >Message: 2
> > >Date: Fri, 09 Mar 2007 00:40:59 +0100 (CET)
> > >From: Magnus Danielson <cfmd at bredband.net>
> > >Subject: Re: [time-nuts] GPS Phase locked Local Oscillator experiment
> > >To: time-nuts at febo.com, nebula at telus.net
> > >Message-ID: <20070309.004059.-1266979269.cfmd at bredband.net>
> > >Content-Type: Text/Plain; charset=us-ascii
> > >
> > >From: Peter Schmelcher <nebula at telus.net>
> > >Subject: Re: [time-nuts] GPS Phase locked Local Oscillator experiment
> > >Date: Thu, 08 Mar 2007 10:55:29 -0800
> > >Message-ID: <5.2.1.1.2.20070308095745.02b9e358 at pop.telus.net>
> > >
> > > >
> > > > >Wonder how the Z3816A would like a modified VP inside... Hmmm... a 
> closed
> > > > >loop system, what are really the timeconstants relevant, to make 
> sure it
> > > > >is stable?
> > > >
> > > > That is where I am going. The UT+ oncore inside the Z3816A is a simple
> > > > crystal and easy to feed with the 3325A. I currently have an 
> ongoing oven
> > > > turning point experiment with the MTI oscillator or I would have 
> done it
> > > > already. The frequency of the local oscillator will need to be
> > > different by
> > > > 0.5 Hz I think. The pps pulse needs to jump back and forth by 1 clock
> > > cycle
> > > > for the pps pulse to have any feedback information in it when the local
> > > > oscillator is phase locked unless the Z3816A reads the sawtooth 
> residual
> > > > from the internal UT+.
> > >
> > >If you have a smaller offset, you get a better dither-curve (a sawtooth)
> > >rather
> > >than a square-wave. Your 3325A has _no_ problem at all doing that. :)
> > >
> > >Also, I would run the 3325A from one of your Rubidiums.
> >
> > A good point Magnus tau matters. This screen capture is the time solution
> > for just a single space vehicle SV7 using an unlocked rubidium.
>
>It looks more or less as I expected. The slope (about -3E-11 frequency error)
>is kind of expected frequency error from the Rubidium. Adjusting the 3325A 
>up by
>550 uHz or thereabouts should compensate for it.
>
> > I also did some testing with different frequencies. 19.095749MHz dithers
> > the pps output so the correct time is in the middle of the two pps pulses.
> > The potential advantage is that no sawtooth information is required for
> > even second averages of the pps output.
>
>The unstability of the Rubidium is not sufficient to leak the additional
>information to your control loop. This is why you want to add dither in 
>forms of
>suitable (intentional) detuning to get the sawtooth shape. On average that 
>leaks
>more information than the squarewave setup. Let's say you are 1/8 Hz off mark,
>then you get about 3 bits of additional information compared to 0 Hz off mark.
>
>Multiples work too, so +/- 1/8 Hz +/- N Hz gives the same effect.
>
>As the dither gives finer resolution, the unstability noise grows bigger 
>and it
>helps more to average out over time. By letting it do that, you don't have 
>to go
>to lower frequency offsets which will be harder to suppress in the control 
>loop.

I added white noise, pink noise and FM to the local oscillator. Nothing had 
the desired effect on the pps pulse position.

The oncore estimates the local oscillator frequency 0.1 seconds before the 
pps output pulse and picks the future clock edge at that moment. (Adding or 
subtracting 10 Hz from the local oscillator frequency results in the same 
sawtooth output.) The oncore software tracking filters have dynamic 
bandwidths but get very very narrow after two minutes. This creates a 
conflict. Disturbing the local oscillator frequency enough to change the 
pps pulse position also results in huge tracking filter bandwidths. What 
happens is before the pps pulse moves by one clock cycle you loose lock on 
all the space vehicles.


> > One disappointment is that TRAIM has a minimum setting of 300ns so a 
> meteor
> > on any SV signal path can degrade the time solution many tens of 
> nanoseconds.
>
>You can't win them all.
>
>Cheers,
>Magnus