PLL tricks

Bill Sloman · Nov 18, 2014

On Tuesday, 18 November 2014 09:53:51 UTC+11, Tom Swift wrote:

"dougfgd@gmail.com" <dougfgd@gmail.com> wrote:

This is the first time I have returned in 10 years after nasty
infections put me off. A pll controlled SAW vco referenced to a bulk
crystal will give lowest noise floor outside the loop -170dbc
possible as the saw can run at a high level. dougfgd at
frequencyprecision.com

Sure, but how do you lock 155.52 to 10? A DDS won't give the exact ratio,

A DDS with a programmable modulus divider can divide by any arbitrary integer

http://www.analog.com/static/imported-files/data_sheets/AD9915.pdf

> so you are stuck with an 80KHz pll loop.

Not true. The DDS synthesises a sine wave as a succession of analog voltages. Classically this produces a staircase approximation to the sine wave, but for a fixed frequency application you can integrate the steps and get a straight line approximation (which is a lot closer, so the imperfections are correspondingly smaller).

At one point in my career I approximated an hyperbola with a succession of exponential sections, which is a trick that you could also use to get an even better approximation to a sine wave.

And you are only stuck with an 80kHz pll if you insist on used John Larkin's bang-bang phase detector - any phase detector that generates an error signal that is more or less linearly related to phase error can work fine at 10MHz - particularly with a DDS source you get only small deviations over the 12.5usec when the two sources aren't perfectly coincident, and you can filter the deviations down to noise level before they get to anywhere where they matter.

The multiplier to 155.52 is
1,944, which means a very loose loop. It will wander all over the place
unless it is stablilized in temperature, supply voltage and DC Error
voltage. Even then, it is going to be tough to get down to picosecond
level at 155.52 MHz. Very tough. 1e-12/1,944=5.144e-16 just for base
stability, not counting jitter. Also difficult to do at 80 KHz:
12.5e-6/1e-12=12,500,000. No loop can do that.

If the base oscillator is dead stable - as a good SAW oscillator is - it's stability will dominate the short term noise. The phase locked loop is going to be designed just to cope with the frequency drifts of the SAW oscillator (which are going to be slow) so it will have a bandwidth of no more than a few Hz.

AFAIK, nobody makes a lockable SAW with low phase noise, and I'm not sure
about an oven, but I don't ...

If the SAW clocks a good DDS you are home and hosed.

--
Bill Sloman, Sydney

Bill Sloman · Nov 18, 2014

On Tuesday, 18 November 2014 11:11:00 UTC+11, Jim Thompson wrote:

On Tue, 09 Sep 2014 16:54:53 -0700, John Larkin
jlarkin@highlandtechnology.com> wrote:

If I hypothetically had a 10 MHz reference and wanted to lock a 155.52
MHz VCXO to it, the obvious way would be to divide both down to 80 KHz
(the GCD) and drive a phase detector back into the VCXO. But that's a
pretty low frequency to run the PD at; to get picosecond stability, an
ordinary analog phase detector would need better than 1 PPM analog
accuracy, which ain't gonna happen.

I can build an ECL edge-sensitive phase detector that might work, but
80K is still pretty low.

There must be tricks to run the phase detector at a higher frequency.

I could DDS the 155.52 down to 10 MHz, and phase detect at 10 MHz, but
that sounds jittery to me, and it looks like I can't hit the exact
frequency ratio anyhow.

Go direct... inverted mesa crystals...

http://electronicdesign.com/components/inverted-mesa-crystals-carry-oscillators-internet-age

They've been around for a while. That article was dated March 6, 2000 and I'd specified a 500MHz etched-crystal oscillator for a system I was designing back in 1997 - and there were at least two alternative sources back then.

The part I wanted to buy - as a complete oscillator - would have cost me $100 back then. One would hope that they were cheaper now.

--
Bill Sloman, Sydney

Jan Panteltje · Nov 18, 2014

On a sunny day (Mon, 17 Nov 2014 13:16:44 -0800 (PST)) it happened
"dougfgd@gmail.com" <dougfgd@gmail.com> wrote in
<fdfbfccb-10ad-4848-86ba-4576677173b5@googlegroups.com>:

