I am using the REST API to control the QA403 to measure some specialty equipment.
I would like to use the triggered acquisition via the REST API. Would it be possible to add this to the API?
Hi @Elmar, how do you envision this might work? You trigger via an API call?
Hi @Matt, I would expect for example an API call like the blocking or async acquisition call which first waits for a threshold [SPL] and then starts the actual acquisition. Exactly the way it works in the UI now. Have the trigger level as an argument. Maybe an API call which cancels the waiting.
This would be to analyse playback equipment via the API.
I have thought a bit further about this, and I would like to have the following options:
- One call to start a “open loop” test (is this still the right name, I cannot access this now as my QA is not connected. Arguments should be a trigger level (in dB), a dead-time after the trigger signal (I know it is not lag, but I need some echoes to be “gone”, and a timeout. A bit like Async acquisition.
- Some calls to get this acquisition’s status
- One call to perform the “open loop” test as above, but then blocking.
I would be really happy with this.
As I can see now, the right name is indeed “triggered acquisition”.
@matt could you let me know if this will be integrated? I am depending on this to continue with a certain setup.
Hi @Elmar, it’s a fairly sizable work item to get an api for this, because the instrument is in a unique state waiting for the trigger. And there would need to code to deal with requests that might happen while in this state. For example, if you are in this unique state and someone wants to change FFT size, what do you do? The obvious answer is “reject it” but that means most every API call needs to be touched to handle this case.
Since you are writing code, why not start a QA403 acquisition and then immediately play back the DAC chirp yourself under SW control? You should be able to start the chirp within a few 10’s of mS of starting the acquisition in code.
So, the process might be something like this (assuming you are using a chirp)
- Set the QA403 parameters you want via APIs
- Do a dummy run using these parameters. What you care about here is getting the chirp waveform from Data/Time/Output.
- Convert this time series to dBFS per your needs, and then convert to WAV
- Start another acq, and as soon you start the QA403 acq, tell the DAC to play the WAV you created in step 3.
The QA403 can handle some slop with a chirp. When you go into FR mode and pick a 64K FFT in loopback, you can switch to TIME domain and look at the output:
Note the buffer ends around 1.45 seconds, but the chirp duration is is 892 mS. So, if you can position the full chirp anyplace in that 1.45 second buffer, your measurement will be valid. That is, if kicking off the DAC WAV playback takes 400 mS, it’s not a problem.
What do you think?
Thanks for your insights @matt, really appreciate that your thinking with me 
The problem is that I don’t have a lot of control over the device under test. The reproduction of the recorded “chirp” can be delayed up to 17s (or with different settings even 34s). So I cannot fit this in the buffer.
One option for this would be to make the recording buffer larger (a different topic). I can catch everything in one go. Option two would be to playback a chirp, reconfigure and wait until the trigger happens. But that would need this feature.
How are these things handled by the asynchronous acquisition? There is also a gap of time, where you could fit-in other requests. Having this feature synchronous (so return after trigger and capture is complete) would also be perfectly fine for me.
And would it be problematic if changes happen while waiting for a trigger? Would be nice to reject this, but it is a bit far-fetched to change settings wile awaiting a trigger.
Hi @Elmar, do you have any control over the wav? Can you tell when it’s getting ready to start or once it has started? Can you say what kind of equipment this is?