RE: Gnuradio in VM on Windows with out of tree modules?

[Getz, Robin]

Morton:

We built GNU Radio 3.7.11 with some blocks, (including the Pluto/IIO ones, but 
missing some others), and put it here:
https://github.com/tfcollins/GNURadio_Windows_Build_Scripts/releases/tag/1.5.0

This doesn’t include the drivers (which need to be installed on windows 
separately):
https://github.com/analogdevicesinc/plutosdr-m2k-drivers-win/releases/latest



From: Discuss-gnuradio  
On Behalf Of Morten Hansen
Sent: Thursday, November 28, 2019 1:32 AM
To: discuss-gnuradio@gnu.org
Subject: Gnuradio in VM on Windows with out of tree modules?

[External]

I want to run some experiments with gnuradio. As I have one main PC with 
Windows 10, I need to use that PC with Virtualbox and a Linux VM running 
Gnuradio.

Is the Gnuradio - VM - Windows10 approach workable?

Will I likely have any major performance issues with the Linix VM over Windows 
approach with gnuradio?

I plan to use Adalm Pluto SDR. Will there be any driver issues due to running 
the Linux VM on top of Windows?

Reason I want to have a Linux VM is that I will test some out of tree 
blocks/libraries.

Re: Is there anything about USRP blocks that breaks them within hier blocks?

[CEL]

Glad to help! 

NB: the null source-to-sink trick might consume up to two CPU cores
completely and thus contribute to global warming as much as about 1.5
ppb of the  total bitcoin infrastructure ;)

Cheers,
Marcus

On Fri, 2019-12-06 at 05:21 +0100, Lukas Haase wrote:
> Dear Marcus, Dear Kevin,
> 
> On 2019-12-05 22:21, Kevin Reid wrote:
> > On Thu, Dec 5, 2019 at 1:04 AM Müller, Marcus (CEL)  > > wrote:
> > 
> > > However, with your zero in- and output hier block,
> > > top_block.connect(something) was *never* called with the hier block,
> > > and hence, the hier block didn't become part of a flow graph that is
> > > to be executed. It's just a graph that *exists*, not one that *does*
> > > something.
> > > 
> > > TL;DR: can't use a hier block without outside connections, since
> > > that's not becoming part of the top_block that'll be executed.
> Wow, that was exactly the answer I was looking for.
> I would have never guessed that.
> I added a "Null Source" outside and a "Null Sink" inside and indeed, it works 
> not as expected.
> > In addition to the usual connect() that takes two blocks, there is also
> > a connect() method overload that takes only one block, specifically to
> > enable adding a block with no connections to a parent hier block or top
> > block.
> > https://www.gnuradio.org/doc/doxygen/classgr_1_1hier__block2.html#ab21892550c8fea3867628400bb8ed0be
> 
> Thank you.
> 
> > I just tested this case — GRC fails to generate an appropriate connect()
> > call in the top block, but if I add one, then the blocks within the hier
> > block execute as expected. I have filed
> > issue https://github.com/gnuradio/gnuradio/issues/2950 about this.
> 
> Wonderful, thank you.
> 
> Luke
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

GRC crashes with assertion zero in M&M Clock Recovery block

[Lukas Haase]

Hi,

I am using GRC 3.7.11 on Ubuntu (WSL). When I use the M&M Clock Recovery block 
GRC crashes randomly with this message:


