All digital PLL

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Andy Peters

Well-known member
Joined
Oct 30, 2007
Messages
2,031
Location
Sunny Tucson
I kinda need a simple, high-quality 2-channel ADC with word clock sync that supports the 44.1 kHz and the 48 kHz multiple sampling frequencies. This seems like it's an ideal project for DIY. Except it seems like none of the usual suspects sell a 22.5792 MHz oscillator, at least in non-full-reel quantities.

Silicon Labs has been sending me e-mail updates about their products, including programmable VCXO and XO devices. One product in particular stood out: the Si598 I2C programmable XO (pdf). Using an I2C port, you can set its output to any frequency between 10 MHz and 810 MHz, with what looks to be spectacular jitter specs.

This guy seems to neatly solve a handful of problems. One oscillator covers all of the converter modulator clock frequencies. The same oscillator is used for both master (internal clocking) and slave (external word-clock) modes. You don't need to implement muxes or switches to select the clock source or clock mode. 

All you need is a micro with an I2C master and a phase detector (which could be in the micro). Some micro port pins can be used for switch inputs (mode select, sample frequency, whatever). In master mode, the micro just sets the oscillator frequency as desired. In slave mode, the micro handles the phase detector and the loop filter, and sets the oscillator frequency as necessary. (Choose an ADC that has a "master mode" for the I2C, where it takes in the MCLK and generates BCLK and LRCLK, and you don't even have to use an external divider to drive the PLL. Just feed LRCLK into the phase detector.)

I'm trying to get a sample and see what these things cost. Even if they're ten bucks, it might end up being cheaper than two oscillators and two VXCOs or PLLs and whatever else is required to implement the clocking.

-a
 
Be skeptical of any jitter spec for an oscillator, the jitter specs you see there are a calculation based on phase noise specs with several parameters that can be used to obscure the real performance of an oscillator.  For example the integration BW of that jitter spec starts at 12kHz, which says nothing of the noise at 10, 100, or 1k Hz offsets.  That's where most of your noise is and typically that's the spec that you're going to be very interested in for audio or so I'm told.  So when you look at the actual phase noise, a -77 dbc/Hz at 100Hz offset is pretty much standard 1/f noise for VCXO's.

I've never used an MPU for a phase detector, typically this is done with CPLD's or FPGA's so you can do some other things like use them as a counter, etc.

I would also consider this http://www.national.com/pf/LM/LMX2541.html#Overview.  It has an internal variable frequency VCO with decent phase noise which can be manipulated with an MPU.  Since it's primarily a PLL you can lock its internal VCO to an external clock source without an extra chip like a CPLD for phase detection.  Using this PLL you could use a cheap 8 bit MPU and pretty much achieve all the things you said...  Just another option to think about.

http://www.minicircuits.com/app/VCO15-6.pdf   Phase Noise info
 
I am slightly curious about this subject because I am looking at a 20+ bit codec for my next generation platform... they're so cheap it seems silly not to use one.

OK here is my question/suggestion...  back in the day when I encountered something like this, I would rig up some kind of bench test to isolate the clock jitter, so I could boost it way louder and listen to it.

How, could one do that in this case? I am guessing it would be more audible as a signal modulation noise, than a noise source by itself. Perhaps listen to the output from a decent DAC, while playing a pure sine wave from a look up table?

If I can't isolate this on the bench and make it sound bad, I don't know how to spank it cost effectively, to sound good.

Since i'm operating without problems at 12 bit resolution and less right now, I don't expect this to be an issue for me for a while, but color me curious.

JR 
 
millzners said:
Be skeptical of any jitter spec for an oscillator, the jitter specs you see there are a calculation based on phase noise specs with several parameters that can be used to obscure the real performance of an oscillator.  For example the integration BW of that jitter spec starts at 12kHz, which says nothing of the noise at 10, 100, or 1k Hz offsets.  That's where most of your noise is and typically that's the spec that you're going to be very interested in for audio or so I'm told.  So when you look at the actual phase noise, a -77 dbc/Hz at 100Hz offset is pretty much standard 1/f noise for VCXO's.

I've never used an MPU for a phase detector, typically this is done with CPLD's or FPGA's so you can do some other things like use them as a counter, etc.

I would also consider this http://www.national.com/pf/LM/LMX2541.html#Overview.  It has an internal variable frequency VCO with decent phase noise which can be manipulated with an MPU.  Since it's primarily a PLL you can lock its internal VCO to an external clock source without an extra chip like a CPLD for phase detection.  Using this PLL you could use a cheap 8 bit MPU and pretty much achieve all the things you said...  Just another option to think about.

http://www.minicircuits.com/app/VCO15-6.pdf   Phase Noise info

Well, I suppose that the overarching point is to simplify the whole clock choice/control logic. If one device will let me replace multiple oscillators, then it's got merit.

Every time I sit down to think about doing something like this, I go around in circles. A micro with I2C will let me do what I want and control the Silicon Labs part digitally, no DAC required to drive a VCXO. But then if you consider the FPGA solution, a lot of things open up: digital phase detector, obviously, but then with even the smallest FPGA (Spartan 3AN50), you can include the S/PDIF transmitter, and since the I2S bus is in the FPGA, you can spy on it and make a digital level meter and drive the meter LEDs directly from FPGA pins. (Or add some glue and drive an analog VU meter.) Plenty of I/O for buttons and such.

But then if you actually change clock frequency and the FPGA is driven by the clock you want to change (say, step from 22.5792 to 24.576 MHz), you have to ensure against glitches, or it can be smoothly ramped. I2C has two "speeds" (100 kHz and 400 kHz) but unless you're dealing with multiple bus masters and timeouts and such, slaves don't care.

Of course the FPGA needs a core supply (1.2V for the S3AN), which is an annoyance.

That National part looks mighty interesting, although small-quantity pricing is about $20 (I think the SiLabs part is much less) and there's always the question of availability.  Also, the SiLabs clock is configured with a known start-up frequency, so the FPGA has a reasonable clock. Of course the micro I'd choose has a built-in oscillator so it can start up with that oscillator and then switch to the external ...

-a

 
JohnRoberts said:
I am slightly curious about this subject because I am looking at a 20+ bit codec for my next generation platform... they're so cheap it seems silly not to use one.

OK here is my question/suggestion...  back in the day when I encountered something like this, I would rig up some kind of bench test to isolate the clock jitter, so I could boost it way louder and listen to it.

How, could one do that in this case? I am guessing it would be more audible as a signal modulation noise, than a noise source by itself. Perhaps listen to the output from a decent DAC, while playing a pure sine wave from a look up table?

If I can't isolate this on the bench and make it sound bad, I don't know how to spank it cost effectively, to sound good.

Since i'm operating without problems at 12 bit resolution and less right now, I don't expect this to be an issue for me for a while, but color me curious.

JR

I've thought about this and the truth is I'm not really sure.  Generally you can say that some phase noise in a system that is there in addition to the 1/f and inherent noise floor of the oscillator is due to noise in the audio band that phase modulates the oscillator and thus appears at an offset frequency of the fundamental.  So that would be, for example, a noisey regulator that produces some junk in the 10-100 Hz audio range and that junk phase modulates the clock and appears in the phase noise measurements at 10-100Hz offset of the fundamental.

So based on that reasoning, if you could take a clock source and demodulate it down to just it's audio, you could have a source of phase modulation noise.  However, when dividing a clock source down you also reduce the phase noise entirely by 6dB per division of 2.  This is why generally crappy clock sources work just fine for audio systems because once you've divided that 22.5792MHz down to your actual clock frequency that inherent oscillator noise becomes insignificant next to total noise of the system.

So in other words, I haven't quite worked out how to hear this stuff even though I was trying to hear the difference between a crap crystal in my DAC with a high-end OCXO with good phase noise.  I'm not sure yet, but all indications point to it not mattering next to everything else in the circuit that produces phase noise.
 
millzners said:
This is why generally crappy clock sources work just fine for audio systems because once you've divided that 22.5792MHz down to your actual clock frequency that inherent oscillator noise becomes insignificant next to total noise of the system.

And in the case of oversampling converters, you don't even divide the clock down to the sample frequency, you let the modulator do whatever it does.

Along those lines, say there's some monstrous jitter on a 48 kHz word clock input which your PLL is able to swallow and output a quality modulator clock -- do you care about the input clock jitter? Put another way, do you need a Big Ben or some sort of cesium clock generator?

-a
 
Andy Peters said:
millzners said:
This is why generally crappy clock sources work just fine for audio systems because once you've divided that 22.5792MHz down to your actual clock frequency that inherent oscillator noise becomes insignificant next to total noise of the system.

And in the case of oversampling converters, you don't even divide the clock down to the sample frequency, you let the modulator do whatever it does.

Along those lines, say there's some monstrous jitter on a 48 kHz word clock input which your PLL is able to swallow and output a quality modulator clock -- do you care about the input clock jitter? Put another way, do you need a Big Ben or some sort of cesium clock generator?

-a

I'm not very familiar with oversampling converters, I should do some reading...

I think with PLL's in that example there's still a crossover offset frequency where the PLL marries the phase noise of both the internal and external references, and the cross-over occurs at the loop filter's center frequency.  So even after all the clean-up, there's still some of the original jittery signal in there. 

But back to the point, the actual benefit of excellent clock sources are still kind of a mystery to me, as opposed to an ok one.  As I understand it, even if you put a cesium in your system, cesium doesn't have great phase noise, just outstanding short and long term stability which is reletively pointless since a recording takes a couple minutes.  The Big Ben probably just uses an OCXO and a PLL but at the end of the day it's not your DAC or your ADC so it's output is at the mercy of those device's internal PLL's... 
 
I know less than you guys, but looking at one low cost oversampled codec that I am considering, there is a THD+N spec at around -80/-85dB below FS that is 15/20 dB above the actual noise floor. THD+N at -60dB is around -36dB so likely dominated by actual noise.

If clock uncertainty shows up as a modulation noise, it will be competing with other errors modulated by signal. This low cost codec (1345) may not be representative of the SOTA.

Clock error being smoothed or averaged by division may depend on the nature of that clock error. It seems a relatively LF error (like at audio frequencies) caused by say PS noise that alters a logic threshold in a buffer might survive the averaging effect of division as it similarly affects concurrent clock periods. 

JR
 
Three of the SiLabs 514-series I2C programmable XOs showed up on my door today. Hopefully, this weekend I'll be able to build up something fun!
 
Andy Peters said:
Three of the SiLabs 514-series I2C programmable XOs showed up on my door today. Hopefully, this weekend I'll be able to build up something fun!

Any luck?
 
millzners said:
Andy Peters said:
Three of the SiLabs 514-series I2C programmable XOs showed up on my door today. Hopefully, this weekend I'll be able to build up something fun!

Any luck?

Hah, one weekend I had to basically paint the roof of my house (single-story home in the desert, the roof coating is a titanium-dioxide white lotsa-latex material, which took the roof from Zone V to Zone XI), and the next found me assembling a jungle-gym structure for my son (which also involved building a frame to contain 6" of wood chips), and last weekend I was back east mixing a couple of shows.

So hopefully this weekend! But I think my wife has other plans ...

-a
 

Latest posts

Back
Top