Hi,
Is :DIGitize the only command to use to acquire data remotely from a scope?
We have an experiment where we are trying to acquire waveforms at a trigger frequency up to 10Hz (hardware trigger connected to the scope).
We are loosing some of these waveforms as the trigger frequency increases to 10Hz because the :Digitize command takes so long . :DIGitize is followed by :WAVeform:DATA? in a loop in C code.
If however I don't use :DIGitize and just send :WAVeform:DATA?, there is no loss of data but then the acquisitions happen independent of the trigger. It is of course possible to poll the trigger register remotely in my code to determine when a trigger occurs but then this is more or less a software dependent trigger.
Is there some other command or method to wait for a trigger on the scope side and then transfer the data without using :DIGitize as this seems to take too long clearing the buffers, stopping the acquisition etc.
I would appreciate any help or ideas for this. Many thanks in advance
Edited by: mulligan252 on May 13, 2014 2:06 AM
Is :DIGitize the only command to use to acquire data remotely from a scope?
We have an experiment where we are trying to acquire waveforms at a trigger frequency up to 10Hz (hardware trigger connected to the scope).
We are loosing some of these waveforms as the trigger frequency increases to 10Hz because the :Digitize command takes so long . :DIGitize is followed by :WAVeform:DATA? in a loop in C code.
If however I don't use :DIGitize and just send :WAVeform:DATA?, there is no loss of data but then the acquisitions happen independent of the trigger. It is of course possible to poll the trigger register remotely in my code to determine when a trigger occurs but then this is more or less a software dependent trigger.
Is there some other command or method to wait for a trigger on the scope side and then transfer the data without using :DIGitize as this seems to take too long clearing the buffers, stopping the acquisition etc.
I would appreciate any help or ideas for this. Many thanks in advance
Edited by: mulligan252 on May 13, 2014 2:06 AM
2) You don't say how much data you are trying to capture and save
3) You don't say anything about what medium you are using to transfer the data (USB, LAN, RS-232, etc)
4) You don't say what programming environment you are using (VBA, Visual C/C++, MATLAB, Python, LabView, etc).
5) You don't say what format you are using for transfer (BYTE, WORD, ASCII, etc)
6) You don't indicate what type of drivers you are invoking (Visa, Sockets, etc)
All of the above will have some effect on your results.
That said...
- DIGITIZE, according to the manual for the Infiniium family, is the fastest way of using the scope. It is an internal macro that combines a RUN with a wait for completion. For other scope families, the answer may be different.
- I doubt that you will be able to trigger and unload data at a 10Hz rate, unless you are using a fast medium (Gbit LAN), with the right protocol (possibly HISLIP), and a very shallow trace depth. I have done some benchmarks in Python and MATLAB, and seen some in C/C++, and there is a certain amount of overhead in getting the captured data pulled out of scope memory and converted into a transferable format. ASCII will be the slowest, BYTE will be the fastest (to transfer, but not necessarily to convert), but least accurate. WORD is the best compromise, but note that you will also need to transfer the Preamble to understand what the bits mean (This is true of BYTE, as well).
- Most of my testing was done using LAN. Some findings: GBit is faster than 100Mbit, Sockets are (usually) faster than Visa, Isolated LAN is faster than Shared LAN, Newer models of scope are faster than older models, Direct connect LAN is faster than going through 1 or more switches, Desktops are (usually) faster than laptops.
More information about what you are doing might be useful.
Al
Disclaimer: For more reliable response, you should consider calling your local Agilent Technical Call Center. The Agilent Forums are monitored on an "as available" basis, and aren't necessarily the fastest way to get technical questions answered.