Faster acquisition rate

Applications, development tools, FPGA, C, WEB
max paper
Posts: 7
Joined: Mon Mar 13, 2017 5:39 am

Faster acquisition rate

Post by max paper » Tue May 16, 2017 9:13 am

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

Jerome_LMA
Posts: 1
Joined: Tue Apr 12, 2016 11:23 am

Re: Faster acquisition rate

Post by Jerome_LMA » Mon May 29, 2017 1:05 pm

I found the same issue. Curious to know what is the bottleneck (time-wise) for fast sampling using TCP/IP query.

User avatar
redpitaya
Site Admin
Posts: 880
Joined: Wed Mar 26, 2014 7:04 pm

Re: Faster acquisition rate

Post by redpitaya » Wed Jul 12, 2017 12:14 pm

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.

albert.ruiz
Posts: 12
Joined: Fri Jul 17, 2015 6:43 am

Re: Faster acquisition rate

Post by albert.ruiz » Fri Jul 14, 2017 1:37 pm

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).

max paper
Posts: 7
Joined: Mon Mar 13, 2017 5:39 am

Re: Faster acquisition rate

Post by max paper » Wed Jul 19, 2017 9:21 am

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...

bryan.hayes
Posts: 6
Joined: Mon May 15, 2017 6:05 pm

Re: Faster acquisition rate

Post by bryan.hayes » Wed Jul 19, 2017 5:31 pm

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.

Pineapple
Posts: 7
Joined: Fri Oct 26, 2018 11:20 am

Re: Faster acquisition rate

Post by Pineapple » Mon Oct 29, 2018 11:29 am

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?

uwe_f
Posts: 3
Joined: Fri Jan 04, 2019 10:53 am

Re: Faster acquisition rate

Post by uwe_f » Tue Feb 05, 2019 10:29 am

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

JimMartz
Posts: 6
Joined: Tue Aug 20, 2019 2:17 pm

Re: Faster acquisition rate

Post by JimMartz » Fri Dec 13, 2019 10:28 pm

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

JimMartz
Posts: 6
Joined: Tue Aug 20, 2019 2:17 pm

Re: Faster acquisition rate

Post by JimMartz » Mon Dec 30, 2019 8:00 pm

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
You do not have the required permissions to view the files attached to this post.

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: Google [Bot] and 18 guests