On Wednesday, September 10, 2014 12:54:53 AM UTC+1, John Larkin wrote:
If I hypothetically had a 10 MHz reference and wanted to lock a 155.52
MHz VCXO to it, the obvious way would be to divide both down to 80 KHz
(the GCD) and drive a phase detector back into the VCXO. But that's a
pretty low frequency to run the PD at; to get picosecond stability, an
ordinary analog phase detector would need better than 1 PPM analog
accuracy, which ain't gonna happen.

I can build an ECL edge-sensitive phase detector that might work, but
80K is still pretty low.

There must be tricks to run the phase detector at a higher frequency.

I could DDS the 155.52 down to 10 MHz, and phase detect at 10 MHz, but
that sounds jitterey to me, and it looks like I can't hit the exact
frequency ratio anyhow.

--

John Larkin Highland Technology, Inc

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

This is the first time I have returned in 10 years after nasty infections put me off.
A pll controlled SAW vco referenced to a bulk crystal will give lowest noise floor outside the loop -170dbc possible as the
saw can run at a high level. dougfgd at frequencyprecision.com

I just orderded this one from ebay,
note that I am at 2.something GHz,
you can run the PLL at a higher frequency than the reference xvco.
http://www.ebay.com/itm/111460880624
The on chip 2.X GHz VCO can also be divided down to as low as 137 MHz.
Just to investigate those AD chips....

And you can feed it externally (10 MHz reference),
and drive it with SPI (the jumpers).
Will have to wait and see if it lives up to expectations.

Making a board + connectors + chip would be more expensive.
Differential out, just what I need.

Tom Swift · Nov 18, 2014

"dougfgd@gmail.com" <dougfgd@gmail.com> wrote:

This is the first time I have returned in 10 years after nasty
infections put me off. A pll controlled SAW vco referenced to a bulk
crystal will give lowest noise floor outside the loop -170dbc
possible as the saw can run at a high level. dougfgd at
frequencyprecision.com

Sure, but how do you lock 155.52 to 10? A DDS won't give the exact ratio,
so you are stuck with an 80KHz pll loop. The multiplier to 155.52 is
1,944, which means a very loose loop. It will wander all over the place
unless it is stablilized in temperature, supply voltage and DC Error
voltage. Even then, it is going to be tough to get down to picosecond
level at 155.52 MHz. Very tough. 1e-12/1,944=5.144e-16 just for base
stability, not counting jitter. Also difficult to do at 80 KHz:
12.5e-6/1e-12=12,500,000. No loop can do that.

AFAIK, nobody makes a lockable SAW with low phase noise, and I'm not sure
about an oven, but I don't think anyone makes those either. GHz SAW's are
great, and I plan on using them in my next project, but it will take a
completely different approach to frequency stabilization.

F.L. Walls at NIST did a nice paper on an extremely low phase noise SAW
oscillator a long time ago. He said it was the lowest noise oscillator
they had ever seen up to that point. But they were running it at an
extremely high level, maybe 30 dBm or so, and there was some concern
about how long it would last. I'll see if I can find the paper and post
it.

Time-Nuts is an excellent resource on all things involving time and
frequency stability and phase noise. You can search the archives with the
url http://www.febo.com/pipermail/time-nuts/ plus your search string.

Welcome back. It is always good to find someone interested in pll's,
phase noise, oscillators, and such, especially when they know what they
are talking about.

Tom Swift · Nov 18, 2014

Tom Swift <spam@me.com> wrote:

Sure, but how do you lock 155.52 to 10? A DDS won't give the exact
ratio, so you are stuck with an 80KHz pll loop. The multiplier to
155.52 is 1,944, which means a very loose loop. It will wander all
over the place unless it is stablilized in temperature, supply voltage
and DC Error voltage. Even then, it is going to be tough to get down
to picosecond level at 155.52 MHz. Very tough.

1e-12/1,944=5.144e-16
just for base stability, not counting jitter.

Please scrap the above statement. Completely wrong. But it will be on the
same order as the following, with the same consequence.

