PLL tricks

John Larkin <jlarkin@highlandtechnology.com> wrote:

The GPS box gives me 10 MHz and 1 PPS references, and an occasional
Ethernet message will give me time to within 1 second.

This may fall in the category of grandmothers and eggs, but here goes:

The GPS module will have a local clock in the few tens of MHz range.
One that I know about had to put the 1PPS edge on one of its local clock
edges, instead of exactly at the start of the second. For high
precision, you have to take this into account. The one I used could
tell you (via its serial port) the offset between the most recent 1PPS
pulse and when the second actually started, so you can apply a
correction. This had to happen for every single 1PPS edge.

It's entirely possible that the GPS module you have can send the 1PPS
exactly on time, but it might be worth checking.

Matt Roberds

 

[Jan Panteltje]

On a sunny day (Tue, 16 Sep 2014 00:39:45 +0200) it happened Gerhard Hoffmann
<ghf@hoffmann-hochfrequenz.de> wrote in <c7p85hF8ojU1@mid.individual.net>:

On 9/15/2014 2:40 PM, Jan Panteltje wrote:

I think this is nice:
http://www.arrl.org/files/file/Technology/ard/rohde94.pdf
I always use JFET oscillators.

I almost never do. Bipolars are much more predictable.

That is is true,
but even then I found these JFET oscilators are very stable and noise free.
You can use those in parallel too:
http://panteltje.com/pub/lighting_a_LED_with_a_candle_IMG_3604.GIF
Not exactly a 'low noise' application,
but for sure a 'low voltage application'.
http://panteltje.com/pub/lighting_a_LED_with_a_candle_setup_IMG_3607.GIF

 

[Jasen Betts]

On 2014-09-15, Piotr Wyderski <peter.pan@neverland.mil> wrote:

Gerhard Hoffmann wrote:

With a BCD DDS your step size can be f_clock / 10e6 and that
that is an advantage if you need a frequency that can be
exactly written in a few decimal digits.

IMHO you don't need to implement the entire counter in BCD.
All you need is a binary counter + a simple compare/reset
circuit to reset the counter after 10e6 steps. The representation
should have no influence on the operating principle. Am I wrong?

Absolutely. it's not a counter. it's an accumulator, what you need is
overflow on adding that perform the modulus operation. I can think of
a coule of different ways to fake that by adding extra "add" steps,
or using different step sizes based on a value comparitor (like the
overflow flag)

However if you've got enough memory for a full wave table (and aren't
using cordic or some other computational method) you could store the
values in the order encountered at your desired step size (if you only
want a single step size) and then, as you propose) use a counter with
a limit reset.

--
umop apisdn


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

 

[Bill Sloman]

On Wednesday, 17 September 2014 00:17:52 UTC+10, John Larkin wrote:

On Tue, 16 Sep 2014 00:31:03 -0400, rickman <gnuarm@gmail.com> wrote:
On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:
On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?

The jitter that matters is what comes out of the VCXO. That is
determined by the VCXO's open-loop jitter spectrum, reduced by the
feedback loop at lower frequencies. There's an analog lowpass filter
in the feedback loop whose unity-gain bandwidth will be roughly 500
Hz. Picosecond jitter in the phase detector path will not make it
through that lowpass filter. What does get through the filter is the
statistical 1/0 decisions of the PD flipflop, which, barring math
tricks, get made at 80 KHz.

If you use a product detector, it isn't quite as statistical, and you can sensibly detect at 10MHz, even with franctional-N approximation to 10MHz.

A DDS approximation to 10MHz would be a whole lot closer, and the systematic deviations you'd have to average out even smaller.

As the XO gets more expensive, the lowpass filter cutoff frequency can
be reduced. That tradeoff is the original subject of the thread.

"Jitter filter" aka "clock cleanup" is a common concept. I expect the
155.52MHz clock to have a lot less time jitter than the 10 MHz reference.

A few ps jitter around the phase detector flop won't matter.

Provided that there enough samples - and the error being averaged is small enough - for the random noise to average to less than a picosecond in your 2msec integrating time.

From this point of view, a bang-bang detector is not a good idea. The random signal you are averaging is either 1 or 0, which is to say either + or -50nsec. With a product detector the random offsets you are averaging are going to be smaller - of the order of a 1psec in 100nsec (if your analog noise levels are low enough).

