[time-nuts] femtosecond jitter anyone?
chris at chriscaudle.org
Fri Apr 24 03:29:31 UTC 2009
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
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
pretty nasty clock and still work fine. They are just synchronous digital
designs, so clock jitter has no effect on operation.
> of the world with standard mfg practices for house word clock only:
Odd that the so-called data sheet contains absolutely no objective
performance information, don't you think?
> The ovenized can also be the internal clock if there are no external
> clocks to synch to in a standalone application
Yeah, but a TCXO would be almost as good, and about 1/10th the cost. I
still have to ask, why is it so important to have an oven? Ovens buy you
long term stability, and better absolute accuracy, neither of which is
terribly important in this application.
>> This is a baseband sampling application, so phase noise on the
>> sampling clock is converted to sidebands on the output
> Ah.. I've been wondering about this...
Then definitely go get those preprints. Required reading before you fire
up the schematic editor again.
> I am ultimately looking to use a rubidium for the real long
> term system reference and generate house word clocks
Why? What would be the benefit to having the absolute accuracy that you
get from rubidium? The outputs of a rubidium oscillator are a quartz based
circuit, so the short term performance (i.e. jitter or phase noise) is
going to be driven by the quality of the quartz circuitry, so the only
thing rubidium buys is low long term drift. That has its place and uses,
but I'm not sure audio synchronization is one of them. Knock yourself out
if you just want it, I like things with ium in the name as much as anyone,
but I don't see the functional benefit.
> Yah, I was originally going with a $33/each 2 layer PCB
So you were going to buy a $250 ovenized oscillator instead of a TCXO, and
then scrimp on the PCB? I hope I don't offend your sensibilities, but I
would make this box completely differently than the approach you are
taking. Implementation is 80% when you are trying to keep noise levels
this low, and you can completely screw up a great device with a bad PCB
layout, bad power layout design, noisy power supply, etc.
> into the PCB, with sharp edges for EMI purposes; then we get into
> blind and buried vias perhaps...
Buried vias for EMI? Won't make a noticeable difference. For practical
purposes vias don't radiate. The loop area through a via is so small
compared to your loop area along the rest of the route that vias will be
the least of your worries.
By the way, what converters were you planning? Those numbers you quoted
earlier sound a lot like the new ESS Tech specs.
More information about the time-nuts