Re: [time-nuts] femtosecond jitter
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
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
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
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
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
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
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?
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?
[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?
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
Re: [time-nuts] femtosecond jitter anyone?
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 coul
Re: [time-nuts] femtosecond jitter anyone?
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?
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?
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 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?
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?
> 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?
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
Re: [time-nuts] femtosecond jitter anyone?
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?
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?
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?
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?
> 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.
Re: [time-nuts] femtosecond jitter anyone?
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 b
Re: [time-nuts] femtosecond jitter anyone?
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
Re: [time-nuts] femtosecond jitter anyone?
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?
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?
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?
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 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?
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?
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?
>> 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 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?
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. 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. 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 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. However it may be necessary to control the temperature of these crystals. Bruce Magnus Danielson wrote: > 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. > > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time
Re: [time-nuts] femtosecond jitter anyone?
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?
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?
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] femtosecond jitter anyone?
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.