With a fractional-N divider and a product detector you would get non-random offsets up to 6.4nsec but they can be guaranteed to average to zero over any 12.5usec interval, which is a lot less than 2msec

Jitter at the PD flop essentially reduces the gain (measured in
volts/ps) of the phase detector.

Only in a bang-bang detector.

--
Bill Sloman, Sydney

 

[Phil Hobbs]

On 9/16/2014 12:31 AM, rickman wrote:

On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you
quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?

The jitter has some (very wide) intrinsic frequency spectrum, which will
get folded (aliased) a zillion times into the fundamental interval, and
will therefore be very nearly white, apart from possible power supply
problems.

The loop bandwidth will probably be only a few hundred hertz, because
you have to filter out the gross ugly ripple from the bang-bang PD
without making the loop unstable. Say 200 clocks at 80 kHz.

Most of the DFF's jitter will thus get filtered out.

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

 

[Phil Hobbs]

On 9/16/2014 1:12 AM, josephkk wrote:

On Sun, 14 Sep 2014 20:58:33 -0400, Phil Hobbs <hobbs@electrooptical.net
wrote:

On 9/14/2014 8:53 PM, josephkk wrote:
On Sun, 14 Sep 2014 17:53:42 -0400, Phil Hobbs <hobbs@electrooptical.net
wrote:


Frequency locking isn't difficult. Time locking to picoseconds is.
http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

What I will say though, is multiplying up by harmonic selection from LC
tanks gives orders of lower phase noise/jitter than a PLL.

Won't LC tanks have horrendous temperature coefficients?

Not that bad after all. Assuming a LC Q-factor of 100, you will have a
1 % -3 dB bandwidth. That would allow a 10000 ppm drift across the
temperature range (100 ppm/C across 100 C). After all, you are
interested in the harmonics of the crystal oscillator, not the filter
performance.

In the words of Rudyard Kipling, "Not so, but far otherwise." For a
single section the phase shift across the width of the resonance is on
the order of 1 radian, so in terms of phase, a filter with a Q of 100
magnifies the component tempcos by roughly 100 times. A time shift of 1
ps is about a milliradian at 155 MHz. Typical inductor tempcos of +100
ppm/C will give you a phase shift of something like

dPhi/dT ~ Q * dL/dT

or 0.01 radian/K, i.e. 10 ps/K.

Cheers

Phil Hobbs

I am not so sure about that. It seems to me that you have used native LC
tank phase noise when a forcing function version is more appropriate.

?-)


How so? I didn't mention phase noise, just tempco.

Cheers

Phil Hobbs

My bad on switching dimensions incorrectly. I think my question still
applies to tempco.

?-)

So you think that there should be a tempco of some forcing function?
What does that mean?

How would you calculate the phase tempco of a filter?

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

 

[John Larkin]

On Tue, 16 Sep 2014 00:31:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?

The jitter that matters is what comes out of the VCXO. That is
determined by the VCXO's open-loop jitter spectrum, reduced by the
feedback loop at lower frequencies. There's an analog lowpass filter
in the feedback loop whose unity-gain bandwidth will be roughly 500
Hz. Picosecond jitter in the phase detector path will not make it
through that lowpass filter. What does get through the filter is the
statistical 1/0 decisions of the PD flipflop, which, barring math
tricks, get made at 80 KHz.

As the XO gets more expensive, the lowpass filter cutoff frequency can
be reduced. That tradeoff is the original subject of the thread.

"Jitter filter" aka "clock cleanup" is a common concept. I expect the
155.52 clock to have a lot less time jitter than the 10 MHz reference.
A few ps jitter around the phase detector flop won't matter.

Jitter at the PD flop essentially reduces the gain (measured in
volts/ps) of the phase detector.


--

John Larkin Highland Technology, Inc

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

 

[John Larkin]

On Tue, 16 Sep 2014 00:21:44 -0500, ChesterW <iamsnoozin@yahoo.com>
wrote:

On 9/15/14, 4:55 PM, Phil Hobbs wrote:
snip



*----------------<----------------------------------------*
| |
VCXO *-----* *-----* *-------* |
155.52 MHz ->-- /1944 ->-|D Q|------|D Q|---| LOOP |----*
| | | | | |FILTER |
V *--^--* *--^--* *-------*
| | |
*------->-------* *---<----10MHz REF
Resynch B-B phase det

With maybe a second DFF stage between the phase detector and the loop
filter, to get rid of any noise caused by metastability.

Cheers