Also difficult to do at
80 KHz: 12.5e-6/1e-12=12,500,000. No loop can do that.

John Larkin · Nov 18, 2014

On Mon, 17 Nov 2014 23:08:17 GMT, Tom Swift <spam@me.com> wrote:

Tom Swift <spam@me.com> wrote:

Sure, but how do you lock 155.52 to 10? A DDS won't give the exact
ratio, so you are stuck with an 80KHz pll loop. The multiplier to
155.52 is 1,944, which means a very loose loop. It will wander all
over the place unless it is stablilized in temperature, supply voltage
and DC Error voltage. Even then, it is going to be tough to get down
to picosecond level at 155.52 MHz. Very tough.

1e-12/1,944=5.144e-16
just for base stability, not counting jitter.

Please scrap the above statement. Completely wrong. But it will be on the
same order as the following, with the same consequence.

Also difficult to do at
80 KHz: 12.5e-6/1e-12=12,500,000. No loop can do that.

I'm pretty sure I can do it; I'll just need a good (expensive) 155.52
MHz OCXO, which is a pretty rare animal.

--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

Tom Swift · Nov 18, 2014

Tom Swift <spam@me.com> wrote:

F.L. Walls at NIST did a nice paper on an extremely low phase noise
SAW oscillator a long time ago. He said it was the lowest noise
oscillator they had ever seen up to that point. But they were running
it at an extremely high level, maybe 30 dBm or so, and there was some
concern about how long it would last. I'll see if I can find the paper
and post it.

I searched for the paper but have not found the right search terms. In
the meantime, here's some other links that may interest you if you have
not already found them.

41st Annual Frequency Control Symposium - 1987
LOW NOISE FREQUENCY SYNTHESIS
http://tf.nist.gov/general/pdf/715.pdf

High-Spectral-Purity Microwave Oscillator: Design Using Conventional
Air-Dielectric Cavity (Note: -220dBc @ 1MHz @ 10GHz)
http://tf.nist.gov/timefreq/general/pdf/1887.pdf

Fundamental limits on the frequency stabilities of crystal oscillators
http://tf.nist.gov/general/pdf/581.pdf

Measurements of the Short-Term Stability of Quartz Resonators
http://tycho.usno.navy.mil/ptti/1974papers/Vol%2006_10.pdf

Index to the proceedings of the Precise Time And Time Interval
(PTTI) systems and applications (formerly applications and planning)
meeting, Topical Index, 1970-2007
http://tycho.usno.navy.mil/ptti/topic_index.html

Past PTTI Meetings, up to 2012
http://tycho.usno.navy.mil/ptti/index.html

Jim Thompson · Nov 18, 2014

On Tue, 09 Sep 2014 16:54:53 -0700, John Larkin
<jlarkin@highlandtechnology.com> wrote:

If I hypothetically had a 10 MHz reference and wanted to lock a 155.52
MHz VCXO to it, the obvious way would be to divide both down to 80 KHz
(the GCD) and drive a phase detector back into the VCXO. But that's a
pretty low frequency to run the PD at; to get picosecond stability, an
ordinary analog phase detector would need better than 1 PPM analog
accuracy, which ain't gonna happen.

I can build an ECL edge-sensitive phase detector that might work, but
80K is still pretty low.

There must be tricks to run the phase detector at a higher frequency.

I could DDS the 155.52 down to 10 MHz, and phase detect at 10 MHz, but
that sounds jitterey to me, and it looks like I can't hit the exact
frequency ratio anyhow.

Tom Swift · Nov 18, 2014

John Larkin <jlarkin@highlandtechnology.com> wrote:

On Mon, 17 Nov 2014 23:08:17 GMT, Tom Swift <spam@me.com> wrote:

Also difficult to do at
80 KHz: 12.5e-6/1e-12=12,500,000. No loop can do that.

I'm pretty sure I can do it; I'll just need a good (expensive) 155.52
MHz OCXO, which is a pretty rare animal.

Yes, very rare. I haven't seen any yet. Besides, you are still up against
one part in 12,500,000. Even if you go to dual 16-bit DACs, the lsb will
be in the noise.

