Re: [time-nuts] femtosecond jitter

[John Larkin]

On 4/15/2018 2:17 PM, Magnus Danielson wrote:

Hi,

On 04/14/2018 06:45 PM, John Larkin wrote:

Hi, Magnus,

We did a little PC board that has two Analog Devices CML comparators
that feed the flop.

   https://www.dropbox.com/s/05ti1c57eush0uq/99S394A.pdf?dl=0

An external DAC tweaks the VBIAS voltage to slew the edge times across
one another, and an external ADC looks at the averaged flop outputs. The
jitter noise floor is probably dominated by the test signals, not the
flop under test.

Ah, thanks. Much clearer now!

You more tweak the voltage than actual timing, it's the slope property
that does the timing, but interesting never the less.


Downstream of the comparators, all the flop sees is time... not voltage 
shift. We used a sampling scope to calibrate the picoseconds-per-volt 
slope of the voltage input from the DAC.



--
** arb

John Larkin, President
Highland Technology, Inc
18 Otis Street
San Francisco, CA 94103

phone 415 551-1700   fax 551-5129
jjlar...@highlandtechnology.com
http://www.highlandtechnology.com

This is a Highland Technology confidential communication

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter

[Magnus Danielson]

Hi,

On 04/14/2018 06:45 PM, John Larkin wrote:
> Hi, Magnus,
> 
> We did a little PC board that has two Analog Devices CML comparators
> that feed the flop.
> 
>   https://www.dropbox.com/s/05ti1c57eush0uq/99S394A.pdf?dl=0
> 
> An external DAC tweaks the VBIAS voltage to slew the edge times across
> one another, and an external ADC looks at the averaged flop outputs. The
> jitter noise floor is probably dominated by the test signals, not the
> flop under test.

Ah, thanks. Much clearer now!

You more tweak the voltage than actual timing, it's the slope property
that does the timing, but interesting never the less.

> We considered something like a micrometer-driven
> differential trombone line... note that 1 fs is one PPM of a nanosecond,
> how far light travels in 12 micro-inches.

Yeah, that would be "interesting" and maybe more work than you wanted to
game for.

> The quantization is probably DAC resolution. The step function is just
> the integral of the histogram.

Sure.

> This is going into a test set that needs maybe 1 ps RMS noise floor, so
> this flop is hugely better than what we need. It's a big deal to set
> this up, so I don't think we'll do any more measurements.

For that needed precision, this seems not to be your limiting factor,
for sure. Good work.

OK. it would have been interesting to characterize it further.

> As a bang-bang phase detector, with some lowpass filtering in the loop,
> this flop would have a noise floor in the attosecond range. You're
> right, temperature will dominate low-frequency noise, and not just in
> the flop.

Yes. With both sensor and steering you can temperature compensate it.
With modest thermal isolation you can keep changes slow enough for
compensation to have a chance.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter

[John Larkin]

Hi, Magnus,

We did a little PC board that has two Analog Devices CML comparators 
that feed the flop.


  https://www.dropbox.com/s/05ti1c57eush0uq/99S394A.pdf?dl=0

An external DAC tweaks the VBIAS voltage to slew the edge times across 
one another, and an external ADC looks at the averaged flop outputs. The 
jitter noise floor is probably dominated by the test signals, not the 
flop under test. We considered something like a micrometer-driven 
differential trombone line... note that 1 fs is one PPM of a nanosecond, 
how far light travels in 12 micro-inches.


The quantization is probably DAC resolution. The step function is just 
the integral of the histogram.


This is going into a test set that needs maybe 1 ps RMS noise floor, so 
this flop is hugely better than what we need. It's a big deal to set 
this up, so I don't think we'll do any more measurements.


As a bang-bang phase detector, with some lowpass filtering in the loop, 
this flop would have a noise floor in the attosecond range. You're 
right, temperature will dominate low-frequency noise, and not just in 
the flop.


John


On 4/14/2018 5:59 AM, Magnus Danielson wrote:

John,

How where these measurements done?
Also, it looks like you have a systematic component in there, about 80
fs guestimating from the plot creating essentially two tracks up the
slope that is the tell-tale of a sinuoid phase modulation of some source.

Considering the temperature stability that you nicely plotted as a
quadratic shape, it seems like a good thermal stability is needed, which
comes as no big chock.

Can do you do a longer measurement and accumulate the data in a
2D-histogram fashion? That is count occurrences for the amplitude/time
position and then color code it accordingly? That have proved to be a
good tool for analysis.

Cheers,
Magnus

On 04/13/2018 05:54 PM, John Larkin wrote:

If you walk the differential data and clock inputs of an NB7V52  CML
flipflop across one another in time, the equivalent jitter is below 20
fs RMS. That's what we're measuring, but our test rig may well dominate
the jitter, so the flop is probably better.

We're using this to test the jitter of some of our timing products, with
1/10 the noise floor and 1e-4 times the cost of other ways to do it.

https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1

https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1

https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



--
** arb

John Larkin, President
Highland Technology, Inc
18 Otis Street
San Francisco, CA 94103

phone 415 551-1700   fax 551-5129
jjlar...@highlandtechnology.com
http://www.highlandtechnology.com

This is a Highland Technology confidential communication

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter

[Attila Kinali]

On Fri, 13 Apr 2018 08:54:41 -0700
John Larkin  wrote:

> If you walk the differential data and clock inputs of an NB7V52  CML 
> flipflop across one another in time, the equivalent jitter is below 20 
> fs RMS. That's what we're measuring, but our test rig may well dominate 
> the jitter, so the flop is probably better.

I heard similar numbers for the NB7V52 last week at EFTF. So you
cannot be that far off.

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter

[Magnus Danielson]

John,

How where these measurements done?
Also, it looks like you have a systematic component in there, about 80
fs guestimating from the plot creating essentially two tracks up the
slope that is the tell-tale of a sinuoid phase modulation of some source.

Considering the temperature stability that you nicely plotted as a
quadratic shape, it seems like a good thermal stability is needed, which
comes as no big chock.

Can do you do a longer measurement and accumulate the data in a
2D-histogram fashion? That is count occurrences for the amplitude/time
position and then color code it accordingly? That have proved to be a
good tool for analysis.

Cheers,
Magnus

On 04/13/2018 05:54 PM, John Larkin wrote:
> If you walk the differential data and clock inputs of an NB7V52  CML
> flipflop across one another in time, the equivalent jitter is below 20
> fs RMS. That's what we're measuring, but our test rig may well dominate
> the jitter, so the flop is probably better.
> 
> We're using this to test the jitter of some of our timing products, with
> 1/10 the noise floor and 1e-4 times the cost of other ways to do it.
> 
> https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1
> 
> https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1
> 
> https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1
> 
> 
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter

[Bruce Griffiths]

Thus a DDMTD using NB7V52's as the mixers should have useful performance

Bruce 
> On 14 April 2018 at 03:54 John Larkin  wrote:
> 
> 
> If you walk the differential data and clock inputs of an NB7V52  CML 
> flipflop across one another in time, the equivalent jitter is below 20 
> fs RMS. That's what we're measuring, but our test rig may well dominate 
> the jitter, so the flop is probably better.
> 
> We're using this to test the jitter of some of our timing products, with 
> 1/10 the noise floor and 1e-4 times the cost of other ways to do it.
> 
> https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1
> 
> https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1
> 
> https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1
> 
> 
> -- 
> ** arb
> 
> John Larkin, President
> Highland Technology, Inc
> 18 Otis Street
> San Francisco, CA 94103
> 
> phone 415 551-1700   fax 551-5129
> jjlar...@highlandtechnology.com
> http://www.highlandtechnology.com
> 
> This is a Highland Technology confidential communication
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] femtosecond jitter

[John Larkin]

If you walk the differential data and clock inputs of an NB7V52  CML 
flipflop across one another in time, the equivalent jitter is below 20 
fs RMS. That's what we're measuring, but our test rig may well dominate 
the jitter, so the flop is probably better.


We're using this to test the jitter of some of our timing products, with 
1/10 the noise floor and 1e-4 times the cost of other ways to do it.


https://www.dropbox.com/s/1i2yz7otty94o9l/NB7_Jitter_1.jpg?raw=1

https://www.dropbox.com/s/qahpb8uh1xr53vj/NB7_Steps.jpg?raw=1

https://www.dropbox.com/s/tpphhi79yxgzy34/NB7_tc.jpg?raw=1


--
** arb

John Larkin, President
Highland Technology, Inc
18 Otis Street
San Francisco, CA 94103

phone 415 551-1700   fax 551-5129
jjlar...@highlandtechnology.com
http://www.highlandtechnology.com

This is a Highland Technology confidential communication

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack]

Folks, thanks for your input and sanity checking.  To recap...

Having never worked with crystals before (only 2 and 10 GHz stuff in  
GaAs power amp RFIC design for cell phone and the like using lab RF  
generators or Vitesse / AMCC asics with clock recovery already done by  
someone/something  else back in the 1990s),   I am revamping this  
design moving away from an OCXO and seeing what the design holds for  
TCXOs and the like.


A 4 layer board is going to be several hundred dollars due to the size  
of the board and I would like to get as close to ideal on the first  
shot (yes indeed there will probably be another spin)...  Since I only  
have experience in the 2+ GHZ region I was originally concerned about  
via stubs with reflection induced effects, having no feel for this  
low frequency region.


I am having issues trying to get the simulator programme for the  
LMK04000 to synch to 44.1kHz and generate 11 / 12 MHz.  One idea I  
suppose: I am looking at preceding the LMK04000 with the Si5326 which  
is a narrow band part compared to the wideband Si5319 to get 44kHz up  
to 10MHz...  Then the LMK04000 can take 10MHz from this or 10MHz from  
an external source outside the box and get it to the final 11 / 12 MHz  
for distribution internal to the box to the converters.  The Si5326  
can also provide an internally derived 10MHz from its reference  
port, so that all design criteria for clocking is satisfied (internal  
clocking mode and external synch to 44.1kHz or 10M external).  I can  
use a 3rd overtone crystal to provide the reference port frequency on  
the Si5326