Phil Hobbs

It's elegant, but it seems counter-intuitive that the rather tough specs
can be met when throwing away over 99% of the phase comparison
information (1-1/125).

ChesterW

For a constant loop bandwidth, you should get some noise averaging by
doing the phase comparison faster, I agree. However, since you have to
crank down the BW to filter out the gross amounts of ripple from a
bang-bang phase detector, I expect that it won't be that different
inside the BW.

Of course, losing all that loop bandwidth does mean that the VCXO has to
be a lot better than it would with a 10 MHz comparison frequency.

Using local feedback, i.e. a DDS-based or fractional-N loop (wide loop
BW but probably fairly horrible drift) inside an 80-kHz bang-bang loop
would relax the requirements on the VCXO proper.

This is all such fun that I may have to try building something like that.

Cheers

Phil Hobbs


Yes, John Larkin gets the prize for the most interesting project of the
week. Lucky dog.

Here's a possible idea for evaluating the feasibility of different
schemes. Calculate the entropy of the 155.52 MHz signal. Estimate the
frequency drift of the VCXO and represent it as the number of bits of
information lost per 12.5 us update period. Then the feedback needs to
supply at least this number of bits of information to be a possible
solution. If the required feedback SNR is too high, then you know you
need to use the information from more phase comparisons, not just the
easy 12.5 us ones.

Something like that. We'll probably lay out a nice multilayer proto
board with a few candidate VCXO locations, 10 MHz filters, and
dipswitches and trimpots in the loop lowpass filter to make it easy to
tune. Seed that with SMA connectors for analysis, and experiment. Good
intern sort of project.

Putting a cover over the XO, to keep air currents off it, can reduce
jitter a lot.


This is cool:

https://dl.dropboxusercontent.com/u/53724080/Software/PhaseNoise.exe

It was done by one of the s.e.d. guys some time ago; Jeroen? It lets
you convert a phase noise curve to RMS jitter.


--

John Larkin Highland Technology, Inc

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

 

[John Larkin]

On Tue, 16 Sep 2014 09:04:29 +0000 (UTC), mroberds@att.net wrote:

John Larkin <jlarkin@highlandtechnology.com> wrote:
The GPS box gives me 10 MHz and 1 PPS references, and an occasional
Ethernet message will give me time to within 1 second.

This may fall in the category of grandmothers and eggs, but here goes:

The GPS module will have a local clock in the few tens of MHz range.
One that I know about had to put the 1PPS edge on one of its local clock
edges, instead of exactly at the start of the second. For high
precision, you have to take this into account. The one I used could
tell you (via its serial port) the offset between the most recent 1PPS
pulse and when the second actually started, so you can apply a
correction. This had to happen for every single 1PPS edge.

It's entirely possible that the GPS module you have can send the 1PPS
exactly on time, but it might be worth checking.

Matt Roberds

I assume that a 1PPS pulse will happen exactly every 1e7 of the 10 MHz
sine wave. If that's not true, we're in for interesting times.

The manual for the GPS box doesn't mention the phase relationship
between the 10M and the 1PPS; I'll have to measure that and provide an
FPGA tweak, just in case. I need to resync the 1PPS to the 10 MHz, and
then promote that event up to 155.52 MHz, absolutely unambiguously.




--

John Larkin Highland Technology, Inc

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

 

[rickman]

On 9/16/2014 12:04 PM, John Larkin wrote:

On Tue, 16 Sep 2014 09:04:29 +0000 (UTC), mroberds@att.net wrote:

John Larkin <jlarkin@highlandtechnology.com> wrote:
The GPS box gives me 10 MHz and 1 PPS references, and an occasional
Ethernet message will give me time to within 1 second.

This may fall in the category of grandmothers and eggs, but here goes:

The GPS module will have a local clock in the few tens of MHz range.
One that I know about had to put the 1PPS edge on one of its local clock
edges, instead of exactly at the start of the second. For high
precision, you have to take this into account. The one I used could
tell you (via its serial port) the offset between the most recent 1PPS
pulse and when the second actually started, so you can apply a
correction. This had to happen for every single 1PPS edge.

It's entirely possible that the GPS module you have can send the 1PPS
exactly on time, but it might be worth checking.

Matt Roberds

I assume that a 1PPS pulse will happen exactly every 1e7 of the 10 MHz
sine wave. If that's not true, we're in for interesting times.

