PLL tricks

[John Larkin]

On Mon, 15 Sep 2014 00:24:51 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 11:58 PM, John Larkin wrote:
On Sun, 14 Sep 2014 23:29:59 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 9:30 PM, John Larkin wrote:
On Sun, 14 Sep 2014 20:56:34 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided
clock
is not an issue? It is not being used to clock anything. It is only
being used to isolate the actual clock edges by enabling the FF. It
only has to meet setup and hold times.

Packaged D-flops rarely come with clock enable pins in my universe. John
specifically said that you needed to drive the DFF differentially to get
the good jitter numbers, so despite having CLK and /CLK pins, there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output into D
and clock it with the undivided signal.


BTW, the FF has to be clocked by the same clock that is being divided
down. Otherwise you get 1 full clock cycle of jitter in the enable
when
you sync it to the other clock.

Doing that would break the PLL, so I'm obviously not proposing anything
so idiotic.

How would that break the PLL? The reference clock is sampled by the D
input clocked by the VCXO clock. The divided signal has to be an enable
on the FF or it won't work because of the inherent delays in generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.

About like this:

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

So where is the output?

Wherever I need it to be. What a PITA you are.

By using the divided clock to clock the reference you have added an
unspecified delay which will vary with time, temperature, process and
voltage. Is all this going to give you the 1 ps spec you need? Is
there really no part available with an enable? That gets around the
problem totally.

Find one.

I realize now that whenever you get pushed into having to deal with
problems you get angry and start insulting people. I'm sure that gets
you miles with your coworkers.

There is no problem to deal with, except my unhappiness at running the
sample loop at 80 KHz, which was the topic of this thread. I'll need a
very good XO if the loop bandwidth is, say, 100 Hz or some such.

I realize now why others have said this may stable in frequency but you
can expect difficulties in phase. Or are you going to hand calibrate
each one for the particular 10EP52 you use?

The question is meaningless. Just the coax from the GPS clock to my
box will add nanoseconds of delay. What matters is long-term stability
of timing, and low jitter, across the entire many-acre facility. Some
of the gadgets that we'll be triggering are over 100 meters from this
timing source. All the various electrical and fiberoptic and device
delays have to be backed out to set the firing target times.


--

John Larkin Highland Technology, Inc

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

 

[Jan Panteltje]

On a sunny day (Mon, 15 Sep 2014 00:30:25 +0200) it happened Gerhard Hoffmann
<ghf@hoffmann-hochfrequenz.de> wrote in <c7mj82F9lftU1@mid.individual.net>:

on the board, and of course FPGAs and such need lots of independently
regulated rails anyway. It's not especially difficult to reduce the
externally-coupled noise on a rails to well below 1 nV/sqrt(Hz),
regardless of what the input supply looks like. That's probably well
below the input-referred noise of the D-flop.

Since you are mentioning really clean supplies:
I have built a preamp to verify the noise on supplies and Vtune lines:

http://www.hoffmann-hochfrequenz.de/downloads/lono.pdf

and used it to measure the noise of batteries, simply because they are
probably the hardest test objects.


http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf

Cool, yes I also noticed some extra noise from eneloops (AAA).
Nicads.. I still have one.

 

[Jan Panteltje]

On a sunny day (Sun, 14 Sep 2014 18:30:16 -0700) it happened John Larkin
<jlarkin@highlandtechnology.com> wrote in
<j8gc1a9n6pq14t5jr17lbmlp38jma1n3ri@4ax.com>:

On Sun, 14 Sep 2014 20:56:34 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided
clock
is not an issue? It is not being used to clock anything. It is only
being used to isolate the actual clock edges by enabling the FF. It
only has to meet setup and hold times.

Packaged D-flops rarely come with clock enable pins in my universe. John
specifically said that you needed to drive the DFF differentially to get
the good jitter numbers, so despite having CLK and /CLK pins, there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output into D
and clock it with the undivided signal.


BTW, the FF has to be clocked by the same clock that is being divided
down. Otherwise you get 1 full clock cycle of jitter in the enable
when
you sync it to the other clock.

Doing that would break the PLL, so I'm obviously not proposing anything
so idiotic.

How would that break the PLL? The reference clock is sampled by the D
input clocked by the VCXO clock. The divided signal has to be an enable
on the FF or it won't work because of the inherent delays in generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.

About like this:

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