clock_recovery_mm_cc: ii > ninput_items[0] (3168 > 3167
python: 
/build/gnuradio-BBYmSv/gnuradio-3.7.11/gr-digital/lib/clock_recovery_mm_cc_impl.cc:214:
 virtual int gr::digital::clock_recovery_mm_cc_impl::general_work(int, 
gr_vector_int&, gr_vector_const_void_star&, gr_vector_void_star&): Assertion 
`0' failed.

>>> Done (return code -6)


Based on the plots, the block seems to be working (I get the proper bits).

My input signal comes in small bursts (asynchronously at random times which is 
why I need M&M).
First I need to filter the signal and center it on its mean value.
I use the following block for it:

https://paste.pics/4573d1f2cf7df0d5e039874c51127dd9

This shows a screenshot, triggered to one of the bursts:

https://paste.pics/a48ec4aef5ddeeef74e96255d72288b3

The original bits can be seen (blue/red) and the filtered, mean-centered 
version that will go into the M&M block (green/black).

Finally the M&M block looks like this:

https://paste.pics/db179025b5c6e98c3b20e76d56bcf139



The output of the block looks as expected ... until GRC crashes.


Is there anything I am doing wrong?


Thanks,
Luke

Re: Is there anything about USRP blocks that breaks them within hier blocks?

[Lukas Haase]

> Marcus Mueller wrote:
>
> NB: the null source-to-sink trick might consume up to two CPU cores
> completely and thus contribute to global warming as much as about 1.5
> ppb of the  total bitcoin infrastructure ;)

Thank you, also good point. Adding a Throttle block with sample_rate=10m should 
alleviate it though, right?

Thanks,
Luke

Re: Discuss-gnuradio Digest, Vol 206, Issue 5

[Andy Walls]

> Date: Fri, 6 Dec 2019 07:22:11 +0100
> From: "Lukas Haase" 

> Hi,
> 
> I am using GRC 3.7.11 on Ubuntu (WSL). When I use the M&M Clock
> Recovery block GRC crashes randomly with this message:
> 
> 
> clock_recovery_mm_cc: ii > ninput_items[0] (3168 > 3167
> python: /build/gnuradio-BBYmSv/gnuradio-3.7.11/gr-
> digital/lib/clock_recovery_mm_cc_impl.cc:214: virtual int
> gr::digital::clock_recovery_mm_cc_impl::general_work(int,
> gr_vector_int&, gr_vector_const_void_star&, gr_vector_void_star&):
> Assertion `0' failed.
> 
> > > > Done (return code -6)

The M&M clock recovery block obviously has an off-by-one error in its
processing.

The M&M clock recovery block is obsolete.  Use the Symbol Synchronizer
block instead, if you must use the M&M TED.


> Based on the plots, the block seems to be working (I get the proper
> bits).
> 
> My input signal comes in small bursts (asynchronously at random times
> which is why I need M&M).
> First I need to filter the signal and center it on its mean value.
> I use the following block for it:
> 
> https://paste.pics/4573d1f2cf7df0d5e039874c51127dd9
> 
> This shows a screenshot, triggered to one of the bursts:
> 
> https://paste.pics/a48ec4aef5ddeeef74e96255d72288b3
> 
> The original bits can be seen (blue/red) and the filtered, mean-
> centered version that will go into the M&M block (green/black).
> 
> Finally the M&M block looks like this:
> 
> https://paste.pics/db179025b5c6e98c3b20e76d56bcf139
> 
> 
> 
> The output of the block looks as expected ... until GRC crashes.
> 
> 
> Is there anything I am doing wrong?

You may want to read this presentation:
https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf


Regards,
Andy


> Thanks,
> Luke
> 

Re: Discuss-gnuradio Digest, Vol 206, Issue 5

[Lukas Haase]

Hi Andy,

On 2019-12-06 14:28, Andy Walls wrote:
> [...]
>
> The M&M clock recovery block is obsolete.  Use the Symbol Synchronizer
> block instead, if you must use the M&M TED.

Thank you.

You do not mean "Polyphase Clock Sync" but "Symbol Synchronizer"? Is this part 
of the standard blocks in GRC?
Because in my 3.7.11 versions (current Ubuntu) I do not find it.

I do not must use the M&M TED.

All I need to do is asynchronously detect a stream of bits like this: 
https://paste.pics/a48ec4aef5ddeeef74e96255d72288b3

Maybe there is a better way to do this?
Important key figure is fast settling/lock time because I cannot afford loosing 
bits (one burst is only 100 or so bits long).

> [...]
>> Is there anything I am doing wrong?
>
> You may want to read this presentation:
> https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf

Thank you, I am studying it.

Best,
Luke