The manual for the GPS box doesn't mention the phase relationship
between the 10M and the 1PPS; I'll have to measure that and provide an
FPGA tweak, just in case. I need to resync the 1PPS to the 10 MHz, and
then promote that event up to 155.52 MHz, absolutely unambiguously.

They may not spec the phase of the 1 pps relative to the 10 MHz, but
they should give you a jitter spec on the 1 pps. What is that number?
That should give you enough insight.

--

Rick

 

[rickman]

On 9/16/2014 8:19 AM, Phil Hobbs wrote:

On 9/16/2014 12:31 AM, rickman wrote:
On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you
quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?


The jitter has some (very wide) intrinsic frequency spectrum, which will
get folded (aliased) a zillion times into the fundamental interval, and
will therefore be very nearly white, apart from possible power supply
problems.

The loop bandwidth will probably be only a few hundred hertz, because
you have to filter out the gross ugly ripple from the bang-bang PD
without making the loop unstable. Say 200 clocks at 80 kHz.

Most of the DFF's jitter will thus get filtered out.

That isn't the question. He is looking to make a PD with 1 ps jitter.
He is using two FFs with RMS jitter of 1 ps each yielding 1.4 ps of RMA
jitter. How does the filter change this spec?

--

Rick

 

[rickman]

On 9/16/2014 10:17 AM, John Larkin wrote:

On Tue, 16 Sep 2014 00:31:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?

The jitter that matters is what comes out of the VCXO. That is
determined by the VCXO's open-loop jitter spectrum, reduced by the
feedback loop at lower frequencies. There's an analog lowpass filter
in the feedback loop whose unity-gain bandwidth will be roughly 500
Hz. Picosecond jitter in the phase detector path will not make it
through that lowpass filter. What does get through the filter is the
statistical 1/0 decisions of the PD flipflop, which, barring math
tricks, get made at 80 KHz.

As the XO gets more expensive, the lowpass filter cutoff frequency can
be reduced. That tradeoff is the original subject of the thread.

"Jitter filter" aka "clock cleanup" is a common concept. I expect the
155.52 clock to have a lot less time jitter than the 10 MHz reference.
A few ps jitter around the phase detector flop won't matter.

Jitter at the PD flop essentially reduces the gain (measured in
volts/ps) of the phase detector.

I'm only responding to your earlier statement that you wanted a PD with
1 ps jitter. So that is not met by this circuit as the PD jitter is 1.4
ps RMS, no?

--

Rick

 

[John Larkin]

On Tue, 16 Sep 2014 12:27:09 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/16/2014 8:19 AM, Phil Hobbs wrote:
On 9/16/2014 12:31 AM, rickman wrote:
On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you
quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?


The jitter has some (very wide) intrinsic frequency spectrum, which will
get folded (aliased) a zillion times into the fundamental interval, and
will therefore be very nearly white, apart from possible power supply
problems.

The loop bandwidth will probably be only a few hundred hertz, because
you have to filter out the gross ugly ripple from the bang-bang PD
without making the loop unstable. Say 200 clocks at 80 kHz.

Most of the DFF's jitter will thus get filtered out.

That isn't the question. He is looking to make a PD with 1 ps jitter.

The PD jitter doesn't matter. The oscillator jitter does.

He is using two FFs with RMS jitter of 1 ps each yielding 1.4 ps of RMA
jitter. How does the filter change this spec?

It smooths out the statistical noise of the bang-bang flop, before
it's applied to the VCXO input.

I'm surprised that I have to explain stuff this simple.



--

John Larkin Highland Technology, Inc

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

 

[John Larkin]

On Tue, 16 Sep 2014 12:28:32 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/16/2014 10:17 AM, John Larkin wrote:
On Tue, 16 Sep 2014 00:31:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?

The jitter that matters is what comes out of the VCXO. That is
determined by the VCXO's open-loop jitter spectrum, reduced by the
feedback loop at lower frequencies. There's an analog lowpass filter
in the feedback loop whose unity-gain bandwidth will be roughly 500
Hz. Picosecond jitter in the phase detector path will not make it
through that lowpass filter. What does get through the filter is the
statistical 1/0 decisions of the PD flipflop, which, barring math
tricks, get made at 80 KHz.

As the XO gets more expensive, the lowpass filter cutoff frequency can
be reduced. That tradeoff is the original subject of the thread.

