Page 1 of 2

Faster acquisition rate

Posted: Tue May 16, 2017 9:13 am
by max paper
I'm acquiring sequences of ultrasound pulses using SCPI with Matlab.
I utilized for this a modified version of an example code (http://redpitaya.readthedocs.io/en/late ... -exm1.html)

It works well, but it is quite slow (around 0.5 s/acquisition).
It appears that the time-consuming commands are the reading of the buffer :
signal_str=query(tcpipObj,'ACQ:SOUR1:DATA?'); % 0.3s
and the conversion in numbers:
signal_num=str2num(signal_str(1,2:length(signal_str)-3)); %0.1s

Is there something I can do to faster the process or will I have to forget the SCPI/Matlab option? The acquisition speed I am aiming for would be in the 1-5 ms range (I'm using a decimation of 8).

Thank you for your help

Re: Faster acquisition rate

Posted: Mon May 29, 2017 1:05 pm
by Jerome_LMA
I found the same issue. Curious to know what is the bottleneck (time-wise) for fast sampling using TCP/IP query.

Re: Faster acquisition rate

Posted: Wed Jul 12, 2017 12:14 pm
by redpitaya
Sorry, but there is not much you can do to speed it up, this is the limitation of the current SCPI server.

However we are working on a better implementation that should be ready in the beginning of October.

Re: Faster acquisition rate

Posted: Fri Jul 14, 2017 1:37 pm
by albert.ruiz
I had the same problem when I was reading the full buffer, what I did to speed up the process was to run the signal processing in the microprocessor from RedPitaya and send just a few data through that way I did not have to send a full buffer which takes a lot of time (you are right).

Re: Faster acquisition rate

Posted: Wed Jul 19, 2017 9:21 am
by max paper
Thanks for the answers.

As I am doing all the signal processing afterward I am not sure I could speed it up this way.
The time-consuming operation is "signal_str=query(tcpipObj,'ACQ:SOUR1:DATA?'); % 0.3s" and I am not sure there is a way to reduce this one...

Re: Faster acquisition rate

Posted: Wed Jul 19, 2017 5:31 pm
by bryan.hayes
max paper wrote:I'm acquiring sequences of ultrasound pulses using SCPI with Matlab.
I utilized for this a modified version of an example code (http://redpitaya.readthedocs.io/en/late ... -exm1.html)

It works well, but it is quite slow (around 0.5 s/acquisition).
I also found a maximum of about 2Hz. Not suitable at all for my needs. I ended up learning C and writing my own program. Now I get several thousand Hz. Seems SCPI is very easy to work with, but also slow.

Re: Faster acquisition rate

Posted: Mon Oct 29, 2018 11:29 am
by Pineapple
redpitaya wrote:
Wed Jul 12, 2017 12:14 pm
However we are working on a better implementation that should be ready in the beginning of October.
Any news about that? Is the solution already integrated in the new software?

Re: Faster acquisition rate

Posted: Tue Feb 05, 2019 10:29 am
by uwe_f
Hi,

in the manual you find some options, like raw or volts for the scale and float and ASCII for the format. Does it make a difference for transferring the buffer through SCPI ?

BR
Uwe

Re: Faster acquisition rate

Posted: Fri Dec 13, 2019 10:28 pm
by JimMartz
Hello,

Has there been any update on this?
it has been 2 years now, maybe its been fixed.

Anyway, I see a bottleneck reading the ADC buffer through SCPI.
I don't think the bottleneck is the network.
I am reading the data as binary.
What is interesting is if I read the date as Volts then it is a 32bit
float and 64k bytes are sent through TCP. And if I read as Raw then
it is a 16bit integer and 32k bytes are sent.
But the time to receive the data is almost the same, leading me to think
it is not the network.
Also, if I read half the buffer (eg 8k samples) then the time is almost
cut in half.

So, I am wondering...
Is the bottleneck in reading the data from the BRAM in the fpga?
Is the bottleneck in sending the data through the SCPI Parser?
Can anyone add any information on this?

Thanks,
Jim

Re: Faster acquisition rate

Posted: Mon Dec 30, 2019 8:00 pm
by JimMartz
All,

Ok I had to fix this on my own.
The biggest issue is that the SCPI server is trying to send
out the data 1 sample at a time, like trying to fill a bucket
one drop at a time.

This issue is in parser.c, functions resultBufferInt16Bin for binary RAW
and resultBufferFloatBin for binary VOLTS.
This issue would also be in the ASCII, but the ascii conversion adds even
more overhead, so I am assuming that if you want a fast response you
would not be using ascii.

I have edited the above two function to send the data out in up to 128
sample chunks, this seems to have made a huge improvement in the time it
takes to read the samples. RAW would be a little faster then VOLTS as it
is only 16bit per sample vs the 32bit float for VOLTS. Also even RAW does
an offset adjustment(calibration), so removing that should also give a little
increase in speed.

I have attached the parser.c file that I have modified the above two functions.
Replace that file in RedPitaya/scpi-server/scpi-parser/libscpi/src and run a
make clean then make, in scpi-server directory while in the ARM schroot.
Then copy over the built binary scpi-server to the RP /opt/redpitaya/bin
Note that you may need to remount the file system so it is not read-only.
Or just rebuild the whole ecosystem.

Thanks,
Jim