Regarding spurs in the near carrier region... Yes. these datasheets  
are a bit of a black box, and every time I look at them they give up  
another layer of the onion... I wonder about the tiny spurs on the  
LMK04000 near 100 Hz on their data (granted different carrier  
frequency, 250MHz).  Does anyone have any experience with these chips  
or have a better suggestion; is there even an issue with these small  
spurs?


Cheers,
-chris



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[J.D. Bakker]

[Another late reply -- Easter and taxes got in the way]

At 09:59 -0400 09-04-2009, Chris Mack / N1SKY wrote:
Imagine this: if you were the mastering engineer for Elvis 50 years 
ago, and if today's digital technology was available back then, would 
you want to archive the King's record inside Iron Mountain on MP3?  
Not really, you would want the most resolution possible for the re-
release onto 32-bit 384kHz whiz-bang chip media in the future.  And 
cumulative error for successive re-releases over the decade for 
frequency drift and re-archival is maybe another concern.


What cumulative errors are going to impact digital-digital transfers??


For example, I am currently using a Rosendahl Nanoclocks (http://
www.rosendahl-studiotechnik.com/nanoclocks.html) for my house master 
word clock and a $6k Eventide Orville for processing of audio.  The 
Eventide used to measure the Nanoclocks at 88200 Hz... now it 
measures 88201 Hz 4 years later... something drifted  The 
Rosendahl uses normal ambient crystals (although they have trimmer 
caps) and use 74ACT00 logic to drive the distribution outputs.  The 
Eventide, I assume uses normal ambient crystals too for the myriad of 
DSPs in it


(What do you mean by 'ambient crystal'? AT cut with minimal df/dT at 
room temperature?)


So your Nanoclock drifted relative to your Eventide. Even assuming 
that the absolute frequency shift of your converter clock was this 
much, that translates to a pitch shift of 0.02 cent. Find me *anyone* 
who can hear that in an ABX test. For that matter, try finding a 
string instrument that stays within 0.02 cent of its tuning after a 
minute or two of playing.


[snip]

I believe Mr. Lavry for his 127dB ADC uses an OCXO which helps 
achieve the specs.  http://www.lavryengineering.com/

productspage_pro_ad122_96mk.html


The fact that one good converter uses an OCXO doesn't mean that you 
have to use an OCXO to build a good converter. The Grimm one 
mentioned by Chris C gets by just fine without one, for example.


JDB.
[plus, all things being equal an ovenized oscillator has higher 
Johnson noise than one running at room temperature]

--
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lartmaker.nl/

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Caudle]

Just for the sake of indexing the archives, I'm sending  this message to
point out the correct subject line of my immediately previous message (Thu
Apr 23 04:19:39 UTC 2009). I always hate it when mail has the digest
header instead of the real subject, then I went and did it myself.

-- 
Chris Caudle


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack]

Hey Chris,

Thanks for the response...  notes below

On Apr 23, 2009, at 12:19 AM, Chris Caudle wrote:

I'm a little late following up on this, but hopefully not too out of  
context.


On Wed, April 8, 2009 10:23 pm, Chris Mack wrote:

The box / design of interest has ADCs, DACs, and a 38.88MHz OCXO of
marginal performance coupled with the proposed DSP based PLLs
generating a local clock for the ADCs and DACs all on the same
circuit board in synch with external gear.


This sounds like a very complicated way to avoid having to make a PLL.
Why don't you just use a good quality VCXO in a PLL to sync to the  
house

clock, and a really low loop frequency, assuming your VCXO phase noise
specs are better than the house clock phase noise at the PLL corner
frequency?



The Silicon Labs DSPLL(TM) chip is a 3 port device... Ovenized xtal on  
the reference clock port (also clocks the DSP internally), input clock  
(house word clock or rubidium) port, and output clocked port (cleaned  
version of input clock).  The xtal reference port needs a low jitter  
clock as it will transfer its jitter to the output clock in a 1:1  
ratio The frequency is not as critical (long term) e.g., aging.   
If the input clock is a 10MHz rubidium that has some short term issues  
with close-in phase noise, the DSPLL will clean it as best it can  
compared to jitter on the ovenized reference port


Yes, the DSPLL is a little bit of a different animal from conventional  
VCXO PLLs perhaps?


The DSPLL is a commercially available chip from Silicon Labs (drop it  
on the PCB, terminate differential or single ended I/O, decouple /  
filter power, and program over SPI), similar to National Semiconductor  
analogue PLL chips (LMK04000 family) except that this Silicon Labs  
chip uses a DSP (and a virtualized digitally controlled oscillator  
implemented in the DSP in a standard virtual PLL loop) internal to its  
inner workings.


I can also get every frequency I desire out of this Silicon Labs part  
no matter what I put into it for frequency to synch to (house word  
clock in the kHz range or rubidium at 10MHz), and the National  
Semiconductor could not get some frequencies with discrete and  
standard frequency valued VCXOs (according to their simulator, perhaps  
their numerator / divisor registers do not have enough resolution and  
would be sometimes out of range)...  And some frequency outputs of the  
National part had some phase noise issues as I recall.


I had trouble finding a proper VCXO for the National part for the  
frequencies of interest and it was in the $50 range where the Silicon  
Labs chip is in the $30 range with no need for a VCXO (albeit an  
ovenized oscillator, but as shown below the ovenized will provide a  
rock solid internal reference when not synchronized to an external  
clock)...


The Silicon Labs also provides great jitter specs for the SONET crowd  
in the femtosecond region (caveat BW of measurement)...


With these DSP based PLLs and clock distribution I am probably going  
to be somewhere just below 1ps of jitter




This 38.88MHz is a DSP clock, essentially a microprocessor clock
(albeit a very nice microprocessor clock) where the DSP simulates a
PLL operating on an incoming clock source, and makes an output clock
of a different frequency, but synchronized to be within AES standards


Yeah, but the out clock is an integer multiple of the in clock, so you
don't really need to jump through synthesizer hoops when a simple  
divider

in a PLL will do.



Indeed, however,  it is a full fractional type DSP PLL and is  
approximately 0.000 ppm for the desired output frequencies compared to  
input frequencies in the frequency plan (as I recall... I haven't run  
the Silicon Labs simulator for the DSP PLL in a couple of months)...
The DSP PLL also has dividers on the clock outputs for integer related  
clocks (e.g., 11 / 22 MHz and 12 / 24MHz used for the oversampled  
44.1kHz and 48kHz that add some jitter I think... not too bad though  
as I recall)


I looked at something similar to see if you could save cost by  
avoiding
the need to have different VCXO's for 44.1k based and 48k based  
material,
and it is difficult to find off the shelf devices that have suitably  
low

phase noise and no spurs in the phase noise. I think in the end it
probably ends up being simpler to get the performance you are  
looking for

by just buying a good VCXO, or two if you need to handle 44.1k and 48k
based material.



I now have the design down to 2 PLLs from 3 PLLs and am now  
distributing the 256 and 128 x oversampled clock frequencies of  
11.2896 MHz and 12,288 MHz after the disclosure of some low jitter ECL  
distribution chips by Bruce (thanks Bruce)...


I still have one performance issue to *maybe* figure out and that is  
the rise time from the DSP PLL chips is slow; maybe 1.2 to 1.4 V/ns  
(74AC is faster I think?)... Even though they are ECL, LVPECL, LVDS  
etc. based clock outputs, they 

Re: [time-nuts] femtosecond jitter anyone?

[Chris Caudle]

By the way, I'm a little new to the list, someone give me and Chris M. a
nudge if this gets a little too audio-specialized and you want us to take
this off list.

 The Silicon Labs DSPLL(TM) chip is a 3 port device...

I'm pretty familiar with the SiLabs devices, those are the ones I
investigated before giving up as not suitable for audio.  Your mileage may
vary. I may have to re-evaluate my opinion as well, I noticed a few things
I had missed before after you mentioned them.

 The frequency is not as critical (long term) e.g., aging.

Which is why I wondered why all the drama with the expensive oven units. 
Why not just put a $10 TCXO on there and spend the savings elsewhere?

 Yes, the DSPLL is a little bit of a different animal from conventional
 VCXO PLLs perhaps?

Yes and no.  The principles are the same, but you get different artifacts
because you are effectively moving to a sampled domain for clock control. 
Spurs in the phase noise, for example.

 I can also get every frequency I desire out of this Silicon Labs part

Yes, but the performance is not identical for every input/output frequency
relationship.  SiLabs have done some really clever things to minimize
those kinds of problems, but look very closely at the phase noise plots,
you'll see some significant spurs, and the 1/f corner frequency is too
high for my liking.

 Labs chip is in the $30 range with no need for a VCXO (albeit an
 ovenized oscillator

Why the big hang up on ovenized?  AES11 recommends 1ppm for multi-studio
synchronization systems, and just 10ppm for single studio systems. You
could do a couple ppm with TCXO, especially if you don't plan on taking
your equipment outdoors, i.e. it will stay in a narrow temperature range.

 The Silicon Labs also provides great jitter specs for the SONET crowd
 in the femtosecond region (caveat BW of measurement)...

Are you talking about the Si5319, or something in that range?  Look at the
phase noise specs.  At 100Hz offset just -65dBc/Hz.  Not too expensive
quartz oscillators can do -125dBc/Hz, good ones can do -135dBc or -145dBc
at 100Hz offset from carrier.  The Si5319 doesn't really hit its stride
until 100kHz offset from carrier, which is way outside what you care about
for audio sampling.

[Came back to edit this: just noticed that those phase noise numbers were
with a 622MHz output, so you can't compare apples to apples by looking at
a dBc/Hz number for a 12MHz clock; I wish they would just use absolute
numbers, s/Hz values;  If that phase noise plot scales, it would be about
-95dBc/Hz for 12MHz, which is not bad, but still not as good as you could
get with a clean fundamental crystal).

The Si5300 seems to have a  phase noise floor that increases at around
60dB/decade from 1000Hz down.  That makes me a little nervous for audio
use because it is starting to increase rapidly while still in the
frequency range that can cause audible sidebands.  Also, the datasheet
just shows telecom frequencies, I would want to measure and verify the
performance with the intended input/output frequencies, and also verify
that no spurs popped up if the input clock was a little off nominal, e.g.
use a VCXO as an input, and sweep it through its adjustment range while
monitoring the output of the synthesizer phase noise.

Do you have an eval board and a way to measure phase noise?  I could
probably hook you up with an eval board if you need it, but I don't have
anything that can measure phase noise down to those levels at the moment.

 With these DSP based PLLs and clock distribution I am probably going
 to be somewhere just below 1ps of jitter

Single numbers like that are not as useful as phase noise plots.  Look at
the AES preprints from Chris Travis and Bruno Putzeys, they have a lot
more to say on the subject than is appropriate for this email.  Preprint
6122 by Putzeys is especially good, as is 6293 by Chris Travis.

 This is a good idea... I have thought about copying and distributing
 the 38.88MHz external to the box as a master clock for other DSPLL
 based boxes,

I meant either generate 44.1kHz word clock directly, or send the clock to
an AES3 transmitter with data line muted AES11 style, or send the
11.2896MHz clock out like Digidesign does for their so-called SuperClock
inputs.  38.88MHz is pretty unusual, only your custom equipment would be
able to use it. If this is a two channel mastering studio, how many analog
conversions are you going to have?  If you do all the processing digital,
only the A/D and D/A need the clean clocks, everything else just needs to
be able to recover the data with no errors.  If you are doing lots of
conversions because you still have a lot of analog processing then I could
see why you might need several devices with the supremo PLL's inside.

 internal oversampling frequencies desired by their converters or
 DSPs)

