PLL tricks

[Kevin Aylward]

"DecadentLinuxUserNumeroUno" wrote in message
news:3fqd2a5mae2rs5o0s17hsc0ro16fd4mslt@4ax.com...

On Sat, 27 Sep 2014 12:45:31 +0100, "Kevin Aylward"
<ExtractkevinRemove@kevinaylward.co.uk> Gave us:

http://www.fujitsu.com/downloads/MICRO/fme/dataconverters/OFC-2010-56Gss-ADC-Enabling-100GbE.pdf

Nice! Fujitsu appears to be placing a lot into it.

Its very, very, impressive. Its needs a good clock as well. < 50fs jitter

All of the optical interlinks we typically use these days (XFP, SFP,
Etc.)are all 10Gb/s ports.

100Gb is a lot of electrons being carefully manipulated. Wow!

Off the cuff. If a single intercontinental fibre can be converted to run 100
Gb/s from 10 Gb/s, say...10Mb/s at $10 per month per customer, its about $1M
revenue p.a. So, there is a lot of scope for the hardware cost.

Kevin Aylward
www.kevinaylward.co.uk
www.anasoft.co.uk - SuperSpice

 

[John Larkin]

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.

Consider this:

If we square up the 10 MHz reference, and the 155.52 MHz oscillator
were somehow locked to it, the edges line up at 80 KHz, namely every
12.5 us. So the bangbang phase detector only delivers one bit of
information (namely early/late) 80K times per second. That may be too
noisy to discipline a cheap 155 MHz VCXO.

If we have a counter mod 1944, to make 80K from 155.52 MHz, assume we
use state 0 to enable the bangbang phase comparison against the 10
MHz. We servo to zero time error. But, as noted, there are other
counter states that, if used to enable the d-flop, are near-misses to
10 MHz reference edges. There are two or three states that are within
+-50 ps, and maybe another 6 or so within about 100 ps.

So, we could do this:

https://dl.dropboxusercontent.com/u/53724080/Circuits/Oscillators/Multi_Bang_PLL.JPG


It's not hard to add a DAC that applies a bit of +- delay trim in one
differential ECL path, with the 10 MHz leg shown by example. A RAM in
the FPGA can map counter states into DAC codes hence time tweaks. So
we can trim 3 to 10 clock near-misses to be almost spot-on, and
multiply the compare rate accordingly. We can have software control
over which edges we use, and how much to time tweak each one. Then we
can trim the RAM data for minimum jitter.

I was going to have a time trim DAC for temperature compensation
anyhow, so this is almost free. The DAC doesn't need to be super fast,
since the near-miss events are fairly scattered in the 1944-state
space.


--

John Larkin Highland Technology, Inc

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

 

[Phil Hobbs]

On 9/27/2014 6:33 PM, John Larkin 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 jitterey to me, and it looks like I can't hit the exact
frequency ratio anyhow.


Consider this:

If we square up the 10 MHz reference, and the 155.52 MHz oscillator
were somehow locked to it, the edges line up at 80 KHz, namely every
12.5 us. So the bangbang phase detector only delivers one bit of
information (namely early/late) 80K times per second. That may be too
noisy to discipline a cheap 155 MHz VCXO.

If we have a counter mod 1944, to make 80K from 155.52 MHz, assume we
use state 0 to enable the bangbang phase comparison against the 10
MHz. We servo to zero time error. But, as noted, there are other
counter states that, if used to enable the d-flop, are near-misses to
10 MHz reference edges. There are two or three states that are within
+-50 ps, and maybe another 6 or so within about 100 ps.

So, we could do this:

https://dl.dropboxusercontent.com/u/53724080/Circuits/Oscillators/Multi_Bang_PLL.JPG


It's not hard to add a DAC that applies a bit of +- delay trim in one
differential ECL path, with the 10 MHz leg shown by example. A RAM in
the FPGA can map counter states into DAC codes hence time tweaks. So
we can trim 3 to 10 clock near-misses to be almost spot-on, and
multiply the compare rate accordingly. We can have software control
over which edges we use, and how much to time tweak each one. Then we
can trim the RAM data for minimum jitter.

I was going to have a time trim DAC for temperature compensation
anyhow, so this is almost free. The DAC doesn't need to be super fast,
since the near-miss events are fairly scattered in the 1944-state
space.

That could be an improvement, but it seems like a lot of work compared
to using local feedback. OTOH you have more minions than I do.

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Bill Sloman]

On Sunday, 28 September 2014 12:45:29 UTC+10, Tom Miller wrote:

"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:4qie2alha115etc597v39e52nvrtnvav0t@4ax.com...
On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoodboat@yahoo.com
wrote:
On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:
On Tue, 09 Sep 2014 16:54:53 -0700, John Larkin wrote:

<snip>

The 10 MHz reference you might be using as a reference might just be a very
high stability 10 MHz OCXO locked to a 1 PPS GPS or Cs time standard. Your
80 KHz should do just fine with a good OCXO, maybe a double oven model.

John's 10MHz reference is a GPS-disiciplined 10MHz sine wave that is supplied by the laser facility. He got around to telling us this on September 15, five days after he started the thread.

<snip>

--
Bill Sloman, Sydney

 

[Bill Sloman]

On Sunday, 28 September 2014 13:18:23 UTC+10, DecadentLinuxUserNumeroUno wrote:

On Sat, 27 Sep 2014 19:45:17 -0400, rickman <gnuarm@gmail.com> Gave us:

That wouldn't last long. This crowd would get thrown out of any bar I
would want to frequent. lol

Yer just jealous because you can't shoot pool worth a shit, even
though all you drink is soda.

On s.e.d. the "pool" we shoot is electronic design. Rickman isn't one of our star performers, but he does contribute from time to time. You don't seem to do as well, though you aren't a non-participant - like krw - or as fumble-fingered as Jamie.

--
Bill Sloman, Sydney

 

[DecadentLinuxUserNumeroUn]

On Sat, 27 Sep 2014 15:05:45 -0400, rickman <gnuarm@gmail.com> Gave us:

On 9/27/2014 12:58 PM, DecadentLinuxUserNumeroUno wrote:
On Sat, 27 Sep 2014 08:48:53 -0700 (PDT), Bill Sloman
bill.sloman@gmail.com> Gave us:


Inductance isn't necessarily a problem - within limits.


Yeah... like frequency of operation.

That remark you made about data rates and orders of magnitude can be
assigned to your grasp of the effects of inductance at these data rates
and when trying to generate clean modulation constellations.

Your grasp is DOWN a few orders of magnitude. And a couple decades.

It is always nice to see professionals having a technical conversation.
The mutual respect is obvious.

You always keep forgetting. Bill SlowTard IS on the "no quarter ever"
list. ask anyone here who doesn't act just like him.

 

[rickman]

On 9/27/2014 4:29 PM, Maynard A. Philbrook Jr. wrote:

In article <m071qv$95b$2@dont-email.me>, gnuarm@gmail.com says...

On 9/27/2014 12:58 PM, DecadentLinuxUserNumeroUno wrote:
On Sat, 27 Sep 2014 08:48:53 -0700 (PDT), Bill Sloman
bill.sloman@gmail.com> Gave us:


Inductance isn't necessarily a problem - within limits.


Yeah... like frequency of operation.

That remark you made about data rates and orders of magnitude can be
assigned to your grasp of the effects of inductance at these data rates
and when trying to generate clean modulation constellations.

Your grasp is DOWN a few orders of magnitude. And a couple decades.

It is always nice to see professionals having a technical conversation.
The mutual respect is obvious.

I've always said this is the place for the after work bar stop.

That wouldn't last long. This crowd would get thrown out of any bar I
would want to frequent. lol

--

Rick

 

[rickman]

On 9/27/2014 5:26 PM, Phil Hobbs wrote:

On 9/27/2014 3:14 PM, rickman wrote:
On 9/27/2014 1:54 PM, Phil Hobbs wrote:
On 9/26/2014 10:24 PM, rickman wrote:
On 9/26/2014 7:58 PM, Phil Hobbs wrote:
On 9/26/2014 1:57 PM, rickman wrote:
On 9/26/2014 1:13 PM, Phil Hobbs wrote:
On 9/26/2014 10:53 AM, Bill Sloman wrote:
On 26/09/2014 11:08 PM, Phil Hobbs wrote:
On 9/26/2014 3:02 AM, rickman wrote:
On 9/25/2014 10:26 PM, Ralph Barone wrote:
Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
Den torsdag den 25. september 2014 18.10.53 UTC+2 skrev John
Larkin:
On Thu, 25 Sep 2014 09:43:14 +0200, Gerhard Hoffmann
ghf@hoffmann-hochfrequenz.de> wrote:
Am 25.09.2014 um 04:40 schrieb John Larkin:

snip

How about "take 1944 samples, do a DFT, throw out the amplitude
information and run your VCXO from the phase information"?

Yeah, and the calculations can very easily be done to produce
overlapped
results (of any length) on every cycle of the 155.52 MHz clock.
So no
need to wait 12.5 microseconds to close the loop.

There's still the 1944-cycle latency, though, which will make the
loop
unstable if you try to go much faster. The good news is that it
wouldn't have the grotesque output ripple of a bang-bang PD, so it
wouldn't have to be filtered as hard.

There's no intrinsic 1944 sample latency if you are using an A/D
converter to sample the 10MHz reference sine wave at 155.52MHz.

There's nothing magic about FFTs--each channel is equivalent to a
bog
standard FIR filter. The filter has to be causal, so since it's
1944
samples wide, the delay has to be at least half that.

With infinite computational resources you could do a non-linear
least-squares fit of a 10MHz-ish sine wave to anything more than
about
four successive samples - since you can be pretty confident that
you
are
looking at a 10MHz sine wave. With a few as 16 samples - if there
was
hardly any noise - you could probably do well enough to nail John
Larkin's picosecond absolute phase demand.

You keep ignoring drift.


The 10MHz sine wave would be described by four parameters -
frequency,
absolute phase, amplitude and DC offset. The DC offset ought to be
zero,
but A/D converters aren't perfect.

Since John actually wants only about 500Hz bandwidth in his PLL
feedback
path, worrying about a 12.5usec latency implicit in the 1944 sample
repeat cycle is probably not a useful exercise, even if it were
real.

