[time-nuts] GPS Phase locked Local Oscillator experiment

Magnus Danielson cfmd at bredband.net
Sat Mar 10 20:04:17 EST 2007


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.

> 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



More information about the time-nuts mailing list