Only conversion between domains matters (analog to digital, or digital to
analog).  Anything which is digital in to DSP to digital out can have a

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack]

Awesome... Thanks for being a sounding wall everyone

Indeed I am using the SRCs from TI for both the 2 DACs and the single  
ADC...


The 127dB discrete ADCs out there are approximately half bit more in  
dyn range than the 124dB core in the ADC... Indeed, there probably is  
some significant jitter in the clock section for the IC ADC (and it is  
single ended, which the Si5326 also supports form CMOS output)...   
However, I am hoping to try some thermal experiments and some dither  
in the analog domain to see what additional envelope pushing can be  
obtained...


Unfortunately the data sheets for the ADC do not have the crucial  
information that normal high speed ADCs would have including  
temperature data and SFDR, SINAD, ENOB etc..  The specs are kinda  
brain-dead in this regard...


But with distribution and PLLs, the jitter budget should be a little  
bit (pun intended?) better that what the clock portion of the  
converters can do (which is an unknown for this experiment), and who  
knows if the internal clock sections of said converters get better  
with temperature change  Worse case, I get some Johnson noise out  
of the system perhaps...  Or the temperature systems are removed and  
not included in the prototype, but the placeholder is there if it is  
needed...


On the low jitter PLL side... In addition to the Si5326, I found that  
MultiGig has chips that will take 38.88MHz and create 2X or 4X with  
0.34ps jittercaveat bandwidth of measurement...  For the Si5326,  
the higher the reference (jitter reference / DSP clock) frequency the  
better the jitter from CLK_IN to CLK_OUT and jitter cleaning...


Nice chips from Analog too...

I am amazed at how low jitter can be

Cheers,
-chris


On Apr 9, 2009, at 7:46 AM, J.D. Bakker wrote:


At 22:03 -0400 08-04-2009, Chris Mack / N1SKY wrote:

On Apr 8, 2009, at 8:50 PM, Bruce Griffiths wrote:



Chris

If you divide the output down to ~38MHz using a noiseless divider  
then
the performance is 20dB or more worse than can be achieved with a  
good

~38MHz crystal oscillator.



Ah, this would work, but there is a synchronization aspect since
framing on AES/EBU is in the mix (pun intended?) and there are more
pieces of external equipment that all need to be synched (within
AES11 framing sync margins)...


From a jitter POV the AES11 profiles are insanely wide, and they make
little sense if you're not using digital tape or other media which
take their time to slew to their final speed. Look at the recent TI
Asynchronous Sample Rate Converters (ASRCs); their rate estimators
have a bandwidth much tighter than needed to track a worst-case AES11
signal.


This 38.88MHz is a DSP clock, essentially a microprocessor clock
(albeit a very nice microprocessor clock) where the DSP simulates a
PLL operating on an incoming clock source, and makes an output clock
of a different frequency, [...]

The output of the DSP PLL in this box / design of interest is 11MHz
to 24MHz to feed the oversample clocks on the ADCs and DACs,
synchronized to the external 44.1kHz to 10MHz master house clock a la
the PLL and the rest of the equipment on the other side of the  
room...


By 'DSP PLL', do you imply that the DSP controls a DDS? If so, is the
DDS a separate chip or do you use a DAC hooked to your DSP?

For best jitter performance in an audio system you may want to
consider getting a free-running low noise XO with a frequency that is
NOT a multiple of your sampling rate(s), have it drive your ADC/DAC
converter directly and use an ASRC (either integrated or, preferably,
FPGA/DSP) to go to your target output rate.

As for fs jitter: I've yet to see a converter chip with differential
clock inputs, and for a single ended clock input I expect that the
total input-referred noise due to ground bounce co is in the order
of a ps, if not worse. (The story changes a bit for discrete
converter designs, as those can have diff clock inputs with specified
noise performance).

JDB.
[all things being equal, voltage pullability == lower Q == more phase
noise. And that's even before you consider control port noise
injection...]
--
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lartmaker.nl/

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Richard (Rick) Karlquist]

Bruce Griffiths wrote:

 Some ECL devices have jitter specs in the 100 to 200fsec range.
 see:
 http://www.onsemi.com


This is misleading.  While it is true that they have this
low jitter at multi-Gb/s rates, the jitter is much greater
than this at lower clock rates.  At 10 MHz, ECL devices
can't do better than several ps random jitter.  This is
because of the broadband phase noise floor which is around
-150 dBc/Hz.

Rick Karlquist N6RK

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Rick

The following NIST paper indicates that the conventional wisdom on ECL
phase noise levels appear to be incorrect at least for some ECL divider
configurations:

http://www.am1.us/Papers/U11605%20Low%20Noise%20Synthesis-%20Walls.pdf

Waveform symmetry and low power supply noise seem to be very important.

The output jitter of a a gate is dependent on its phase noise
properties, and the slew rate of its input signal at the threshold crossing.
Surely if the SiGe ECL devices were driven with an input with a
comparable slew rate surely its output jitter would be similar even for
lower frequency inut signals?

Bruce

Richard (Rick) Karlquist wrote:
 Bruce Griffiths wrote:

   
 Some ECL devices have jitter specs in the 100 to 200fsec range.
 see:
 http://www.onsemi.com

 

 This is misleading.  While it is true that they have this
 low jitter at multi-Gb/s rates, the jitter is much greater
 than this at lower clock rates.  At 10 MHz, ECL devices
 can't do better than several ps random jitter.  This is
 because of the broadband phase noise floor which is around
 -150 dBc/Hz.

 Rick Karlquist N6RK

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

   


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Mike Monett wrote:
Chris

The biggest problem with the OCXO is probably that it has a square
wave output.

With careful  design it is possible to achieve a jitter  of  a few
tens of femtosec for a logic level output from a limiter,  but the
OCXO designers are unlikely to have used such a limiter.

   [...]

Bruce

   Bruce

   This would  be  an  excellent subject for  a  tutorial  on precision
   system design. Do you have any links to support your claim of a tens
   of femtosec for a logic level from a limiter?

   I am  not  aware of any logic family that  can  support  that jitter
   performance.

   When you  post items that stretch the state of the art, it  would be
   nice if you would show us all how to do the same.

   Mike

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

   
Some ECL devices have jitter specs in the 100 to 200fsec range.
see:
http://www.onsemi.com



A jitter of a few tens of femtosec is achieved by some clock drivers:
http://www.analog.com/en/clock-and-timing/clock-generation-and-distribution/adclk905/products/product.html
http://www.analog.com/en/clock-and-timing/clock-generation-and-distribution/adclk925/products/product.html

Some ADC's have internal sampling jitter of a few tens of femtosec:
http://www.analog.com/en/analog-to-digital-converters/ad-converters/ad9461/products/product.html
However a very clean low noise source is required.


Achieving a jitter of less than a 1picosec at 10MHz with a well designed
limiter/filter cascade and a good source isn't too difficult, however
the intrinsic random jitter of most common logic families is indeed a
limiting factor.
(HCOS inverters have typical random jitter of ~ 4ps, ACMOS inverters
have an intrinsic random jitter of ~ 1ps faster CMOS families have lower
random jitter).
However such jitter can only be achieved if the logic gate input signal
slew rate is fast enough or the gates input noise will increase the jitter.

The achievable jitter increases as the input signal slew rate decreases
(ie a s the frequency decreases for a fixed amplitude sinewave input).

 100ns jitter at 1Hz due to the limiter noise is routine (around 10ns
should be possible). JPL achieved  100ns decades ago.
 10ns jitter at 10Hz due to limiter noise is relatively easy whilst a
potential jitter of around 1ns rms is achievable.
However a clean low noise input signal is required.

Bruce


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] femtosecond jitter anyone?

[Mike Monett]

   Chris

   The biggest problem with the OCXO is probably that it has a square
   wave output.

   With careful  design it is possible to achieve a jitter  of  a few
   tens of femtosec for a logic level output from a limiter,  but the
   OCXO designers are unlikely to have used such a limiter.

  [...]

   Bruce

  Bruce

  This would  be  an  excellent subject for  a  tutorial  on precision
  system design. Do you have any links to support your claim of a tens
  of femtosec for a logic level from a limiter?

  I am  not  aware of any logic family that  can  support  that jitter
  performance.

  When you  post items that stretch the state of the art, it  would be
  nice if you would show us all how to do the same.

  Mike

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Magnus Danielson]