You Romulan!
http://en.memory-alpha.org/wiki/Romulan_Star_Empire

 

[Jan Panteltje]

On a sunny day (Sun, 14 Sep 2014 21:50:50 -0700) it happened John Larkin
<jlarkin@highlandtechnology.com> wrote in
<jgrc1ahr4g0jjd98f4db1sc0kfm1for155@4ax.com>:

On Mon, 15 Sep 2014 00:24:51 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 11:58 PM, John Larkin wrote:
On Sun, 14 Sep 2014 23:29:59 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 9:30 PM, John Larkin wrote:
On Sun, 14 Sep 2014 20:56:34 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided
clock
is not an issue? It is not being used to clock anything. It is only
being used to isolate the actual clock edges by enabling the FF. It
only has to meet setup and hold times.

Packaged D-flops rarely come with clock enable pins in my universe. John
specifically said that you needed to drive the DFF differentially to get
the good jitter numbers, so despite having CLK and /CLK pins, there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output into D
and clock it with the undivided signal.


BTW, the FF has to be clocked by the same clock that is being divided
down. Otherwise you get 1 full clock cycle of jitter in the enable
when
you sync it to the other clock.

Doing that would break the PLL, so I'm obviously not proposing anything
so idiotic.

How would that break the PLL? The reference clock is sampled by the D
input clocked by the VCXO clock. The divided signal has to be an enable
on the FF or it won't work because of the inherent delays in generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.

About like this:

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

So where is the output?

Wherever I need it to be. What a PITA you are.

By using the divided clock to clock the reference you have added an
unspecified delay which will vary with time, temperature, process and
voltage. Is all this going to give you the 1 ps spec you need? Is
there really no part available with an enable? That gets around the
problem totally.

Find one.


I realize now that whenever you get pushed into having to deal with
problems you get angry and start insulting people. I'm sure that gets
you miles with your coworkers.

There is no problem to deal with, except my unhappiness at running the
sample loop at 80 KHz, which was the topic of this thread. I'll need a
very good XO if the loop bandwidth is, say, 100 Hz or some such.



I realize now why others have said this may stable in frequency but you
can expect difficulties in phase. Or are you going to hand calibrate
each one for the particular 10EP52 you use?

The question is meaningless. Just the coax from the GPS clock to my
box will add nanoseconds of delay. What matters is long-term stability
of timing, and low jitter, across the entire many-acre facility. Some
of the gadgets that we'll be triggering are over 100 meters from this
timing source. All the various electrical and fiberoptic and device
delays have to be backed out to set the firing target times.

In the video world that is done by measuring the phase where it needs to be correct,
and providing a feedback signal to the unit (your VCO in this case).
Been done for many many years, over hundreds of miles, to the nanosecond.
Cancelling for cable lenght etc is impossible,
as even one degree temperature change will change that delay,
any bend in the cables will, ANYTHING.
You are a Romulan:
http://en.memory-alpha.org/wiki/Romulan_Star_Empire
Quote:
"Empire was known for its xenophobic character and policies of extreme secrecy and territorial protectionism."

^^^^^^^^^^^^^^^

--

John Larkin Highland Technology, Inc

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

 

[ChesterW]

On 9/14/14, 5:30 PM, Gerhard Hoffmann wrote:

on the board, and of course FPGAs and such need lots of independently
regulated rails anyway. It's not especially difficult to reduce the
externally-coupled noise on a rails to well below 1 nV/sqrt(Hz),
regardless of what the input supply looks like. That's probably well
below the input-referred noise of the D-flop.

Since you are mentioning really clean supplies:
I have built a preamp to verify the noise on supplies and Vtune lines:

http://www.hoffmann-hochfrequenz.de/downloads/lono.pdf

and used it to measure the noise of batteries, simply because they are
probably the hardest test objects.


http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf


It's not yet accesible from the rest of the website, you must know
the exact address since I'm not yet happy with the results. I see
much more 1/f noise than F.Walls from NIST, and partly 30 dB/decade.

I have used an old Avantek wideband amplifier with 57 dB gain and mixed
down the noise @100 MHz with a signal generator, ring mixer & low pass
to AF, and it was as flat as could be down to 0.1 Hz. So if it's
flat, the system shows it as flat. wierd.

regards, Gerhard

Nice. I wonder if the noise will change with the charge state of the
battery. I think it should if it scales with the batteries internal
resistance. It might make a good calibration point.

