[sdiy] Frequency shifted from BBD?

[Tom Wiltshire]

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?).