Re: [time-nuts] GPS Phase locked Local Oscillator experiment
Message: 1
Date: Sun, 11 Mar 2007 02:04:17 +0100 (CET)
From: Magnus Danielson cfmd@bredband.net
Subject: Re: [time-nuts] GPS Phase locked Local Oscillator experiment
To: time-nuts@febo.com, nebula@telus.net
Message-ID: 20070311.020417.-925721003.cfmd@bredband.net
Content-Type: Text/Plain; charset=us-ascii
From: Peter Schmelcher nebula@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@pop.telus.net
Message: 2
Date: Fri, 09 Mar 2007 00:40:59 +0100 (CET)
From: Magnus Danielson cfmd@bredband.net
Subject: Re: [time-nuts] GPS Phase locked Local Oscillator experiment
To: time-nuts@febo.com, nebula@telus.net
Message-ID: 20070309.004059.-1266979269.cfmd@bredband.net
Content-Type: Text/Plain; charset=us-ascii
From: Peter Schmelcher nebula@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@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