Execution time for FDwfAnalogInStatus

[Carl Troili]

Hi,

I am using an Analog Discovery 3 to acquire a short sample of data many times a second.

What I would like to achieve is to sample 1000 samples at 100 Mhz 1000 times a second ie I want to sample 1 Millions samples a second.

I am using Python and the Pydwf library.

I am achieving 300 acquisitions of 1000 samples a second and I can also achieve 300 acquisitions of 10000 samples but I cannot increase the number of acquisitions.

By measuring the time before and after different calls to the SDK using timex=time.time() I have pinpointed the problem to the call status = analogIn.status(True). It takes by itself 3 ms and it doesn't matter if the acqusition is 1000 samples or 10000 samples.

I believe analogin.status is the same as FDwfAnalogInStatus.

Is there anything I can do to improve the response time of that function call ?

 

The code is basically this https://github.com/sidneycadot/pydwf/blob/master/source/pydwf-examples/AnalogInRecordMode.py

But I have analogIn.acquisitionModeSet(DwfAcquisitionMode.Single) instead of record to control the length of the sample window.

My actual code is added below.

Regards

 

Carl Troili

AnalogInSingleMode.py

[attila]

Hi @Carl Troili

See the included example, I get above 3000 captures / second.

[Carl Troili]

Thanks, I try that one.

 

Regards

 

Carl

[Carl Troili]

It works the same on my computer. I will add the signal generators and then repeat it.

 

Regards Carl

[attila]

Hi @Carl Troili

It may be useful for you project the high resolution trigger time available with AD3, see the AnalogIn_Trigger.py example.

[Carl Troili]

In the top of the example it says it requires python version 2.7.3. 

I am using 3.11.3

What kind of errors should I look for if I continue to use a version 3 Python.

 

Regards

 

Carl

[Carl Troili]

Thanks for the suggestion to improve resolution. 

[Guest]

18 hours ago, attila said:

Hi @Carl Troili

See the included example, I get above 3000 captures / second.

Hi @attila

As far as I am aware, the FDwfAnalogInStatus() initiates a USB bus transfer, right? And I think USB2 bus transactions are limited to 1 kHz, as per the USB spec.

That would imply that you cannot exceed 1k calls of DwfAnalogInStatus per second, yet your example seems to do it.

Can you explain where my understanding is wrong?

Cheers, Sidney

 

[Guest]

I think I understand -- my assumption that FDwfAnalogInStatus unconditionally initiates a bus transfer appears to be wrong. In case of short captures, it seems to be using buffered data.

[Guest]

Hi @Carl Troili

 

I am the author of the pydwf package so naturally, I am always interested when it is suggested that native ctypes-based code (as used in Digilent's examples) would be faster than using pydwf. I can only think of very weird programs where this could be the case, since pydwf itself is little more than a proper wrapper around the ctypes-based interface.

To investigate, I ported Attila's example to pydwf and I see essentially the same performance between his Python example and a version that uses pydwf, using an Analog Discovery 2.

Atilla's example by default captures waveforms of 64 samples. Increasing that to the 1000 you're aiming for lowers the performance from 3.3 kWaveforms/sec to 2.4 kWaveforms/sec, using my pydwf-based version. So that should get you to where you need to be.

I think I now understand what's going on. In your original post (where you said you were stuck at 300 acquisitions per second) you refer to the 'AnalogInRecordMode.py' example. That example uses "Record" mode, which is specifically intended for *continuous* captures, which is not what you want.

If you want to capture individual waveforms (eg captured by a trigger), that is not the optimal mode of the device to use. You should be using the "Single" acquisition mode instead.

I have included Atilla's example ported to pydwf as an attachment so you can play around with it, to see if you can get it to do what you need.

 

Cheers, Sidney

AnalogIn_Wps_PyDwf.py

[Carl Troili]

Hi @reddish give me some time and I will check out your code also. For your info I modified the AnalogInRecordMode.py to a single version.

Thanks for responding.

 

Carl

[Carl Troili]

Hi @reddish, now I have tested your script. As I increase the number of samples my total bandwidth increases.  I went all the way from 64 samples to 16384 samples and got 3536 waveforms at 64 samples and 830 waveforms at 16384 samples.

An anomaly was at 512 samples. Then I could only acquire 694 waveforms. With both fewer number of samples and more samples I could acquire more than 3000 samples.  I repeated it with the original Analogin_Wps.py and got the same behavior

 

If I increased the number of samples to 513 I got above 3000 waveforms/s again and I lowered it to 504 samples and got above 3000 waveforms again. It does not really affect me but it might be worthwhile for @attila to look into

 

Thanks again for your help and interest.

[attila]

Hi @Carl Troili

This must a bottleneck in the USB 'firmware' or driver, when transferring 1024 bytes, 2 USB packets