Bruce Griffiths skrev:
 Hej Magnus
 
 Magnus Danielson wrote:
 Hej Bruce,

 Bruce Griffiths skrev:
   
 Magnus

 Magnus Danielson wrote:
 
 Bruce Griffiths skrev:
   
   
 Magnus

 For examples of the use of crystals in filters for cleaning up the
 output of a crystal oscillator look at the circuit schematics for some
 of the early crystal frequency standards.
 Crystal filters were used quite liberally in some of these to clean up
 the outputs.
 
 
 It's used in the step-up chain of the SR620 for instance. The SR620 has 
 a 10 MHz oscillator (TCXO or as in my case a Wenzel OCXO) which is 
 stepped up to 90 MHz using a fairly ordinary odd-order stepup and 
 filtering chain. The ECL logic counter frontend use this as coarse 
 counter frequency. The analog interpolators is a bit interesting in a 
 few peculiarities but nothing really exciting.

   
   
 Except if you believe that they actually use a Z5U capacitor (specified
 in the parts list) for the interpolator TDC ramp capacitor.
 If so, this would make for some interesting linearity and dielectric
 absorption compensation software.
 
 The caps listed as Z5U in the part list is not the timing caps. C701 and 
 C711 both being 100 pF NP0 is the timing caps. If you look careful you 
 will see it referenced. A 7 us sample pulse will charge a polypropylen 
 cap with the buffered value for a sligthly later performed 12 bit ADC 
 conversion.

   
 
 The online version of the manual specifies both of these caps as Z5U
 (see attachment).
 This may be an error in this version of the manual, or perhaps early
 versions used Z5U??
 100pF NP0 surface mount caps have been available for decades.

My manual specifies NP0 for these. Maybe a hardware revision that 
occured between the manuals.

 Autocalibration will adjust the discharge current, measure the voltage 
 bias and adjust the linearization data (65 bytes per channel).

   
 Dielectric absorption and voltage dependence correction for Z5U caps
 would be very challenging.

I do not disagree with you on that, but we do not know how it actually 
works. I could lift the lid and try to identify what is really sitting 
in there.

It could be that the online manual reflects the original mistake.

 Agree. Any temperature effects will occur with very flat slopes as the 
 tuning is far away from the frequency of interest.

 A number of shunting LCRs can be used, infact a suitable crystal could 
 be used to shunt into ground.

   
 
 Series tuned LC shunts are generally better as at resonance their ESR
 can be much lower than that of a crystal, the signal level that they can
 handle without damage is also much higher.
 Although a single LC series tuned shunt wont provide large attenuation
 one can always use one tuned to each significant harmonic per filter
 section.

It needs to be combined with a general low-pass filter of a few poles.

Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Hej Magnus

Magnus Danielson wrote:
 Bruce Griffiths skrev:
   
 Hej Magnus

 Magnus Danielson wrote:
 
 Hej Bruce,

 Bruce Griffiths skrev:
   
   
 Magnus

 Magnus Danielson wrote:
 
 
 Bruce Griffiths skrev:
   
   
   
 Magnus

 For examples of the use of crystals in filters for cleaning up the
 output of a crystal oscillator look at the circuit schematics for some
 of the early crystal frequency standards.
 Crystal filters were used quite liberally in some of these to clean up
 the outputs.
 
 
 
 It's used in the step-up chain of the SR620 for instance. The SR620 has 
 a 10 MHz oscillator (TCXO or as in my case a Wenzel OCXO) which is 
 stepped up to 90 MHz using a fairly ordinary odd-order stepup and 
 filtering chain. The ECL logic counter frontend use this as coarse 
 counter frequency. The analog interpolators is a bit interesting in a 
 few peculiarities but nothing really exciting.

   
   
   
 Except if you believe that they actually use a Z5U capacitor (specified
 in the parts list) for the interpolator TDC ramp capacitor.
 If so, this would make for some interesting linearity and dielectric
 absorption compensation software.
 
 
 The caps listed as Z5U in the part list is not the timing caps. C701 and 
 C711 both being 100 pF NP0 is the timing caps. If you look careful you 
 will see it referenced. A 7 us sample pulse will charge a polypropylen 
 cap with the buffered value for a sligthly later performed 12 bit ADC 
 conversion.

   
   
 The online version of the manual specifies both of these caps as Z5U
 (see attachment).
 This may be an error in this version of the manual, or perhaps early
 versions used Z5U??
 100pF NP0 surface mount caps have been available for decades.
 

 My manual specifies NP0 for these. Maybe a hardware revision that 
 occured between the manuals.

   
 Autocalibration will adjust the discharge current, measure the voltage 
 bias and adjust the linearization data (65 bytes per channel).

   
   
 Dielectric absorption and voltage dependence correction for Z5U caps
 would be very challenging.
 

 I do not disagree with you on that, but we do not know how it actually 
 works. I could lift the lid and try to identify what is really sitting 
 in there.

   

