Hi @Moto, there is a lag between when the QA403 changes frequency/amplitude and when the windows subsystem actually applies the change. This is due to the buffers that are involved: Windows has its buffers, the QA403 app has its buffers. So, often times you might see in the display (when in mirroring mode) two peaks: One is the old frequency, another is the new frequency. This means that Windows was still playing the old tone during the acquisition and more settling time is needed.
You can check this by increasing the freq/amp pause setting. In the picture below, the 500mS indicates that anytime the frequency or amplitude of the mirror device is changed, the software will ensure at least 500mS has elapsed before starting an acquisition. You can bump this up to 2000 mS and see if it changes your measurements. And then pull it back as needed to improve measurement time.
Hi @Moto, yes, that was me that typed the first response to your mail. I have no idea how this got so confused and jumbled. The forum software is Discourse and it’s hosted on their servers, so I hope this doesn’t happen often and was a one-time glitch.
Now that I can see the plot, the issue you are seeing looks to be a windowing issue. Below is a frequency response sweep in loopback. Normally, when using the internal generator, the frequency is tweaked slightly to ensure it falls into the middle of a bin. When using an external DAC, there’s no way to lock precisely because the DAC frequency will be off a bit from the QA40x frequency. So, sometimes a tone that is generated might fall in the middle of a bin, and other times it might straddle two bins.
You can replicate this on a QA40x in loopback. Disable, the “round to eliminate leakage” checkbox in the Gen1 setting, and then make some sweeps in the AmpFreqResponse test using different windows. Below, I did just that using BlackmanHarris, FlatTop and Hann windows. And you can see how each respond. The issue is that each window has a different bandwidth and so tones that straddle two bins have different peak values, but the same RMS values. You can see this by placing an RMS measurement alongside a Pk measurement. The RMS measurement will be ruler flat while the peak will not. The RMS measurement isn’t bothered by a tone straddling two bins, since it’s look for energy. The peak measurement is simply looking for the largest peak.
So, could you repeat with a Flat Top window and see if that solves the problem?
PS. A logical question to ask is “why not use RMS measurements instead of peak?” which is a valid question for sure. But then you run into the issue of tones with wider skirts potentially contaminating measurements.
PPS. Note your SW is showing a USB voltage of 3.8V! That’s pretty low, and likely the split rail regulators inside the QA40x have fallen out of regulation at that voltage (and hence the red warning). This would manifest as problems (noise floor, harmonics) at higher amplitudes.
@matt as usual you nailed it. Deviation when using flat top is less than .05db.
Do you think this is not an issue with REW or Multitone because they use rms measurements?
I just asked Paul why develops Multitone about your comment of why peak vs rms. I thought perhaps that the reason I’d never had to worry about window type in Multitone was that he used rms. He says no, that he uses peak so that leaves me wondering why I can use a variety of window types in Multitone when doing stepped sine sweeps. Here was his comment.
Multitone uses peak for linearity measurement. I don’t see why a different FFT window might result in such variations, except if the window calculation isn’t compensated for scalloping loss. Flat top has the lowest scalloping loss among these three (max of 0.02dB) while Hann has a max of 1.42dB. The actual amplitude error depends on where the particular windowed signal falls among FFT bins, which is why you may want to measure using a frequency that is centered on the middle of a bin.