ChesterW

 

[ChesterW]

On 9/14/14, 5:47 PM, Phil Hobbs wrote:

On 9/14/2014 6:30 PM, Gerhard Hoffmann wrote:

on the board, and of course FPGAs and such need lots of independently
regulated rails anyway. It's not especially difficult to reduce the
externally-coupled noise on a rails to well below 1 nV/sqrt(Hz),
regardless of what the input supply looks like. That's probably well
below the input-referred noise of the D-flop.

Since you are mentioning really clean supplies:
I have built a preamp to verify the noise on supplies and Vtune lines:

http://www.hoffmann-hochfrequenz.de/downloads/lono.pdf

and used it to measure the noise of batteries, simply because they are
probably the hardest test objects.


http://www.hoffmann-hochfrequenz.de/downloads/NoiseMeasurementsOnChemicalBatteries.pdf



It's not yet accesible from the rest of the website, you must know
the exact address since I'm not yet happy with the results. I see
much more 1/f noise than F.Walls from NIST, and partly 30 dB/decade.

I have used an old Avantek wideband amplifier with 57 dB gain and mixed
down the noise @100 MHz with a signal generator, ring mixer & low pass
to AF, and it was as flat as could be down to 0.1 Hz. So if it's
flat, the system shows it as flat. wierd.

regards, Gerhard

Nice. If you make two amplifiers, take the cross-spectrum of their
outputs, and average for awhile, you can get rid of the amplifier
voltage noise pretty well. (The current noise adds, of course.)

Cheers

Phil Hobbs

+1

You could try the idea by separating the paralleled amplifier outputs
into two groups using your existing board.

ChesterW

 

[rickman]

On 9/15/2014 3:28 AM, Jan Panteltje wrote:

On a sunny day (Sun, 14 Sep 2014 21:50:50 -0700) it happened John Larkin
jlarkin@highlandtechnology.com> wrote in
jgrc1ahr4g0jjd98f4db1sc0kfm1for155@4ax.com>:

On Mon, 15 Sep 2014 00:24:51 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 11:58 PM, John Larkin wrote:
On Sun, 14 Sep 2014 23:29:59 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 9:30 PM, John Larkin wrote:
On Sun, 14 Sep 2014 20:56:34 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided
clock
is not an issue? It is not being used to clock anything. It is only
being used to isolate the actual clock edges by enabling the FF. It
only has to meet setup and hold times.

Packaged D-flops rarely come with clock enable pins in my universe. John
specifically said that you needed to drive the DFF differentially to get
the good jitter numbers, so despite having CLK and /CLK pins, there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output into D
and clock it with the undivided signal.


BTW, the FF has to be clocked by the same clock that is being divided
down. Otherwise you get 1 full clock cycle of jitter in the enable
when
you sync it to the other clock.

Doing that would break the PLL, so I'm obviously not proposing anything
so idiotic.

How would that break the PLL? The reference clock is sampled by the D
input clocked by the VCXO clock. The divided signal has to be an enable
on the FF or it won't work because of the inherent delays in generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.

About like this:

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

So where is the output?

Wherever I need it to be. What a PITA you are.

By using the divided clock to clock the reference you have added an
unspecified delay which will vary with time, temperature, process and
voltage. Is all this going to give you the 1 ps spec you need? Is
there really no part available with an enable? That gets around the
problem totally.

Find one.


I realize now that whenever you get pushed into having to deal with
problems you get angry and start insulting people. I'm sure that gets
you miles with your coworkers.

There is no problem to deal with, except my unhappiness at running the
sample loop at 80 KHz, which was the topic of this thread. I'll need a
very good XO if the loop bandwidth is, say, 100 Hz or some such.



I realize now why others have said this may stable in frequency but you
can expect difficulties in phase. Or are you going to hand calibrate
each one for the particular 10EP52 you use?

The question is meaningless. Just the coax from the GPS clock to my
box will add nanoseconds of delay. What matters is long-term stability
of timing, and low jitter, across the entire many-acre facility. Some
of the gadgets that we'll be triggering are over 100 meters from this
timing source. All the various electrical and fiberoptic and device
delays have to be backed out to set the firing target times.

