My QA402 just randomly glitches during measurements. This happens whether I’m running an automated test or just running measurements from the main screen. I’m able to reproduce the issue whether I’m using the loopback or measuring an actual device. The glitch only seems to happen for one or two measurements and then it goes back to measuring normally.
The following pics show my setup and one of the glitches that I encountered. I have a BNC cable connected directly from the L+ Output to the L+ Input. The L- Input has a 50 Ohm muting cap installed. All other BNC connectors are open. The unit is plugged directly into a Sabrent powered USB hub which is in turn connected to a Windows Surface Laptop 4 running Windows 10.
I was running continuous measurements with a 192k sample rate, 256k FFT, Hann window, 8kHz signal @ -4 dBv.
The first screenshot shows a normal measurement running on the main screen. After several refreshes of the screen that all looked more or less identical the glitch shown in screenshot two occurred. The next screen refresh was back to normal for several more cycles as shown in screenshot three.
When these glitches happen during an automated measurement it causes these odd spikes in the graph and I have to restart the test and hope that it completes before another glitch happens. This screenshot was taken with the loopback setup as above but connected directly to the laptop instead of going through the USB hub. The spike in the graph corresponds to one of the glitched measurements that showed up on the screen during the measurement.
Hi @LandscapeJohn, can you see if this happens at 48K sample rate? Also, if you have an instance where this does happen (as in your first photo), then click to “time domain” and share that waveform. That will help to see if the cause is an underflow or not (that is, the QA40x box needed data to send but it wasn’t available because the host computer was busy and so it substituted a buffer of zeros).
Trying it at 48k today I wasn’t able to reproduce the issue. I don’t remember if I had tried that before today. It took me a while to pause it at the right time to get a screenshot of the time domain waveform during a glitch but I finally got one. Maybe you see something I don’t but to me it looks the same as the normal time domain waveforms.
Hi @LandscapeJohn, I tried to repro for 30 minutes last night with your settings but could not. I set a breakpoint in code so that if a THD measurement went south (due to a glitch) it would stop. And then let it run for 5K cycles at 192K with no issues.
Just to make sure: This only happens for you at 192K sample rate AND it happens in loopback, correct? And are you 100% sure the time domain waveform reflects the bad event? I agree, it does like fine. But at the higher sample rate a 128 word stutter (512 byte buffer) due to overflow/underflow might be present and not seen on the 70 Hz waveform you have (2700 samples per cycles). And since you see this at 192ksps and not 48ksps, that strongly suggests something with USB.
I’d propose the following: Next week we should have a new release to activate the front-panel I2S. As part of that, flag bits in the QA40x hardware will be added to catch underflow/overflow, and then those will show up in the upper left (along with Range, Atten, etc) if a transaction completes with an error. And then you can see if either of those conditions is present when you see the problem. And if it is, then we can work on timing changes in the app. For example, when in 192K sample mode, the PC has to provide 4X more updates per second. We could increase buffer sizes at the higher sample rates to help with the loading.
If you are still seeing glitches at 192K but are not seeing under/overflow show up on the screen, then we’d send you a label so you could return the unit for evaluation.
Thanks for the followup, @matt. I went ahead and tested some more today and it looks like it only is happening at 192k; even running at 96k I didn’t see any glitches. I’m as sure as I can be that the time and frequency waveforms reflect the same even since I switched between them a couple times when taking the screenshot but I went ahead and did it again today to verify as best as I could.
I may have made a breakthrough, though, since today the time waveform had a small glitch in the middle of it that I was able to zoom in and capture. Hopefully this gives you an idea what’s going on and if not then I’ll plan to download the update next week and see if that helps us diagnose.
Here’s the zoom-in on the glitch in the time-domain waveform today:
I was having the same issue this morning. Trying to do an average of 10 measurements in I’d get a glitch on the fourth or fifth. Was at 48k sampling. Running V 0.999
Hi @LandscapeJohn, yes, that is what the issue is. I think with the over/underflow detected, the acquisition will be thrown out and another repeated and you’ll never see bad waveform. Stay tuned for new firmware next week. Thanks!
Yes, you should see “DAC underflow” or “ADC overflow” messages in the upper left if those are occurring in 1.1. If that pops up, then treat the measurement as suspect. Later, code will be put in to repeat the measurement automatically (same if a range error occurs). But if you are seeing something glitchy without an error message, then please post your time domain screen shot.
Update for 1.12: I think these messages (DAC underflow, ADC overflow) are a bit pessimistic. In other words, the acquisition was fine but the message still shows up.