"Jitter filter" aka "clock cleanup" is a common concept. I expect the
155.52 clock to have a lot less time jitter than the 10 MHz reference.
A few ps jitter around the phase detector flop won't matter.

Jitter at the PD flop essentially reduces the gain (measured in
volts/ps) of the phase detector.

I'm only responding to your earlier statement that you wanted a PD with
1 ps jitter. So that is not met by this circuit as the PD jitter is 1.4
ps RMS, no?

I want ballpark 1 ps time stability, and a bang-bang ECL phase
detector is a simple way to get close to that. The PD jitter will get
attenuated by the loop filter, so the VCXO jitter can be way less than
the jitter of the PD flops, or the likely bigger jitter of the 10 MHz
reference.

As noted, the stability and jitter that matters is at the output of
the VCXO.


--

John Larkin Highland Technology, Inc

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

 

[rickman]

On 9/16/2014 1:00 PM, John Larkin wrote:

On Tue, 16 Sep 2014 12:27:09 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/16/2014 8:19 AM, Phil Hobbs wrote:
On 9/16/2014 12:31 AM, rickman wrote:
On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you
quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?


The jitter has some (very wide) intrinsic frequency spectrum, which will
get folded (aliased) a zillion times into the fundamental interval, and
will therefore be very nearly white, apart from possible power supply
problems.

The loop bandwidth will probably be only a few hundred hertz, because
you have to filter out the gross ugly ripple from the bang-bang PD
without making the loop unstable. Say 200 clocks at 80 kHz.

Most of the DFF's jitter will thus get filtered out.

That isn't the question. He is looking to make a PD with 1 ps jitter.

The PD jitter doesn't matter. The oscillator jitter does.

If your PD jitter doesn't matter why do you use the ECL FFs? It could
all be done in the FPGA.

--

Rick

 

[rickman]

On 9/16/2014 1:04 PM, John Larkin wrote:

On Tue, 16 Sep 2014 12:28:32 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/16/2014 10:17 AM, John Larkin wrote:
On Tue, 16 Sep 2014 00:31:03 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?

The jitter that matters is what comes out of the VCXO. That is
determined by the VCXO's open-loop jitter spectrum, reduced by the
feedback loop at lower frequencies. There's an analog lowpass filter
in the feedback loop whose unity-gain bandwidth will be roughly 500
Hz. Picosecond jitter in the phase detector path will not make it
through that lowpass filter. What does get through the filter is the
statistical 1/0 decisions of the PD flipflop, which, barring math
tricks, get made at 80 KHz.

As the XO gets more expensive, the lowpass filter cutoff frequency can
be reduced. That tradeoff is the original subject of the thread.

"Jitter filter" aka "clock cleanup" is a common concept. I expect the
155.52 clock to have a lot less time jitter than the 10 MHz reference.
A few ps jitter around the phase detector flop won't matter.

Jitter at the PD flop essentially reduces the gain (measured in
volts/ps) of the phase detector.

I'm only responding to your earlier statement that you wanted a PD with
1 ps jitter. So that is not met by this circuit as the PD jitter is 1.4
ps RMS, no?

I want ballpark 1 ps time stability, and a bang-bang ECL phase
detector is a simple way to get close to that. The PD jitter will get
attenuated by the loop filter, so the VCXO jitter can be way less than
the jitter of the PD flops, or the likely bigger jitter of the 10 MHz
reference.

As noted, the stability and jitter that matters is at the output of
the VCXO.

So why use ECL FFs?

--

Rick

 

[Kevin Aylward]

"John Larkin" wrote in message
news:udbe1ali3msjs4bsjo2nioql0eulvtas09@4ax.com...

On Mon, 15 Sep 2014 13:47:32 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 09/15/2014 01:31 PM, Kevin Aylward wrote:
"Phil Hobbs" wrote in message news:54160E66.80808@electrooptical.net...

On 9/14/2014 8:43 AM, upsidedown@downunder.com wrote:
On Sun, 14 Sep 2014 13:22:23 +0100, Mike Perkins <spam@spam.com
wrote:

Frequency locking isn't difficult. Time locking to picoseconds is.
http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

What I will say though, is multiplying up by harmonic selection
from LC
tanks gives orders of lower phase noise/jitter than a PLL.

Won't LC tanks have horrendous temperature coefficients?

Not that bad after all. Assuming a LC Q-factor of 100, you will have a
1 % -3 dB bandwidth. That would allow a 10000 ppm drift across the
temperature range (100 ppm/C across 100 C). After all, you are
interested in the harmonics of the crystal oscillator, not the filter
performance.

