New feature: high speed continuous recording
-
- Posts: 14
- Joined: Mon Oct 17, 2016 1:36 pm
Re: New feature: high speed continuous recording
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.
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
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.
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.
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
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.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).
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).Furthermore, I still cannot understand why the units are arbitrary and not 100mV peak to peak.
-
- Posts: 1
- Joined: Tue Jan 24, 2017 6:44 pm
Re: New feature: high speed continuous recording
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
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
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
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 .
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 .
-
- Posts: 5
- Joined: Thu Jun 16, 2016 9:58 am
Re: New feature: high speed continuous recording
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
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.
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
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.
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.
-
- Posts: 1
- Joined: Fri Mar 10, 2017 3:20 pm
Re: New feature: high speed continuous recording
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
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.
![Smile :)](./images/smilies/icon_e_smile.gif)
Thanks in advance
Best regards
Kevin
-
- Posts: 2
- Joined: Fri Mar 17, 2017 1:59 pm
Re: New feature: high speed continuous recording
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
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
-
- Posts: 18
- Joined: Fri May 20, 2016 3:55 pm
Re: New feature: high speed continuous recording
Hi Nils,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.
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.
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: New feature: high speed continuous recording
Hi Achim,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.
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.
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 61 guests