ADALM2000: Multi channel pulse height analyzer about scopy HOT 7 CLOSED

Scopy implements peak-peak measurement for single channels. However measurements across multiple channels cannot be done at the moment, nor mathematical operations with measured values.

from scopy.

Hi again. Concerning the peak-to-peak measurement, could I get a histogram of a set of peak-to-peak values in an automated way? Do I need a script for it?

from scopy.

There is no way currently implemented to get histogram in an automated way in Scopy. You could use libm2k to acquire the data and process it directly in Python (or another language) - https://wiki.analog.com/university/tools/m2k/libm2k/libm2k

from scopy.

I have already a python code that is doing that, but it is processing about 17 events/second and it should process more than 800 events/second. Each waveform pulse (bi-exponential shape) has about 500 ns and we have a little less than 1M pulses/second. Probalby, there is some latency/overhead issues due to the USB protocol. Is there any way to improve that? I tried to play with Set kernel buffer count command but it did not change anything at all. Should I work directly with the firmware or use some burst technique?

from scopy.

Setting the number of kernel buffers basically guarantees how many buffers are continous across subsequent acquisitions. In libm2k, you should always use the same number of samples for getSamples() when doing this. On board there is 512 MB of RAM, but some of it is used by the system. In our tests you could reliably use 200MB which translates to 100MS - aprox 1 second of data at maximum sample rate.

The USB 2.0 interface will limit streaming to 2-3 MSPS in our tests. You can run iio_readdev --benchmark to get a more accurate value. Unfortuately there is no way to detect that an overflow occured.

If you can burst, and don't need continous monitoring, you could acquire K buffers where K is the number of kernel buffers. You can then stitch the buffers in the software and analyse.

In certain cases, the triggering mechanism can also be leveraged to get more data - although I don't think it could be used here.

If the USB throughput is still an issue, running the application directly on target could work .. You would need to port your application to C/C++ and crosscompile it to the device and run it there.

https://wiki.analog.com/university/tools/pluto/devs/embedded_code?s[]=standalone&s[]=pluto
This article is for the Pluto, but the same applies to ADALM2000.

-Adrian

from scopy.

The triggering would be desirable to select the waveforms (pulses with 100 samples) before data transmission to the computer, but I am not sure if it is possible to use it.
If I go for the streaming and do the triggering offline, should I use the getSamples or getSamplesRawInterleaved commands? What about the oversampling?

from scopy.

Oversampling is a divider for the sampling frequency - I think it only works for maximum sampling frequency.

getsamplesrawinterleaved - are the samples as they are sent via libiio
getsamples - are processed to convert to voltages and demuxed to channel std::vectors.
Either is fine.

from scopy.