But I also fail to see the point. Why bother locking one edge out of
1,944 to another edge that only occurs once in 125 cycles. There is no
way that anyone can make practical use of that, expecially since the only
one who knows which edges are locked is you. The information is not
available outside your box.

Yes, I know about phase slips in SONET. They happen all the time. Who
cares? The sysem is designed to handle them. The only thing you care
about is making sure all the targets get the trigger signal at the same
time, and as far as I can tell, that is determined by the boxes that get
the signal, not this box. SONET is not going to give you that timing
accuracy.

The system has been running fine for a decade or so. That means there are
other boxes in the system that have been transmitting the trigger signal
over the net that were designed by someone else. I'll bet they have not
gone through the gyrations you have to try to get 1ps accuracy, but their
system works fine. Why does it work now, and why change it?

Jim Thompson · Nov 18, 2014

On Tue, 09 Sep 2014 16:54:53 -0700, John Larkin
<jlarkin@highlandtechnology.com> wrote:

If I hypothetically had a 10 MHz reference and wanted to lock a 155.52
MHz VCXO to it, the obvious way would be to divide both down to 80 KHz
(the GCD) and drive a phase detector back into the VCXO. But that's a
pretty low frequency to run the PD at; to get picosecond stability, an
ordinary analog phase detector would need better than 1 PPM analog
accuracy, which ain't gonna happen.

I can build an ECL edge-sensitive phase detector that might work, but
80K is still pretty low.

There must be tricks to run the phase detector at a higher frequency.

I could DDS the 155.52 down to 10 MHz, and phase detect at 10 MHz, but
that sounds jitterey to me, and it looks like I can't hit the exact
frequency ratio anyhow.

John Larkin · Nov 18, 2014

On Tue, 18 Nov 2014 00:03:01 GMT, Tom Swift <spam@me.com> wrote:

John Larkin <jlarkin@highlandtechnology.com> wrote:

On Mon, 17 Nov 2014 23:08:17 GMT, Tom Swift <spam@me.com> wrote:

Also difficult to do at
80 KHz: 12.5e-6/1e-12=12,500,000. No loop can do that.

I'm pretty sure I can do it; I'll just need a good (expensive) 155.52
MHz OCXO, which is a pretty rare animal.

Yes, very rare. I haven't seen any yet.

I can get them, but they will be in the $600 range, which isn't great
but is tolerable for the project we have in mind. That's another tale.

Besides, you are still up against

one part in 12,500,000. Even if you go to dual 16-bit DACs, the lsb will
be in the noise.

My loop won't have any DACs. The loop has been described elsewhere in
this thread. An EclipsPlus bang-bang phase detector output is lowpass
filtered into the OCXO vco input. It will be pretty simple. But it is
hard to analyze.

Besides, a VCXO integrates its frequency control input. A 16-bit DAC
could easily control a good OCVCXO to picosecond accuracy. I'll be
using, in effect, a 1 bit DAC.

But I also fail to see the point. Why bother locking one edge out of
1,944 to another edge that only occurs once in 125 cycles. There is no
way that anyone can make practical use of that, expecially since the only
one who knows which edges are locked is you. The information is not
available outside your box.

It sure will be. This has also been discussed here. The 10 MHz
reference is accompanied by a 1 PPS pulse. That 1 PPS has to be
promoted into the 155.52 MHz time domain, without ever missing a
single cycle anywhere, anytime.

Yes, I know about phase slips in SONET. They happen all the time. Who
cares? The sysem is designed to handle them. The only thing you care
about is making sure all the targets get the trigger signal at the same
time, and as far as I can tell, that is determined by the boxes that get
the signal, not this box. SONET is not going to give you that timing
accuracy.

The system distributes clocks and triggers to several hundred timing
modules scattered about the site, using SONET sort of signaling, over
fiber. Our timing modules in turn fire about 2000 "clients" to
picosecond accuracy. It works, but it needs some upgrades.

The system has been running fine for a decade or so. That means there are
other boxes in the system that have been transmitting the trigger signal
over the net that were designed by someone else. I'll bet they have not
gone through the gyrations you have to try to get 1ps accuracy, but their
system works fine. Why does it work now, and why change it?

