New feature: high speed continuous recording

Discussions about active development projects
Post Reply
tsitsimp
Posts: 14
Joined: Mon Oct 17, 2016 1:36 pm

Re: New feature: high speed continuous recording

Post by tsitsimp » Wed Jan 18, 2017 4:56 pm

Hi again,

Still trying to correctly represent a 1MHz sine wave

Assuming that decimation is set to 4, then sampling rate 31.25MHz. With this rate, it takes approximately 524 microseconds to fill the buffer (524.288 in specific ==> x=16384/31.25e6). For the udp receiver block in simulink I have put the buffer size and length of message to be 16384. I have also set the sampling frequency of the udp block at 524.288e-6 so that when I run the simulink for 1 second, I will see 31,250,000 data points (1907.34863281 packets of 16384 samples). That is indeed (almost) the case because matlab sends 1908 packets. However, when I plot the data in between packets of 16384 points I fail to see continuity; data is truncated in between .

The same happens when I increase the decimation rate at 8. In this case the udp block gets a packet of 16384 points every 1 millisecond. See the two graphs in the word doc I attached.
New Microsoft Word Document.docx
Could anyone suggest why is this happening? I ve noticed other people had no trouble with udp along with this function, and Nils mentions that we should avoid decimation rate of 1 unless we want to log a handful of seconds, in which case we would use the third mode of the function to save the data in ram.

Furthermore, I still cannot understand why the units are arbitrary and not 100mV peak to peak. I noticed that they doubled though when I put 200mV
You do not have the required permissions to view the files attached to this post.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Wed Jan 18, 2017 11:56 pm

For the udp receiver block in simulink I have put the buffer size and length of message to be 16384. I have also set the sampling frequency of the udp block at 524.288e-6 so that when I run the simulink for 1 second, I will see 31,250,000 data points (1907.34863281 packets of 16384 samples).
I don't know how the receiver block of simulink works, but if the buffer size is measured in bytes, you might need to account for the fact that each sample is 2 bytes. That's the only idea I have based on your description.
Furthermore, I still cannot understand why the units are arbitrary and not 100mV peak to peak.
The samples from rp_remote_acquire are ADC counts (multiplied by 4). To convert them to voltages, you need to apply the offset and gain calibration values. Note that the values from the Red Pitaya calibration are calculated for the native ADC range -16384 - 16383 (ie not multiplied by 4).

mirko.caspar
Posts: 1
Joined: Tue Jan 24, 2017 6:44 pm

Re: New feature: high speed continuous recording

Post by mirko.caspar » Tue Jan 24, 2017 6:52 pm

Dear Nils,

thanks for the great tool.

You provided the binary for a version of rp_remote_acquire running without the kernel module (around end of October 2016). I'm looking for the actual sources of this version. The last commit in your devel-branch was in October and seems not to contain this extension.

I'd be really grateful if you can commit or provide this actual sources.

Thanks in advance,

Mirko

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Tue Jan 24, 2017 9:02 pm

Hi,

right, I should also update my own repository ...
Meanwhile you can find the latest sources to the tool in the Red Pitaya repository under RedPitaya/Test/rp_remote_acquire .

Tomaok
Posts: 5
Joined: Thu Jun 16, 2016 9:58 am

Re: New feature: high speed continuous recording

Post by Tomaok » Wed Feb 08, 2017 4:55 pm

Hi every body,

I've done a little test with the tool "rp_remote_acquire" on Version: 0.95.
I've used this tool to write 256Mo into a file in tmpfs at different decimation factor and with the "time" command
to evaluate theoretical time vs practical one.
here is the result in the attachment.
To resume it, below a decimation factor of 8, real time doesn't fit with measurement. in addition this time is always the same below d=8. So i figure out that it doesn't work at this rate!
But i've read in the first post above that we could reach full speed!
So the question is why i can not ?

any ideas/suggestions are very welcome.

TOM
You do not have the required permissions to view the files attached to this post.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Wed Feb 08, 2017 6:04 pm

Hi Tom,

at decimation <= 4, the filesystem becomes the bottleneck, see this post. The RAM buffers are filled at the desired rate, but writing them to a file on tmpfs is not fast enough.

Regarding your attempts at 5,6,7: only powers of 2 are supported as decimation settings.

The reason why you see lower throughput at 1 is that there is a higher load on the RAM from the 125MSps writing to RAM buffers.

Kev
Posts: 1
Joined: Fri Mar 10, 2017 3:20 pm

Re: New feature: high speed continuous recording

Post by Kev » Fri Mar 10, 2017 3:48 pm

Hi everybody,

First thank you for your work Nils!

I successfully installed the tool and get binary files as output. For further processing i use Matlab.
I am not sure how to handle the data. I can import the binary data with the command "fread". Thereby i must define the resulting data type. How Nils described, it should be an int16. But i don't know how i get the voltage values of them.

Maybe someone has experience with Matlab and this tool and can share a step-by-step description. :)

Thanks in advance

Best regards
Kevin

achimoe
Posts: 2
Joined: Fri Mar 17, 2017 1:59 pm

Re: New feature: high speed continuous recording

Post by achimoe » Fri Mar 17, 2017 3:34 pm

Hello everybody,

I tried to get going with the continuous recording but I must be missing something.
As I'm new to Red Pitaya I downloaded the latest SD Card Image which gave me
OS 0.97-336.
Then I cloned according to the documentation https://github.com/RedPitaya/RedPitaya.git
I could build and run the simple examples.

Then I build ~/RedPitaya/Test/rp_remote_acquire which succeeded.
Next I executed ./rp_remote_acquire -m file -k 1024 -c 0 -d 64 -f /tmp/out.dat
This never returns, cannot be aborted by Ctrl+C and when I kill the process the output file
exists but is empty.

Thanks for any help,
Achim

Amraam
Posts: 18
Joined: Fri May 20, 2016 3:55 pm

Re: New feature: high speed continuous recording

Post by Amraam » Fri Mar 17, 2017 10:30 pm

Nils Roos wrote: It was not designed with triggering in mind, and some design choices might turn out to be unfavourable for a trigger function. The blockwise data dumping in particular could become awkward. But I don't see insurmountable obstacles, so if you want to have a go at it, I'll gladly tell you more.
Hi Nils,

after some months I'm considering the possibility to implement mods to manage triggers, could you tell me all the infos that you consider relevant?
All details are appreciated.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: New feature: high speed continuous recording

Post by Nils Roos » Sun Mar 19, 2017 10:50 pm

achimoe wrote:Next I executed ./rp_remote_acquire -m file -k 1024 -c 0 -d 64 -f /tmp/out.dat
This never returns, cannot be aborted by Ctrl+C and when I kill the process the output file
exists but is empty.
Hi Achim,

In order to function, rp_remote_acquire needs a special fpga configuration. There's a bitstream in the source folder that needs to be loaded. Either place it in the same directory as the executable and use the "-l" option or load it manually with "cat ddrdump.bit >/dev/xdevcfg" beforehand.

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 19 guests