Acquire function

Oxthorp · Post by **Oxthorp** » Fri Jul 03, 2015 3:25 pm

Hi everyone,

I try since 3 days to implement a program in order to acquire data when a trigger happen on a falling edge. But I use threads to acquire NMEA data (from GPS) in parallel.

I modified a bit the acquire function but I don't understand the utility of the "retiries" variable . Can I delete it ?

Moreover, when I acquire my data (with the trigger armed), the variable "ret_val" has only the value -1 or -2, I never catch the 0... That's weird...

Thanks in advance for your help.

Regards

Oxthorp (alias Kev Ttn')

Nils Roos · Post by **Nils Roos** » Fri Jul 03, 2015 8:59 pm

Hi,

acquire does the following:
1. it tests if new data is available (which is the case after a trigger event occurred and the buffer got filled)
2a. if not, it decrements the retries-variable and sleeps for a millisecond, then goes back to 1.
2b. if new data is available, it prints it out and exits

So, if you are only seeing ret_val values of -1 or -2 it means that either no trigger event was observed or the acquisition after a trigger is still in progress.

Kev' Ttn · Post by **Kev' Ttn** » Mon Jul 06, 2015 8:22 am

Hi Nils !

First of all, thanks for your reply.

Then, if I delete the "retries" variable and I only check the ret_val with a while like this : while (ret_val != 0); Is it correct ? Because, in my program, I want to execute it as fast as possible (as everyone I guess ^^").

If I am obliged to use the "retries" variable, nevermind, I'll do my best but I need to acquire the data very quickly. Actually, with the original "acquire" function, I have a 21ms (16384 points at 125MS/s) delay to acquire all the data. And I want to go faster. So I thought I could modify the code to improve the performances.

Thanks in advance.

Regards.

Oxthorp · Post by **Oxthorp** » Tue Jul 07, 2015 2:22 pm

Hi back,

After hours of research on my code, I found my problem. I had modified the main_osc.h file, and in a function, a condition couldn't happen ... I should not have change this file. Now, it works well and I modified my main.c to delete the retries variable. It's works perfectly now, I'm trying something else

In fact, I noticed that the delay time to acquire data after a trigger happen is about 30ms for a 16384 data points signal. I want to acquire in less time so I think to skip the filter step in the FPGA and read integer data in the ARM.

Is it simple to delete all the filtering function ? Do I have to change a lot of code in the Verilog project ? Because, I tried to delete the filtering function directly in the FPGA (and let the float where they are in the ARM), but after I compiled my project, I don't receive any data.

If someone can help me ...

Kind regards.

Nils Roos · Post by **Nils Roos** » Tue Jul 07, 2015 11:12 pm

Getting rid of the filter will not help you. The bottleneck in the whole chain is the way samples are read out of the FPGA buffers.
Accessing the buffers through the AXI GP master is simply not a very fast operation, and is responsible for most of the ~30ms you need to read 16384 samples.

There are at least 4 different solutions from different users and the RP team to this problem, which all involve transferring samples directly to external RAM with DMA over the AXI HP internal bus. None of them are compatible with the existing acquire tool, unfortunately.

Kev' Ttn · Post by **Kev' Ttn** » Wed Jul 08, 2015 9:32 am

Hi Nils,

Thanks again for your answer and all your details.
Do you know the data rate of this protocol ? (Just by curiosity

)

So, I'll let the FPGA project as it is. And I'll work on an other function until this one will be improve

Have a good day !

(and thanks again)

Arnold · Post by **Arnold** » Wed Jul 08, 2015 9:38 am

Hi,

what are the 4 different solutions and how fast will you be able to read the samples in SW approx., compared to ~30ms you need to read 16384 samples using AXI HP internal bus?

Thanks,
A

Nils Roos · Post by **Nils Roos** » Thu Jul 16, 2015 8:35 pm

I know of the following:

Melko's Non-stop data write on a storage device
Pavel's project, with which you are already familiar, had that functionality, too - not sure if it's still in there
the current Red Pitaya ecosystem has the neccessary functions in the fpga, but has no software support to actually use them, as yet
my own high speed continuous recording

All of them should be capable of writing samples to external RAM at the highest sample rate on both channels.

Accessing the samples is a regular read from uncached external RAM. You can expect roughly the same speed as with every other (uncached) memory buffer.

Redpitaya Forum