PLL tricks

[John Larkin]

On Tue, 16 Sep 2014 10:58:08 -0700, dplatt@coop.radagast.org (David
Platt) wrote:

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.

The question is whether the 1 PPS ever happens any more or any less
than 10,000,000 cycles of the 10 MHz output.

I'd be shocked if it ever did.

The phase relationship between the 1PPS TTL rise, and the 10 MHz sine
wave, can be measured and allowed for, as long as it never slips a
full 100 ns.


--

John Larkin Highland Technology, Inc

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

 

[rickman]

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

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.

Ok, so your ECL FFs are pointless? You just said the loop averages out
the jitter...

--

Rick

 

John Larkin <jlarkin@highlandtechnology.com> wrote:

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

One [GPS module] 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.

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.

I looked up the particular GPS module I was dealing with. It has a
12.5 MHz internal clock, and the user guide says that since the 1PPS
signal can go on any edge of the internal clock, the quantization error
is +/- 20 ns. Since 10 MHz is 100 ns, you might be OK.

This is implied by the +/- spec, but since the 1PPS output goes on the
*closest* local clock edge, the 1PPS output can go high *before* the
"true" GPS 1PPS would have gone high. The 1PPS output from this module
is 1 millisec wide, so it would still be high when your 10 MHz edge
(or zero crossing) got there.

The user guide also gives a plot of the actual quantization error of
the 1PPS output relative to a cesium clock, and it runs about +/- 21 ns.
There is also a plot after applying the correction supplied over the
serial data, which brings the error down to the +8/-5 ns range. The
serial data is a 32-bit floating-point number, and the documentation
says it is in seconds, but I recall it being in something else,
probably nanoseconds.

There was a newer module from the same company with a faster clock -
about 16 MHz - which reduced the claimed error to +/- 15 ns. The graphs
show an actual error in about that range, and about +5/-5 ns after
correction. The docs for that module say the correction value is in
nanoseconds, which agrees with what I remember.

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.

The modules we were using didn't have a 10 MHz output, so I don't know
how that usually relates to the 1PPS output. I *did* have to make sure
the correction was being applied to the 1PPS output in software, because
that was used to steer a very much faster counter (hundreds of MHz).

I need to resync the 1PPS to the 10 MHz, and then promote that event
up to 155.52 MHz, absolutely unambiguously.

I understand the larger problem, but I don't know enough to suggest a
good solution to it. I just wanted to point out that if you need better
than a few dozen nanosec accuracy on the 1PPS signal from the GPS
module, applying the correction is probably a good idea.

Another random thing I'll throw in here: if you are getting any
time-of-day data from the GPS receiver, either directly or through
somebody else, you might like to know that about once every 18 months or
so, it will tell you 23:59:58... 23:59:59... 23:59:60... 00:00:00.
That :60 will confuse your software if it isn't expecting it. (It's
also possible for it to skip 23:59:59, but that hasn't happened yet.)

Matt Roberds

 

[Phil Hobbs]

On 09/16/2014 01:58 PM, David Platt wrote:

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

So your binary counter chips are divide-by-(16 +- epsilon) ?

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 09/16/2014 12:27 PM, rickman 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.
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?

You're not thinking very hard, or have forgotten how to go from time to
frequency and back.

Jitter is proportional to phase noise in radians for small excursions

White phase noise -> RMS phase error proportional to sqrt(BW)

BW is 0.5% of rep rate -> sqrt(BW) = 7% of full interval -> max RMS
jitter is ~ 7% of 1.4 ps ~= 0.1 ps.


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 09/16/2014 10:52 AM, Bill Sloman wrote:

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, you keep ignoring the problem of drift. It's quite true that you
can get good noise performance with an ordinary phase detector, but if
you estimate the drift level you need in order to maintain 1 ps
accuracy, it's horrendously small.

According to John's measurements, the picosecond ECL DFF has jitter too
small to measure easily and very low tempco of propagation delay. It
also has some gigantic gain, so drift of other elements in the loop
hardly contributes at all.

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 09/16/2014 01:49 PM, John Larkin wrote:

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.