Whether that is easy to do is another question.
Some manufacturers (eg Philip's) had purple NP0 surface mount caps
whereas X7R surface mount caps etc were light brown.

 It could be that the online manual reflects the original mistake.

   
 Agree. Any temperature effects will occur with very flat slopes as the 
 tuning is far away from the frequency of interest.

 A number of shunting LCRs can be used, infact a suitable crystal could 
 be used to shunt into ground.

   
   
 Series tuned LC shunts are generally better as at resonance their ESR
 can be much lower than that of a crystal, the signal level that they can
 handle without damage is also much higher.
 Although a single LC series tuned shunt wont provide large attenuation
 one can always use one tuned to each significant harmonic per filter
 section.
 

 It needs to be combined with a general low-pass filter of a few poles.

   

Placing the series tuned LC circuits in shunt with the LC low pass
filter shunt capacitors would be convenient although some adjustment of
the low pass element values would then be required.
Filter design software would be useful for this, however real
measurements and plus more realistic models for the inductors would be
useful particularly is the series resonances of the inductors are
located in the filter stop band.
 Cheers,
 Magnus

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

   

Bruce

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[J.D. Bakker]

At 20:59 -0700 08-04-2009, Tom Van Baak wrote:
   The incoming clock source (master house clock) to this box / design 
  of interest is in another rack mount box external to this design on 
  the other side of the room and is anywhere from 44.1kHz up to a 10MHz 
  Rubidium (see also http://www.antelopeaudio.com).  This clock source 
  on the other side of the room also drives other equipment to be in 
  synch for any framing on AES/EBU digital.

Can you comment more on the antelopeaudio box?

[...]

Now if an audio company used surplus Sulzer, or FTS 1200, or
Oscilloquartz BVA oscillators in their design, or even H-masers,
well, that would make sense. But Rb? Something doesn't feel right
about this.

The words 'snake oil' have been used in the audio community, for 
pretty much all the reasons you've mentioned. For everything but 
esoteric stuff like distributed phased microphone/speaker arrays the 
drift specs of a simple TCXO are sufficient.

JDB.
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lartmaker.nl/

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[J.D. Bakker]

At 22:03 -0400 08-04-2009, Chris Mack / N1SKY wrote:
On Apr 8, 2009, at 8:50 PM, Bruce Griffiths wrote:

  Chris

  If you divide the output down to ~38MHz using a noiseless divider then
  the performance is 20dB or more worse than can be achieved with a good
  ~38MHz crystal oscillator.


Ah, this would work, but there is a synchronization aspect since 
framing on AES/EBU is in the mix (pun intended?) and there are more 
pieces of external equipment that all need to be synched (within 
AES11 framing sync margins)...

 From a jitter POV the AES11 profiles are insanely wide, and they make 
little sense if you're not using digital tape or other media which 
take their time to slew to their final speed. Look at the recent TI 
Asynchronous Sample Rate Converters (ASRCs); their rate estimators 
have a bandwidth much tighter than needed to track a worst-case AES11 
signal.

This 38.88MHz is a DSP clock, essentially a microprocessor clock 
(albeit a very nice microprocessor clock) where the DSP simulates a 
PLL operating on an incoming clock source, and makes an output clock
of a different frequency, [...]

The output of the DSP PLL in this box / design of interest is 11MHz 
to 24MHz to feed the oversample clocks on the ADCs and DACs, 
synchronized to the external 44.1kHz to 10MHz master house clock a la 
the PLL and the rest of the equipment on the other side of the room...

By 'DSP PLL', do you imply that the DSP controls a DDS? If so, is the 
DDS a separate chip or do you use a DAC hooked to your DSP?

For best jitter performance in an audio system you may want to 
consider getting a free-running low noise XO with a frequency that is 
NOT a multiple of your sampling rate(s), have it drive your ADC/DAC 
converter directly and use an ASRC (either integrated or, preferably, 
FPGA/DSP) to go to your target output rate.

As for fs jitter: I've yet to see a converter chip with differential 
clock inputs, and for a single ended clock input I expect that the 
total input-referred noise due to ground bounce co is in the order 
of a ps, if not worse. (The story changes a bit for discrete 
converter designs, as those can have diff clock inputs with specified 
noise performance).

JDB.
[all things being equal, voltage pullability == lower Q == more phase 
noise. And that's even before you consider control port noise 
injection...]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lartmaker.nl/

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack / N1SKY]

On Apr 8, 2009, at 11:59 PM, Tom Van Baak wrote:

 The incoming clock source (master house clock) to this box / design
 of interest is in another rack mount box external to this design on
 the other side of the room and is anywhere from 44.1kHz up to a 10MHz
 Rubidium (see also http://www.antelopeaudio.com).  This clock source
 on the other side of the room also drives other equipment to be in
 synch for any framing on AES/EBU digital.

 Can you comment more on the antelopeaudio box? I admit I know
 little about high-end audio, but it seems clear to me that the several
 companies that over the years have incorporated atomic clocks
 into their digital audio work might be misguided; confusing what is
 long-term accuracy with short-term stability.

 Sure, the word atomic clock sounds really cool. But high-quality
 OCXO typically have much better jitter and short-term stability than
 the telecom-style Rb oscillators that are used by audio companies.
 Or do I misunderstand?

 It would seem to me that very low jitter (or phase noise out to, say,
 100 kHz, or ADEV from, say 10 us) is much more important for
 audio work than specifications about absolute frequency accuracy
 or long-term drift (such as what telecom Rb oscillators offer).

 Now if an audio company used surplus Sulzer, or FTS 1200, or
 Oscilloquartz BVA oscillators in their design, or even H-masers,
 well, that would make sense. But Rb? Something doesn't feel right
 about this.

Hey Tom,

For audiophile or consumer in the home, a Rb clock may be overkill  
especially if the price tag is huge... But the market will bear what  
the market will bear and there is already a user base.  To note, the  
jitter does not matter as much in the transport chain up until the  
converter.  Once at the converter jitter is paramount, but the jitter  
in the thermally hot chip will probably trump everything else.  This  
is especially true for 16-bit 44.1kHz at the consumer level.

However, this is for mastering, not audiophile or consumer  
applications.   Mastering is the final creative and scientific step  
before an album is manufactured, after the recording studio phase is  
complete; every commercially released album is mastered (mastering  
does not use that huge mixing desk / console like you see on TV; the  
less equipment in front of the mastering engineer, the better,  
because of acoustic comb filtering bouncing off the gear).

Mastering also comprises the possibility of archival.

Imagine this: if you were the mastering engineer for Elvis 50 years  
ago, and if today's digital technology was available back then, would  
you want to archive the King's record inside Iron Mountain on MP3?   
Not really, you would want the most resolution possible for the re- 
release onto 32-bit 384kHz whiz-bang chip media in the future.  And  
cumulative error for successive re-releases over the decade for  
frequency drift and re-archival is maybe another concern.

For example, I am currently using a Rosendahl Nanoclocks (http:// 
www.rosendahl-studiotechnik.com/nanoclocks.html) for my house master  
word clock and a $6k Eventide Orville for processing of audio.  The  
Eventide used to measure the Nanoclocks at 88200 Hz... now it  
measures 88201 Hz 4 years later... something drifted  The  
Rosendahl uses normal ambient crystals (although they have trimmer  
caps) and use 74ACT00 logic to drive the distribution outputs.  The  
Eventide, I assume uses normal ambient crystals too for the myriad of  
DSPs in it

The Antelope Rb unit is $6k which is a little overboard in price  
considering one can get a Rb on ebay in the $200 range (age of the Rb  
unknown perhaps).  However, Antelope also has OCXOs that discipline  
to the Rb for the long term (although they fail to disclose the  
useful life of a Rb clock and have brain-dead specs for phase noise;  
only one data point at 10kHz -140dBc)...  caveat emptor in 20 years  
(hmmm let's see, $6k amortized over 20 years = $300/year)? The  
Antelope Rb and OCXO are all 75 ohm BNC.

The normal mode of operation in a recording studio or mastering suite  
is to synchronize gear together with one master house word clock  
usually 44.1kHz, 48kHz, 88.2kHz or 96kHz (I usually use 88.2kHz;  
twice the CD sampling rate, then Sample Rate Convert (-140dB to  
-170dB dynamic range) before PQ coding a red book standard audio CD  
at a dithered 16-bit, 44.1kHz).  This is all on 75 ohm BNC usually or  
AES11 digital black on higher frequencies characteristic of AES  
framing on 110 ohm differential.  These house word clocks may have  
jitter in the nanosecond range to maybe 10ps or so...

The math for full 24-bit accuracy for 88.2kHz sampling rate (44.1kHz  
BW) shows 0.43 ps of timing uncertainty.  Even if it were 20 bits of  
accuracy, 6ps would be the limit...  The converters I am using are  
124 dB and 132 dB of dynamic range for ADC and DAC respectively.   
There could be some dynamic range gains with the proposed  
modifications to 

[time-nuts] femtosecond jitter anyone?

[Chris Mack / N1SKY]

Hello fellow time nuts,

Have a project here with an OCXO from Vectron at 38.88MHz being the  
jitter reference for a DSP based PLL.

The Vectron part has a little bit of close-in phase noise below 12kHz  
of BW.   Is there a way to filter this, say by driving an external  
(temperature stabilized) crystal backwards (in the non-traditional  
sense rather than using the crystal to provide a clock for a system)  
and recovering the signal?

Also the output of the Vectron part is square and it would be ideal  
to distribute a sine wave

I cannot find traditional crystal filters that have a direct center  
at 38.88MHz also with any usable bandwidth (for the close-in skirt)  
for this application.

The DSP PLL has femtosecond jitter capabilities depending on how it  
is applied, e.g., for SONET and the like and also depending upon  
measurement BW used.  Also the jitter reference comes into play here  
as well

For the sampling application this is being used for, it would be  
ideal (by design) to keep the timing uncertainty below 0.45ps or so...

Any thoughts?

Cheers,
-chris
N1SKY
--
Chris Mack
Electrical Engineer / RF Engineer / Software Engineer / Mastering  
Engineer
Temple, NH


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack / N1SKY]

Hey Magnus,

This is a good idea for testing..  I have Howard Johnson's book for  
high speed digital design (a handbook of black magic) which shows  
some circuits with varactors on the transmission line with some ECL  
gates creating a variable delay based on an analogue voltage... maybe  
that could work before filtering into a sine

The DSP ultimately has 3 ports where the jitter reference (pins XA  
and XB differential sine or square) is one port for the digitally  
controlled oscillator (and also the clock to run the DSP), then the  
remaining 2 ports for input clock (CLK_IN) and the output (CLK_OUT)  
generated clock (any frequency really based on PLL coefficients).

It is roughly 1:1 jitter transfer from jitter reference (38,88MHz) to  
output clock, regardless of CLK_IN but for only a certain bandwidth,  
12kHz to 20MHz or so;  It gets better, slightly, when looking close  
into the carrier but ultimately this jitter reference is used to  
clean an input clock on other pins for the outgoing PLL generated  
output.

The same circuit could also be used outside of testing the jitter  
reference I suppose and be used on the incoming clock to be cleaned  
signal too

Yes, it may actually be ideal to put jitter on the incoming clock to  
be cleaned... With added jitter on the incoming clock to be cleaned,  
it may keep the PLL out of the dead zone and ultimately force it do  
some useful work at all times rather than coast/drift in said dead  
zone  But what shape of jittter to be introduced (noise shape on  
the proposed analogue voltage perturbing the varactors)? hm

Still trying to figure out crystals for filter purposes though since  
any documentation I have on crystals shows a typical circuit with  
logic gates to make a clock to feed a microprocessor (different from  
what I need it to do of course since I already have an OCXO)   
Harrumph

Cheers,
-chris

On Apr 8, 2009, at 5:09 PM, Magnus Danielson wrote:

 Chris Mack / N1SKY skrev:
 Hello fellow time nuts,

 Have a project here with an OCXO from Vectron at 38.88MHz being the
 jitter reference for a DSP based PLL.

 The Vectron part has a little bit of close-in phase noise below 12kHz
 of BW.   Is there a way to filter this, say by driving an external
 (temperature stabilized) crystal backwards (in the non-traditional
 sense rather than using the crystal to provide a clock for a system)
 and recovering the signal?

 Also the output of the Vectron part is square and it would be ideal
 to distribute a sine wave

 I cannot find traditional crystal filters that have a direct center
 at 38.88MHz also with any usable bandwidth (for the close-in skirt)
 for this application.

 The DSP PLL has femtosecond jitter capabilities depending on how it
 is applied, e.g., for SONET and the like and also depending upon
 measurement BW used.  Also the jitter reference comes into play here
 as well

 For the sampling application this is being used for, it would be
 ideal (by design) to keep the timing uncertainty below 0.45ps or  
 so...

 Any thoughts?

 Do you want to apply jitter to the 38,88 MHz clock?

 In particular, do you want to be able to modulate it with various
 amounts of sine in order to test jitter tolerance (a common SDH/SONET
 test).?

 Essentially you want phase modulations for those purposes. You can  
 apply
 them on the output signal for smaller amounts, but for larger  
 deviations
 it is not as convenient. Tolerance modulations may need to be several
 cycles peak-to-peak. A combination of phase modulation and frequency
 modulation can be used. One approach is to phase lock the  
 oscillator to
 a reference and insert the modulation signal into the PLL loop.

 Cheers,
 Magnus

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/ 
 time-nuts
 and follow the instructions there.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Magnus Danielson]

Chris,

Chris Mack / N1SKY skrev:
 Hey Magnus,
 
 This is a good idea for testing.. 

Applying jitter frequencies for jitter tolerance testing is standard 
stuff and needs to be done. Jitter tolerance curves match up with MTIE 
tolerance curves very neatly.

 I have Howard Johnson's book for  
 high speed digital design (a handbook of black magic) which shows  
 some circuits with varactors on the transmission line with some ECL  
 gates creating a variable delay based on an analogue voltage... maybe  
 that could work before filtering into a sine

I think a normal LC tank would be more suitable for that task.

It's a good introductional level book for digital signals, but isn't 
very applicable to waveshaping or clock characterisation and testing.

 The DSP ultimately has 3 ports where the jitter reference (pins XA  
 and XB differential sine or square) is one port for the digitally  
 controlled oscillator (and also the clock to run the DSP), then the  
 remaining 2 ports for input clock (CLK_IN) and the output (CLK_OUT)  
 generated clock (any frequency really based on PLL coefficients).

I still don't understand what you want it to do... or what it is 
supposed to do and what jitter reference means in your context, low 
jitter or know jitter.

 It is roughly 1:1 jitter transfer from jitter reference (38,88MHz) to  
 output clock, regardless of CLK_IN but for only a certain bandwidth,  
 12kHz to 20MHz or so;  It gets better, slightly, when looking close  
 into the carrier but ultimately this jitter reference is used to  
 clean an input clock on other pins for the outgoing PLL generated  
 output.

Sounds like a locked oscillator with PLL bandwidth of 12 kHz. The jitter 
of the locked oscillator is high-pass filtered by the PLL loop.

 The same circuit could also be used outside of testing the jitter  
 reference I suppose and be used on the incoming clock to be cleaned  
 signal too
 
 Yes, it may actually be ideal to put jitter on the incoming clock to  
 be cleaned... With added jitter on the incoming clock to be cleaned,  
 it may keep the PLL out of the dead zone and ultimately force it do  
 some useful work at all times rather than coast/drift in said dead  
 zone  But what shape of jittter to be introduced (noise shape on  
 the proposed analogue voltage perturbing the varactors)? hm

If you have a dead-zone on your PLL you need to fix it. I have learned 
the hard way that dead-zone PLLs can cause significant jitter/wander 
since they will get very abrupt shifts of direction in each end of the 
dead-zone. When using detectors (every simple ones like SR-FF) which 
does not have dead-zones it becomes feasible to tune it properly.

Continuous detector and active filter for PI regulation should be the 
standard approach most of the times. Not hard and expensive to achieve 
by todays standards IMHO.

May I stress that when doing SDH/SONET this is of particular importance.

 Still trying to figure out crystals for filter purposes though since  
 any documentation I have on crystals shows a typical circuit with  
 logic gates to make a clock to feed a microprocessor (different from  
 what I need it to do of course since I already have an OCXO)   
 Harrumph

It's actually not that hard to figure out. If you model a crystal as an 
LCR chain in parallel with a C then you have a model for an oscillator 
and a single mode. several LCR chains in parallel is needed if multiple 
modes needs to be modeled/simulated.

Crystal filters build upon these types of models. I still don't think 
you need to revert to crystal filters. If you just want to sine up a 
squarewave, a simple LC tank may be just want you need. A CLC or CRC 
PI-filter may also suite your needs more than sufficiently.

If you need very high Q filters for a fairly fixed frequency, crystal 
filters may be used, but PLLs may also be part of the solution, as you 
can see them as a form of self-retuneable bandpass filter.

Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Magnus

Magnus Danielson wrote:
 Bruce Griffiths skrev:
   
 Magnus

 For examples of the use of crystals in filters for cleaning up the
 output of a crystal oscillator look at the circuit schematics for some
 of the early crystal frequency standards.
 Crystal filters were used quite liberally in some of these to clean up
 the outputs.
 

 It's used in the step-up chain of the SR620 for instance. The SR620 has 
 a 10 MHz oscillator (TCXO or as in my case a Wenzel OCXO) which is 
 stepped up to 90 MHz using a fairly ordinary odd-order stepup and 
 filtering chain. The ECL logic counter frontend use this as coarse 
 counter frequency. The analog interpolators is a bit interesting in a 
 few peculiarities but nothing really exciting.

   
Except if you believe that they actually use a Z5U capacitor (specified
in the parts list) for the interpolator TDC ramp capacitor.
If so, this would make for some interesting linearity and dielectric
absorption compensation software.

 The crystal filters of that chain is setup in PI-filter style with the 
 crystals in serial mode.

   
 However it may be necessary to control the temperature of these crystals.
 

 Indeed. I wonder if he really needs that level of sine purity. An LC 
 tank should be sufficient to get started.

   
The filter phase instability is reduced significantly if one uses LC
filter traps tuned to the unwanted harmonics together with a low pass
filter rather than using a high Q bandpass filter.
 Cheers,
 Magnus

 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

   

Bruce

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack / N1SKY]

 This is a good idea for testing..

 Applying jitter frequencies for jitter tolerance testing is standard
 stuff and needs to be done. Jitter tolerance curves match up with MTIE
 tolerance curves very neatly.