Which it is (972 samples' worth, anyway).


ISTM that the main issues with the B-B loop are: (1) gross PD
ripple;
(b) the huge and poorly controlled gain of the phase detector,
which
will depend critically on the residual wideband jitter of the two
clocks; and (c), that all the wideband jitter of the VCXO will be
aliased down into the fundamental interval.

Any metastability worries can be got round by reclocking the PD
output
from either one of the oscillators, which won't cause significant
extra
latency in an 80-kHz loop. Wrapping the VCXO inside a simple
wideband
fractional-N PLL would improve its phase noise. (Many reasonable
suggestions have been made for that part of the job, of which ISTM
none
will accomplish the required long-term timing stability.)

The residual drift and low-frequency crap could be removed
afterwards,
using the bang-bang PD to control a varactor phase shifter on
the 10
MHz
sine wave input. The combination ought to be pretty impressive.

One would be impressed that he'd got it to work, less impressed by
the
fact that he hadn't been able to recognise the superiority of
any of
the
better schemes that have been proposed here.

Most of which ignore drift. A picosecond is not a long time.


My money's on Gerhard Hoffmann's 200MHz 16-bit A/D converter
sampling at
155.52MHz and feeding a number cruncher embedded in a reasonably
big
programmable logic device. He mentioned a Xilinx Spartan-6

http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/

A pretty big hammer to replace a single D-flop!

I could have sworn there was some other stuff in that design...
another
d-flop to start (fancy ECL stuff, and expensive)... a rather tricky
filter and bunches more. Most of that gets replaced with logic in
the
FPGA, the ADC and a DAC.

man-with-only-a-hammer-alert

The D-flop costs about $5 in unit quantity, which is pretty cheap
for an
FPGA, especially since all the programming effort would be amortized
over 8 whole units.

And the rest??? Doesn't that have NRE design costs?

Not on the same scale at all. One can design a PLL on a napkin in a few
minutes. The parlour tricks are (1) analogue conditioning of the 10
MHz; (2) resampling the divider output to get rid of its jitter and
timing drift; (3) characterization when you're done. All three of those
things still have to be done with the FPGA approach.

Methinks he doth protest *too* much. I also think you are hand waving
now.

Nope. I've done similar things both ways. What exactly did you not
agree with, and why?


Actually the need for analog conditioning the 10 MHz is greatly reduced
in the digital approach as this can be done in the digital domain. There
is *no* need to resample anything in the digital approach.

You have an exaggerated idea of the timing coherence of ADCs and FPGAs
over temperature, then. Logic slows down significantly with increasing
temperature, and a picosecond is not a long time. You may think I'm
arm-waving, but I haven't seen a lot of carefully supported numerical
estimates from you--just a lot of generalities. You also haven't
addressed my point about DSP standing or falling by the exact equal
spacing of the data samples, which ISTM is fatal to your view.



As for the rest, the 10 MHz will have to be cleaned up in analogue
somehow, because otherwise its jitter will show up in the FPGA's
output--the analogy between DSP and real genuine analogue signal
processing stands or falls by the samples being evenly spaced.
Most of
the time that's not such a worry, but for 1 ps timing accuracy, it
most
emphatically is.

Not sure which 10 MHz you are talking about, from the bang bang
detector
or the signal processing based approach. I'm not sure why there would
be a 10 MHz signal in the signal processing approach.

Because that's what you're locking to, of course.

Oh, you mean the reference clock... The DSP can do a lot of "cleaning
up". Once you are in the digital domain this comes without all the
analog vagaries.

How _exactly_ would you clean up the clock you're locking to in the
digital domain, without depending on the reference or VCXO for
essentially ideal sampling? Analogue bandpass filters, I understand.
AFAICT your proposal is "pay no attention to the man behind the curtain!"

I don't understand your objection. The 10 MHz is sampled and can be
filtered digitally before being phase detected or even as part of the PD
depending on what you need. Why would that need to be done in the
analog domain? What do you think is happening when it is sampled by the
ADC?

Are you worried that there is noise above the nyquist rate? Yes,
antialias would need to be done in the analog domain, but with a 155 MHz
sample rate you should be able to do pretty well with a simple filter
having little impact on the ref clock.

--

Rick

 

On Saturday, September 27, 2014 9:24:33 PM UTC-4, John Larkin wrote:

On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoo...@yahoo.com wrote:
On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:

[time-trim DAC before 10MHz digitizer]

That's the time equivalent of adding a ripple-removing waveform to the
phase comparator output.

I don't think so. The bangbang pd only acquires a limited amount of
information, namely 80 Kbits/sec. There's nothing we can add
downstream of that to increase the info (or decrease the noise.) If we
enable more comparison edges, we get more info to work with; or. for
the same loop filter, less noise at its output.

I meant that you could, alternatively, pass those same reference edges
through the phase detector, producing a periodic ripple, and cancel
that (and the artifacts from unequal sampling intervals) with a
periodic ripple-cancelling waveform.

IOW, a more complicated version of cancelling a fractional-n scheme's
ripple by summing a waveform in after the phase detector.

Your idea--doing it in the time domain--is cleaner.

The extension is to measure the timing of arbitrary 155.52 MHz clock
edges--not just the ones that line up with 10MHz edges every 12.5uS--and
process those.

My idea of locking a 9x VCXO to the 10MHz--thereby creating 9x as many
comparison edges--has the problem that the 90MHz PLL adds a phase offset
w.r.t the original 10MHz.

However small, that's an added error (and, the extra comparison edges aren't helping if they're not in the right places!). Plus, any offset could drift.

FWIW, 1 degree of phase-detector error at 10MHz = 280pS!


Cheers,
James

 

[Bill Sloman]

On 28/09/2014 4:01 AM, Phil Hobbs wrote:

On 9/26/2014 10:57 PM, Bill Sloman wrote:
On 27/09/2014 9:58 AM, Phil Hobbs wrote:
On 9/26/2014 1:57 PM, rickman wrote:
On 9/26/2014 1:13 PM, Phil Hobbs wrote:
On 9/26/2014 10:53 AM, Bill Sloman wrote:
On 26/09/2014 11:08 PM, Phil Hobbs wrote:
On 9/26/2014 3:02 AM, rickman wrote:
On 9/25/2014 10:26 PM, Ralph Barone wrote:
Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
Den torsdag den 25. september 2014 18.10.53 UTC+2
skrev John Larkin:
On Thu, 25 Sep 2014 09:43:14 +0200, Gerhard
Hoffmann <ghf@hoffmann-hochfrequenz.de> wrote:
Am 25.09.2014 um 04:40 schrieb John Larkin:

<snip>

Which it is (972 samples' worth, anyway).

Only if you let yourself be jammed into the computational
straight-jacket of the DFT or FFT.

(a) that is what we were discussing, and (b) causality is not only a
problem with DFTs, it's a generic problem common to all digital filters.

The DFT is not the only way of extracting phase information. My thought
experiment - of using a non-linear multiparameter least squares curve
fitting program to extract four parameters - frequency, absolute phase,
magnitude and DC offset from an arbitrary set of more than four
observations makes the point that you can't invoke causality as an
excuse for sloppy thinking.

ISTM that the main issues with the B-B loop are: (1) gross
PD ripple; (b) the huge and poorly controlled gain of the
phase detector, which will depend critically on the
residual wideband jitter of the two clocks; and (c), that
all the wideband jitter of the VCXO will be aliased down
into the fundamental interval.

Any metastability worries can be got round by reclocking
the PD output from either one of the oscillators, which
won't cause significant extra latency in an 80-kHz loop.
Wrapping the VCXO inside a simple wideband fractional-N
PLL would improve its phase noise. (Many reasonable
suggestions have been made for that part of the job, of
which ISTM none will accomplish the required long-term
timing stability.)

The residual drift and low-frequency crap could be removed
afterwards, using the bang-bang PD to control a varactor
phase shifter on the 10 MHz sine wave input. The
combination ought to be pretty impressive.

One would be impressed that he'd got it to work, less
impressed by the fact that he hadn't been able to recognise
the superiority of any of the better schemes that have been
proposed here.

Most of which ignore drift. A picosecond is not a long time.

They don't. I've got no idea where you got that idea.

Um, from reading the thread? You need few-ppm analogue stability in all
parameters to get 1 ps stability out of a 100 ns reference period.
Logic slows down with increasing temperature, phase detector offsets
drift, filter components drift, you name it. The more of that stuff you
have strung together, the worse it gets.

But this only matters in the signal path leading up to the
mixing/sampling stage. The time you take to process the data you've
sampled then only matters to the extent that it influences the stability
of the PLL feedback path, and you can shape the frequency response of
the feedback loop to cope with quite long delays.

My money's on Gerhard Hoffmann's 200MHz 16-bit A/D converter
sampling at 155.52MHz and feeding a number cruncher
embedded in a reasonably big programmable logic device. He
mentioned a Xilinx Spartan-6

http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/



snip

As for the rest, the 10 MHz will have to be cleaned up in analogue
somehow, because otherwise its jitter will show up in the FPGA's
output--the analogy between DSP and real genuine analogue signal
processing stands or falls by the samples being evenly spaced. Most
of the time that's not such a worry, but for 1 ps timing accuracy,
it most emphatically is.

The samples will be as evenly spaced as the clock edges coming out
of the 155.52MHz VCXO - which will be very evenly spaced indeed.

We hope. That's the problem we're trying to solve, of course.

No it isn't. The output from a 155.52MHz VCXO is going to be very
regular. The problem to be solved is to get the frequency to be exactly
155.52MHz vis-a-vis the 10MHz reference sine wave - the right regularity.

The fact that 155.52MHz is not a simple multiple of 10MHz is going
to complicate the digital signal processing, which is why you want to
do it a decent-sized and quick FPGA, but that's a number-crunching
exercise, and The A/D converter approach gives you lots of good
numbers to crunch.

Sure. But the ADC's jitter spec is at constant temperature, no?

It's sampling delay specification - if it has got one - is likely to
include some temperature dependence. Any sampling/mixing system is
going to have some kind of temperature dependent sampling delay.

200MHz A/D converters use the same kind of fast transistors as ECLinPS,
and the advantage of the A/D converter is that is needs rather less
buffering prior to sampling than most of the schemes John has been
thinking about.

There will be no "jitter" on the 10MHz waveform - unless the
GSP-disciplining is done very crudely indeed.

Doesn't have to be very crude to be bigger than a picosecond!

In the laser facility context it does.

<snipped currently irrelevant content>

--
Bill Sloman, Sydney

 

[Bill Sloman]

On 28/09/2014 5:15 AM, John Larkin wrote:

On Sat, 27 Sep 2014 14:01:07 -0400, Phil Hobbs
hobbs@electrooptical.net> wrote:

On 9/26/2014 10:57 PM, Bill Sloman wrote:
On 27/09/2014 9:58 AM, Phil Hobbs wrote:
On 9/26/2014 1:57 PM, rickman wrote:
On 9/26/2014 1:13 PM, Phil Hobbs wrote:
On 9/26/2014 10:53 AM, Bill Sloman wrote:
On 26/09/2014 11:08 PM, Phil Hobbs wrote:
On 9/26/2014 3:02 AM, rickman wrote:
On 9/25/2014 10:26 PM, Ralph Barone wrote:
Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
Den torsdag den 25. september 2014 18.10.53 UTC+2
skrev John Larkin:
On Thu, 25 Sep 2014 09:43:14 +0200, Gerhard
Hoffmann <ghf@hoffmann-hochfrequenz.de> wrote:
Am 25.09.2014 um 04:40 schrieb John Larkin:

<snip>

Which it is (972 samples' worth, anyway).

Only if you let yourself be jammed into the computational
straight-jacket of the DFT or FFT.

(a) that is what we were discussing, and (b) causality is not only a
problem with DFTs, it's a generic problem common to all digital filters.

Causality is one of those cool, over-riding, simplifying things like
conservation of energy. The ideal lowpass filter, and its analog and
digital Butterworth approximations, is a beautiful example of the
cruelty of causality.

But "causality" has nothing to do with the question of whether you need
to be sampling at an integral multiple of the frequency you are looking for.

My thought experiment - invoking non-linear mulitparamater least squares
curve fitting as a technique for extracting four parameters - amplitude,
frequency, DC offset and absolute phase - to fit a sine wave to an
arbitrary set of of more than four observations - makes the point
perfectly clearly.

<snip>

Most of which ignore drift. A picosecond is not a long time.

They don't. I've got no idea where you got that idea.

Um, from reading the thread? You need few-ppm analogue stability in all
parameters to get 1 ps stability out of a 100 ns reference period.
Logic slows down with increasing temperature, phase detector offsets
drift, filter components drift, you name it. The more of that stuff you
have strung together, the worse it gets.

Sure - but what's that got to do with Gerhard Hoffmann's proposition?
His has the virtue of of minimising the number of components in the
signal path before sampling/mixing. Sampling/mixing converts the data
you want to DC, and subsequent processing is outside the signal path.
You've got to do it fast enough to keep the PLL feedback loop stable and
- ideally - critically damped, but you only want 500Hz bandwidth around
that loop.

Yeah. Anything with a filter, or an ADC, or a DAC, in the critical
path is going to have serious temperature drift issues.

This is where the A/D converter proposition looks good. No comparator,
nowhere near as much broad-band filtering inthe 10MHz reference path.

My money's on Gerhard Hoffmann's 200MHz 16-bit A/D converter
sampling at 155.52MHz and feeding a number cruncher
embedded in a reasonably big programmable logic device. He
mentioned a Xilinx Spartan-6

http://www.xilinx.com/products/silicon-devices/fpga/spartan-6/

snip

As for the rest, the 10 MHz will have to be cleaned up in analogue
somehow,

Cleaning it up in the digital domain will probably work at least as well.

My imagined non-linear multi-parameter least square curve fitting
process would reject any non-10MHz sine wave component as noise.

because otherwise its jitter will show up in the FPGA's
output--the analogy between DSP and real genuine analogue signal
processing stands or falls by the samples being evenly spaced. Most
of the time that's not such a worry, but for 1 ps timing accuracy,
it most emphatically is.

The samples will be as evenly spaced as the clock edges coming out
of the 155.52MHz VCXO - which will be very evenly spaced indeed.

We hope. That's the problem we're trying to solve, of course.

The fact that 155.52MHz is not a simple multiple of 10MHz is going
to complicate the digital signal processing, which is why you want to
do it a decent-sized and quick FPGA, but that's a number-crunching
exercise, and The A/D converter approach gives you lots of good
numbers to crunch.

Sure. But the ADC's jitter spec is at constant temperature, no?

Not just jitter, but aperture drift vs temp. That is generally not
specified. ADCs do often spec input offset vs temp, and it's mediocre
for fast ADCs, which incidentally tend to run hot. We use the
LTC2242-12 at 250 MHz, and we heat sink it from above and below. And
the danged thing costs almost $60.

But a fast A/D converter tends to be a collection of comparators, and
all your schemes seem to put a comparator on the 10MHz reference
sine-wave to convert it to the square wave you can sample.

You aren't exactly gagging at a gnat and swallowing an elephant, but you
do seem to be remarkably worried about the propagation delay in the A/D
converter, while ignoring the propagation delay in your comparator, not
to mention the time delay in the relatively narrow-band band-pass filter
you are going to have to put in front of it.

There will be no "jitter" on the 10MHz waveform - unless the
GSP-disciplining is done very crudely indeed.

Doesn't have to be very crude to be bigger than a picosecond!

An ideal 5 volt p-p 10 MHz sine wave, into a real-world ECL
comparator, will have a slope of 155 uv/ps. If the comparator noise is
10 nv/rthz and we assume a working bandwidth of 2 GHz, the effective
comparator noise is about 500 uv RMS, so the jitter should be a few ps
RMS, which looks OK without further effort. Drift is a bigger concern,
especially if I have an input bandpass filter to remove fuzzies.

That's the advantage of the A/D converter approach - no comparator and
most of the filtering is moved to the digital domain, after the sampling
has happened, so there's no time delay in the digital filter.

--
Bill Sloman, Sydney

 

[John Larkin]

On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoodboat@yahoo.com
wrote:

On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:
On Tue, 09 Sep 2014 16:54:53 -0700, 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.

Consider this:

If we square up the 10 MHz reference, and the 155.52 MHz oscillator
were somehow locked to it, the edges line up at 80 KHz, namely every
12.5 us. So the bangbang phase detector only delivers one bit of
information (namely early/late) 80K times per second. That may be too
noisy to discipline a cheap 155 MHz VCXO.

Why not just use a non-cheap 155.52 MHz VCXO?

There aren't all that many 155.52's around.

If the VCXO is very good you won't need to correct its phase very
often. (In fact you can't--its rock won't let you.)

The typical VCXO has about a 10 KHz modulation bandwidth. That's more
than I'll need, since even the cheapies have low jitter out into the
roughly 1 ms range.

A 1Hz error at 155.52 MHz is 80fs phase error per 80 kHz comparison
cycle.

If we have a counter mod 1944, to make 80K from 155.52 MHz, assume we
use state 0 to enable the bangbang phase comparison against the 10
MHz. We servo to zero time error. But, as noted, there are other
counter states that, if used to enable the d-flop, are near-misses to
10 MHz reference edges. There are two or three states that are within
+-50 ps, and maybe another 6 or so within about 100 ps.

So, we could do this:

https://dl.dropboxusercontent.com/u/53724080/Circuits/Oscillators/Multi_Bang_PLL.JPG

It's not hard to add a DAC that applies a bit of +- delay trim in one
differential ECL path, with the 10 MHz leg shown by example. A RAM in
the FPGA can map counter states into DAC codes hence time tweaks. So
we can trim 3 to 10 clock near-misses to be almost spot-on, and
multiply the compare rate accordingly. We can have software control
over which edges we use, and how much to time tweak each one. Then we
can trim the RAM data for minimum jitter.

I was going to have a time trim DAC for temperature compensation
anyhow, so this is almost free. The DAC doesn't need to be super fast,
since the near-miss events are fairly scattered in the 1944-state
space.

That's the time equivalent of adding a ripple-removing waveform to the
phase comparator output.

I don't think so. The bangbang pd only acquires a limited amount of
information, namely 80 Kbits/sec. There's nothing we can add
downstream of that to increase the info (or decrease the noise.) If we
enable more comparison edges, we get more info to work with; or. for
the same loop filter, less noise at its output.

Doing it for tiny increments at the 10MHz comparator is better than
my initial while-jogging brainstorm of analog ramps for big increments.

Seems promising.

A Q=1e7 low-drift 155.52MHz resonator and some low noise processing would
eliminate a lot of this finagling.

I was going to have a time trim DAC anyhow. If I feed it from the
FPGA, and not from the uP, and use a middling fast DAC, I have the
option to do this if I need it.


--

John Larkin Highland Technology, Inc

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

 

[rickman]

On 9/27/2014 8:11 PM, Bill Sloman wrote:

On Sunday, 28 September 2014 08:33:53 UTC+10, John Larkin wrote:
On Tue, 09 Sep 2014 16:54:53 -0700, John Larkin
jlarkin@highlandtechnology.com> wrote:

snip

I was going to have a time trim DAC for temperature compensation
anyhow, so this is almost free. The DAC doesn't need to be super fast,
since the near-miss events are fairly scattered in the 1944-state
space.

Your "time-trim DAC" probably ought to be an MC100EP195, as has been proposed earlier.

http://www.onsemi.com/pub_link/Collateral/MC10EP195-D.PDF

The catch is visible in Figure 4 of that data sheet. While the part offers a nominally 10psec granularity over a delay range which starts anywhere from 1.65 to 2.75nsec and can be as long as 9.5 to 15.8nsec, the actual delay varies from part to part, and with temperature. The temperature drift is about 15psec/degree Celcius on the longest delay.

If you use the part to set up a mark-to-space ratio at constant frequency and digitise the DC value of the filtered waveform, you can calibrate the delay with considerable precision and very rapidly - when I worked out a scheme it looked as if we could have measured every delay within a few milliseconds, though that was for the MC100E195 which was a 7-bit rather than an 10-bit device.

That is not what he has drawn on his napkin. He seems to be summing a
bias voltage to the differential 10 MHz square wave to adjust the point
on the rising edge that crosses the threshold in the D-FF. This is
applying assumptions to the analog nature of both the D-FF inputs and
the comparator outputs. Clearly this is intended to be a fine
adjustment as it can only work over the rise time of the digital
differential signal.

The device you link to is one (or one very like it) used by a friend in
a unit he built for the Naval Observatory to provide a 1 PPS output from
their newest atomic clock. Seems this clock uses a 100 MHz output as
it's timing reference.

--

Rick

 

[rickman]

On 9/27/2014 11:18 PM, DecadentLinuxUserNumeroUno wrote:

On Sat, 27 Sep 2014 19:45:17 -0400, rickman <gnuarm@gmail.com> Gave us:

That wouldn't last long. This crowd would get thrown out of any bar I
would want to frequent. lol


Yer just jealous because you can't shoot pool worth a shit, even
though all you drink is soda.

Actually I do pretty well at the pool table although I'm a bit rusty.
Who was the guy who bragged about being about to shoot without touching
the table? That is out of my league.

--

Rick

 

[Tom Miller]

"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:mbue2a9mcv8taar0tmjq0dp395l097ues3@4ax.com...

On Sat, 27 Sep 2014 22:45:29 -0400, "Tom Miller"
tmiller11147@verizon.net> wrote:


"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:4qie2alha115etc597v39e52nvrtnvav0t@4ax.com...
On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoodboat@yahoo.com
wrote:

On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:
On Tue, 09 Sep 2014 16:54:53 -0700, 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.

Consider this:

If we square up the 10 MHz reference, and the 155.52 MHz oscillator
were somehow locked to it, the edges line up at 80 KHz, namely every
12.5 us. So the bangbang phase detector only delivers one bit of
information (namely early/late) 80K times per second. That may be too
noisy to discipline a cheap 155 MHz VCXO.

Why not just use a non-cheap 155.52 MHz VCXO?

There aren't all that many 155.52's around.



If the VCXO is very good you won't need to correct its phase very
often. (In fact you can't--its rock won't let you.)

The typical VCXO has about a 10 KHz modulation bandwidth. That's more
than I'll need, since even the cheapies have low jitter out into the
roughly 1 ms range.


A 1Hz error at 155.52 MHz is 80fs phase error per 80 kHz comparison
cycle.

If we have a counter mod 1944, to make 80K from 155.52 MHz, assume we
use state 0 to enable the bangbang phase comparison against the 10
MHz. We servo to zero time error. But, as noted, there are other
counter states that, if used to enable the d-flop, are near-misses to
10 MHz reference edges. There are two or three states that are within
+-50 ps, and maybe another 6 or so within about 100 ps.

So, we could do this:

https://dl.dropboxusercontent.com/u/53724080/Circuits/Oscillators/Multi_Bang_PLL.JPG

It's not hard to add a DAC that applies a bit of +- delay trim in one
differential ECL path, with the 10 MHz leg shown by example. A RAM in
the FPGA can map counter states into DAC codes hence time tweaks. So
we can trim 3 to 10 clock near-misses to be almost spot-on, and
multiply the compare rate accordingly. We can have software control
over which edges we use, and how much to time tweak each one. Then we
can trim the RAM data for minimum jitter.

I was going to have a time trim DAC for temperature compensation
anyhow, so this is almost free. The DAC doesn't need to be super fast,
since the near-miss events are fairly scattered in the 1944-state
space.

That's the time equivalent of adding a ripple-removing waveform to the
phase comparator output.

I don't think so. The bangbang pd only acquires a limited amount of
information, namely 80 Kbits/sec. There's nothing we can add
downstream of that to increase the info (or decrease the noise.) If we
enable more comparison edges, we get more info to work with; or. for
the same loop filter, less noise at its output.



Doing it for tiny increments at the 10MHz comparator is better than
my initial while-jogging brainstorm of analog ramps for big increments.

Seems promising.

A Q=1e7 low-drift 155.52MHz resonator and some low noise processing
would
eliminate a lot of this finagling.

I was going to have a time trim DAC anyhow. If I feed it from the
FPGA, and not from the uP, and use a middling fast DAC, I have the
option to do this if I need it.


--


The 10 MHz reference you might be using as a reference might just be a
very
high stability 10 MHz OCXO locked to a 1 PPS GPS or Cs time standard. Your
80 KHz should do just fine with a good OCXO, maybe a double oven model.

The 10M comes from a Symmetricom SyncServer 250, which the customer
will provide. The 10M is a single-ended, BNC connectorized, sine wave.
I assume there will be some ground loop noise and EMI fuzz and such,
picked up between boxes, so there will be a bit of jitter on the 10M.
My PLL can probably clean that up.


--

Looking at the spec sheet for the S250, it states that it chooses in order
GPS, IRIG-B, _1PPS_, then 10 MHz for the reference. I guess it outputs a
cleaned up 10 MHz for the output. I did not see any spec for the PN on the
10 MHz so you might want to check it just in case. I would guess it does use
the 1 PPS from the GPS RX as its reference in normal mode. If all the other
sources fail, it locks to the external 10 MHz.

The main market for the S250 is for NTP service.


Good luck, hope to hear the end result.


tm

 

[rickman]

On 9/28/2014 12:08 AM, dagmargoodboat@yahoo.com wrote:

On Saturday, September 27, 2014 9:24:33 PM UTC-4, John Larkin wrote:
On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoo...@yahoo.com wrote:
On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:

[time-trim DAC before 10MHz digitizer]

That's the time equivalent of adding a ripple-removing waveform to the
phase comparator output.

I don't think so. The bangbang pd only acquires a limited amount of
information, namely 80 Kbits/sec. There's nothing we can add
downstream of that to increase the info (or decrease the noise.) If we
enable more comparison edges, we get more info to work with; or. for
the same loop filter, less noise at its output.

I meant that you could, alternatively, pass those same reference edges
through the phase detector, producing a periodic ripple, and cancel
that (and the artifacts from unequal sampling intervals) with a
periodic ripple-cancelling waveform.

IOW, a more complicated version of cancelling a fractional-n scheme's
ripple by summing a waveform in after the phase detector.

Your idea--doing it in the time domain--is cleaner.

I think it is a red herring. The vague and general statement of more
frequent sampling having "more" information is off the mark and of no
value. Sampling the phase more often will give you information of
higher frequency content in the phase deviations. I believe the
frequency control signal is intended to be filtered to a 500 Hz
bandwidth. Of what value is more frequent sampling of the phase error
then? Any higher frequency content of the error signal will just be
filtered out.

If the bandwidth of the control signal is just 500 Hz an 80 kHz sample
rate should be plenty fast enough to produce enough "information".

The extension is to measure the timing of arbitrary 155.52 MHz clock
edges--not just the ones that line up with 10MHz edges every 12.5uS--and
process those.

My idea of locking a 9x VCXO to the 10MHz--thereby creating 9x as many
comparison edges--has the problem that the 90MHz PLL adds a phase offset
w.r.t the original 10MHz.

However small, that's an added error (and, the extra comparison edges aren't helping if they're not in the right places!). Plus, any offset could drift.

I believe that phase error can be minimized . The 90 MHz divided output
can be resynced to the 90 MHz clock by an ECL FF and the 10 MHz
reference can be divided by two in the same type of ECL FF. Now your
reference frequency at the PD is 5 MHz rather than 10, but the same
phase offset (or very close offsets) are in each path leading to the PD.

But why does the phase of the 90 MHz clock matter? I think what is
important is the stability of the phase of the 90 MHz clock.

FWIW, 1 degree of phase-detector error at 10MHz = 280pS!


Cheers,
James

--

Rick

 

[John Larkin]

On Sat, 27 Sep 2014 21:08:28 -0700 (PDT), dagmargoodboat@yahoo.com
wrote:

On Saturday, September 27, 2014 9:24:33 PM UTC-4, John Larkin wrote:
On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoo...@yahoo.com wrote:
On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:

[time-trim DAC before 10MHz digitizer]

That's the time equivalent of adding a ripple-removing waveform to the
phase comparator output.

I don't think so. The bangbang pd only acquires a limited amount of
information, namely 80 Kbits/sec. There's nothing we can add
downstream of that to increase the info (or decrease the noise.) If we
enable more comparison edges, we get more info to work with; or. for
the same loop filter, less noise at its output.

I meant that you could, alternatively, pass those same reference edges
through the phase detector, producing a periodic ripple, and cancel
that (and the artifacts from unequal sampling intervals) with a
periodic ripple-cancelling waveform.

I don't think that works. The edges that are 100 ps early always make
a 0, and the edges that are 100 ps late always make a 1, so they add
ripple but no useful phase-error information. They only help if they
are moved into the zero-time window.

The single-test bangbang PD has a transfer function like

---------------------
/
/
/
---------
^
clk


so we want to shift the new non-phase-0 tests in time so that they add
in their linear ranges.


---------------------
/
/
/
---------


---------------------
/
/
/
---------


---------------------
/
/
/
---------
^
clk

not


---------------------
/
/
/
---------


---------------------
/
/
/
---------------


---------------------
/
/
/
---------------------
^
clk


The reason I like my idea, aside from it being my idea, is that it's
simple, flexible, and I know it will work.


--

John Larkin Highland Technology, Inc

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

 

[rickman]

On 9/27/2014 11:26 PM, Bill Sloman wrote:

On Sunday, 28 September 2014 13:18:23 UTC+10, DecadentLinuxUserNumeroUno wrote:
On Sat, 27 Sep 2014 19:45:17 -0400, rickman <gnuarm@gmail.com> Gave us:

That wouldn't last long. This crowd would get thrown out of any bar I
would want to frequent. lol

Yer just jealous because you can't shoot pool worth a shit, even
though all you drink is soda.

On s.e.d. the "pool" we shoot is electronic design. Rickman isn't one of our star performers, but he does contribute from time to time. You don't seem to do as well, though you aren't a non-participant - like krw - or as fumble-fingered as Jamie.

Interesting analogy. If this were a pool hall, I'd likely find a place
where people follow the rules more and know how to be courteous to one
another. But this isn't a pool hall. Heck, if it were there are a
number of folks here who would have been banned long ago. In a pool
hall no one cares how good you are if you only come to make trouble all
the time.

--

Rick

 

[John Larkin]

On Sat, 27 Sep 2014 22:45:29 -0400, "Tom Miller"
<tmiller11147@verizon.net> wrote:

"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:4qie2alha115etc597v39e52nvrtnvav0t@4ax.com...
On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoodboat@yahoo.com
wrote:

On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:
On Tue, 09 Sep 2014 16:54:53 -0700, 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.

Consider this:

If we square up the 10 MHz reference, and the 155.52 MHz oscillator
were somehow locked to it, the edges line up at 80 KHz, namely every
12.5 us. So the bangbang phase detector only delivers one bit of
information (namely early/late) 80K times per second. That may be too
noisy to discipline a cheap 155 MHz VCXO.

Why not just use a non-cheap 155.52 MHz VCXO?

There aren't all that many 155.52's around.



If the VCXO is very good you won't need to correct its phase very
often. (In fact you can't--its rock won't let you.)

The typical VCXO has about a 10 KHz modulation bandwidth. That's more
than I'll need, since even the cheapies have low jitter out into the
roughly 1 ms range.


A 1Hz error at 155.52 MHz is 80fs phase error per 80 kHz comparison
cycle.

If we have a counter mod 1944, to make 80K from 155.52 MHz, assume we
use state 0 to enable the bangbang phase comparison against the 10
MHz. We servo to zero time error. But, as noted, there are other
counter states that, if used to enable the d-flop, are near-misses to
10 MHz reference edges. There are two or three states that are within
+-50 ps, and maybe another 6 or so within about 100 ps.

So, we could do this:

https://dl.dropboxusercontent.com/u/53724080/Circuits/Oscillators/Multi_Bang_PLL.JPG

It's not hard to add a DAC that applies a bit of +- delay trim in one
differential ECL path, with the 10 MHz leg shown by example. A RAM in
the FPGA can map counter states into DAC codes hence time tweaks. So
we can trim 3 to 10 clock near-misses to be almost spot-on, and
multiply the compare rate accordingly. We can have software control
over which edges we use, and how much to time tweak each one. Then we
can trim the RAM data for minimum jitter.

I was going to have a time trim DAC for temperature compensation
anyhow, so this is almost free. The DAC doesn't need to be super fast,
since the near-miss events are fairly scattered in the 1944-state
space.

That's the time equivalent of adding a ripple-removing waveform to the
phase comparator output.

I don't think so. The bangbang pd only acquires a limited amount of
information, namely 80 Kbits/sec. There's nothing we can add
downstream of that to increase the info (or decrease the noise.) If we
enable more comparison edges, we get more info to work with; or. for
the same loop filter, less noise at its output.



Doing it for tiny increments at the 10MHz comparator is better than
my initial while-jogging brainstorm of analog ramps for big increments.

Seems promising.

A Q=1e7 low-drift 155.52MHz resonator and some low noise processing would
eliminate a lot of this finagling.

I was going to have a time trim DAC anyhow. If I feed it from the
FPGA, and not from the uP, and use a middling fast DAC, I have the
option to do this if I need it.


--


The 10 MHz reference you might be using as a reference might just be a very
high stability 10 MHz OCXO locked to a 1 PPS GPS or Cs time standard. Your
80 KHz should do just fine with a good OCXO, maybe a double oven model.

The 10M comes from a Symmetricom SyncServer 250, which the customer
will provide. The 10M is a single-ended, BNC connectorized, sine wave.
I assume there will be some ground loop noise and EMI fuzz and such,
picked up between boxes, so there will be a bit of jitter on the 10M.
My PLL can probably clean that up.


--

John Larkin Highland Technology, Inc

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

 

[Tom Miller]

"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:4qie2alha115etc597v39e52nvrtnvav0t@4ax.com...

On Sat, 27 Sep 2014 16:40:59 -0700 (PDT), dagmargoodboat@yahoo.com
wrote:

On Saturday, September 27, 2014 6:33:53 PM UTC-4, John Larkin wrote:
On Tue, 09 Sep 2014 16:54:53 -0700, 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.

Consider this:

If we square up the 10 MHz reference, and the 155.52 MHz oscillator
were somehow locked to it, the edges line up at 80 KHz, namely every
12.5 us. So the bangbang phase detector only delivers one bit of
information (namely early/late) 80K times per second. That may be too
noisy to discipline a cheap 155 MHz VCXO.

Why not just use a non-cheap 155.52 MHz VCXO?

There aren't all that many 155.52's around.



If the VCXO is very good you won't need to correct its phase very
often. (In fact you can't--its rock won't let you.)

The typical VCXO has about a 10 KHz modulation bandwidth. That's more
than I'll need, since even the cheapies have low jitter out into the
roughly 1 ms range.


A 1Hz error at 155.52 MHz is 80fs phase error per 80 kHz comparison
cycle.

If we have a counter mod 1944, to make 80K from 155.52 MHz, assume we
use state 0 to enable the bangbang phase comparison against the 10
MHz. We servo to zero time error. But, as noted, there are other
counter states that, if used to enable the d-flop, are near-misses to
10 MHz reference edges. There are two or three states that are within
+-50 ps, and maybe another 6 or so within about 100 ps.

So, we could do this:

https://dl.dropboxusercontent.com/u/53724080/Circuits/Oscillators/Multi_Bang_PLL.JPG

It's not hard to add a DAC that applies a bit of +- delay trim in one
differential ECL path, with the 10 MHz leg shown by example. A RAM in
the FPGA can map counter states into DAC codes hence time tweaks. So
we can trim 3 to 10 clock near-misses to be almost spot-on, and
multiply the compare rate accordingly. We can have software control
over which edges we use, and how much to time tweak each one. Then we
can trim the RAM data for minimum jitter.

I was going to have a time trim DAC for temperature compensation
anyhow, so this is almost free. The DAC doesn't need to be super fast,
since the near-miss events are fairly scattered in the 1944-state
space.

That's the time equivalent of adding a ripple-removing waveform to the
phase comparator output.

I don't think so. The bangbang pd only acquires a limited amount of
information, namely 80 Kbits/sec. There's nothing we can add
downstream of that to increase the info (or decrease the noise.) If we
enable more comparison edges, we get more info to work with; or. for
the same loop filter, less noise at its output.



Doing it for tiny increments at the 10MHz comparator is better than
my initial while-jogging brainstorm of analog ramps for big increments.

Seems promising.

A Q=1e7 low-drift 155.52MHz resonator and some low noise processing would
eliminate a lot of this finagling.

I was going to have a time trim DAC anyhow. If I feed it from the
FPGA, and not from the uP, and use a middling fast DAC, I have the
option to do this if I need it.


--

The 10 MHz reference you might be using as a reference might just be a very
high stability 10 MHz OCXO locked to a 1 PPS GPS or Cs time standard. Your
80 KHz should do just fine with a good OCXO, maybe a double oven model.

Can you get someone that makes 10 MHz OCXOs to make one with a 17.28 MHz
rock and then do a X9 multiplier to get your 155.52 MHz clock? The 17.28 can
be divided by 216 to get a 50% DC output for the phase comparison. Lock it
up with a slow loop and the PN should be very low.

Be a fun thing to whip up and test.