Plutosdr issue - no Industrial IO Block available

Hi. I installed gnuradio on my ubuntu Eoan from this PPA https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases gr-iio, libiio, libad*, is also installed via system's packet manager. But I'm still lacking fmcomms block (the complete Industrial I/O to be exact...) Any idea how to mak

Re: Plutosdr issue - no Industrial IO Block available

Hi, I am assuming that you installed Gnuradio 3.8 . If you’ve successfully built gr-iio(because there was an another branch for 3.8+), you have to copy yml files to gnuradio blocks path. You can look at my recent issue on gr-iio repository. https://github.com/analogdevicesinc/gr-iio/issues/74#i

Re: Correlation Estimator block threshold settings in Absolute/Dynamic mode

Thank you for your help, Nick, Christoph, and Achilleas! @Christoph > How close to 1 did you use thresholds for the relative threshold method? > For the relative threshold method I use thresholds between 1-exp(-5) > .. 1-exp(-8). Even with 1-exp(-15) I get many false positive detections. And it s

Re: Plutosdr issue - no Industrial IO Block available

Hi. Thanks for the link. The following command seems to solve my issue: sudo cp /usr/share/gr-iio/grc/blocks/*.yml /usr/share/gnuradio/grc/blocks/ I would like to file a bug - any idea what package causes the issue? gr-iio or gnuradio? Kind regards, Andreas Am 03.04.20 @ 10:45 Anıl Gürses wr

Re: Plutosdr issue - no Industrial IO Block available

Hi, That’s great. The problem arises from gr-iio package. Normally, it should move this files to Gnuradio blocks path or the copy process should be updated on the wiki. Note: You can apply the same things for Gnuradio 3.9 . Let me know if you have other questions > On 3 Apr 2020, at 17:39,

Compensating for sample delay in one audio source channel

I have an audio interface (behringer UCA222) which, for whatever reason, has a 1 sample delay in one of the input channels. Consequently, the two input channels have unequal phase across the entire bandwidth. I'd like to compensate for that. I measured the delay with this flow graph: [image: imag

Re: Trial: Livestreaming GNU Radio Tutorials - Today at 8 PM UTC

Well that went fairly well! Thanks to the 250+ folks who came by. We worked out an issue with my video stream and the second half was smooth sailing. Tonight (in two and a half hours) I'm going to do a shorter stream focused on demonstrating how to use the Python Block in GRC to add custom fu

Control of running time

Hi all, Is there a way of precisely controlling the simulation/running time of GNU Radio, i.e. initial and final time instants? Thanks. Regards, Artur

Re: Control of running time

Short answer: no. - MLD On Fri, Apr 3, 2020 at 2:44 PM Artur Nogueira wrote: > Hi all, > > Is there a way of precisely controlling the simulation/running time of GNU > Radio, i.e. initial and final time instants? > > Thanks. > > Regards, > Artur >

Re: Control of running time

On 04/03/2020 02:43 PM, Artur Nogueira wrote: Hi all, Is there a way of precisely controlling the simulation/running time of GNU Radio, i.e. initial and final time instants? Thanks. Regards, Artur You can use a "head" block to control how many samples go through before the graph terminates.

capture spectra to SigMF?

Any suggestions on appropriate/inappropriate ways of writing log(mag(fft(i,q))) to SigMF, rather than (i,q)? We want to sweep 0.5 - 6 GHz repeatedly 24x7 with an Ettus X310, concurrently using one antenna/UBX160 each inside and outside a hangar, to capture local spectra and see how well the existi

Re: Control of running time

Thanks Michael and Marcus! Regards Artur Em sex., 3 de abr. de 2020 às 16:01, Marcus D. Leech < patchvonbr...@gmail.com> escreveu: > On 04/03/2020 02:43 PM, Artur Nogueira wrote: > > Hi all, > > > > Is there a way of precisely controlling the simulation/running time of > > GNU Radio, i.e. initia