The problem with N750 and N1500 caps is the loose tolerance on the
tempco, which iirc is about +- 20%. Good enough for ham radio onesies,
together with the home oven and freezer, but pretty tough user for
first-principles compensation. You might be able to get a bit closer by
measuring a few off a given reel, but then it'll change with soldering,
stress, and so forth.

Finding a topology that's insensitive might be possible, e.g. a high Q
LPF followed by another high Q HPF, with your 10 MHz selected to be in
the flatband between them. It's situations where the total reactance is
changing rapidly that you want to avoid.

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

 

[Dimitrij Klingbeil]

On 16.09.2014 20:13, John Larkin wrote:

The question is whether the 1 PPS ever happens any more or any less
than 10,000,000 cycles of the 10 MHz output.

I'd be shocked if it ever did.

The phase relationship between the 1PPS TTL rise, and the 10 MHz sine
wave, can be measured and allowed for, as long as it never slips a
full 100 ns.

It probably won't slip more than 100 ns, but it will also likely not
be constant.

If the time source is a Symmetricom XLi series or similar (I think, you
mentioned something about "symetrix" somewhere), then the PPS will
likely be internally synchronized to the 10 MHz.

From the Symmetricom XLi datasheet: "1PPS output accuracy: 30 ns RMS,
100 ns Peak (99%)" - whatever the last "(99%)" may mean ...

The XLi (as well as any decent timing receiver of modern vintage) should
be able to provide sawtooth correction, but the sawtooth correction is
usually provided over a RS-232 serial link as a data value (offset of
last PPS pulse to the true second instant).

This means, the phase relationship between the PPS signal and the true
time will be variable (a sawtooth) and you'll have to account for that
post-factum, by evaluating the message data sent over the serial link.

Again, "Sawtooth Correction" is a very common topic on the Time Nuts
mailing list. The people over there deal with GPS timing receivers on a
daily basis and some of them have developed sophisticated correction
algorithms for the various "gotchas" that these receivers (no matter how
expensive) have. It might be a good idea to search the mailing list
archive for sawtooth related topics. Maybe someone of those guys is even
using a timing receiver of the exact same type as you'll have to use.

Regards
Dimitrij

 

[rickman]

On 9/16/2014 2:39 PM, Phil Hobbs wrote:

On 09/16/2014 12:27 PM, rickman 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.
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?


You're not thinking very hard, or have forgotten how to go from time to
frequency and back.

Jitter is proportional to phase noise in radians for small excursions

White phase noise -> RMS phase error proportional to sqrt(BW)

BW is 0.5% of rep rate -> sqrt(BW) = 7% of full interval -> max RMS
jitter is ~ 7% of 1.4 ps ~= 0.1 ps.

That isn't the PD. He said he wanted a PD with 1 ps of jitter. He has
a PD with 1.4 ps of jitter... I'm just sayin'


--

Rick

 

[rickman]

On 9/15/2014 7:03 PM, Bill Sloman wrote:

On Tuesday, 16 September 2014 00:26:02 UTC+10, 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?

I don't think so. I think the point that was being made was that most DDS chips have a fixed binary modulus or 2^32 or 2^48 or whatever, so that you can't get an exact frequency match to any number that isn't a power of two.

I'd be willing to bet that most DDS chips are FPGAs or CPUs where you
can do whatever you like.

--

Rick

 

[Gerhard Hoffmann]

Am 16.09.2014 um 17:27 schrieb John Larkin:

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.

Rene Tschaggelar from Switzerland.
http://www.ibrtses.com/products/PhaseNoise102.exe

Looks like his website is slowly decomposing.
But I have no right to complain.

Gerhard

 

[rickman]

On 9/16/2014 3:00 PM, Dimitrij Klingbeil wrote:

On 16.09.2014 20:13, John Larkin wrote:

The question is whether the 1 PPS ever happens any more or any less
than 10,000,000 cycles of the 10 MHz output.

I'd be shocked if it ever did.

The phase relationship between the 1PPS TTL rise, and the 10 MHz sine
wave, can be measured and allowed for, as long as it never slips a
full 100 ns.

It probably won't slip more than 100 ns, but it will also likely not
be constant.

