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.
Hi @Var, release 1.192 is HERE
Can you see if the IDLE issue is better or not when time permits? Thanks!
No Problem. I mainly use the IDLE function when Troubleshooting and testing power meters. Probably next week I will have some power meters to check and will report back. Thanks!
Matt- I used the Idle function yesterday several times and there was never a software crash, so it looks like the problem is fixed. Will let you know if that changes…Thanks!
well I need the steady state input during the measurement while calibrating the THD of a VCA to minimum for example!
There are times that I need to calibrate while measuring and the input needs to be steady.
I think that input burst can effect the reading I get in those cases and a measuring device can not and should not effect the measured object.
Hi @Deadcap, your VCA must have an ADSR-type circuit running the control voltage on VCA. what are the attack, decay, sustain and releases times you are typically working with?
Mat it is not something I can define as repetitive, however I can give you a few instances of THD call that I am preforming.
Recording console’s channel Vca (automation not dynamics) uses a THD call trim.
Audio compressor wether it is a tube variable MU compressor that has a THD call or a solid state VCA that has THD call to it.
and not only vca’s need to be measured (thd) while in a constant load, every amplifier that is loading its supply rails needs to be measured while those supply rails are loaded and their voltages may be sagging and with ripple that generates THD accordingly (think class A single ended amp with 1200v on anode and 20uf cap on b+).
Hi @Deadcap, OK, got it.
There are two important considerations for each of these:
First, FFTs can’t tell you much if the amplitude isn’t mostly constant during the acquisition. So, we need to get to a steady state for a meaningful measurement.
Second, in I think all the cases you mention, there is a time required to get to that steady state . And that time isn’t very long. In the case of an amp supply rail sagging, that is usually measured in 10’s of milliseconds (CEA-490 contemplates a 20mS burst). In the case of a compressor or a VCA being driven by a an automation curve, it’s adjustable. But a “slow” compressor response time is usually 50mS or so.
So, let’s say you have a compressor with some unknown attack time. We can run a single cycle of the acquisition using control+space. That yields the following:
Knowing the FFT wants to see a constant amplitude, we can roughly eyeball that the first 50 mS of the burst we want to throw out. In the settings dialog, look at the latency compensation setting. By default, that is tossing out of the first 40 mS of the acquisition. We can nudge that up to 60 mS (the next value allowed), and then we can be sure that the first 60 mS of the burst are ignored for the calculation of the FFT.
And from that, we can get a steady-state measurement of the THD, for example.
And then, if you need to tune something, pick a small FFT size and that will give you a 2-3 updates per second. And you can be sure that each acquisition is throwing out the transient period.
So, regardless of the equipment, you capture a burst, look at the time domain to see how long it takes to get rid of the various transient response you don’t care about, and then apply that as latency compensation. This will work for stead-state settling times up to about 2.75 seconds in duration. But I think everything you brought up takes 10’s of milliseconds to settle into a steady-state.
What do you think?
1 Like