Faster acquisition rate
-
- Posts: 7
- Joined: Mon Mar 13, 2017 5:39 am
Faster acquisition rate
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
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
-
- Posts: 1
- Joined: Tue Apr 12, 2016 11:23 am
Re: Faster acquisition rate
I found the same issue. Curious to know what is the bottleneck (time-wise) for fast sampling using TCP/IP query.
- redpitaya
- Site Admin
- Posts: 926
- Joined: Wed Mar 26, 2014 7:04 pm
Re: Faster acquisition rate
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.
However we are working on a better implementation that should be ready in the beginning of October.
-
- Posts: 12
- Joined: Fri Jul 17, 2015 6:43 am
Re: Faster acquisition rate
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).
-
- Posts: 7
- Joined: Mon Mar 13, 2017 5:39 am
Re: Faster acquisition rate
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...
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...
-
- Posts: 6
- Joined: Mon May 15, 2017 6:05 pm
Re: Faster acquisition rate
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.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).
-
- Posts: 7
- Joined: Fri Oct 26, 2018 11:20 am
-
- Posts: 3
- Joined: Fri Jan 04, 2019 10:53 am
Re: Faster acquisition rate
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
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
-
- Posts: 6
- Joined: Tue Aug 20, 2019 2:17 pm
Re: Faster acquisition rate
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
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
-
- Posts: 6
- Joined: Tue Aug 20, 2019 2:17 pm
Re: Faster acquisition rate
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
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.
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: Bing [Bot] and 3 guests