If the time source is a Symmetricom XLi series or similar (I think, you
mentioned something about "symetrix" somewhere), then the PPS will
likely be internally synchronized to the 10 MHz.

From the Symmetricom XLi datasheet: "1PPS output accuracy: 30 ns RMS,
100 ns Peak (99%)" - whatever the last "(99%)" may mean ...

The XLi (as well as any decent timing receiver of modern vintage) should
be able to provide sawtooth correction, but the sawtooth correction is
usually provided over a RS-232 serial link as a data value (offset of
last PPS pulse to the true second instant).

This means, the phase relationship between the PPS signal and the true
time will be variable (a sawtooth) and you'll have to account for that
post-factum, by evaluating the message data sent over the serial link.

Again, "Sawtooth Correction" is a very common topic on the Time Nuts
mailing list. The people over there deal with GPS timing receivers on a
daily basis and some of them have developed sophisticated correction
algorithms for the various "gotchas" that these receivers (no matter how
expensive) have. It might be a good idea to search the mailing list
archive for sawtooth related topics. Maybe someone of those guys is even
using a timing receiver of the exact same type as you'll have to use.

I believe he doesn't really care about the "exact" position of the 1
pps. As he has said he is using the 1 pps to establish the "time"
relative to the 10 MHz. The 99% is interesting. If that really is
correct and 1 in 100 is outside the 100 ns window, he may have to add
some circuitry in the FPGA to ignore errant 1 pps pulses. That should
be easy enough. Just requiring three consecutive errors in a row will
reduce the chance of a errant resync to better than once a week. Making
that number 5 anomalies makes for an errant resync once in 300 years.

Only the single clock errors need to be ignored. If the 1 pps is many
clock cycles out it is either noise or someone pulled the cable off.

A friend designed something vaguely like this for the Naval Observatory.
It received a 100 MHz clock from a new atomic clock and a 1 pps from
the Kalman filter they used to average all the various clock sources.
It then produced a 1 pps that was fed into the filter as this atomic
clock's 1 pps.

--

Rick

 

[David Platt]

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

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.




The question is whether the 1 PPS ever happens any more or any less
than 10,000,000 cycles of the 10 MHz output.

I'd be shocked if it ever did.

The phase relationship between the 1PPS TTL rise, and the 10 MHz sine
wave, can be measured and allowed for, as long as it never slips a
full 100 ns.

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

According to these graphs, the old Oncore VP had a 9.54 MHz
oscillator, and its sawtooth *could* jump more than 100 nanoseconds
between one sample or the next on occasion (not often but it did
happen).

This matches my own experience, using an Oncore UT+ in a
GPS-disciplined frequency-locked 10 MHz oscillator project, and that
of another developer with whom I've traded code and ideas. Both of us
have noticed occasional one-sample "slips" in the Oncore GPS timing,
which causes a substantial hiccough in the frequency lock. I think
that may be what you'll see in the data for 9/9/14 at

http://snulbug.mtview.ca.us/dave/fll.png

where you can see the frequency error (purple) and the VXCO control
voltage (green) bounce around.

The later Oncore M12+ has a higher-speed LO clock and it looks as if
its worst-case sample-to-sample jitter would be under 50 nanoseconds.
Modern timing-grade GPS receivers are probably quite a bit better.

 

[jeroen Belleman]

On 16/09/14 17:27, John Larkin wrote:
[..]

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.

Nope, not me. Rene Tschaggelar perhaps?

Jeroen Belleman

 

[Dimitrij Klingbeil]

On 16.09.2014 04:49, Bill Sloman wrote:

On Tuesday, 16 September 2014 11:21:09 UTC+10, John Larkin wrote:

Fox and SciLabs make tiny surface-mount synthesized (any frequency
you want) VCXOs with PECL outputs and claimed sub-ps RMS jitter.
The question is, over what time span is the jitter that low?

If you ask, they will probably tell you.

You aren't interested in longer periods, because eventually you are
going use their voltage input to lock the frequency to the 10MHz
reference which you are given as part of your site services, and to
which you are obliged to lock your 155.52MHz frequency source.

...
http://www.silabs.com/Support%20Documents/TechnicalDocs/si550.pdf

Careful with that Si550!

