Was hoping to do some THD v Frequency and THD v Output measurements today. Each time I tried, I got the following error. I’ve included the settings I used.
Also, can you explain the function of the Input Level Range Adder field, please?
Hi @Dave_MacKinnon, that problem with plug-ins was flagged by @Rammis on Friday, and it was fixed in release 1.132 HERE that I just posted.
the input level range adder, if you’ve enabled Autoset Input Range, will keep the input level X dB above the actual level. That is, you have 0 dBV coming out of your DUT, and you pick an Input Level Range Adder of 10 dB, then the input range will be set to 12 dBV (closest to 10 dBV). This allows you test very wide ranges automatically, without having to change input ranges. A good starting value to use for Input Level Range Adder is 18 dB.
Thanks as always, Matt! Appreciate the quick answer!
Hi @Dave_MacKinnon Can you share your plug-in settings, including FFT and Window? If the FFT is too small and the lower frequency too low, then the Peak Detect will lock onto a DC value instead of the actual value.
FFT is set to 1024k, sample at 192k. Settings for the sweep are below.
The first error might have been because the frequency was too low. I had it set for 10Hz, but the same happened with the settings below.
Hi @Dave_MacKinnon, OK, got it. The issue is the very high sample rate combined with very small FFT. 1024 samples at 192K = 5.33ms of audio. But you’ve specified at 20 Hz starting point, which needs 50 mS of audio to capture a single cycle. You can see this in a way by adding the “Sys:Resolution” measurement tile. Note that the minimum frequency you can discern with these settings 188 Hz. Also, if you run this manually (20 Hz with 1K fft and 192K sample, note that the green “F” marker isn’t present, meaning the system cannot determine the fundamental
If I bump the FFT size up to 16K, the system resolution drops to 11.7 Hz, and the “F” marker appears again.
In your particular case, because the fundamental couldn’t be determined, and exception was generated. BUT, that exception didn’t give you any useful information. The next release will change that so that the exception gives you something more to go on.
Thanks very much for reporting
Thanks again Matt. Do you feel there will be any reduction in accuracy caused by reducing the FFT, or am I simply being too OCD about measurements?
@Dave_MacKinnon, just to check, I think you need a LARGER, not smaller, FFT. The answer is somewhat complex. Some things like THD+N, for example, can go very, very fast (use a small FFT) while other things like THD will need a larger THD to tease out the harmonics. This is because the THD+N measurements are dominated by noise, and that can be quickly measured. But in the cases when THD+N isn’t dominated by noise, the harmonics are (by definition) substantial and can be readily seen in a smaller FFT.
A good experiment to do whatever you are operating in a new region you are sure is to run two sweeps with different FFT sizes. Here’s a range of sweeps for THD in loopback with different FFT sizes. Note things only get a tiny better between 64K and 256K at higher levels. But they still get better.But the difference between 4K and 16K is pretty sizeable.
And remember, if you are happy with the results of a measurement at 16K fft and 48K sample rate, if you move to 192K sample you will need a 64K FFT to scrub down to the same level.