Of course, here is the weird part... It's not SONET; but it is a chip  
that can be used for SONET...  This is for a very specific form of  
audio clocking (not audiophile, nor consumer) for a mastering  
engineering application.  Common input clock frequencies: 44.1kHz to  
96kHz or also a 10MHz rubidium.

The DSP PLL is this chip (I am still learning the intricacies of this  
chip):

https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5326.pdf

The system clock (to drive the DSP and the DSP's DCO) is essentially  
a jitter reference, pins XA and XB (differential, single ended  
capable); Jitter is transferred nearly 1:1 from XA,XB to CLK_OUT.   
This is the 38.88 MHz reference from Vectron with some skirting  
issues to be filtered before connected to the XA and XB pins.

The input (on CLK_IN pins) is the source clock to be cleaned (e.g.,  
44.1kHz to 96kHz or 10MHz Rb).

The output (on CLK_OUT pins)  is 11 MHz to 25MHz for 256x  
oversampling master clock for ADCs and DACs

24-bit accuracy for 40kHz (88.2kHz to 96kHz sample rate encompassing  
a 45/55 anti-alias filter) shows the need for sub picosecond timing  
aperture uncertainty.

Of course 24-bit in the real world is hard to achieve (even the new  
32-bit converters have a problem with it) with issues internal to  
the sampling mechanisms in a DAC / ADC, but with some out-of-band  
dither and thermal management, coupled with low jitter sampling  
clock, there may be an additional bit or so to be obtained.  This is  
all part of the experiment

 I have Howard Johnson's book for

 I think a normal LC tank would be more suitable for that task.

 It's a good introductional level book for digital signals, but isn't
 very applicable to waveshaping or clock characterisation and testing

Yes, HJ's books leaves me wanting a little more... seems like an  
analogue / RF book for digital folks.

I am looking for sharp Q to get rid of any skirt around the 38,88MHz  
of the Vectron OCXO.

Temperature can be obtained from cooling componentry already in situ,  
such that a known temperature is established.

Cheers,
-chris


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Magnus Danielson]

Bruce Griffiths skrev:
 Chris
 
 Chris Mack / N1SKY wrote:
 This is a good idea for testing..
   
 Applying jitter frequencies for jitter tolerance testing is standard
 stuff and needs to be done. Jitter tolerance curves match up with MTIE
 tolerance curves very neatly.

 
 Of course, here is the weird part... It's not SONET; but it is a chip  
 that can be used for SONET...  This is for a very specific form of  
 audio clocking (not audiophile, nor consumer) for a mastering  
 engineering application.  Common input clock frequencies: 44.1kHz to  
 96kHz or also a 10MHz rubidium.

 The DSP PLL is this chip (I am still learning the intricacies of this  
 chip):

 https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5326.pdf

 The system clock (to drive the DSP and the DSP's DCO) is essentially  
 a jitter reference, pins XA and XB (differential, single ended  
 capable); Jitter is transferred nearly 1:1 from XA,XB to CLK_OUT.   
 This is the 38.88 MHz reference from Vectron with some skirting  
 issues to be filtered before connected to the XA and XB pins.

 The input (on CLK_IN pins) is the source clock to be cleaned (e.g.,  
 44.1kHz to 96kHz or 10MHz Rb).

 The output (on CLK_OUT pins)  is 11 MHz to 25MHz for 256x  
 oversampling master clock for ADCs and DACs

 24-bit accuracy for 40kHz (88.2kHz to 96kHz sample rate encompassing  
 a 45/55 anti-alias filter) shows the need for sub picosecond timing  
 aperture uncertainty.

   
 These ADCs probably have internal jitter way above a few femtosec.
 
 Of course 24-bit in the real world is hard to achieve (even the new  
 32-bit converters have a problem with it) with issues internal to  
 the sampling mechanisms in a DAC / ADC, but with some out-of-band  
 dither and thermal management, coupled with low jitter sampling  
 clock, there may be an additional bit or so to be obtained.  This is  
 all part of the experiment

   
 I have Howard Johnson's book for
   
   
 I think a normal LC tank would be more suitable for that task.
   
 It's a good introductional level book for digital signals, but isn't
 very applicable to waveshaping or clock characterisation and testing
 
 Yes, HJ's books leaves me wanting a little more... seems like an  
 analogue / RF book for digital folks.

 I am looking for sharp Q to get rid of any skirt around the 38,88MHz  
 of the Vectron OCXO.

   
 Unless you are prepared to place the crystals in an oven with the
 temperature regulated tightly and carefully tune the filter periodically
 then using a crystal filter (or any passive filter with a sufficiently
 narrow bandwidth to cleanup the skirts) will not be particularly useful.
 It would be much easier to use a low bandwidth analog PLL with a low
 noise VCXO to cleanup the 38.88MHz signal.

Consider using a low noise oscillator at a higher frequency and divide 
down. A high quality reference such as a 19,44 MHz OCXO should be the 
real reference, again readilly available. The typical frequency 
relationship is a handy 8 or 16 which allows for low noise divisions if 
needed. For those frequencies, SAW devices may be more suitable.

 Temperature can be obtained from cooling componentry already in situ,  
 such that a known temperature is established.

   
 
 probably not much use unless one arranges to use this to tune the
 crystal filter, even then thermal gradients, thermal transients and
 aging will make this problematic.

Sound nasty.

Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Magnus Danielson]

Hej Bruce,

Bruce Griffiths skrev:
 Magnus
 
 Magnus Danielson wrote:
 Bruce Griffiths skrev:
   
 Magnus

 For examples of the use of crystals in filters for cleaning up the
 output of a crystal oscillator look at the circuit schematics for some
 of the early crystal frequency standards.
 Crystal filters were used quite liberally in some of these to clean up
 the outputs.
 
 It's used in the step-up chain of the SR620 for instance. The SR620 has 
 a 10 MHz oscillator (TCXO or as in my case a Wenzel OCXO) which is 
 stepped up to 90 MHz using a fairly ordinary odd-order stepup and 
 filtering chain. The ECL logic counter frontend use this as coarse 
 counter frequency. The analog interpolators is a bit interesting in a 
 few peculiarities but nothing really exciting.

   
 Except if you believe that they actually use a Z5U capacitor (specified
 in the parts list) for the interpolator TDC ramp capacitor.
 If so, this would make for some interesting linearity and dielectric
 absorption compensation software.

The caps listed as Z5U in the part list is not the timing caps. C701 and 
C711 both being 100 pF NP0 is the timing caps. If you look careful you 
will see it referenced. A 7 us sample pulse will charge a polypropylen 
cap with the buffered value for a sligthly later performed 12 bit ADC 
conversion.

Autocalibration will adjust the discharge current, measure the voltage 
bias and adjust the linearization data (65 bytes per channel).

 The crystal filters of that chain is setup in PI-filter style with the 
 crystals in serial mode.

   
 However it may be necessary to control the temperature of these crystals.
 
 Indeed. I wonder if he really needs that level of sine purity. An LC 
 tank should be sufficient to get started.

   
 The filter phase instability is reduced significantly if one uses LC
 filter traps tuned to the unwanted harmonics together with a low pass
 filter rather than using a high Q bandpass filter.

Agree. Any temperature effects will occur with very flat slopes as the 
tuning is far away from the frequency of interest.

A number of shunting LCRs can be used, infact a suitable crystal could 
be used to shunt into ground.

Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Chris