I've used that one, and when running at a constant frequency, it has
indeed very low phase noise, put it seemed to have one major WTF when
it comes to frequency tracking. See below for details...

The thing internally uses a programmable PLL that runs around several
GHz. The exact value is not specified, and it's not fixed anyway.

The PLL parameters are programmed by SiLabs in the factory, that's what
allows the parts to be made to order within a week to any imaginable
center frequency with 5 decimal digits precision.

The PLL is locked to an internal crystal oscillator, but the crystal
itself is NOT pullable in an "analog" way. Instead the "VCXO" control
voltage input internally goes to an ADC, is digitized (no, they don't
specify at how many bits resolution), and then some logic digitally
calculates the correction values to the PLL registers and adjusts the
running PLL. They don't specify directly how many times per second that
adjust rate is, but their maximum specified modulation rate of 10 kHz
means that the adjust rate is 20k updates per second or thereabouts.
(As I remember, John was not pleased with a prospective 80k rate...)

Now to the "WTF".

When the digital RF PLL in that Si550 is "updated" with a new ADC value,
it seems to do that in a rather strange way. The update rate is not
externally visible and the module was a pig to debug, so I did not find
out what exactly happened in there, but the outside observable effects
suggested that the PLL update was sometimes happening unpredictably. It
seemed that, if the update happens at the wrong moment, the PLL can hit
a glitch - like issuing an uncontrolled cycle or skipping a cycle (not
sure which one of them it was).

Whatever it was, it was big enough of an issue to sometimes cause the
internal DLL in a Xilinx FPFA to lose sync and spit out a number of
uncontrolled cycles into the FPGA logic. When the Si550 control voltage
was held constant (shorted to a fixed voltage), that never happened, but
when the Si550 was being actively controlled, the resulting clock from
it would sometimes (semi-regularly) throw a wrench in the FPGA. The FPGA
was processing video, and the result was loss of framing. In the end, I
fixed this by putting an analog 1:1 PLL (just to clean the artifacts)
between the Si550 and the rest of the circuitry (2 FPGAs and DSPs).
The analog PLL tracked the frequency and it did not pass through the
glitches, so the solution worked (at the expense of an additional PLL).

This adventure was some 4 years ago, so SiLabs may have fixed the Si550
by now, who knows. Or it could have been something entirely different
(although difficult to imagine what exactly). In any case, before using
it in an application that is sensitive to absolute timing, it may be a
good idea to run a test with full scale modulation and watch carefully.

Regards
Dimitrij

 

[Bill Sloman]

On Wednesday, 17 September 2014 04:44:04 UTC+10, Phil Hobbs wrote:

On 09/16/2014 10:52 AM, Bill Sloman wrote:
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, you keep ignoring the problem of drift. It's quite true that you
can get good noise performance with an ordinary phase detector, but if
you estimate the drift level you need in order to maintain 1 ps
accuracy, it's horrendously small.

If the cycle time of the 10MHz waveform - 100nsec - is equated to a full-scale of 1V then 1psec is 10uV. A Faulkner and Harding long-tailed pair phase detector built around a a monolithic dual transistor can do that well without any effort. The equivalent with a dual FET can do better (but you need a bigger gate drive than you need base drive - bigger than you can easily get directly from ECLinPS).

E.A.Faulkner and D.W.Harding - Journal of Scientific Instruments (UK) volume 43 starting on page 97 (1966). J. Sci. Instr. published two other variations in 1968. It wasn't rocket science then, and it certainly isn't now.

