SCPI communication speed

Applications, development tools, FPGA, C, WEB
dafa
Posts: 1
Joined: Fri Nov 18, 2016 9:22 am

SCPI communication speed

Post by dafa » Thu Jun 29, 2017 4:30 pm

Hi all,

I use SCPI commands to get the 125 MHz sampled data from the RedPitaya. As I noticed, the SCPI communication is quite slow. I have now measured the execution time of the API C functions with a C-program (Meas1) and a further measurement at the same settings from the PC with the SCPI commands in a Python-program (Meas2).

Meas1: Python-program ---> SCPI-server ---> API ---> FPGA
Meas2: C-program ---> API ---> FPGA

For example it takes 0.2 ms in the C-programm to get the data and in the Python-program it takes 600.2 ms. In the SCPI-server I lose about 600 ms, regardless of the amount of data I transfer from RedPitaya to my PC. Since I would like to acquire as much data as possible, this delay really limits my project.

Is the SCPI communication in general slow or where exactly lies the bottleneck?
Is there a possibility to make the SCPI communication faster?

Thanks a lot!
Last edited by dafa on Tue Jul 18, 2017 1:59 pm, edited 1 time in total.

izi
Posts: 34
Joined: Wed May 27, 2015 11:49 am

Re: SCPI communication speed

Post by izi » Wed Jul 05, 2017 11:09 am

We are aware SCPI is slow.

Some of the issues are linked to a missing feature in the FPGA code,
and to an ugly workaround in the C API (a delay to make sure buffer is filled with data before trigger).
This will be improved after rewriting the FPGA code and API (we are currently writing the API and debugging the new FPGA code).

The existing SCPI code will not be fixed before this major changes are done.

werefkin
Posts: 7
Joined: Tue Jan 26, 2021 4:16 pm

Re: SCPI communication speed

Post by werefkin » Tue Jan 26, 2021 4:22 pm

izi wrote:
Wed Jul 05, 2017 11:09 am
We are aware SCPI is slow.

Some of the issues are linked to a missing feature in the FPGA code,
and to an ugly workaround in the C API (a delay to make sure buffer is filled with data before trigger).
This will be improved after rewriting the FPGA code and API (we are currently writing the API and debugging the new FPGA code).

The existing SCPI code will not be fixed before this major changes are done.
Hi!

I would like to know, did you resolve this issue since that time? I am running SCPI data acquisition as well, and the time needed to get the data is around 250 ms, independently on the frequency.

The question is -- how is it possible to speed up the data acquisition?

Best regards

culley20
Posts: 2
Joined: Sun Jan 02, 2022 1:57 am

Re: SCPI communication speed

Post by culley20 » Sun Jan 09, 2022 1:42 am

Hello! I am wondering this as well.

All my best,
Michael Cullen

jdetlefs
Posts: 7
Joined: Wed Dec 22, 2021 10:01 pm

Re: SCPI communication speed

Post by jdetlefs » Thu Jan 13, 2022 5:39 pm

Anyone get this to be faster?

I am working in LabVIEW and noticed missing out on possible data between
the loops for each measurement iteration.

For example, say I sample at 125MHz or decimate rate of 1 and measuring a sine wave input on
Channel 1. I measure 16K samples once, and then it loops, measures another 16K samples but
the sine waves do not start where the previous ended.

Is there a way around this?

Is it possible to by pass buffers in software/hardware and then use labview for continuous data collection at high speeds?

juretrn
Posts: 104
Joined: Tue Nov 16, 2021 11:38 am

Re: SCPI communication speed

Post by juretrn » Mon Jan 17, 2022 1:00 pm

Hi jdetlefs,

I agree this doesn't sound like the ideal solution, especially if you are waiting for buffer filling.
Did you consider using our continuous data streaming server? I am not sure what data rates are achievable over LAN, but the FPGA is able to fill RAM buffers for both ADC channels at full 125 MSps.

Regards, Jure