Things get old and start to break. I suspect they had some gyrations
of their own, back then.

--

John Larkin Highland Technology, Inc
picosecond timing precision measurement

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

Bill Sloman · Nov 23, 2014

On Sunday, 23 November 2014 10:01:34 UTC+11, John Larkin wrote:

On Sat, 22 Nov 2014 22:20:40 GMT, Tom Swift <spam@me.com> wrote:
John Larkin <jlarkin@highlandtechnology.com> wrote:
On Tue, 18 Nov 2014 00:03:01 GMT, Tom Swift <spam@me.com> wrote:

<snip>

The system is definitely not SONET. It uses the OC-3 frequency and
hardware, including the optical fibers and connectors, but the
encoding is different. Refer to the Stanford NIF article at

http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

I'm one of the authors of that paper! I designed the V880 delay
generator modules, and helped brainstorm the system architecture.

Definitely a gotcha.

<snip>

The delay generators have a 155.52 MHz VCXO that is phase-locked to
the biphase optical data stream. I used an ECL flop as a bang-bang
phase detector. But that was updated at 77.76 MHz, and now I want to
do it at 80 KHz. Hey, that's only 1000:1.

The ECL-bistable bang-bang phase detector is almost certainly a mistake. A linear phase detector - realised as simply as ECL exclusive-OR - would let you average over a lot more edges, and get a fairly spectacular improvement in signal to noise ratio. Sequential phase detectors can also produce an output which is a linear function of phase output, if you are careful. Because they are essentially zero-crossing detectors, their bandwidth is higher and they lock in more of the comparator noise, but at least you can still average that noise over a lot more edges than a bang-bang detector will let you look at.

The GPS is not needed. It could be replaced by a SRS PRS10 Rubidium,
and the time of day could be obtained from WWVB in Fort Collins at
60 KHz:

My input will be from a rubidium source disciplined by GPS. The 10 MHz
and 1 PPS are my inputs so are, from my perspective, defined to be
perfect.

<snip>

You don't even have the equipment needed to measure the
error to one picosecond in a single shot.

Sure I so. I use a 20 GHz sampling scope. Each trigger puts one dot on
the screen. We run that for a while. The biggest error is temperature,
under 1 ps/degC, but the modules run in a very, very well-controlled
environment. Scope drift is a problem, too.

Another gotcha.

> AFAIK, nobody does.

Oops.

<snip>

> I call it designing electronics. Somebody's got to do it.

But, as you demonstrate, you don't have to do it perfectly to make money.

--
Bill Sloman, Sydney

Tom Swift · Nov 23, 2014

John Larkin <jlarkin@highlandtechnology.com> wrote:

On Tue, 18 Nov 2014 00:03:01 GMT, Tom Swift <spam@me.com> wrote:

But I also fail to see the point. Why bother locking one edge out
of 1,944 to another edge that only occurs once in 125 cycles.

There is no way that anyone can make practical use of that,
expecially since the only one who knows which edges are locked is
you. The information is not available outside your box.

It sure will be. This has also been discussed here. The 10 MHz
reference is accompanied by a 1 PPS pulse. That 1 PPS has to be
promoted into the 155.52 MHz time domain, without ever missing a
single cycle anywhere, anytime.

That is simply not true. You are only generating a 155.52 MHz clock.

There is no relation between the 1 PPS from GPS and the operating
frequency of 155.52 MHz. You are locking to the 10MHz clock, which
locks to the 1 PPS signal.

But the 1 PPS can have +/-50 ns of jitter and probably suffers from
sawtooth error and can change phase rapidly. Here are some examples.
Notice the large phase change between some 1 PPS pulses:

http://www.leapsecond.com/pages/vp/sawtooth.htm
http://www.leapsecond.com/pages/vp/heater.htm
http://www.leapsecond.com/pages/m12/sawtooth.htm

The 1 PPS error has to be heavily filtered to provide a decent lock
for an OCXO. This can give an average to within +/-1e-12 of the
target frequency, if it is done right. Here are some examples of
different GPSDO Allen Deviation plots:

