Discussions about active development projects
#7053 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.
#7055 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).
#7086 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
#7087 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 .
#7152 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.
#7154 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.

Who is online

Users browsing this forum: No registered users and 1 guest