Plutosdr issue - no Industrial IO Block available

[Andreas Weller]

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 make Plutosdr available on ubuntu for gnuradio?

Thank you!


Kind regards,
   Andreas

Re: Plutosdr issue - no Industrial IO Block available

[Anıl Gürses]

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#issuecomment-604016301 


I hope that would solve your problem.

Stay safe,
Thanks



> On 3 Apr 2020, at 11:33, Andreas Weller  wrote:
> 
> 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 make Plutosdr available on ubuntu for gnuradio?
> 
> Thank you!
> 
> 
> Kind regards,
>   Andreas
> 
> 

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

[Fabian Missbrenner]

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
seems to get worse over time. The longer the flowgraph runs, the more
false positives are detected. I guess that somehow has to do with the
way that the threshold is updated in the relative mode? But that's
speculation..

@Nick
> The magnitude of the correlation depends on the magnitude of your signal. The 
> AGC normalizes the signal amplitude before the correlator, so you see 
> expected behavior. The correlation estimator block expects the input to have 
> a normalized amplitude.
@Achilleas
> This means that if one wants to build a correlator that works with an 
> arbitrary scaling "a" (suppose a genie gave you that at the Rx), the only 
> thing you should have to do is to
> put as the parameter "threshold" in the block the quantity "a fraction".
> This would make the whole system transparent: no matter what the scaling is, 
> your estimator would work exactly the same.
> HOWEVER, as it turns out the "correct" scaling that works for this block is 
> to set  "threshold= a^2 fraction".
> This is really weird and I do not see any intuition behind that type of 
> scaling...

As genies are currently busy with forecasting the Covid-19 situation,
I'll stick with an AGC3 block prior to the Estimator. ;-)

Best regards
Fabian

Re: Plutosdr issue - no Industrial IO Block available

[Andreas Weller]

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 wrote:
> 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#issuecomment-604016301
> 
> I hope that would solve your problem.
> 
> Stay safe,
> Thanks
> 
> 
> 
>> On 3 Apr 2020, at 11:33, Andreas Weller > > wrote:
>>
>> 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 make Plutosdr available on ubuntu for gnuradio?
>>
>> Thank you!
>>
>>
>> Kind regards,
>>   Andreas
>>
>>
> 

Re: Plutosdr issue - no Industrial IO Block available

[Anıl Gürses]

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, Andreas Weller  wrote:
> 
> 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 wrote:
>> 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#issuecomment-604016301
>> 
>> I hope that would solve your problem.
>> 
>> Stay safe,
>> Thanks
>> 
>> 
>> 
>>> On 3 Apr 2020, at 11:33, Andreas Weller >> >> wrote:
>>> 
>>> 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 make Plutosdr available on ubuntu for gnuradio?
>>> 
>>> Thank you!
>>> 
>>> 
>>> Kind regards,
>>>   Andreas

Compensating for sample delay in one audio source channel

[Phil Frost]

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: image.png]

Initially the delay was set to 0. I have a Y cable hooked up to the audio
interface so the same square wave is fed back in to both inputs. Then I
compare the phase of the inputs in the time sink. From this I see the 2nd
channel needs to be delayed by 1 sample to correct the error.

I thought the delay block would correct this, but unfortunately it doesn't
seem to do anything. The time sink shows the two channels from the audio
source with the same 1 sample difference in phase no matter how I set the
delay block.

Is there some other way I should go about this?

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

[Derek Kozel]

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 functionality quickly and easily into a flowgraph.


Keen eye'd folks will notice that I had the PST/EST times one hour 
wrong. The correct time is 1 PM Pacific, 4 PM Eastern, 8 PM UTC, and 10 
PM Central European.


https://twitch.tv/derekkozel

On 02/04/2020 14:33, Derek Kozel wrote:

Hi folks,

I'm going to try out doing online livestreams of the GNU Radio 
introductory tutorials. If it's successful I'll work my way through 
all the tutorials over the next few weeks in the evenings. I thought 
some folks might be interested in watching and participating. I'll be 
focused on testing out the tutorial steps and content and making 
updates/improvements if I can.


https://twitch.tv/derekkozel

The first one will be at 9 PM BST (noon PST, 3 PM EST, 20:00 UTC, 10 
PM CET) tonight.


https://wiki.gnuradio.org/index.php/Tutorials

Hopefully it'll be useful, it'll definitely be entertaining.

Cheers,
Derek

Control of running time

[Artur Nogueira]

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

[Michael Dickens]

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

[Marcus D. Leech]

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.  But precisely control of start time? Nope.

capture spectra to SigMF?

[Card, Stu]

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 existing structure shields
in<->out.

We don't want to capture samples to disk then post process, but rather
convert from samples to spectra in real time, do in software the equivalent
of a SpecAn max-hold function for a while, then write those traces to disk.
This is so we don't have to buy truckloads of disk drives to capture all
the intermittent emissions for a week. ;-)

We can do this in what seem to us the obvious ways, but would rather not
reinvent wheels, especially if there are any conventions on how this should
be done in the spirit of SigMF.

Thanks!

Re: Control of running time

[Artur Nogueira]

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. 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.  But precisely control of start time? Nope.
>
>
>