[sdiy] Frequency shifted from BBD?

[rburnett at richieburnett.co.uk]

When generating an arbitrary frequency clock signal the edges of the 
clock output are forced to occur at the nearest edge of the master 
clock.  It is that "temporal quantisation" that results in the jitter on 
the output clock in the time-domain.

In the frequency-domain you can think of all of those unwanted 
inharmonic components in the spectrum as resulting from aliasing of the 
infinite spectrum of the wanted output clock, when generated at the 
finite sample rate of the master clock.

Going to a higher master clock rate for the NCO obviously helps by 
reducing the amount of jitter.  There are better ways to "clean up" 
digital clocks generated by NCO / DDS techniques using filtering, 
comparators etc, but they're not trivial.

-Richie,



On 2024-10-28 11:08, Tom Wiltshire wrote:
> I notice I "misspoke" there a little -
> 
> I should have said that for a *period* of 3.25,  the output would be
> cycles of *period* 3 and *period* 4: 3,3,3,4,3,3,3,4,3,3,3,4,etc
> 
>> On 27 Oct 2024, at 16:14, Mike Bryant <mbryant at futurehorizons.com>
>> wrote:
>> 
>> *
>> It's inherent to any digital NCO, not the PIC#s example
>> specifically. For most frequencies, the frequency increment will not
>> be a neat divisor of the accumulator wraparound value. This means
>> that there will be a slight jitter in the output frequency. One way
>> to think about it is that the NCO creates a frequency by averaging.
>> So if we wanted a frequency of 3.25, the output would be cycles of
>> frequency 3 and frequency 4: 3,3,3,4,3,3,3,4,3,3,3,4,etc
>> 
>> This is of course a problem even in a totally digital domain.  The
>> easiest solution there is to sum weighted inputs from the final
>> sample and last but one sample, varying the weighting according to
>> where you are in the sequence.  Of course this is easy in digital
>> but would require some fancy VCA work plus a sample and hold to
>> store the last output from the BBD which would become the 'last but
>> one' sample.
>> 
>> -------------------------
>> 
>> From: Synth-diy <synth-diy-bounces at synth-diy.org> on behalf of Tom
>> Wiltshire <tom at electricdruid.net>
>> Sent: 27 October 2024 14:00
>> To: Didier Leplae <didierleplae at yahoo.com>
>> Cc: SDIY <synth-diy at synth-diy.org>
>> Subject: Re: [sdiy] Frequency shifted from BBD?
>> 
>> Brian already gave a comprehensive answer, but here's my own take.
>> 
>>> On 25 Oct 2024, at 21:47, Didier Leplae <didierleplae at yahoo.com>
>> wrote:
>>> 
>>> Do you think this is specifically a problem with the PIC’s
>> hardware NCO or do you think this is inherent to any digital clock?
>> 
>> It's inherent to any digital NCO, not the PIC#s example
>> specifically. For most frequencies, the frequency increment will not
>> be a neat divisor of the accumulator wraparound value. This means
>> that there will be a slight jitter in the output frequency. One way
>> to think about it is that the NCO creates a frequency by averaging.
>> So if we wanted a frequency of 3.25, the output would be cycles of
>> frequency 3 and frequency 4: 3,3,3,4,3,3,3,4,3,3,3,4,etc
>> This jitter pattern has a much lower frequency than the actual
>> output frequency, and can be within the audible range even for
>> multiple-100KHz or MHz outputs.
>> 
>>> There seem to be a bunch of BBD based devices that have tap tempo
>> for example, which I imagine must be done with a uP.
>> 
>> Yes. There are other ways of creating a digital clock that don't
>> have the jitter problems of NCOs. For a tap tempo delay, I would use
>> a divider-based system, since this provides an output with no
>> jitter.
>> A divider-based clock isn't feasible for a flanger because the steps
>> between frequencies cannot be made small enough over a wide enough
>> range - or at least, not on the hardware I was using. It *might* be
>> possible on some chip with a much higher clock frequency and a much
>> bigger divider.
>> 
>>> In fact I make already make a delay module like this, but it seems
>> to present more of a problem with chorus and flanger circuits
>> because of the higher frequencies.
>> 
>> Yes. It's not only to do with the higher frequency, but also the
>> need to sweep the frequency, which implies the need to have
>> imperceptibly small steps between all the frequencies you can
>> generate. For a tap tempo delay, that wouldn't matter, and if the
>> available clock frequencies provided outputs that were even several
>> milliseconds apart, that would be close enough (who can tap more
>> accurately than 5milliseconds anyway?).
>> 
>> ________________________________________________________
>> This is the Synth-diy mailing list
>> Submit email to: Synth-diy at synth-diy.org
>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>> Check your settings at:
>> https://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org
> ________________________________________________________
> This is the Synth-diy mailing list
> Submit email to: Synth-diy at synth-diy.org
> View archive at: https://synth-diy.org/pipermail/synth-diy/
> Check your settings at: 
> https://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org