Diren As for CPU load: the easiest way is to run *htop *or any other program to check how much of resources are being consumed by the process that you are running. As for your last question regarding sample rate: There is no chance you will provide samples at 61.44 MSPS to Pluto (USB interface limitations). Here <https://plutosdr.org/adalm-pluto-performance-metrics/>you can find the performance metrics. To understand more how sample rate impacts your design, please read: - https://wiki.gnuradio.org/index.php/Sample_Rate_Tutorial - https://wiki.gnuradio.org/index.php/FAQ#What_does_sample_rate_mean_in_GNU_Radio ? Regards
niedz., 5 cze 2022 o 13:53 DİREN ERDEM AYDIN <ayd...@mef.edu.tr> napisał(a): > Thanks for the response Fabian. > > Actually, there is no "actual" problem, the system is working properly. > > My question is related to what you said in your mail "*One exception here > is for example your PlutoSDR Source/Sink - both will actually > provide/require the sample rate you specify.*" In this case, I'm not sure > Pluto Sink is provided with 61.44 M samples. Vector source outputs 6.144 k > samples since LPF interpolation is 1 Pluto sink block receives that number. > > I think that the input sample rate is not related to sample rate > parameter in the Pluto Sink block. It is related to the data transfer rate > between AD9363 and FPGA. > > Regards, > Diren > > On Sun, Jun 5, 2022 at 12:13 PM Fabian Schwartau <fab...@opencode.eu> > wrote: > >> Hi Diren, >> >> I am not exactly sure what your problem is. >> What you should know: gnuradio does not inherently has any sample rate >> (unlike Simulink for example). Each block receives samples, processes >> them, and outputs the same number of samples as fast as it can (except >> if the block is interpolating/decimating - which is not the case for you >> LPF). Between the blocks are buffers, which buffer the samples until the >> next block will process it. The sample rate you set in most blocks is >> just to calculate stuff (like the filter response) based on other >> frequency settings (like your cut-off frequency). One exception here is >> for example your PlutoSDR Source/Sink - both will actually >> provide/require the sample rate you specify. >> So, as your LPF has an interpolation of 1, it does not interpolate and >> will output the same number of samples it receives. Your vector source >> will provide samples as fast as possible until some buffer is full and >> it will then keep it full. >> One problem might be that your CPU cannot keep up filtering the >> 61.44MSPS, which is quite a bit. Try increasing the transition width of >> the filter, which will reduce the filter order and thus the CPU load. >> >> Hope that helps, >> Fabian >> >> Am 04.06.22 um 23:09 schrieb DİREN ERDEM AYDIN via GNU Radio, the Free & >> Open-Source Toolkit for Software Radio: >> > Hello All, >> > >> > I'm working with Adalm Pluto SDR, trying to transmit and receive a >> > custom burst signal given in the figure. To create the signal I'm using >> > a vector block that creates a pulse and then due to a low pass filter I >> > can extract the desired waveform. Flowgraph is also added. >> > >> > As far as I know, input/output sample rates of connected blocks should >> > be matched. However, I'm providing 10k fewer samples to LPF because of >> > the high sample rate of pluto, 61.44 M. When I tried to increase the >> > samples in the vector source to Mega ranges frequency response of the >> > signal drops drastically. I have also tried to use interpolation in >> > between vector block and LPF, but it doesn't work either. >> > >> > My question is the LPF block normalizes the input sample rate to 61.44 >> > M? The whole system works OK but this thing stays unclear for me. Thank >> you. >> > >> > Regards, >> > Diren >> >> >>