Chris Mack / N1SKY wrote:
 This is a good idea for testing..
   
 Applying jitter frequencies for jitter tolerance testing is standard
 stuff and needs to be done. Jitter tolerance curves match up with MTIE
 tolerance curves very neatly.

 

 Of course, here is the weird part... It's not SONET; but it is a chip  
 that can be used for SONET...  This is for a very specific form of  
 audio clocking (not audiophile, nor consumer) for a mastering  
 engineering application.  Common input clock frequencies: 44.1kHz to  
 96kHz or also a 10MHz rubidium.

 The DSP PLL is this chip (I am still learning the intricacies of this  
 chip):

 https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5326.pdf

 The system clock (to drive the DSP and the DSP's DCO) is essentially  
 a jitter reference, pins XA and XB (differential, single ended  
 capable); Jitter is transferred nearly 1:1 from XA,XB to CLK_OUT.   
 This is the 38.88 MHz reference from Vectron with some skirting  
 issues to be filtered before connected to the XA and XB pins.

 The input (on CLK_IN pins) is the source clock to be cleaned (e.g.,  
 44.1kHz to 96kHz or 10MHz Rb).

 The output (on CLK_OUT pins)  is 11 MHz to 25MHz for 256x  
 oversampling master clock for ADCs and DACs

 24-bit accuracy for 40kHz (88.2kHz to 96kHz sample rate encompassing  
 a 45/55 anti-alias filter) shows the need for sub picosecond timing  
 aperture uncertainty.

   
These ADCs probably have internal jitter way above a few femtosec.

 Of course 24-bit in the real world is hard to achieve (even the new  
 32-bit converters have a problem with it) with issues internal to  
 the sampling mechanisms in a DAC / ADC, but with some out-of-band  
 dither and thermal management, coupled with low jitter sampling  
 clock, there may be an additional bit or so to be obtained.  This is  
 all part of the experiment

   
 I have Howard Johnson's book for
   

   
 I think a normal LC tank would be more suitable for that task.
   
 It's a good introductional level book for digital signals, but isn't
 very applicable to waveshaping or clock characterisation and testing
 

 Yes, HJ's books leaves me wanting a little more... seems like an  
 analogue / RF book for digital folks.

 I am looking for sharp Q to get rid of any skirt around the 38,88MHz  
 of the Vectron OCXO.

   
Unless you are prepared to place the crystals in an oven with the
temperature regulated tightly and carefully tune the filter periodically
then using a crystal filter (or any passive filter with a sufficiently
narrow bandwidth to cleanup the skirts) will not be particularly useful.
It would be much easier to use a low bandwidth analog PLL with a low
noise VCXO to cleanup the 38.88MHz signal.

 Temperature can be obtained from cooling componentry already in situ,  
 such that a known temperature is established.

   

probably not much use unless one arranges to use this to tune the
crystal filter, even then thermal gradients, thermal transients and
aging will make this problematic.

 Cheers,
 -chris


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

   

Bruce

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack / N1SKY]

On Apr 8, 2009, at 8:02 PM, Bruce Griffiths wrote:


 Unless you are prepared to place the crystals in an oven with the
 temperature regulated tightly and carefully tune the filter  
 periodically
 then using a crystal filter (or any passive filter with a sufficiently
 narrow bandwidth to cleanup the skirts) will not be particularly  
 useful.
 It would be much easier to use a low bandwidth analog PLL with a low
 noise VCXO to cleanup the 38.88MHz signal.


http://www.national.com/pf/LM/LMK04000B.html

Their app note uses a very low noise VCXO...  The simulator software  
gets pretty close...

Cheers,
-chris


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Chris Mack / N1SKY wrote:
 On Apr 8, 2009, at 8:02 PM, Bruce Griffiths wrote:


   
 Unless you are prepared to place the crystals in an oven with the
 temperature regulated tightly and carefully tune the filter  
 periodically
 then using a crystal filter (or any passive filter with a sufficiently
 narrow bandwidth to cleanup the skirts) will not be particularly  
 useful.
 It would be much easier to use a low bandwidth analog PLL with a low
 noise VCXO to cleanup the 38.88MHz signal.

 

 http://www.national.com/pf/LM/LMK04000B.html

 Their app note uses a very low noise VCXO...  The simulator software  
 gets pretty close...

 Cheers,
 -chris


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

   
Chris

If you divide the output down to ~38MHz using a noiseless divider then
the performance is 20dB or more worse than can be achieved with a good
~38MHz crystal oscillator.
This seems to be a complex method of degrading the performance over that
possible with a simpler design.

Bruce

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack / N1SKY]

On Apr 8, 2009, at 8:50 PM, Bruce Griffiths wrote:

 Chris

 If you divide the output down to ~38MHz using a noiseless divider then
 the performance is 20dB or more worse than can be achieved with a good
 ~38MHz crystal oscillator.


Ah, this would work, but there is a synchronization aspect since  
framing on AES/EBU is in the mix (pun intended?) and there are more  
pieces of external equipment that all need to be synched (within  
AES11 framing sync margins)...

The box / design of interest has ADCs, DACs, and a 38.88MHz OCXO of  
marginal performance coupled with the proposed DSP based PLLs  
generating a local clock for the ADCs and DACs all on the same  
circuit board in synch with external gear.

This 38.88MHz is a DSP clock, essentially a microprocessor clock  
(albeit a very nice microprocessor clock) where the DSP simulates a  
PLL operating on an incoming clock source, and makes an output clock  
of a different frequency, but synchronized to be within AES standards  
for framing when considering the additional equipment scattered  
around the room, made by different manufacturers, different inner  
workings etc.

