The issues with QA403 and 1.183 in terms of usage

How to use the AQ40X software (version 1.183) to control QA403 for continuous signal transmission, similar to the “settings → Fixed Tone Generator → start” feature in the QA401 software.

I don’t know the QA401 but try using the Idle button for a continuous tone.

1 Like

Hey guys, just got my QA403 this week and I’m having a lot of fun learning. But I I’m having the same issue: the generator is virtually unusable as it resets and pulses with every loop. I have been reading that “idle” will fix the pulsing, but it only works when you’re not in “run” mode collecting data.

It’s fine for now, I’m using an external generator for some things, but I’m thinking it won’t be able to measure gain and such.

Anybody figured this one out yet?

Hi- the QA403 measures gain just fine with it’s “pulsing”- that is just what it does to do its thing. The idle mode allows it to be just a generator.

1 Like

Okay, I’m still learning. I couldn’t understand why I was forced to stop acquiring data in order to use the generator without pulsing.

I didn’t realize you can use the visualizers while running the generator in idle mode. I’m good, but have a long way to go.

Have been using my QA402 and am still learning things. This forum is pretty well supported which helps.

1 Like

Hi @Jonas, the bursting you note is often one of the first questions someone will send to support. And it is a departure from the way a lot of audio test gear works. There are two parts to this question: The analyzer input and analyzer output.

Analyzer Input

Keep in mind that all test gear that is relying on the FFT to make measurements is effectively working in bursts–a 32K FFT for an amplitude measurement is a measurement made on 32K samples. What happens before or after those samples is irrelevant because they are ignored by the FFT.

If you play a constant tone from an external generator, the QA403 happily measures whatever is inside the 32K samples it collects.

Analyzer Output

So, given the input is a discrete event, why not make the output a discrete event? If you put the QA403 into loopback, select a 4K FFT and and switch to the time domain, you will see the following burst. The 4K FFT (4096/48000=85mS) is 85mS of time, and that time is centered in the burst (red box).

OK, but what if you are dealing with something like a bluetooth device that had 40mS of path delay?

In that case, the acquired samples would appear to arrive late, and instead of capturing the chunk in the middle, we’d capture the chunk up front, which would be wrong.

To compensate for devices with excessive path delay, you can specify a larger pre-buffer (Edit->Settings). That will grow the amount of buffer, and increase the space prior to the 4K samples used for the FFT.

Another concern with a burst can be the dynamics. For example, there might something odd with noise gates opening/closing, or a compressor attack. In those cases, you again use the path delay to grow the region prior to the measurement so that you can effectively make a steady state measurement of the system.

And then, if you want to understand the compressor behavior, you can use an automated test (AMP Dynamics) to construct a stimulus:

And then the captured data lets you see how the DUT responds to the changes in amplitude. Here is the waveform in the time domain in loopback.

And here is the output from the plug-in. showing the gain tracking is precisely 0 (which is expected in loopback). A compressor would exhibit gains that varied based on time whenever there was a change in amplitude.

More info on the dynamics plugin at the link HERE

What about IDLE…what does it do and when do I need it?

OK, so just about any measurement you might anticipate can be solved using bursts. And you get a very clean way to see the start/stop activity, can pause between bursts (to limit heating, for example. See Edit->Settings Pause Between Acquisitions).

In the end, you get an extremely agile system that can make a series of discrete measurements very quickly while stepping both frequency and amplitude. And–the best part–there is a perfect sample-exact relationship between the input and output. If you are using a sound card, you can’t be sure what the phase relationship is between input and output. It may change every acquisition, it may not. The act of starting and stopping or re-plugging the sound card may change the relationship too.

What can’t this do?

And the answer to that is simply this: Help a human debug a circuit. There are simply times you need to hunker down with a DVM or scope and trace your way through a circuit and look at the AC shape and DC offsets at each stage. And for that, IDLE is used.

When IDLE is active (shown in lower left of app), measurements aren’t happening. Idle is activated by stopping measurements and pushing ‘I’ or the idle button.


The system is just generating a sine at the frequency and amplitude you have indicated with the GEN1 settings. And you can probe away with manual test tools.

Hopefully this helps explain a bit more.

1 Like

I have encountered that problem too and I think that there are times that you must start a measurement on a steady state of the electronics. Imagine a tube amp with a sagging PSU when loaded measuring THD on the output you will get more accurate results when applying a steady power into the DUT instead of bursting it with input = load bursts… an other case I had was with messuring compressor gain reduction with timing constants like attack and release times and trying to calliberat the VCA THD call…
I really need to be able to preform measurements with steady input in those cases.

Since we are on the topic of IDLE, I wanted to mention that the QA40x software will often just shut down (crash) when coming out of IDLE. It happens maybe 30% of the time. When I am done using my QA402 in IDLE mode, and then click on IDLE to turn the mode off, the software will be non-response for a few seconds and then it is like you just exited the program…

I really need to be able to preform measurements with steady input in those cases.

Hi @Deadcap, you can probably get there using the pre-buffer setting. How many seconds of steady state sine do you need before the measurement is made?

Hi @Var, yes, that has been noticed and in the last few release you’ve probably noted some changes to timing and/or idle display as this issue is debugged. It seems more prevalent on slower machines, but it still happens on fast machines.

What is curious is if you turn off idle using the ‘i’ key, and then immediately run it copes fine… But if the software turns off idle and then transitions to run mode the crash is apt to happen. And yes, when it happens the app crashes hard. I hope this gets solved soon.

I doubt it is machine related as I believe it is an older I5820k running at 4Ghz. I use my mouse to click “IDLE” on or off. What you described is what seems to happen- not all of the time though.