About 4 of every 5 or 6 acquisitions give either DAD underflow or ADC overflow or both errors with a mangled FFT displayed. No user interactions.
Differential left charnel loopback.
I can confirm multiply underflow/overflow errors on my units. QA40x 1.171 together with QA403 slower than QAAnalyzer with QA401. Also CPU utilization looks higher with QA40x
Running 1.173 - this appears to be performance related. Increasing the FFT bins or sample rate changes the probability of errors. at 192 ksp and FFT 128 approximately 25% have errors. 96ksp 128k gives approximate 10% error rate.192kps/512kFFT gives >90% error rate.
Hi @mhuth1776, the under/over errors an often be pessimistic. That is, the trace looks as expected but you still see the error. In your case, however, the trace indeed looks like packet loss. I see you are at 192K. If you switch to 48k do you still see the issue?
Below is a THD/Freq&litude trace executed at 48ksp 128k FFT. It shows two bugs:
1 is the packet loss where the THD jumps up on one of the traces. The other is the missing samples at the same frequency every time. This occurs twice during the THD/freq scan. The first is at approximately 24.75 Hz, and the second is at a bit higher frequency which I did not catch when it happened.
To fix the packet loss, I suspect you will have to do something with the application priority, as the packet loss is worse when something else is going on in another window. It looks like the 48kps only loses packets when another task has the disk system hung up. I was downloading some files when these packet losses occurred. However, at higher sample rates and/or larger FFT sizes, the packet loss occurs regardless of other activity. Moving the mose around can perhaps make it worse, though.
I’m attaching a stand-alone capture of the failure to compute THD at 24.536 Hz. It is quite repeatable.
Spoke too soon. After playing around with this, I think the problem is the old harmonic selection and notch filter Q problem. At one point you were going to add some advanced features to do a bin count for the width and a harmonic count for the THD computation, but that hasn’t happened, apparently.
At any rate, this was happening reproducibly. The peak selector was set to the peak of the trace. Increasing the sample rate or FFT size would make the bug go away, as did setting the peak to be the generator setting. After that, I tried to reproduce the problem again, and could not even after reverting to the previous settings. Next time I catch it I will save the settings so I can be sure.
Hi @mhuth1776,
What does your system-about say for processor, OS type (32/64bit), installed ram and OS version? Can you try another USB port on your machine?
I think it should be picking up the 2H in the example you showed. A test you can do is to use GEN2 to be the second harmonic. Set the frequency resolution to 0.5 Hz, and then step around with the FREQ2 up/down button.
Here I have GEN1 at 245.5 Hz (no rounding), and the 2H is correctly picked up when GEN2 is set to 41 Hz.
And the 2H is correctly picked up when the GEN2 is as high as 56.5 Hz.
And then for your nominal (GEN1 = 24.536 Hz) it also appears that the 2H is correctly picked up when GEN is set to 49.4 Hz.
In the capture you shared, the green “F” at the bottom shows it has correctly locked onto the fundamental. The “—” for the THD % suggests that there was an invalidate computation at some point. Usually if something along the way result in a “NaN” (not a number) then that is flagged as a “—” result. Yes, please do report back if you can reproduce again. Thanks very much for this report.
| Device name | Z97-Win10 |
|---|---|
| Processor | Intel(R) Core™ i7-4790K CPU @ 4.00GHz 4.00 GHz |
| Installed RAM | 32.0 GB (31.7 GB usable) |
| Device ID | 64E87322-C875-4117-8584-0D17C37169C5 |
| Product ID | 00330-80004-57075-AA309 |
| System type | 64-bit operating system, x64-based processor |
| Pen and touch | No pen or touch input is available for this display |
This is a 4-core - 8-thread cpu with a Z97 chipset. It is a few years old, but should have more than enough horsepower to run the QA403 software. I have tried several ports - front panel, motherboard, powered hub with no noticeable difference.
I will see if I can reproduce the missing harmonics problem. What I can say is that when the problem occurred, the FFT bins were such that the harmonic fell outside the integer multiples of the fundamental bin, as shown by the markers. Unfortunately, I did not capture that screen shot, as I thought this was readily reproducible. When I had it reproduces, I could step the generator frequency and at some point the problem would resolve. Then stepping the generator frequency back caused it to show up again.
I am famous for finding bugs that no one else sees!
Hi @mhuth1776,
I think there are two issues here that hopefully aren’t overlapping. The link below goes through some things that need to be done when looking at THD and low frequencies. Some have been fixed, but it’s a good overview of the math and how low frequencies need a bit more attention.
Second, can you please try this:
- Set up for left-channel loopback for L+, and short L- input
- Set File->New Settings
- Go to Gen1 and disable round to eliminate leakage
- Set 0 dBV full scale input
- Select the AmpThdVersusFrequency Automated Test and setup as follows:
This will run 1000 cycles. While running, use your machine as you normally would–videos, downloads, etc
Here’s the plot I get at 48K:
And then I changed the sample rate to 192 and press F3 to run the test again:
Can you run this on your machine and share what you get?
So I have figured out a way to reproduce the THD-- problem. It is definitely a software bug. When the THD measurement upper frequency is set to the Nyquist limit of either 24k or 48k depending on the sampling rate, the problem occurs. While it is not possible to set the upper frequency to the Nyquist limit in the THD screen (gets invalid value error - BTW, I though I saw an update that was to make that possible) it is possible for it to get that value from the following procedure:
Set the sample rate to 192kps. Now set the THD measurement upper frequency to something over 48kHz. Then, set the sample rate to 96kps. The upper measurement frequency gets set to 48kHz, and the THD measurement goes away.
Here is a settings file that reproduces the problem: Or not, can’t upload a settings file! The key point is that the settings file shows the measurement bandwidth set to 24000,
Now onto the second problem, which would seem to be unrelated. This second problem is the occurrences of over/under runs on the ADC/DAC which result in corrupted FFTs. As you have asked, I ran the two experiments, one at 48k and one at 192k sample rates.
Seems similar to your results, compensating for scaling. However, here are results from three more 192ksps runs using useful FFT sizes of 64k, 128, and 256k.
While it’s a little hard to see, the 132k and 256k FFTs swing wildly from around -114 all the way up to -50dB. This was accompanied by many incorrect FFT screens displayed in the man window while acquiring the data. At 64k FFT bins, things settled down to where it belongs, with only an occasional “chicken-little” announcement on the FFT display. I’ve attached a crop of the graph.
Unfortunately, the 64kFFT is not always without errors:
Hi @muhtuh1776, thanks for the repo steps. I’m trying this based on your instructions:
- File->New Settings to get to a common point
- Set to 192Ksps
- Change measurement stop frequency to 95k
- Enable Gen1 and add THD % and dB to measurements
- Run
Display is as expected.
- Reduce sample rate to 96k.
- Click OK to message that Measurement Stop is being reduced
Display as expected
What am I missing?
Whoops…found it. FFT size needs to be 512K. Doesn’t seem to happen when FFT is 256K or smaller, or 1024K. Just 512K.
In any case, this will be investigated and fixed for next release. Thanks very much for reporting this!
In the THD and THD+N setting for Measurement Upper Frequency you had to be less than Nyquist. In the RMS setting for Measurement Upper Frequency you had to be less than OR EQUAL to Nyquist. This has been changed for the next release so that all settings for Measurement Upper Frequency have to be LESS THAN OR EQUAL to Nyquist.
Thanks very much for reporting! The issue you reported with THD not showing up is fixed too.
For the errors you are seeing at 192k, I took a video of the QA403 running on a very low-spec fanless PC (N4000 processor). This was 1000 acquisitions (500 Hz to 1500 Hz in 1 Hz steps, with “round to eliminate leakage” unchecked). Alongside the acquisition is a youtube video playing. The video is smaller FFT sizes and shows no errors, but as FFT sizes go up, errors do begin to increase. We will study more and see if anything can be done.
Just to point out that 4790k at 4+GHz is hardly a low spec machine. Never does the hardware monitor show any of the CPUs at much over 35% when acquiring data from the Q403. The Q401 at 192ksps and 256k FFT never misses a packet whereas the q403 with its software misses about 2 out of three.
Hi @mhuth1776, when time permits can you please version 1.178 located HERE and see if that helps the issue of larger FFT at 192Ksps?
The 1.178 version has more overlapped IO buffers allocated to the OS, and for larger FFT on the low-spec fanless mentioned above, it has fixed the problem.
That seems to have fixed the over/under run problem. I’ve seen a couple of ADC overruns, but it seems like they were of the pessimistic variety.
Thanks, Matt!