I see a lot of the crystal oscillators out there spec 45/55 min/max duty cycle at their operating frequency. They always spec this at 1/2 Vdd.

Why do they spec it at this voltage level? I am looking for an oscillator for an asynchronous SPDIF receiver and audio PWM modulation chip and would really like something that was 50/50. Do these crystal oscillators 'shape up' and give a better duty cycle (not to mention clock jitter) at full operating voltage?

 

One solution is to get a crystal oscillator at twice the desired frequency and then run it to a flip-flop, that should get you 50/50 at the desired freq.

Lefty

__________________
Measurement changes behavior

 

I think you are misinterpreting the spec. I believe the duty cycle is measured where the waveform crosses Vcc/2, not when the actual supply voltage is half the nominal. In other words, if Vcc=5V, the duty cycle would be measured where the output crosses 2.5V.
You are gonna say "Duh!".
As Lefty says, use a toggle FF (divide by 2) if you want to get really close.

__________________
Ron

 

Doh! I gotcha now

 

I make crystal oscillators for a living.

The duty cycle on logic output oscillators is normally quoted at the midpoint between the high and low output voltages. For CMOS output oscillators that is almost always at half the supply voltage. Also most oscillators are designed to have a 50% duty cycle, but there will be a tolerance on that.

Oscillators below about 10 MHz are usually made by dividing the crystal frequency so the duty cycle will be very near to 50%. As you get to higher frequencies, there is no divider so asymmetries in the section that actually oscillates will be passed directly onto the output.

Also at high frequencies, the rise and fall times take a significant fraction of the cycle time, so if the rise and fall times differ, that will vary the duty cycle.

That is why the duty cycle is not exactly 50%, and is usually quoted as 45 to 55%. For most oscillator users it isn't important so that is why the specification isn't tighter at lower frequencies, where in practice the duty cycle will be closer to 50%.

 

That's very interesting. If he's talking about clocks as in time pieces, then it can be very significant because any discrepancy well add up over a period of time. You must always assume the crystal will not be dead on. Even the amount of solder flow on a pre-fabbed circuit board will change the stray capacitance. You must always account for this discrepancy either through software or physically with a variable capacitor.

I wrote a piece of software that could fine tune a crystal's frequency inaccuracies that I got in a big fight about on here...lol, so I won't go to into it too much. Just to say it has very minute fine adjustment that uses two delay loops, where one loop would determine the other delay loops instruction of when to jam load the counter. That clock as far as I could test it was as accurate as an atomic clock but had to give it away to my customer.

Now a crystal will age and that will cause it to change slightly. With software it can be reprogrammed to account for aging too.

 

Except that clock duty cycle has absolutely nothing to do with the accuracy of a crystal-controlled timepiece. What you said is true about clock frequency, but that wasn't the issue here.

__________________
Ron

 

Well, I am looking at a 12.288MHz or 24.576MHz oscillator for the S/PDIF receiver (which also happens to serve as the master clock for the whole audio system). That's 81.4ns per clock period, so a 45/55 min/max limit would be about +/- 4ns. With Tplh and Tplh and pulse width distortion, I don't think a JK or toggle flip flop would really improve on that. They also list 49/51 ( <1ns duty cycle difference absolute) as typical on most data sheets, with jitter in the ~100ps range. So maybe I would be better not messing around with this? I'm looking at eval board data sheets and it looks like on most eval boards they just take the crystal oscillator input straight to the chip, no PLL or duty cycle correction. That's the way we did it at Cirrus with the part I worked on, but who knows what they did on other eval boards.

Hmm.

 

Oh well excuuuuuuuuse me. I did not realize you were the issue setter.

 

Why do you need 50% duty cycle?

__________________
Ron

 

I'm not. Speakerguy is (on this thread).

__________________
Ron

 

Speaker guy! I get it

 

Huh? 'Splain more here? I don't see how you can "fine tune" and "jam load" a counter to correct the clock without having a reference to which you can compare. Even the "atomic clocks" you see hanging on everyone's walls these days aren't even close to being as accurate as a true atomic clock.

Dean

__________________
Dean Huster, Electronics Curmudgeon
Contributing Editor emeritus, "Q & A", of the former "Poptronics" magazine (formerly "Popular Electronics" and "Electronics Now" magazines).

R.I.P.

 

OH come on now. Your asking me to explain to you where the industry standard is. There are several. WWV is a few of them. I know they get their information from atomic clocks. A cell phone gets continuous updates. So yes I compare it to something. Then I jam load the counter in my clock circuit that I designed using micro-fine delay loops which trigger another delay loop which then, jam load the counter. Very fine increments. In fact, every second is exactly the same length of time unlike even the PC which uses the 8253 (TIC) and it is jam loaded every few minutes so that every minute is not 60 seconds. I know, I've been through the code. You can pull up the graphic clock and watch the correction factor. So what they do now is download clock updates like a cell phone.
So how would I compare my clock software? To Swiss movement baby. Swiss movement. Even sweep, continuous 60 seconds per minute, accurate over a long length of time with no fine tuning capacitor to knock around. It is software adjustable.

Now, that being said. I have posted it once. If you like I can post it again. I will be glad to explain it, but I don't want to fight with anybody about it. You can build one yourself and you tell me how accurate it is.

Fair enough?

 

I would be interested SV, I have never seen your circuit before.

And Roff, the more I think about it the less important I think duty cycle probably is. So long as everything is only done on one edge of the clock signal, only the device jitter should matter.