In other words the offset performance required is small, but well short of horrendously small. Since - as we've worked out - the PLL is there to keep the 155.52MHz in frequency lock with the 10MHz reference, the absolute offset doesn't matter (though it won't be big).

According to John's measurements, the picosecond ECL DFF has jitter too
small to measure easily and very low tempco of propagation delay. It
also has some gigantic gain, so drift of other elements in the loop
hardly contributes at all.

He also points out that the gain depends on the jitter level. Designing a stable phase locked loop around a phase detector with uncertain gain is tricky.

Product detectors have a very stable and predictable gain (in volts per radian), and they inject a great deal less random noise into the loop.

My impression is that John got his bang-bang detector to work by his usual exhaustive fiddling, and hasn't explored the other options as carefully as he might have.

--
Bill Sloman, Sydney

 

[rickman]

On 9/16/2014 4:52 AM, Jan Panteltje wrote:

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

I'm afraid I can't read your schematic. How are the FETs connected to
the transformer? It looks like all the gates, all the drains and the
two coils of the transformer are all shorted together.

--

Rick

 

[rickman]

On 9/16/2014 4:45 PM, rickman wrote:

On 9/16/2014 4:52 AM, Jan Panteltje wrote:
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

I'm afraid I can't read your schematic. How are the FETs connected to
the transformer? It looks like all the gates, all the drains and the
two coils of the transformer are all shorted together.

Opps, make that all the gates and all the sources...

--

Rick

 

[Bill Sloman]

On Wednesday, 17 September 2014 03:49:42 UTC+10, John Larkin wrote:

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:

How would you calculate the phase tempco of a filter?

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.

Mullard's (now Ferroxcube's) nickel-zinc ferrite cores (blue series) were touted as having an equal and opposite temperature coefficient to polystyrene capacitors.

And if the filtered output of the phase detector is only going to have useful content at around 500Hz and below, you could run an A/D converter on the crudely filtered output and do the serious frequency shaping digitally.

You'd want about 20-bits at the output, but that's easy enough at 500Hz and below.

--
Bill Sloman, Sydney

 

[John Larkin]

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

On 9/16/2014 3:00 PM, Dimitrij Klingbeil wrote:
On 16.09.2014 20:13, John Larkin wrote:

The question is whether the 1 PPS ever happens any more or any less
than 10,000,000 cycles of the 10 MHz output.

I'd be shocked if it ever did.

The phase relationship between the 1PPS TTL rise, and the 10 MHz sine
wave, can be measured and allowed for, as long as it never slips a
full 100 ns.

It probably won't slip more than 100 ns, but it will also likely not
be constant.

If the time source is a Symmetricom XLi series or similar (I think, you
mentioned something about "symetrix" somewhere), then the PPS will
likely be internally synchronized to the 10 MHz.

From the Symmetricom XLi datasheet: "1PPS output accuracy: 30 ns RMS,
100 ns Peak (99%)" - whatever the last "(99%)" may mean ...

The XLi (as well as any decent timing receiver of modern vintage) should
be able to provide sawtooth correction, but the sawtooth correction is
usually provided over a RS-232 serial link as a data value (offset of
last PPS pulse to the true second instant).

This means, the phase relationship between the PPS signal and the true
time will be variable (a sawtooth) and you'll have to account for that
post-factum, by evaluating the message data sent over the serial link.

Again, "Sawtooth Correction" is a very common topic on the Time Nuts
mailing list. The people over there deal with GPS timing receivers on a
daily basis and some of them have developed sophisticated correction
algorithms for the various "gotchas" that these receivers (no matter how
expensive) have. It might be a good idea to search the mailing list
archive for sawtooth related topics. Maybe someone of those guys is even
using a timing receiver of the exact same type as you'll have to use.

I believe he doesn't really care about the "exact" position of the 1
pps. As he has said he is using the 1 pps to establish the "time"
relative to the 10 MHz. The 99% is interesting. If that really is
correct and 1 in 100 is outside the 100 ns window, he may have to add
some circuitry in the FPGA to ignore errant 1 pps pulses. That should
be easy enough. Just requiring three consecutive errors in a row will
reduce the chance of a errant resync to better than once a week. Making
that number 5 anomalies makes for an errant resync once in 300 years.

Only the single clock errors need to be ignored. If the 1 pps is many
clock cycles out it is either noise or someone pulled the cable off.

A friend designed something vaguely like this for the Naval Observatory.
It received a 100 MHz clock from a new atomic clock and a 1 pps from
the Kalman filter they used to average all the various clock sources.
It then produced a 1 pps that was fed into the filter as this atomic
clock's 1 pps.

Coincidence: I sold the Naval Observatory a bunch of VME fanout
modules, for shooting the 1 PPS stuff around.

http://www.highlandtechnology.com/DSS/V860DS.shtml





--

John Larkin Highland Technology, Inc

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