In the words of Rudyard Kipling, "Not so, but far otherwise." For a
single section the phase shift across the width of the resonance is on
the order of 1 radian, so in terms of phase, a filter with a Q of 100
magnifies the component tempcos by roughly 100 times. A time shift of
1 ps is about a milliradian at 155 MHz. Typical inductor tempcos of
+100 ppm/C will give you a phase shift of something like

dPhi/dT ~ Q * dL/dT
or 0.01 radian/K, i.e. 10 ps/K.

You will need to give me a heads up on what applications this delay
change will matter. Temperature changes are typically sub Hz. Once
equipment warms up, it could be minutes for a one degree change in
temperature. The steady state frequency won't change, its n x input f.
Considering that say, a 10MHz oscillator might hit -100 dBc at 10 Hz
offset compared to its wonderful -160dBc flatband (100kHz +) , systems,
in general have to be a lot more tolerant of close in phase noise.

Its a fact that many main stream high performance xtal oscillator
vendors use LC tanks to up-convert the xtal frequency to achieve lower
noise than is available from a PLL. You seem to be implying that there
is some flaw with this approach for some applications. I would be
interested to know the details.


In John's application, it will make the 10 MHz BPF the dominant source
of drift in the whole board, because it's outside the loop.

It doesn't have to be.

Right. I need a 10 MHz bandpass filter with really small delay vs
temperature behavior.

Not that I am in anyway indicating what I am currently working on, I entered
the thread to make a general discussion point that generating a high
frequency VCO using LC tank multiplication will most likely to certain,
result in much lower phase noise than using a PLL to lock/ that higher
frequency with a HF (low Q) oscillator. i.e. Its difficult to get a high
performance, high stability oscillator directly at say, 2.5 Ghz. Xtals are
shit up there. This may or my not have relevance to your particular problem.
For example, a 50G/s optical system could take the HF VCO clock and lock it
to incoming data.

So, for example, a 10MHz xtal VCO fed into tanks to multiple up, looks like
a N*F VCO. This combined HF VCO could be locked in a PLL with your incoming
10MHz, for example.

I would guess that your incoming 10 MHz has a low frequency (< 1Hz) phase
noise way below that which a standard xtal oscillator has. Otherwise, I
still wont understand why 10 mili Hz noise bothers you. Noise ramps up at
30db/dec typically below 100Hz.

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

 

[John Larkin]

On Tue, 16 Sep 2014 13:15:39 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/16/2014 1:00 PM, John Larkin wrote:
On Tue, 16 Sep 2014 12:27:09 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/16/2014 8:19 AM, Phil Hobbs wrote:
On 9/16/2014 12:31 AM, rickman wrote:
On 9/15/2014 11:08 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:37:19 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/15/2014 10:33 PM, John Larkin wrote:
On Mon, 15 Sep 2014 22:18:05 -0400, rickman <gnuarm@gmail.com> wrote:

That is RMS, I was quoting peak (max). See above in the text you
quoted...

The RMS jitter is specified as 200 fs typ, and the RMS jitter is
specified as 1 ps RMS max.

Ok, so just the two FFs in your circuit create 1.4 ps of jitter RMS
"max" then, no?

No. They are inside the PLL feedback loop.

You might consider moving over to the "basics" newsgroup. It gets
timesome explaining this simple of stuff to newbies.

I know, it is hard to explain something you don't understand.

How can a very slow PLL reduce the cycle to cycle jitter of the PD?


The jitter has some (very wide) intrinsic frequency spectrum, which will
get folded (aliased) a zillion times into the fundamental interval, and
will therefore be very nearly white, apart from possible power supply
problems.

The loop bandwidth will probably be only a few hundred hertz, because
you have to filter out the gross ugly ripple from the bang-bang PD
without making the loop unstable. Say 200 clocks at 80 kHz.

Most of the DFF's jitter will thus get filtered out.

That isn't the question. He is looking to make a PD with 1 ps jitter.

The PD jitter doesn't matter. The oscillator jitter does.

If your PD jitter doesn't matter why do you use the ECL FFs? It could
all be done in the FPGA.

An FPGA would have a horrible tempco, ballpark 10s of PS per degree C.
And it would add massive jitter, from crosstalk and tiny Vcc wiggles
and tiny temperature variations. Differential ECL is way less
sensitive to things like that.

