[time-nuts] GPS Phase locked Local Oscillator experiment

[Peter Schmelcher]

>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.

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.

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.

Peter


> > >The big difference is that Peter used another GPS clock as reference. 
> By that
> > >he is actually doing a delta measurement between the receivers. 
> Hooking the
> > >3325 up to a Cesium would be a much more interesting measurement.
> >
> > I have measured the stability of the Z3616A 10MHz output indirectly by
> > measuring a good ovenized crystal oscillator in the past it is less than
> > 50uHz rms with 10 samples of 1.8 seconds. For comparison my two rubidium
> > oscillators are about 200 to 350 uHz rms. The HP engineers did a good job.
>
>Indeed.
>
> > >You would like to query the receiver in a different maner, so that would
> > >require a modified firmware.
> >
> > My data logging is not what it should be. I do not know a simple way to 
> log
> > the sawtooth data to a file so I did a screen capture.
>
>It should be a fairly short script to do it. :)
>
>Personally I fancy real programs (in C).
>
>Cheers,
>Magnus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rubSV7.JPG
Type: image/jpeg
Size: 60849 bytes
Desc: not available
Url : http://www.febo.com/pipermail/time-nuts/attachments/20070310/0ec1b691/attachment-0001.jpeg