http://www.leapsecond.com/pages/gpsdo/

The sawtooth error comes from the internal crystal oscillator in the
GPS receiver. It is not temperature compensated and wanders all over
the place. The sawtooth comes from the beating effect of the crystal
frequency offset and the GPS one second timing.

You could eliminate the beating effect by deriving the internal
crystal frequency from the 1 PPS signal. This is shown in the
Trimble ThunderBolt System Architecture, Figure 5-10 on page 56 in

http://trl.trimble.com/docushare/dsweb/Get/Document-
10001/ThunderBoltBook2003.pdf

This still leaves many sources of error in the GPS timing. Some are
listed in Table 5-1, GPS Error Sources, on page 52

Error Source 1 Standard Deviation
Atmospheric Models (Ionosphere) 5 - 50 ns
Receiver noise (Multipath) 1 - 20 ns
Satellite Clock Model 10 ns
Satellite Orbit Model 5 ns
Antenna Survey 1 ns

The system distributes clocks and triggers to several hundred
timing modules scattered about the site, using SONET sort of
signaling, over fiber. Our timing modules in turn fire about 2000
"clients" to picosecond accuracy. It works, but it needs some
upgrades.

The system is definitely not SONET. It uses the OC-3 frequency and
hardware, including the optical fibers and connectors, but the
encoding is different. Refer to the Stanford NIF article at

http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

SONET is NRZ with a data rate of 155.52 Mbit/s. NRZ can have long
runs of ones or zeros and requires special encoding to prevent the
receiver PLL from losing lock.

NIF is bi-phase with a data rate of 77.76 Mbit/s. It has at least
one transition per bit, and is self-synchronizing. Here is the
Wikipedia description:

http://en.wikipedia.org/wiki/Biphase_mark_code

Here is a decoder using a PLL:

https://patentimages.storage.googleapis.com/pdfs/US4167760.pdf

Here is a decoder that doesn't use a PLL:

https://patentimages.storage.googleapis.com/pdfs/US4746898.pdf

This has immense consequences on the system. The actual trigger
occurs after the first frame synchronization pattern after a data
frame match.

This is determined by the first clock edge after the match in the
Delay Generator, and only indirectly by the Master Timing
Transmitter (MTT), since the pll filters the clock edges.

If no pll is used in the Delay Generator, the MTT could have enough
jitter so that clock edge is up to one half of a bit cell off, and
the system would probably still function.

The real heroes are the clocks in each Delay Generator. These
establish the synchronization needed to fire the lasers. The MTT just
tells them which clock edge to use.

The GPS is not needed. It could be replaced by a SRS PRS10 Rubidium,
and the time of day could be obtained from WWVB in Fort Collins at
60 KHz:

http://www.thinksrs.com/products/PRS10.htm
http://www.nist.gov/pml/div688/grp40/wwvb.cfm

This combination would probably be more reliable, since it does not
depend on GPS which is easily jammed. Truck and taxi drivers often
carry GPS jammers to prevent the home office from snooping on their
routes.

So your fixation with locking to within one picosecond is
meaningless. You don't even have the equipment needed to measure the
error to one picosecond in a single shot. AFAIK, nobody does. The
best you can do is average, and the HP 5370B will get down to 100
fs. But who cares, when GPS can wander a hundred ns or more?

The system has been running fine for a decade or so. That means
there are other boxes in the system that have been transmitting
the trigger

have not gone through the gyrations you have to try to get 1ps
accuracy, but their system works fine. Why does it work now, and
why change it?

Things get old and start to break. I suspect they had some
gyrations of their own, back then.

Symmetricom bought Timing Solutions in October, 2006:

http://www.microwavejournal.com/articles/3890-symmetricom-acquires-
timing-solutions-corp

Microsemi bought Symmetricom in November, 2013:

http://www.electronicspecifier.com/around-the-industry/microsemi-
acquires-symmetricom

Microsemi probably doesn't want to be bothered maintaining a single
one-of-a-kind box, so when the contract expire(s,d) they probably
gave an outlandish quote. LLNL probably figures it would be cheaper
to get you to build another and get you on a maintenance contract.

