search

analogdevicesinc / scopy

A software oscilloscope and signal analysis toolset
http://wiki.analog.com/scopy
GNU General Public License v3.0
400 stars 164 forks source link

ADALM2000: Multi channel pulse height analyzer #1512

Closed danielbon closed 6 months ago

danielbon commented 11 months ago

Does Scopy can be used as a Multichannel Pulse Height (Peak) Analyzer using one ADC channel? Is it also possible to use it by acquiring the height of the subtraction of channels A and B (i.e., A-B).?

adisuciu commented 10 months ago

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.

danielbon commented 6 months ago

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?

adisuciu commented 6 months ago

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

danielbon commented 6 months ago

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?

adisuciu commented 6 months ago

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

danielbon commented 6 months ago

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?

adisuciu commented 6 months ago

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.