The incoming clock source (master house clock) to this box / design  
of interest is in another rack mount box external to this design on  
the other side of the room and is anywhere from 44.1kHz up to a 10MHz  
Rubidium (see also http://www.antelopeaudio.com).  This clock source  
on the other side of the room also drives other equipment to be in  
synch for any framing on AES/EBU digital.

The output of the DSP PLL in this box / design of interest is 11MHz  
to 24MHz to feed the oversample clocks on the ADCs and DACs,  
synchronized to the external 44.1kHz to 10MHz master house clock a la  
the PLL and the rest of the equipment on the other side of the room...

The only caveat is that the 38.88MHz DSP microprocessor clock must be  
low jitter in order to have the DSP PLL be low jitter..  The DSP PLL  
does not really care about absolute frequency in the long term  
(38.88MHz or 37MHz, doesn't matter), but it will rebroadcast short  
term effects of jitter to clocks of the ADCs and DACs in the box of  
interest.

Sounds like maybe some LCs to filter out the additional harmonics and  
maybe attempt to get close into the carrier eh?

Thanks Magnus and Bruce for being a sounding wall

Cheers,
-chris


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Chris

Now we have a more complete picture of what you are trying to do our
suggestions will perhaps be a little more useful.

Cleaning up a  marginal OCXO is quite complex and probably more
expensive than obtaining an OCXO or other reference that has lower noise.
Is it in fact possible to just substitute a low noise  non oven crystal
oscillator for the 38.88MHz OCXO?
With an appropriate oscillator design it should be possible to
significantly reduce the phase noise of the 38.88MHz source at the
expense of long term drift and aging.
Achieving low jitter with such a source isn't difficult.

The other question that arises is why is the OCXO phase noise so poor at
frequency offsets less than 12kHz?

Bruce

Chris Mack / N1SKY wrote:
 On Apr 8, 2009, at 8:50 PM, Bruce Griffiths wrote:
   
 Chris

 If you divide the output down to ~38MHz using a noiseless divider then
 the performance is 20dB or more worse than can be achieved with a good
 ~38MHz crystal oscillator.

 

 Ah, this would work, but there is a synchronization aspect since  
 framing on AES/EBU is in the mix (pun intended?) and there are more  
 pieces of external equipment that all need to be synched (within  
 AES11 framing sync margins)...

 The box / design of interest has ADCs, DACs, and a 38.88MHz OCXO of  
 marginal performance coupled with the proposed DSP based PLLs  
 generating a local clock for the ADCs and DACs all on the same  
 circuit board in synch with external gear.

 This 38.88MHz is a DSP clock, essentially a microprocessor clock  
 (albeit a very nice microprocessor clock) where the DSP simulates a  
 PLL operating on an incoming clock source, and makes an output clock  
 of a different frequency, but synchronized to be within AES standards  
 for framing when considering the additional equipment scattered  
 around the room, made by different manufacturers, different inner  
 workings etc.

 The incoming clock source (master house clock) to this box / design  
 of interest is in another rack mount box external to this design on  
 the other side of the room and is anywhere from 44.1kHz up to a 10MHz  
 Rubidium (see also http://www.antelopeaudio.com).  This clock source  
 on the other side of the room also drives other equipment to be in  
 synch for any framing on AES/EBU digital.

 The output of the DSP PLL in this box / design of interest is 11MHz  
 to 24MHz to feed the oversample clocks on the ADCs and DACs,  
 synchronized to the external 44.1kHz to 10MHz master house clock a la  
 the PLL and the rest of the equipment on the other side of the room...

 The only caveat is that the 38.88MHz DSP microprocessor clock must be  
 low jitter in order to have the DSP PLL be low jitter..  The DSP PLL  
 does not really care about absolute frequency in the long term  
 (38.88MHz or 37MHz, doesn't matter), but it will rebroadcast short  
 term effects of jitter to clocks of the ADCs and DACs in the box of  
 interest.

 Sounds like maybe some LCs to filter out the additional harmonics and  
 maybe attempt to get close into the carrier eh?

 Thanks Magnus and Bruce for being a sounding wall

 Cheers,
 -chris


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.

   


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] femtosecond jitter anyone?

[Chris Mack / N1SKY]

Thanks Bruce,

The 12kHz is a figure for the DSP PLL and how they measure it  
(starting at 12kHz usually for jitter over BW measurements) I  
haven't touched SONET since 1997 and this may be a SONET spec?

I am using the simulator software for the LMK04000 series to see what  
jitter is for the OXCO... -70dBc at 1 Hz, -100dBc 10Hz per the spec  
sheet with all the other datapoints comes out to 1.3ps  (1Hz to  
20MHz) of jitter RMS.

So the OCXO is decent without having to purchase a better one (and  
the minimum quantity of 25 at $250 each +/-) for this initial  
prototype; this seems to be semi-custom since 38.88MHz OCXOs are not  
in stock at Digikey  I plan on building a bunch of boxes over  
time with this OCXO in it and finding disparate OCXOs on ebay was not  
an option, especially if a new circuit board would need to be spun  
every time.

I just didn't know if I could get better with some filtering, and get  
it into the femtosecond range...  Currently this should be able to  
maintain 22 bits of accuracy at 40kHz, which is pretty doggone good,  
but was interested in pushing the envelope a little since I can go  
(with an input alias filter) to 96kHz...  Yes, there is some internal  
jitter to the ADCs, some perhaps due to thermal, and the box is going  
to be hot with a power budget already at 250W hence the thermal /  
cooling and dither experiments and I was hoping to not be limited by  
the clock performance.

I still want to filter such as to distribute a sine...

Cheers,
-chris


On Apr 8, 2009, at 10:22 PM, Bruce Griffiths wrote:

 Chris

 Now we have a more complete picture of what you are trying to do our
 suggestions will perhaps be a little more useful.

 Cleaning up a  marginal OCXO is quite complex and probably more
 expensive than obtaining an OCXO or other reference that has lower  
 noise.
 Is it in fact possible to just substitute a low noise  non oven  
 crystal
 oscillator for the 38.88MHz OCXO?
 With an appropriate oscillator design it should be possible to
 significantly reduce the phase noise of the 38.88MHz source at the
 expense of long term drift and aging.
 Achieving low jitter with such a source isn't difficult.

 The other question that arises is why is the OCXO phase noise so  
 poor at
 frequency offsets less than 12kHz?

 Bruce

 Chris Mack / N1SKY wrote:
 On Apr 8, 2009, at 8:50 PM, Bruce Griffiths wrote:

 Chris

 If you divide the output down to ~38MHz using a noiseless divider  
 then
 the performance is 20dB or more worse than can be achieved with a  
 good
 ~38MHz crystal oscillator.



 Ah, this would work, but there is a synchronization aspect since
 framing on AES/EBU is in the mix (pun intended?) and there are more
 pieces of external equipment that all need to be synched (within
 AES11 framing sync margins)...

 The box / design of interest has ADCs, DACs, and a 38.88MHz OCXO of
 marginal performance coupled with the proposed DSP based PLLs
 generating a local clock for the ADCs and DACs all on the same
 circuit board in synch with external gear.

 This 38.88MHz is a DSP clock, essentially a microprocessor clock
 (albeit a very nice microprocessor clock) where the DSP simulates a
 PLL operating on an incoming clock source, and makes an output clock
 of a different frequency, but synchronized to be within AES standards
 for framing when considering the additional equipment scattered
 around the room, made by different manufacturers, different inner
 workings etc.

 The incoming clock source (master house clock) to this box / design
 of interest is in another rack mount box external to this design on
 the other side of the room and is anywhere from 44.1kHz up to a 10MHz
 Rubidium (see also http://www.antelopeaudio.com).  This clock source
 on the other side of the room also drives other equipment to be in
 synch for any framing on AES/EBU digital.

 The output of the DSP PLL in this box / design of interest is 11MHz
 to 24MHz to feed the oversample clocks on the ADCs and DACs,
 synchronized to the external 44.1kHz to 10MHz master house clock a la
 the PLL and the rest of the equipment on the other side of the  
 room...

 The only caveat is that the 38.88MHz DSP microprocessor clock must be
 low jitter in order to have the DSP PLL be low jitter..  The DSP PLL
 does not really care about absolute frequency in the long term
 (38.88MHz or 37MHz, doesn't matter), but it will rebroadcast short
 term effects of jitter to clocks of the ADCs and DACs in the box of
 interest.

 Sounds like maybe some LCs to filter out the additional harmonics and
 maybe attempt to get close into the carrier eh?

 Thanks Magnus and Bruce for being a sounding wall

 Cheers,
 -chris


 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/ 
 listinfo/time-nuts
 and follow the instructions there.




 ___
 time-nuts mailing list -- 

Re: [time-nuts] femtosecond jitter anyone?

[Bruce Griffiths]

Chris

The biggest problem with the OCXO is probably that it has a square wave
output.
With careful design it is possible to achieve a jitter of a few tens of
femtosec for a logic level output from a limiter, but the OCXO designers
are unlikely to have used such a limiter.

To produce a sinewave output,  I'd probably start with a low Q (5? to
minimise phase shift tempco) tuned tank in the collector of a BJT driven
by a logic leve output to get an approximate sine wave and follow it
with an LC low pass filter with series tuned traps for the harmonics
across the shunt elements of the LC filter and adjust the filter
component values to achieve the desired response with the series tuned
LC circuits shunt elements in place.

Bruce

Chris Mack / N1SKY wrote:
 Thanks Bruce,

 The 12kHz is a figure for the DSP PLL and how they measure it  
 (starting at 12kHz usually for jitter over BW measurements) I  
 haven't touched SONET since 1997 and this may be a SONET spec?

 I am using the simulator software for the LMK04000 series to see what  
 jitter is for the OXCO... -70dBc at 1 Hz, -100dBc 10Hz per the spec  
 sheet with all the other datapoints comes out to 1.3ps  (1Hz to  
 20MHz) of jitter RMS.

   
I presume the -70dBc @ 1Hz is a phase noise spec for the OCXO?
If so this is much higher than the state of the art for a sinewave
output OCXO.

 So the OCXO is decent without having to purchase a better one (and  
 the minimum quantity of 25 at $250 each +/-) for this initial  
 prototype; this seems to be semi-custom since 38.88MHz OCXOs are not  
 in stock at Digikey  I plan on building a bunch of boxes over  
 time with this OCXO in it and finding disparate OCXOs on ebay was not  
 an option, especially if a new circuit board would need to be spun  
 every time.

 I just didn't know if I could get better with some filtering, and get  
 it into the femtosecond range...  Currently this should be able to  
 maintain 22 bits of accuracy at 40kHz, which is pretty doggone good,  
 but was interested in pushing the envelope a little since I can go  
 (with an input alias filter) to 96kHz...  Yes, there is some internal  
 jitter to the ADCs, some perhaps due to thermal, and the box is going  
 to be hot with a power budget already at 250W hence the thermal /  
 cooling and dither experiments and I was hoping to not be limited by  
 the clock performance.

 I still want to filter such as to distribute a sine...

 Cheers,
 -chris


 On Apr 8, 2009, at 10:22 PM, Bruce Griffiths wrote:

   
 Chris

 Now we have a more complete picture of what you are trying to do our
 suggestions will perhaps be a little more useful.

 Cleaning up a  marginal OCXO is quite complex and probably more
 expensive than obtaining an OCXO or other reference that has lower  
 noise.
 Is it in fact possible to just substitute a low noise  non oven  
 crystal
 oscillator for the 38.88MHz OCXO?
 With an appropriate oscillator design it should be possible to
 significantly reduce the phase noise of the 38.88MHz source at the
 expense of long term drift and aging.
 Achieving low jitter with such a source isn't difficult.

 The other question that arises is why is the OCXO phase noise so  
 poor at
 frequency offsets less than 12kHz?

 Bruce

 Chris Mack / N1SKY wrote:
 
 On Apr 8, 2009, at 8:50 PM, Bruce Griffiths wrote:

   
 Chris

 If you divide the output down to ~38MHz using a noiseless divider  
 then
 the performance is 20dB or more worse than can be achieved with a  
 good
 ~38MHz crystal oscillator.


 
 Ah, this would work, but there is a synchronization aspect since
 framing on AES/EBU is in the mix (pun intended?) and there are more
 pieces of external equipment that all need to be synched (within
 AES11 framing sync margins)...

 The box / design of interest has ADCs, DACs, and a 38.88MHz OCXO of
 marginal performance coupled with the proposed DSP based PLLs
 generating a local clock for the ADCs and DACs all on the same
 circuit board in synch with external gear.

 This 38.88MHz is a DSP clock, essentially a microprocessor clock
 (albeit a very nice microprocessor clock) where the DSP simulates a
 PLL operating on an incoming clock source, and makes an output clock
 of a different frequency, but synchronized to be within AES standards
 for framing when considering the additional equipment scattered
 around the room, made by different manufacturers, different inner
 workings etc.

 The incoming clock source (master house clock) to this box / design
 of interest is in another rack mount box external to this design on
 the other side of the room and is anywhere from 44.1kHz up to a 10MHz
 Rubidium (see also http://www.antelopeaudio.com).  This clock source
 on the other side of the room also drives other equipment to be in
 synch for any framing on AES/EBU digital.

 The output of the DSP PLL in this box / design of interest is 11MHz
 to 24MHz to feed the oversample clocks on the ADCs and DACs,
 synchronized to the 

Re: [time-nuts] femtosecond jitter anyone?

[Tom Van Baak]

 The incoming clock source (master house clock) to this box / design  
 of interest is in another rack mount box external to this design on  
 the other side of the room and is anywhere from 44.1kHz up to a 10MHz  
 Rubidium (see also http://www.antelopeaudio.com).  This clock source  
 on the other side of the room also drives other equipment to be in  
 synch for any framing on AES/EBU digital.

Can you comment more on the antelopeaudio box? I admit I know
little about high-end audio, but it seems clear to me that the several
companies that over the years have incorporated atomic clocks
into their digital audio work might be misguided; confusing what is
long-term accuracy with short-term stability.

Sure, the word atomic clock sounds really cool. But high-quality
OCXO typically have much better jitter and short-term stability than
the telecom-style Rb oscillators that are used by audio companies.
Or do I misunderstand?

It would seem to me that very low jitter (or phase noise out to, say,
100 kHz, or ADEV from, say 10 us) is much more important for
audio work than specifications about absolute frequency accuracy
or long-term drift (such as what telecom Rb oscillators offer).

Now if an audio company used surplus Sulzer, or FTS 1200, or
Oscilloquartz BVA oscillators in their design, or even H-masers,
well, that would make sense. But Rb? Something doesn't feel right
about this.

/tvb


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.