Analog Discovery Pro ADP2230

[Dan_Hay]

I was curious in purchasing this product. If you had to quantify it, how fast is this able to take a trigger for acquisition and then save the collected data to a file, and then take another triggered response? I currently have the analog discovery 2 which seems to need a half second delay in between each trigger in order to not miss any. 

[artvvb]

Moved to another section of the forum where this might get more visibility.

Gut feel, time between repeated acquisitions (if fully offloading over USB before arming another one) should be similar. Unlike AD2, the ADP2230 has rapid triggers for buffering subsequent acquisitions in DDR, where the blind time is only a couple microseconds (1-2 us). Data still needs to be offloaded over USB eventually, so you're typically limited by the internal buffer for the number of acquisitions that can be taken (it should be split evenly).

Thanks,

Arthur

[Dan_Hay]

Awesome, thank you for getting back to me and moving this in a better location. From what I gather, is that if I continue doing the implementation I have currently it will exhibit the same time restrictions; however, if I store it in the internal buffer, it can run 1-2 us. How large is this internal buffer? Can it hold a lot of data? Can I determine what data gets stored in the buffer, like sliced down data or max points from an acquisition window? Thank you for anything that you can help with it. It is much appreciated

Edited September 26, 2024 by Dan_Hay

[artvvb]

@attila may have some more accurate information or other ideas on this.

Some of these questions will be answered by the spec sheet and reference manual, which you can find here: Analog Discovery Pro (ADP2230) - Digilent Reference. In general, the buffer will store 128 MS per channel of raw data (plus some extra stuff like some extra samples to calculate noise) from however many acquisitions are specified, down to something like 10 samples per acquisition. I believe that all measurements, like finding the maximum value in an acquisition, are done in host software rather than on device, so pre-calculating that kind of thing can't currently be used to help further compress.

When you say you're currently using the data logger, out of curiosity, do you mean you're using the "Logger" top-level instrument, or the "Logging" feature inside of the Scope instrument? The latter can do scripted measurements and might also help improve on your existing system, if you're not using it already.

[attila]

Hi @Dan_Hay

The scope channel of AD1,2,3,ADP2230,ADP3x50 can be configured to capture min/max values.
If you want continuous capture or control loop, you can use scan or record capture.

If you need separate captures AD1,2,3 can do about 100 waveforms/sec, depending on trigger and capture length.
The ADP2230, ADP3X50 provides memory segmentation with ~1us latency between captures.

[Dan_Hay]

So the buffer size for this equipment is essentially the Hi @attila, I appreciate the help. When I was testing the scan and record feature it would trigger once and then just run continously. I would need to do separate triggers for max point saving. Is that possible for the scan and record feature that I looked over? I am running this alongside a laser at an operating environment of 500 kHz. That rate would be my end goal but if I can do data collection faster than what I am currently doing, that would be awesome. 

[attila]

Hi @Dan_Hay

The latest version lets you capture min/max values FDwfAnalogInChannelFilterSet filterMinMax with trigger sampling. See FDwfAnalogInSamplingSourceSet in AnalogIn_SamplingClock.py which you can also use with acqmodeRecord AnalogIn_Record.py for continuous capture. There is one min/max pair saved for two consecutive events, so you could select FDwfAnalogInSamplingSlopeSet DwfTriggerSlopeEither

[Dan_Hay]

Is that min/max feature only available in the sdk? I have done everything in the provided software. If it would be better to switch to the python variant, I will. How fast can I collect and save data from the daq using that approach? 

[attila]

Hi @Dan_Hay

See the earlier mentioned examples and functions.
You could probably get about 50M 100M samples/s, 200-300MB/s / 16bit sample / 2 samples (min-max).
If considerable software processing is performed on the data, use separate thread/process for data transfer function call.

On 9/2/2024 at 4:44 PM, attila said:

The latest version lets you capture min/max values FDwfAnalogInChannelFilterSet filterMinMax with trigger sampling. See FDwfAnalogInSamplingSourceSet in AnalogIn_SamplingClock.py which you can also use with acqmodeRecord AnalogIn_Record.py for continuous capture. There is one min/max pair saved for two consecutive events, so you could select FDwfAnalogInSamplingSlopeSet DwfTriggerSlopeEither

 

[Dan_Hay]

Awesome, thank you @attila. I'll let you know if I have any follow up questions after taking this approach. I currently do not have any processing being done on the data right after collecting it. If I do, it happens post processing so I should get close to those rates you mentioned. 

[Dan_Hay]

Hello @attila, when it comes to the ADP2230 and ADP3X50 how many waveforms/sec would you expect to reach if I was triggering and capturing 32 samples of a signal in an acquisition window that is 80 ns time division?

 

On 8/29/2024 at 4:00 AM, attila said:

Hi @Dan_Hay

The scope channel of AD1,2,3,ADP2230,ADP3x50 can be configured to capture min/max values.
If you want continuous capture or control loop, you can use scan or record capture.

If you need separate captures AD1,2,3 can do about 100 waveforms/sec, depending on trigger and capture length.
The ADP2230, ADP3X50 provides memory segmentation with ~1us latency between captures.

 

[attila]

Hi @Dan_Hay

The device buffered capture latency is around 1us + trigger event.

In the following experiment, 1000 captures with ADP2230 takes 1.09ms, so 0.915 M waveforms/sec and transfer (also depends on software delay/processing) 2.39sec 418 wps. The same experiment with ADP3450 has slightly better performance 1.5 M wps and transfer 1158 wps.

clear();
Scope.run();
var tpc = Date.now();
while(Scope.wait()){
    if(!Scope.State.running()) break;
}
tpc = (Date.now() - tpc)/1000; // ms to sec
const n = Scope.Buffer.value;
print("buffers: ", n);
print("total transfer time:", tpc, "wfps:", n/tpc);

var tdev2 = Scope.Time.taken3;
Scope.Buffer.value = 1;
var tdev1 = Scope.Time.taken3;
print("first capture:", (new Date(tdev1[0]*1000)).toISOString(), "+", tdev1[1]/tdev1[2]);
print("last capture:", (new Date(tdev2[0]*1000)).toISOString(), "+", tdev2[1]/tdev2[2]);

tdev2[0] -= tdev1[0]; // seconds
tdev2[1] -= tdev1[1]; // fraction
if(tdev2[1]<0) {
    tdev2[1] += tdev2[2]; // fraction/sec
    tdev2[0]--;
}
var tdev = tdev2[0] + tdev2[1]/tdev2[2];
print("total capture time:", tdev, "wfps:", n/tdev);

 

[Dan_Hay]

@attila when it comes to this code and results, does this mean I can sample a signal roughly 900-1500 kHz based on a triggering sequence and it'll take 400-1100 Hz to transfer off the device after the buffer limit has been reached? Does this mean I can collect the data  and periodically offload the buffers while still sampling at the same rate? I want to make sure I understand the results clearly. 

[attila]

Hi @Dan_Hay

The devices can do 0.9/1.5 million captures / second. Parallel to this, the transfer to computer is 400/1100 captures / second. The captures and transfer of these can be done simultaneously or with custom app/script you can wait for the device to perform up to 32768 captures and transfer these afterwards.

[Dan_Hay]

@attila I appreciate you answering all of these questions. One last question, what type of time delay can you expect when using the custom app/script approach to using these? I know we experience slow downs on the discovery 2 and would like to know if you had an expected time lose versus complexity of the script when it comes to these other devices. Preferably we'd like to stay above 500 kHz and higher but if the complexity of the scripts slow it down below this, it would be hard to justify. Granted we probably won't do heavy complex algorithms in tandem of data capture. These would be performed post processing. 

[attila]

Hi @Dan_Hay

For custom app/script, the device buffering performance will be the same since it is done in the device. Transfer performance (latency) may be better with a custom app/script, as there is significant processing performed in the WF app.

[attila]

The AnalogIn_Buffers.py example with ADP3450 measures 3370 wps for transfer.