In the video world that is done by measuring the phase where it needs to be correct,
and providing a feedback signal to the unit (your VCO in this case).
Been done for many many years, over hundreds of miles, to the nanosecond.
Cancelling for cable lenght etc is impossible,
as even one degree temperature change will change that delay,
any bend in the cables will, ANYTHING.
You are a Romulan:
http://en.memory-alpha.org/wiki/Romulan_Star_Empire
Quote:
"Empire was known for its xenophobic character and policies of extreme secrecy and territorial protectionism."

^^^^^^^^^^^^^^^

I suppose that is better than being a Ferengi...

http://en.memory-alpha.org/wiki/Ferengi

"The Ferengi's most distinguishing feature was their large ears"

--

Rick

 

[Gerhard Hoffmann]

Am 15.09.2014 um 09:46 schrieb ChesterW:

On 9/14/14, 5:47 PM, Phil Hobbs wrote:

Nice. If you make two amplifiers, take the cross-spectrum of their
outputs, and average for awhile, you can get rid of the amplifier
voltage noise pretty well. (The current noise adds, of course.)

Cheers

Phil Hobbs


+1

You could try the idea by separating the paralleled amplifier outputs
into two groups using your existing board.

But then I still had to build another copy of the other gain stages.
Maybe I'll do a "stereo" version with all switches under software
control and less gain per stage since I have 1 dB gain missing at
1 MHz.

Also, everything seems to have a lot of 1/f noise, so the effort
to extend the coupling to 0.1 Hz is somehow wasted. since the
measurements are under program control, I could just as well live
with a 10 Hz lower edge frequency and compute the pole away.
That would give more dynamic range, not less in praxi.

The NIST people have used correlation and get 10 dB deeper into the
noise, but the 20 averaged opamps bring me quite close.
I'm sorry that I have given away the other unpopulated boards. The
89441A could do the cross correlation.

