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

Magnus Danielson magnus at rubidium.se
Thu Feb 13 16:58:09 CET 2020


As you where doing BBD, and care about BBD output noise, why not try to
feed it a 1 kHz or better yet 3 kHz tone from a ... you know...
synthesizer. Then use another oscillator as measurement lock-up
oscillator, this one you want a DC-coupled linear FM input if you can
get it, but otherwise you have to go with the normal CV input.

As phase-detector you can use a ring-modulator, but here you want a DC
output of the signal, which most does not do as they have DC-blockers.
You could use an XOR-gate if you have square-waves into it.

Out of the phase-detector, you have two signal paths, one is the loop
filter for the PLL. Here I prefer to build a PI-loop, which is
essentially an integrator. The minimum build-up is an op-amp with a
input resistor and then a capacitor and resistor in series in the
negative feedback path. The minimum setup is however a bit difficult to
dimension things correctly on, as it get good result when all the
parameters is fixed so it's own values can be fixed. A gain-pot may be
needed to scale loop-gain properly, that helps part of the PLL design
problem. The second path from the phase-detector should have a fixed
gain stage typically. So, a TL-072 with a handful of passives and a
XOR-gate of your choosing. Maybe another op-amp pair to square signals
up if needed.

Then, finally, a spectrum analyzer over the audio frequency range.
Nothing exotic, but good dynamics come into use. I would maybe use a
DN60 because it's lying around, but even the phone with an app would
work. If your oscilloscope can pull a FFT off, fine.

If one can insert a signal from an offset oscillator (for a 1 kHz
carrier signal, consider a 1,1 kHz tone to measure to produce the 100 Hz
offset) with a known relationship in amplitude relative the carrier
signal, say -30 dB, then one can calibrate the scale for improved
knowledge of noise levels, as phase-noise is reported in dBc/sqrt(Hz),
decibels relative carrier, and corrected with the filter bandwidth.

It's not that this is very exotic things, it's just that since you do
not use these things like this, they may not be very well prepared for
it, so it's more that which causes you problems. Some oscillators have
PLL capability, I have a pair of JLC Moog 921 clones lying around, which
has the PLL in them so it becomes more the effort of pulling the right

As you getto this, the cleanness of the oscillators etc. may become a
problem, but if you clearly can hear problems, then maybe you have good
enough stuff.

Phase-noise measurements like these isn't all that hard, and if you work
a little more with it, you will find slopes of noise as well as spikes.
The slopes is due to the white and flicker noise, and as shaped by the
resonator bandwidth, as modeled by Dr. David Leeson in an article in Feb
1966. That and his 2016 50 year lookback is good reads, while just a
scratch on the surface. For long-term stability we use the
time-stability measure called Allan Deviation, of Dr. David Allan, as
published in the same Feb 1966 special issue. For Allan deviation, read
the Wikipedia article on Allan Variance, which I wrote.

One can home-brew quite sensitive phase-noise measurement tools for very
low cost, even for higher frequencies. I have a couple of more extensive
rigs that I use to measure high stability quartz oscillators and atomic
clocks. My basement lab grew slightly out of hand from measure and
perfect the ASM-1 VCOs, which is where I started.


On 2020-02-13 15:21, Tom Wiltshire wrote:
> Thanks Magnus.
> What’s the “ghetto” way of doing such a test?!
> I don’t have either a reference source of frequencies that high
> (25-600KHz) or a spectrum analyser. The scope does an FFT, but that’s
> as close as it gets. I don’t even have a very accurate way to measure
> frequencies, much less while they’re jumping about.
> Tom
> ==================
>        Electric Druid
> Synth & Stompbox DIY
> ==================
>> On 13 Feb 2020, at 14:15, Magnus Danielson <magnus at rubidium.se
>> <mailto:magnus at rubidium.se>> wrote:
>> Hi,
>> 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.
>> Cheers,
>> Magnus
>> 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
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20200213/0729801e/attachment.htm>

More information about the Synth-diy mailing list