I make digital delay generators with an FPGA in a similar phase-locked
loop. Uncompensated delay tempco is typically around 40 ps/degC and
jitter is maybe 30 ps RMS. An ECL bangbang loop can be a couple ps RMS
jitter and roughly 1 ps per degree C.

The FPGA could probably be improved, with a lot of work battling the
P&R tools, but it won't approach the ECL.

None of which overcomes the basic fact that the GCD of 10MHz and
155.52 MHz is 80 KHz.


--

John Larkin Highland Technology, Inc

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

 

[John Larkin]

On Tue, 16 Sep 2014 08:22:25 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

On 9/16/2014 1:12 AM, josephkk wrote:
On Sun, 14 Sep 2014 20:58:33 -0400, Phil Hobbs <hobbs@electrooptical.net
wrote:

On 9/14/2014 8:53 PM, josephkk wrote:
On Sun, 14 Sep 2014 17:53:42 -0400, Phil Hobbs <hobbs@electrooptical.net
wrote:


Frequency locking isn't difficult. Time locking to picoseconds is.
http://www.slac.stanford.edu/econf/C011127/TUAP069.pdf

What I will say though, is multiplying up by harmonic selection from LC
tanks gives orders of lower phase noise/jitter than a PLL.

Won't LC tanks have horrendous temperature coefficients?

Not that bad after all. Assuming a LC Q-factor of 100, you will have a
1 % -3 dB bandwidth. That would allow a 10000 ppm drift across the
temperature range (100 ppm/C across 100 C). After all, you are
interested in the harmonics of the crystal oscillator, not the filter
performance.

In the words of Rudyard Kipling, "Not so, but far otherwise." For a
single section the phase shift across the width of the resonance is on
the order of 1 radian, so in terms of phase, a filter with a Q of 100
magnifies the component tempcos by roughly 100 times. A time shift of 1
ps is about a milliradian at 155 MHz. Typical inductor tempcos of +100
ppm/C will give you a phase shift of something like

dPhi/dT ~ Q * dL/dT

or 0.01 radian/K, i.e. 10 ps/K.

Cheers

Phil Hobbs

I am not so sure about that. It seems to me that you have used native LC
tank phase noise when a forcing function version is more appropriate.

?-)


How so? I didn't mention phase noise, just tempco.

Cheers

Phil Hobbs

My bad on switching dimensions incorrectly. I think my question still
applies to tempco.

?-)



So you think that there should be a tempco of some forcing function?
What does that mean?

How would you calculate the phase tempco of a filter?

Cheers

Phil Hobbs

Measure the tempco of the inductors, add a tweak for PCB pad
capacitance, Spice it.

Than add NTC caps (if you can buy the values that you need) or a DAC
and a varicap. Or tweal the delay somewhere else in the system.

There may be a bandpass topology that has a parabolic or some such
flat delay TC over some temperature region. But the inductors will be
the killers. At 10 MHz, active filters are possible.




--

John Larkin Highland Technology, Inc

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

 

[David Platt]

In article <hing1a9qugb9fjahclbeendus8ehjiu9o6@4ax.com>,
John Larkin <jlarkin@highlandtechnology.com> wrote:

The GPS module will have a local clock in the few tens of MHz range.
One that I know about had to put the 1PPS edge on one of its local clock
edges, instead of exactly at the start of the second. For high
precision, you have to take this into account. The one I used could
tell you (via its serial port) the offset between the most recent 1PPS
pulse and when the second actually started, so you can apply a
correction. This had to happen for every single 1PPS edge.

I assume that a 1PPS pulse will happen exactly every 1e7 of the 10 MHz
sine wave. If that's not true, we're in for interesting times.

Saying "exactly" for timing coincidence which involves continuous
waveforms is a trifle risky...

The Motorola Oncore receivers (quite popular some years ago) exhibited
this behavior. There's a predictable deterministic "sawtooth" pattern
to the timing offset between "true start of second" and "leading edge
of the PPS pulse". As noted, you can determine this offset
after-the-fact for any particular pulse, and can even predict it
fairly well some time in advance.

I believe that this situation remains true for many more-modern GPS
receivers... the PPS pulse is synchronous to an internal clock (which
is probably faster than that of the Oncore).

I'd guess that some high-end timing-grade GPS receivers may "bend"
their internal clocks to reduce the clock-related PPS jitter... but
there's always going to be some.