Adjusting F_BUS to correct for drift

[macaba]

Hi all,

I'd like to generate a 1kHz clock signal (using analogWriteFrequency or IntervalTimer).
Both of these use F_BUS as a clock source. Is it possible to gently steer the F_BUS clock so that I can apply corrections to give an exact 1kHz signal (using an accurate PPS signal from external source, or NTP to detect the drift)?
I've found reference to being able to change the capacitance of the RTC crystal to correct the PPM drift on that, can I do something similar for the main crystal?

My eventual aim (the simplified version) is to have multiple Teensy devices outputting phase synchronized (to 1kHz) clock signals using sync from a PPS input or NTP data.

Thanks,
Mark

 

[kpc]

Any goals? phase accuracy, jitter/phase noise/allen variance, lock time, etc.

An easy alternative is to use the square wave output of the audio library, you can control its frequency in 10 uHz steps and the phase in 10^-7 degree steps, although with terrible jitter (approx 2us RMS). You could trade resolution vs jitter.
To significantly improve the jitter, output a sine wave, filter this and run this through a comparator to recreate the square wave. This can achieve crystal like jitter, mainly limited by noise and spurious on the line, in combination with the power supply.

 

[macaba]

Any goals? phase accuracy, jitter/phase noise/allen variance, lock time, etc.

Honestly? Whilst I do have a practical objective ('as good as possible, requiring no more than $10 of external parts, if needed, to improve performance'), I wanted to use this project as an exercise on understanding, and learning how to measure, all those things.
I'd say I have relaxed requirements, your aforementioned 2us RMS jitter doesn't sound bad to me. This is just a distributed clock source for ADC/DAC in an application where the phase shouldn't drift by more than 100uS compared to other clocks, and 500uS compared to UTC time. (if there is proper terminology for this, please don't hesitate to use it!)

Your use of the audio library is intriguing as a powerful solution though I tend to seek out the elegantly simple solutions, I'd still like to find out if it's possible to correct F_BUS (then my whole teensy is synchronized, I can call micros() anywhere and trust it).

 

[kpc]

Are you sure? Designing clocks is all about controlling jitter and drift. (Although the latter is not really stringent requirement for you)
I made a small mistake, the RMS jitter would actually be 6 us.
Using this jitter, assuming you would like to sample 100 Hz, you can only achieve 8 bits of resolution. Sampling 1 kHz will only give you 5 bits of effective resolution, regardless of the number of ADC bits.

 

[macaba]

Using this jitter, assuming you would like to sample 100 Hz, you can only achieve 8 bits of resolution. Sampling 1 kHz will only give you 5 bits of effective resolution, regardless of the number of ADC bits.

This is a slight deviation from the topic but I'm too intrigued; why? Is there a name for this effect? (would make it easier for me to search and independently study this)
In any case, the 1kHz is a sample request clock - the ADC is self clocking, hence why I thought (perhaps very wrongly) my requirements are relaxed.

 

[kpc]

Suppose that you are sampling a sine wave. When you change the sample position, the amplitude will change a little, so it will look like the signal is AM modulated by the jitter, thereby limiting the dynamic range.
Normally I work with ADC's at over 1 GHz sampling rate (clock jitter o.o.m. femtoseconds), where this effect is much more pronounced, but with microseconds of jitter this effect will also appear audio frequencies.
This applications note will give you more information.
As a quick and dirty estimate of the number of bits, just divide SNR by 6.

Edit: the jitter requirement is: tj < 1 / (1.22 * 2^b * 2*pi*fin)
where tj is the rms jitter, b is the number of bits, fin is the maximum input frequency.

Edit2: Just as a reference (not your case), to be able to sample signals up to 20 kHz @ 16 bit, you would need a clock with 90 ps jitter.
People also keep on talking about 24 bit audio. This would mean having a 350 fs jitter clock. (There are some relaxing effects for audio, so a 7 ps clock would be sufficient)

 

[WMXZ]

Edit2: Just as a reference (not your case), to be able to sample signals up to 20 kHz @ 16 bit, you would need a clock with 90 ps jitter.
People also keep on talking about 24 bit audio. This would mean having a 350 fs jitter clock. (There are some relaxing effects for audio, so a 7 ps clock would be sufficient)

@kpc,
only to be clear, the clock jitter translate to electronic noise, which limits the achievable dynamic range, or better bit range (16 or 24 bit), right?
in other words, as most ADC clocks are not as clean as suggested in above quote, really no ADC will reach the nominal bit-range.

 

[kpc]

The 100 ps should be achievable with most crystal oscillators. The ENOB of most codecs is in the order of 14-16 bits, with only the exceptions maybe achieving somewhat over 16 bits (according to datasheet), so this jitter is fine. For audio the requirements will be relaxed somewhat more, due to the roll-off of the spectrum and that you nominally do not use it for audio at full-scale. The 24 bit example was just to show the insane requirements you need to actually achieve its dynamic range. In practice i have only seen actual 24 bit ADC's for DC signals. For one of my applications, I am still looking for an (inexpensive) codec or ADC with 18 bits ENOB.
When I have some spare time at work, I might measure the actual phase noise of the Teensy 3.1. These results can be integrated to a RMS jitter value.

When you use an integer division of the clock there will in general be no problem. The problems really appear when using fractional divisions, since this will introduce jitter, because the output signals still have to be aligned to a 1/f_cpu grid.