jdetlefs
Posts: 7
Joined: Wed Dec 22, 2021 10:01 pm

Re: SCPI communication speed

Post by jdetlefs » Mon Jan 24, 2022 3:52 pm

Hi Jure,

I have not tried the continuous data streaming server. I will look into that.

Do you know if it is possible to control the fast analogs and slow analogs simultaneously via LabVIEW? I was told it could be done and so we bought 13 of these things but am having a hard time getting even the provided examples to perform in real-time or simply fast enough. There is a long delay between action and result. Simply turning on and off a signal lags by half a second or more if you try to run continuously or add a while loop. Even a basic oscilloscope or function generator VI that should perform equal to the red pitaya app is seemingly impossible.

I have to control multiple analog outs in real time, simultaneously, based on incoming data.

Is is possible with LabVIEW? if not, how do I program this? I don't know 'C'... Is that the only language that can achieve this? Not even python?

pavel
Posts: 789
Joined: Sat May 23, 2015 5:22 pm

Re: SCPI communication speed

Post by pavel » Mon Jan 24, 2022 4:11 pm

I am not sure if I understand correctly your requirements based on the information you have provided so far. It would be helpful to have more numbers. How fast and for how long do you want the data to be read?

If you want the data samples to be read at 125 MSPS continuously for longer than 2 seconds, then the Red Pitaya board does not have enough resources to do so. There is not enough on-board memory to store more than 2 seconds of data samples and the 1 Gbit/s Ethernet connection is not fast enough to send the samples continuously at full speed (125 MSPS).

jdetlefs
Posts: 7
Joined: Wed Dec 22, 2021 10:01 pm

Re: SCPI communication speed

Post by jdetlefs » Tue Jan 25, 2022 11:06 pm

Hey Pavel,

Great to speak with you. We are using several Red Pitayas for our technology.

Our main criteria is to use LabVIEW (first choice) or somehow else to control a lot of
the fast and slow analogs simultaneously. The faster and more data the better because
we can oversample and average thus reducing noise.

Our bare minimum for RF In Out is I think about 20 MS/sec. I think even collecting 500,000 samples per 100 milliseconds is okay in some cases.

The main issues is programming simultaneous RF IN, RF OUTs, and Slow INs/Outs. It seems that
all the labview examples run once and then end, and are not designed to run continuously. Adding while loops or using the run continuous function essentially fail to recreate the performance of the function generator/ oscilloscope app in the dashboard.

To start, I just need a basic function generator / oscilloscope app like the dashboard, but made in LabVIEW. I can't seem to create anything like the original performance wise. If I do get the on/off switch on the signal output working, there is at least a half second delay from when I turn it off and when the signal actually stops, and the same thing when I try to turn it back on.

Thank you for any help or advice.
James

jdetlefs
Posts: 7
Joined: Wed Dec 22, 2021 10:01 pm

Re: SCPI communication speed

Post by jdetlefs » Tue Jan 25, 2022 11:06 pm

Hey Pavel,

Great to speak with you. We are using several Red Pitayas for our technology.

Our main criteria is to use LabVIEW (first choice) or somehow else to control a lot of
the fast and slow analogs simultaneously. The faster and more data the better because
we can oversample and average thus reducing noise.

Our bare minimum for RF In Out is I think about 20 MS/sec. I think even collecting 500,000 samples per 100 milliseconds is okay in some cases.

The main issues is programming simultaneous RF IN, RF OUTs, and Slow INs/Outs. It seems that
all the labview examples run once and then end, and are not designed to run continuously. Adding while loops or using the run continuous function essentially fail to recreate the performance of the function generator/ oscilloscope app in the dashboard.

To start, I just need a basic function generator / oscilloscope app like the dashboard, but made in LabVIEW. I can't seem to create anything like the original performance wise. If I do get the on/off switch on the signal output working, there is at least a half second delay from when I turn it off and when the signal actually stops, and the same thing when I try to turn it back on.

Thank you for any help or advice.
James

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: No registered users and 16 guests