I'd call that pretty good vendor lock-in.

John Larkin · Nov 23, 2014

On Sat, 22 Nov 2014 22:20:40 GMT, Tom Swift <spam@me.com> wrote:

John Larkin <jlarkin@highlandtechnology.com> wrote:

On Tue, 18 Nov 2014 00:03:01 GMT, Tom Swift <spam@me.com> wrote:

But I also fail to see the point. Why bother locking one edge out
of 1,944 to another edge that only occurs once in 125 cycles.

There is no way that anyone can make practical use of that,
expecially since the only one who knows which edges are locked is
you. The information is not available outside your box.

It sure will be. This has also been discussed here. The 10 MHz
reference is accompanied by a 1 PPS pulse. That 1 PPS has to be
promoted into the 155.52 MHz time domain, without ever missing a
single cycle anywhere, anytime.

That is simply not true. You are only generating a 155.52 MHz clock.

Sorry, I'm going to do what I described. It's sensible and it's
required.

There is no relation between the 1 PPS from GPS and the operating
frequency of 155.52 MHz. You are locking to the 10MHz clock, which
locks to the 1 PPS signal.

But the 1 PPS can have +/-50 ns of jitter and probably suffers from
sawtooth error and can change phase rapidly. Here are some examples.
Notice the large phase change between some 1 PPS pulses:

http://www.leapsecond.com/pages/vp/sawtooth.htm
http://www.leapsecond.com/pages/vp/heater.htm
http://www.leapsecond.com/pages/m12/sawtooth.htm

The 1 PPS error has to be heavily filtered to provide a decent lock
for an OCXO. This can give an average to within +/-1e-12 of the
target frequency, if it is done right. Here are some examples of
different GPSDO Allen Deviation plots:

http://www.leapsecond.com/pages/gpsdo/

The sawtooth error comes from the internal crystal oscillator in the
GPS receiver. It is not temperature compensated and wanders all over
the place. The sawtooth comes from the beating effect of the crystal
frequency offset and the GPS one second timing.

You could eliminate the beating effect by deriving the internal
crystal frequency from the 1 PPS signal. This is shown in the
Trimble ThunderBolt System Architecture, Figure 5-10 on page 56 in

http://trl.trimble.com/docushare/dsweb/Get/Document-
10001/ThunderBoltBook2003.pdf

That states that their 1 PPS is divided down from the master 10 MHz
oscillator. The 1 PPS can slew, in 100 ns steps, during acquisition.
After that, it should happen precisely once every 10e6 cycles of the
10M reference. Section 5.1.1 explains that pretty well. I assume that
the equivalent of "jam sync" will never happen; that would be a
disaster.

This still leaves many sources of error in the GPS timing. Some are
listed in Table 5-1, GPS Error Sources, on page 52

Error Source 1 Standard Deviation
Atmospheric Models (Ionosphere) 5 - 50 ns
Receiver noise (Multipath) 1 - 20 ns
Satellite Clock Model 10 ns
Satellite Orbit Model 5 ns
Antenna Survey 1 ns

The system distributes clocks and triggers to several hundred
timing modules scattered about the site, using SONET sort of
signaling, over fiber. Our timing modules in turn fire about 2000
"clients" to picosecond accuracy. It works, but it needs some
upgrades.

The system is definitely not SONET. It uses the OC-3 frequency and
hardware, including the optical fibers and connectors, but the
encoding is different. Refer to the Stanford NIF article at

http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

I'm one of the authors of that paper! I designed the V880 delay
generator modules, and helped brainstorm the system architecture.

SONET is NRZ with a data rate of 155.52 Mbit/s. NRZ can have long
runs of ones or zeros and requires special encoding to prevent the
receiver PLL from losing lock.

NIF is bi-phase with a data rate of 77.76 Mbit/s. It has at least
one transition per bit, and is self-synchronizing. Here is the
Wikipedia description:

http://en.wikipedia.org/wiki/Biphase_mark_code

Here is a decoder using a PLL:

https://patentimages.storage.googleapis.com/pdfs/US4167760.pdf

