Maximum continuous sample rate

[Max Fomitchev-Zamilov]

What is the maximum continuous acquisition sampling rate that is achievable on the Analog Discovery 2 scope?

I am contemplating an API-driven software that will provide for continuous / streaming data acquisition, need to know what data rate will this system sustain.

[Bianca]

Hi @Max Fomitchev-Zamilov,

The maximum sampling rate achievable for the Discovery2 is 100MS/s

Best regards,

Bianca

[StuE]

On 10/9/2017 at 9:03 PM, Bianca said:

Hi @Max Fomitchev-Zamilov,

The maximum sampling rate achievable for the Discovery2 is 100MS/s

Best regards,

Bianca

@Bianca, from what I've seen on my AD2, there's a ~0.5s gap between groups of samples when the buffer is filled before the next set of samples collected at 100MS/s (or whatever sampling rate used). This is using Labview, so it's entirely possible that I've screwed up, and if so I'd love to know!

Max F-Z asked for the maximum continuous acquisition sampling rate on the AD2, but I'd suggest that continuous means completely uninterrupted data collection. Is this possible (ie circular writing to the buffer, for example), or is it that continuous sampling is only available until the buffer is full? Even on Waveforms it looks like the gap between filled buffers is present.

Cheers

Stu

[attila]

Hi @StuE

The device has 8k sample/ channel buffer in which it can store data at up to 100MHz.
When using labview VIs make sure the sampleRate x acquisitionTime does not exceed 8192 samples.

At lower rate (1MHz) you can use the WaveForms SDK to record more data.

 

[StuE]

12 hours ago, attila said:

Hi @StuE

The device has 8k sample/ channel buffer in which it can store data at up to 100MHz.
When using labview VIs make sure the sampleRate x acquisitionTime does not exceed 8192 samples.

At lower rate (1MHz) you can use the WaveForms SDK to record more data

 

Hi @attila

thanks for the fast response. As long as I keep below the limit of the buffer it's fine, the issue is that I would like to monitor my laser in real-time, continuously, for the entire data acquisition. If I have to limit my data collection to avoid filling the buffer it'll slow my experiment down. I'm taking ~5000-1000 spectra from a fast sCMOS camera, triggered from an optical chopper, and I want to reference the laser intensity prior to my sample using this, but it needs to be able to resolve every shot of my laser running at rep rates up to 10.416kHz, outputting sub-30fs pulses. The intrinsic integration of the (relatively) slower response of the photodiode means I don't need to run at 1000MS/s, but I will need to run in the ~100-500kHz range, I suspect. 100kS/s gives me ~81ms to collect data, while each spectra takes ~163us to collect. The buffer only allows me to collect ~500 samples before needing to stop measuring, which is more than an order of magnitude less than I'd ideally collect for a decent SNR.

My questions, then:

1) Is there any way to write to ram or directly to a (fast solid state) drive to circumvent this limitation?

2) In waveforms I can change the configuration to allow my buffer to take 16384 samples; can I do that in labview? That get me almost enough samples to work with post-collection averaging.

It seems like not being able to continuously pull data off the device somehow really limits it. Any help you can provide would be great, this is a great device, but right now it looks like it's not going to do what I bought it for.

[attila]

Hi @StuE

The VIs "Analog Discovery Toolkit for LabVIEW" only provide a subset of the functions.

To perform scope recording, continuous data streaming, to select 2nd device configuration 16k scope buffer use the WaveForms SDK.
For this you can find examples in Python.

Please take a look at the previous links and the following ones:

https://www.hackster.io/austin-stanton/analog-discovery-2-usb-oscilloscope-labview-2016-update-374b9c

 

[StuE]

2 hours ago, attila said:

Hi @StuE

The VIs "Analog Discovery Toolkit for LabVIEW" only provide a subset of the functions.

To perform scope recording, continuous data streaming, to select 2nd device configuration 16k scope buffer use the WaveForms SDK.
For this you can find examples in Python.

Please take a look at the previous links and the following ones:

https://www.hackster.io/austin-stanton/analog-discovery-2-usb-oscilloscope-labview-2016-update-374b9c

 

@attila ok, I don't really know Python and was hoping to avoid that but looks like I'll need to learn. Thanks for the advice.

[attila]

Hi @StuE

Here the WaveForms Runtime/SDK is accessed from LabView directly without Python:
https://www.hackster.io/austin-stanton/analog-discovery-2-usb-oscilloscope-labview-2016-update-374b9c
The provided examples in the SDK are mostly in Python which you can use as pseudocode.

[StuE]

On 1/31/2019 at 11:31 PM, attila said:

Hi @StuE

Here the WaveForms Runtime/SDK is accessed from LabView directly without Python:
https://www.hackster.io/austin-stanton/analog-discovery-2-usb-oscilloscope-labview-2016-update-374b9c
The provided examples in the SDK are mostly in Python which you can use as pseudocode.

Hi @attila,

thanks for the suggestion to base my code off of the python examples, it's helped a fair bit but I just need to clarify something:

Taking "AnalogIn_record.py" as a basis, it's pretty clear what the program is doing, but I'm not sure how the data retrieval from the buffer to the computer memory works in relation to this line:
"""    dwf.FDwfAnalogInStatusData(hdwf, c_int(0), byref(rgdSamples, sizeof(c_double)*cSamples), cAvailable) # get channel 1 data   ""

Say this gets called partway through the collection process, when ~2000 (eg cSamples = 2000) out of 20000 samples have been taken. Does this function pull those 2000 out of the buffer into memory and then clear the buffer? Alternatively, if that's not the case, when the buffer is filled, what happens?

I'm just trying to work out where/when I need to move data around to prevent the buffer filling up, and I'm not sure what's happening. I'm tempted to move to scanShift mode, but record appears to be a better option for my application

 

[attila]

Hi @StuE

In record mode the device buffer is used as a fifo. 
The scan shift mode returns all the data fetched from the device buffer. It is not mend for recording, does not provide buffer overflow information.

Record loop:
FDwfAnalogInStatus(HDWF hdwf, BOOL fReadData, DwfState *psts); // fetch status and data
FDwfAnalogInStatusRecord(HDWF hdwf, int *pcdDataAvailable, int *pcdDataLost, int *pcdDataCorrupt)
cdDataAvailable - how many new samples are available since the last fetch
cdDataLost/Corrupt - indicates fifo overflow, try to improve the loop performance, reduce sample rate, for AD select second device configuration to have more buffer

Get the new data samples:
FDwfAnalogInStatusData(HDWF hdwf, int idxChannel, double *rgdVoltData, int cdData);
cdData <= cdDataAvailable

[StuE]

@attila as you suggested I used the python example. For some reason it wasn't working; wouldn't stream off the buffer. Something I did randomly made it work but I'm not entirely sure what I did (although since it's working it doesn't really matter)

One thing, though. Looking at the waveform of the data stream running at 100kHz or 200kHz, I can see that there ARE some missed samples. I think I can work around these, but it's worth noting. I did wonder whether I could split my signal across the two AnalogIn channels and pull data down at different times to characterise how much is dropped but haven't tried it yet.

Thanks for the advice re doubling the buffer size, that's the first thing I'm going tomorrow while my laser warms up. Thanks for your advice.

[attila]

Hi @StuE

I don't know what delays does the LabView application introduce, but recording in WaveForms app or running the Python example record script it works for me without missing samples even above 1MHz.