All my Pb batteries are sulfated, the perfect insulator. :-(
Not one uA charge current at 35V. I won't buy new ones, ever.
There is the starter battery of my R1200GSA bike however, lets see.

Lithiumferrophosphate seems to be more interesting.

Gerhard

 

[ChesterW]

On 9/15/14, 3:27 AM, Gerhard Hoffmann wrote:

Am 15.09.2014 um 09:46 schrieb ChesterW:
On 9/14/14, 5:47 PM, Phil Hobbs wrote:

snip

my R1200GSA bike however, lets see.

Lithiumferrophosphate seems to be more interesting.

Gerhard

Your bike is a famous movie star.

http://www.longwayround.com/journeys_long-way-round.htm

ChesterW

 

[Jasen Betts]

On 2014-09-14, John Larkin <jlarkin@highlandtechnology.com> wrote:

On Sun, 14 Sep 2014 20:06:44 GMT, Jan Panteltje <panteltje@yahoo.com
wrote:

How come the Enterprise, no matter how badly it was shot up, never
lost pressurization and never lost its artificial gravity generator?

And why did they always beam into derelict spaceships and alien
planets that had breathable atmospheres and Earth-level gravity?

Why were no babies ever born on the Enterprise? Why did nobody ever
bleed or vomit? Did they have unisex rest rooms? Did they have
bathtubs? Where were the trash cans? Were snacks not allowed on the
bridge?

The producer didn't have the special-effects budget.

--
umop apisdn


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

 

[Phil Hobbs]

On 9/15/2014 12:24 AM, rickman wrote:

On 9/14/2014 11:58 PM, John Larkin wrote:
On Sun, 14 Sep 2014 23:29:59 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 9:30 PM, John Larkin wrote:
On Sun, 14 Sep 2014 20:56:34 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways.
First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided
clock
is not an issue? It is not being used to clock anything. It
is only
being used to isolate the actual clock edges by enabling the
FF. It
only has to meet setup and hold times.

Packaged D-flops rarely come with clock enable pins in my
universe. John
specifically said that you needed to drive the DFF
differentially to get
the good jitter numbers, so despite having CLK and /CLK pins,
there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider
output into D
and clock it with the undivided signal.


BTW, the FF has to be clocked by the same clock that is being
divided
down. Otherwise you get 1 full clock cycle of jitter in the
enable
when
you sync it to the other clock.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by
the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I
think we
are not talking about the same circuits.

About like this:

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


So where is the output?

Wherever I need it to be. What a PITA you are.

By using the divided clock to clock the reference you have added an
unspecified delay which will vary with time, temperature, process and
voltage. Is all this going to give you the 1 ps spec you need? Is
there really no part available with an enable? That gets around the
problem totally.

The problem is imaginary. Reclocking the divider output from the VCXO
gets rid of all the divider junk, and the resynchronized output has the
same jitter as the VCXO, plus whatever very small contribution comes
from the D-flop. If it existed, a DFF with a clock enable would
function in much the same way. What difference do you see between the
two cases? The DFF output is synchronous with the VCXO either way.

Cables and distribution systems will have to be calibrated somehow, but
that's not the problem at hand.

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/14/2014 11:31 PM, rickman wrote:

On 9/14/2014 9:41 PM, Phil Hobbs wrote:
On 9/14/2014 8:56 PM, rickman wrote:
On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided
clock
is not an issue? It is not being used to clock anything. It is
only
being used to isolate the actual clock edges by enabling the FF. It
only has to meet setup and hold times.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins, there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output
into D
and clock it with the undivided signal.


BTW, the FF has to be clocked by the same clock that is being
divided
down. Otherwise you get 1 full clock cycle of jitter in the enable
when
you sync it to the other clock.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in
generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in
even an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.



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

Where is the output?

From the VCXO.

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/15/2014 4:27 AM, Gerhard Hoffmann wrote:

Am 15.09.2014 um 09:46 schrieb ChesterW:
On 9/14/14, 5:47 PM, Phil Hobbs wrote:

Nice. If you make two amplifiers, take the cross-spectrum of their
outputs, and average for awhile, you can get rid of the amplifier
voltage noise pretty well. (The current noise adds, of course.)

Cheers

Phil Hobbs


+1

You could try the idea by separating the paralleled amplifier outputs
into two groups using your existing board.

But then I still had to build another copy of the other gain stages.
Maybe I'll do a "stereo" version with all switches under software
control and less gain per stage since I have 1 dB gain missing at
1 MHz.

Also, everything seems to have a lot of 1/f noise, so the effort
to extend the coupling to 0.1 Hz is somehow wasted. since the
measurements are under program control, I could just as well live
with a 10 Hz lower edge frequency and compute the pole away.
That would give more dynamic range, not less in praxi.

The NIST people have used correlation and get 10 dB deeper into the
noise, but the 20 averaged opamps bring me quite close.
I'm sorry that I have given away the other unpopulated boards. The
89441A could do the cross correlation.

All my Pb batteries are sulfated, the perfect insulator. :-(
Not one uA charge current at 35V. I won't buy new ones, ever.
There is the starter battery of my R1200GSA bike however, lets see.

Lithiumferrophosphate seems to be more interesting.

Gerhard

The cross-spectrum trick can also be extended to more amplifiers. With
N of them, you get N(N-1)/2 cross spectra, which allows better noise
rejection. It's only really practical at low speed, unless you have a
lot of hardware, but 10 amps and 10 T/H stages will get you another 17
dB or something like that.

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

 

[Piotr Wyderski]

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?

Best regards, Piotr

 

[John Larkin]

On Mon, 15 Sep 2014 01:45:05 -0400, "Tom Miller"
<tmiller11147@verizon.net> wrote:

"John Larkin" <jlarkin@highlandtechnology.com> wrote in message
news:j8gc1a9n6pq14t5jr17lbmlp38jma1n3ri@4ax.com...
On Sun, 14 Sep 2014 20:56:34 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/14/2014 8:49 PM, Phil Hobbs wrote:
On 9/14/2014 8:42 PM, rickman wrote:
On 9/14/2014 8:02 PM, Phil Hobbs wrote:
On 9/14/2014 6:59 PM, rickman wrote:
On 9/14/2014 5:32 PM, Phil Hobbs wrote:

Acquisition aids are a separate problem. I was talking about
*resynchronizing*, which is important here in two ways. First, the
jitter from the divide-by-1944 circuit has to be eliminated.

Why do you not understand that the jitter and delay of the divided
clock
is not an issue? It is not being used to clock anything. It is only
being used to isolate the actual clock edges by enabling the FF. It
only has to meet setup and hold times.

Packaged D-flops rarely come with clock enable pins in my universe.
John
specifically said that you needed to drive the DFF differentially to
get
the good jitter numbers, so despite having CLK and /CLK pins, there's
nothing to use as a clock enable.

The usual method for resynchronizing is to put the divider output into
D
and clock it with the undivided signal.


BTW, the FF has to be clocked by the same clock that is being divided
down. Otherwise you get 1 full clock cycle of jitter in the enable
when
you sync it to the other clock.

Doing that would break the PLL, so I'm obviously not proposing
anything
so idiotic.

How would that break the PLL? The reference clock is sampled by the D
input clocked by the VCXO clock. The divided signal has to be an
enable
on the FF or it won't work because of the inherent delays in generating
the divided signal.

Nonsense. It just has to observe the setup and hold times.


If you reclock the divided signal there will be tons of delay in even
an
ECL FF.


Putting a DFF on the counter output and clocking it with the 10 MHz
makes a crappy bang-bang phase detector, not a resynchronizer.

I have no idea what you are talking about. You seem to have a very
different picture of what the correct circuit is than I do. I think we
are not talking about the same circuits.

About like this:

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



--

What is the 1 PPS for? I must have missed that message.

I did mention that somewhere. Ultimately I have to send out fiberoptic
data frames that include time-of-day fields. The GPS box gives me 10
MHz and 1 PPS references, and an occasional Ethernet message will give
me time to within 1 second. The FPGA contains the counters and logic
and stuff, and a uP manages things at the millisecond level. The whold
project is pretty straightforward except for the PLL.

The trick is to make everything stable to picoseconds. The entire
system error budget is 100 ps, of which I can claim a small share.


--

John Larkin Highland Technology, Inc

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

 

[Jeroen Belleman]

On 2014-09-15 16:26, Piotr Wyderski 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?

Best regards, Piotr

An NCO doing Fc*125/1944 and clocked at Fc=155.52 MHz would put
out 10 MHz, with small cycle-to-cycle errors in a pattern that
repeats every 12.5 us. Easy to do in binary in an FPGA.

Jeroen Belleman

 

[Spehro Pefhany]

On 15 Sep 2014 10:08:14 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:

On 2014-09-14, John Larkin <jlarkin@highlandtechnology.com> wrote:
On Sun, 14 Sep 2014 20:06:44 GMT, Jan Panteltje <panteltje@yahoo.com
wrote:


How come the Enterprise, no matter how badly it was shot up, never
lost pressurization and never lost its artificial gravity generator?

And why did they always beam into derelict spaceships and alien
planets that had breathable atmospheres and Earth-level gravity?

Why were no babies ever born on the Enterprise? Why did nobody ever
bleed or vomit? Did they have unisex rest rooms? Did they have
bathtubs? Where were the trash cans? Were snacks not allowed on the
bridge?

The producer didn't have the special-effects budget.

Apparently some snacks were allowed:

https://www.youtube.com/watch?v=Z1EZK0CKtK4

 

[Kevin Aylward]

"Phil Hobbs" wrote in message news:54160BAF.3090808@electrooptical.net...

On 9/14/2014 2:02 PM, Kevin Aylward wrote:

"Gerhard Hoffmann" wrote in message
news:c7l84fFsqprU1@mid.individual.net...

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

PLL are useful when you want programmability in frequency and no
inductors,
but 80 year old LC tank technology blows PLL away in terms of noise
performance. For example, meeting -150 dBc (30fs jitter) flat band
phase
noise at 2.5GHz is, essentially, not achievable with PLL techniques,
not
that I am giving anything away on one of my current projects...

http://cds.linear.com/docs/en/datasheet/6948f.pdf

shows only -100dBc/Hz on its performance curves.

???
on page 8 I see the 3 and 4 GHz units break the -150 dBc/Hz
at 10 MHz offset, still linearly sinking towards the flat
noise floor.

Ah... I should add... flat band noise with a multiplication of times 9
Multiplying up has an inherent theoretical noise increase of 20.log(mult
ratio), so a times 9 is going to increase the basic oscillator phase
noise by around 20dB, irrespective of any added noise of the processing.

But not the jitter. The reason the phase noise goes up is that the jitter
stays more or less the same, but the period goes down by a factor N, so the
phase fluctuations increase by N times.

Sure.

Going back to "Ultra low noise claim of the 6948f" data sheet above, I now
see that at ~2.5Ghz it is -100dBc at 100k offset, and -130dBc at 1MHz. A
decent x9 (277Mhz->2.5Ghz) LC tank design should come it at around -145 dBc
at those frequency offsets. So ultra low noise appears to be relative to the
claimer

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

 

[Kevin Aylward]

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

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

 

[Phil Hobbs]

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.

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

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.

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