The issues with QA403 and 1.183 in terms of usage

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