Here is a decoder that doesn't use a PLL:

https://patentimages.storage.googleapis.com/pdfs/US4746898.pdf

This has immense consequences on the system. The actual trigger
occurs after the first frame synchronization pattern after a data
frame match.

This is determined by the first clock edge after the match in the
Delay Generator, and only indirectly by the Master Timing
Transmitter (MTT), since the pll filters the clock edges.

If no pll is used in the Delay Generator, the MTT could have enough
jitter so that clock edge is up to one half of a bit cell off, and
the system would probably still function.

The real heroes are the clocks in each Delay Generator. These
establish the synchronization needed to fire the lasers. The MTT just
tells them which clock edge to use.

The delay generators have a 155.52 MHz VCXO that is phase-locked to
the biphase optical data stream. I used an ECL flop as a bang-bang
phase detector. But that was updated at 77.76 MHz, and now I want to
do it at 80 KHz. Hey, that's only 1000:1.

The GPS is not needed. It could be replaced by a SRS PRS10 Rubidium,
and the time of day could be obtained from WWVB in Fort Collins at
60 KHz:

My input will be from a rubidium source disciplined by GPS. The 10 MHz
and 1 PPS are my inputs so are, from my perspective, defined to be
perfect.

http://www.thinksrs.com/products/PRS10.htm
http://www.nist.gov/pml/div688/grp40/wwvb.cfm

This combination would probably be more reliable, since it does not
depend on GPS which is easily jammed. Truck and taxi drivers often
carry GPS jammers to prevent the home office from snooping on their
routes.

So your fixation with locking to within one picosecond is
meaningless.

And required. And fun.

You don't even have the equipment needed to measure the
>error to one picosecond in a single shot.

Sure I so. I use a 20 GHz sampling scope. Each trigger puts one dot on
the screen. We run that for a while. The biggest error is temperature,
under 1 ps/degC, but the modules run in a very, very well-controlled
environment. Scope drift is a problem, too.

AFAIK, nobody does. The

best you can do is average, and the HP 5370B will get down to 100
fs. But who cares, when GPS can wander a hundred ns or more?

The system has been running fine for a decade or so. That means
there are other boxes in the system that have been transmitting
the trigger

have not gone through the gyrations you have to try to get 1ps
accuracy, but their system works fine. Why does it work now, and
why change it?

Things get old and start to break. I suspect they had some
gyrations of their own, back then.

Symmetricom bought Timing Solutions in October, 2006:

http://www.microwavejournal.com/articles/3890-symmetricom-acquires-
timing-solutions-corp

Microsemi bought Symmetricom in November, 2013:

http://www.electronicspecifier.com/around-the-industry/microsemi-
acquires-symmetricom

Microsemi probably doesn't want to be bothered maintaining a single
one-of-a-kind box, so when the contract expire(s,d) they probably
gave an outlandish quote. LLNL probably figures it would be cheaper
to get you to build another and get you on a maintenance contract.

I don't think my company has ever received a maintanance contract for
anything.

I'd call that pretty good vendor lock-in.

I call it designing electronics. Somebody's got to do it.

--

John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com

PLL tricks

Bill Sloman

Guest

Bill Sloman

Guest

Jan Panteltje

Guest

Tom Swift

Guest

Tom Swift

Guest

John Larkin

Guest

Tom Swift

Guest

Jim Thompson

Guest

Tom Swift

Guest

Jim Thompson

Guest

John Larkin

Guest

Bill Sloman

Guest

Tom Swift

Guest

John Larkin

Guest

Welcome to EDABoard.com

Sponsor

Online statistics

Forum statistics

PLL tricks

Bill Sloman

Guest

Bill Sloman

Guest

Jan Panteltje

Guest

Tom Swift

Guest

Tom Swift

Guest

John Larkin

Guest

Tom Swift

Guest

Jim Thompson

Guest

Tom Swift

Guest

Jim Thompson

Guest

John Larkin

Guest

Bill Sloman

Guest

Tom Swift

Guest

John Larkin

Guest

Log in

Welcome to EDABoard.com

Sponsor