[sdiy] Flangelicious noises - some queries about NCO jitter and resampling and similar

Magnus Danielson magnus at rubidium.se
Thu Feb 13 15:15:00 CET 2020


The classical wow and flutter test is to use a reference signal and then
measure side-band noise.

One way is to phase-lock an oscillator, as the phase-lock locks up, the
lock forces the output of the phase-detector to produce side-band.
Measure the noise out of the phase-detector, preferably with spectrum
analyzer. With a separate oscillator being inserted offset from the
carrier, with known amplitude and offset relative the carrier, the scale
can be calibrated.

Report noise amplitude in reference to the amplitude of the carrier
wave. This phase-noise measurement is essentially what is described in
IEEE Std 1139.


On 2020-02-11 13:06, Tom Wiltshire wrote:
> Hi All,
> I thought I’d give you an update on this.
> I’ve been able implement some of the ideas you all provided, although
> it wasn’t straightforward (is it ever?).
> Moving to the new chip allowed me to double the NCO clock to 32MHz
> (idea 1). I also doubled the frequency increment to use more
> resolution in the NCO (idea2). This means that the NCO output is four
> times higher than I need it, so I then have to implement /4 somehow
> (idea 3). Luckily there are two “Configurable Logic Cells” on the chip
> that can be set up as divide-by-two flip-flops. Unfortunately they
> don’t accept the output from the NCO as an input, so I had to route
> the NCO via another module (the “Digital Signal Modulator”) set-up to
> pass the NCO straight through. The final divided NCO output goes to
> the “Complementary Waveform Generator” module that makes the final
> biphase-output-with-deadband that I need.
> In summary, the final “BBD Clock” uses five different hardware modules
> on the 16F18313 chip! It looks like this:
> NCO -> DSM -> CLC1 -> CLC2 -> CWG
> Ok, so in theory I should see some improvement in performance. Now I
> come to my new question! -
> How can I evaluate the performance of this version against the old
> version?
> Currently the only real metric I have is “does it sound noisy?” when
> it’s put in the final circuit. This isn’t great since the noise level
> depends very heavily on the exact relationship between the frequency
> increment and the NCO length, so it can vary markedly for quite small
> changes.
> Thanks,
> Tom
> ==================
>        Electric Druid
> Synth & Stompbox DIY
> ==================
>> On 31 Jan 2020, at 12:07, Tom Wiltshire <tom at electricdruid.net
>> <mailto:tom at electricdruid.net>> wrote:
>> Ok, so the advice would be:
>> 1) Use the highest NCO clock I can to minimise jitter
>> 2) Increase the frequency increments as much as possible to use as
>> much of the available increment resolution as I can
>> 3) Divide the resulting frequency down if it’s too much high
>> 4) Add a little bit of dither to break up audible cycles/tones
>> 5) Sample the LFO at as high a frequency as possible
>> Is that a fair summary? Anything I’ve missed? (Noise shaping the
>> dither, I suppose)
>> For (1) I can move the clock from 16MHz to 32MHz, so there’s a small
>> improvement.
>> For (2) we can increase the frequency increment, assuming I can work
>> out a way to get the chip to provide the division for (3). If I could
>> run the NCO at (say) x8 of the frequency I need, that might offer
>> some real benefit.
>> The dither (4) doesn’t really depend on anything else, so that should
>> be do-able.
>> The LFO sample frequency should also be able to increase since the
>> whole chip is running twice as fast as the previous generation (32 vs
>> 16MHz again). So everything else being equal, I might be able to up
>> the LFO sample rate to 50KHz or so. However, that seems a bit crazy
>> (audio-rate sampling for an LFO with a max of 20Hz) and instead I
>> might do better to add some interpolation of the frequency increment
>> at the end of each cycle. E.g. We’re aiming for an increment of X,
>> and we’ve got an increment of Y, so next cycle uses X+x to get a bit
>> closer. The difficulty there is that we need to know how many NCO
>> cycles there will be before our next LFO sample, and that sounds
>> horribly like division! So maybe just whacking the LFO sample rate up
>> is in fact the best you can do for that after all.
>> Thanks,
>> Tom
>> ==================
>>        Electric Druid
>> Synth & Stompbox DIY
>> ==================
>>> On 28 Jan 2020, at 13:07, René Schmitz <synth at schmitzbits.de
>>> <mailto:synth at schmitzbits.de>> wrote:
>>> Hi Richie,
>>> On 28.01.2020 13:23, rburnett at richieburnett.co.uk
>>> <mailto:rburnett at richieburnett.co.uk> wrote:
>>> >>> What I don’t understand though is how this helps. Increasing the
>>> >>> output frequency is going to increase aliasing too, and dividing it
>>> >>> down again afterwards doesn’t seem to remove that to me. How does
>>> >>> this work please, René?
>>> >>
>>> >>  It's a standard trick. With higher DDS clock you get smaller
>>> >> time-errors, and then the divide down just removes transitions between
>>> >> the transitions. Higher synthesized frequency allows you to use more
>>> >> of the upper bits of the DDS, to achieve more effective bits useable
>>> >> in the DDS.
>>> >
>>> > Ok, so this allows you to make better use of the available DDS frequency
>>> > bit resolution, by synthesising a higher output frequency and then
>>> > dividing it down.  But it doesn't do anything to help with
>>> > jitter/aliasing at the top end.
>>> Here are your original points:
>>> 1) Resampling of the LFO output by the NCO reset
>>> 2) Frequency stepping caused by the NCO minimum frequency step
>>> 3) Jitter cycles caused by the NCO
>>> Well it helps updating your NCO more frequently, because each cycle
>>> is shorter now. I.e. higher sampling rate of your LFO.
>>> The NCOs minimum frequency step is reduced. Because the tuning word
>>> effectively shifts right, bringing in room for more LSBs.
>>> The cycle to cycle time variation (aka jitter) is still 1/f(clock)
>>> of your NCO. Not really an improvement there by the division, if you
>>> run the NCO at the same frequency as before. But if you can run the
>>> NCO clock higher then the variation is reduced.
>>> Best,
>>> René
>>> --
>>> synth at schmitzbits.de <mailto:synth at schmitzbits.de>
>>> http://schmitzbits.de <http://schmitzbits.de/>
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org <mailto:Synth-diy at synth-diy.org>
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org <mailto:Synth-diy at synth-diy.org>
>> http://synth-diy.org/mailman/listinfo/synth-diy
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20200213/0dea30f0/attachment.htm>

More information about the Synth-diy mailing list