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

2019-12-06 Thread 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: Is there anything about USRP blocks that breaks them within hier blocks?

2019-12-06 Thread 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

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

2019-12-05 Thread Lukas Haase 
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

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

2019-12-05 Thread Kevin Reid 
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.
>

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

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.

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

2019-12-05 Thread CEL 
Hi Lukas, hi Marcus the prime,

the UHD blocks *can't* know they're in a hier block. That information
is not available to them, at all. "Hier Block" is just a flow-graph
construction-time concept: It doesn't exist when the UHD block is
constructed, and it doesn't exist when the flow graph starts executing.

_BUT_: When you run a GNU Radio flowgraph, you call the start() method
of a top_block, which is essentially a hier block containing the whole
flow graph. It was told which blocks and connections (vertices and
edges) make up the flow graph, by being told to
top_block.connect(start,end) blocks. In the case of hier blocks, the
connect() thing basically leads to a recursive addition of the subgraph
contained in the hier block.

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.

Best regards,
Marcus the second

On Wed, 2019-12-04 at 16:44 -0500, Marcus D. Leech wrote:
> On 12/04/2019 04:08 PM, Lukas Haase wrote:
> > Hi Marcus,
> > 
> > 
> > 
> > No, unofrtunately.
> > 
> > 0 gain is still something like -10dBm. Huge and clearly visible on a 
> > spectrum analyzer.
> > Where the exact tone is doesn't matter because my span is 10Mhz (I actually 
> > meant 915MHz) and I used full span to look at the entire frequency range.
> > 
> > The point is: I filled all numbers in numerically and everything works if 
> > the URSP Source is in my main block. Then I *copy and paste* everything (to 
> > avoid any doubts) into a hier-block, put in the hier block and it stops 
> > working. I showed the exact screenshots.
> > Even the leakage from the USRP itself is gone which means that the USRP 
> > just turns off, crashed badly or similar.
> > 
> > This is either a weird bug or we are not supposed to use the USRP block 
> > within a hier block.
> > 
> > Thanks,
> > Luke
> > 
> > 
> The USRP source wouldn't really have any "idea" that it's inside a hier 
> block.  This may be a weird Gnu Radio limitation--hier blocks normally
>have at least an input, and usually an input and an output.  But a GR 
> expert might want to chime in about whether this case "works".
> 
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

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

2019-12-04 Thread Marcus D. Leech 

On 12/04/2019 04:08 PM, Lukas Haase wrote:

Hi Marcus,



No, unofrtunately.

0 gain is still something like -10dBm. Huge and clearly visible on a spectrum 
analyzer.
Where the exact tone is doesn't matter because my span is 10Mhz (I actually 
meant 915MHz) and I used full span to look at the entire frequency range.

The point is: I filled all numbers in numerically and everything works if the 
URSP Source is in my main block. Then I *copy and paste* everything (to avoid 
any doubts) into a hier-block, put in the hier block and it stops working. I 
showed the exact screenshots.
Even the leakage from the USRP itself is gone which means that the USRP just 
turns off, crashed badly or similar.

This is either a weird bug or we are not supposed to use the USRP block within 
a hier block.

Thanks,
Luke


The USRP source wouldn't really have any "idea" that it's inside a hier 
block.  This may be a weird Gnu Radio limitation--hier blocks normally
  have at least an input, and usually an input and an output.  But a GR 
expert might want to chime in about whether this case "works".

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

2019-12-04 Thread Lukas Haase 
Hi Marcus,

Marcus D. Leech:>> On 12/03/2019 09:40 PM, Lukas Haase wrote: Hi,
>>
>> Am I not supposed to put USRP blocks within a hierarchichal block
>> and if so, why?
>>
>> Very strange minimal example (Ettus USRP X310, Windows 10,
>> gnuradio 3.7.13.5):
>>
>> https://paste.pics/8a1cf2b2661fab2bc71b760e369997b9
>>
>> Works and with a spectrum analyzer I see the tone at 916 MHz.
>>
>> Then I do nothing more than putting the Signal Source and USRP
>> Sink into a hier block and using it:
>>
>> https://paste.pics/8c7c200035a083e218625360defc8015
>>
>> https://paste.pics/bcd7969f3299f54e56b0d3ca210d97af
>>
>> It's hard to believe but true: The spectrum analyzer stays silent!
>>  It doesn't output anything.
>>
>> All messages on the console are same as well: The FPGA image gets
>> loaded onto the USRP and it starts. For a brief moment at startup,
>> the spectrum analyzer shows a small tone at 916MHz which
>> disappears again.
>
> Your gain is 0, that might have some bearing.   Also, you should see
> the main tone at 915M, because your baseband signal is at -1M.



No, unofrtunately.

0 gain is still something like -10dBm. Huge and clearly visible on a spectrum 
analyzer.
Where the exact tone is doesn't matter because my span is 10Mhz (I actually 
meant 915MHz) and I used full span to look at the entire frequency range.

The point is: I filled all numbers in numerically and everything works if the 
URSP Source is in my main block. Then I *copy and paste* everything (to avoid 
any doubts) into a hier-block, put in the hier block and it stops working. I 
showed the exact screenshots.
Even the leakage from the USRP itself is gone which means that the USRP just 
turns off, crashed badly or similar.

This is either a weird bug or we are not supposed to use the USRP block within 
a hier block.

Thanks,
Luke

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

2019-12-03 Thread Marcus D. Leech 

On 12/03/2019 09:40 PM, Lukas Haase wrote:

Hi,

Am I not supposed to put USRP blocks within a hierarchichal block and if so, 
why?

Very strange minimal example (Ettus USRP X310, Windows 10, gnuradio 3.7.13.5):

https://paste.pics/8a1cf2b2661fab2bc71b760e369997b9

Works and with a spectrum analyzer I see the tone at 916 MHz.

Then I do nothing more than putting the Signal Source and USRP Sink into a hier 
block and using it:

https://paste.pics/8c7c200035a083e218625360defc8015

https://paste.pics/bcd7969f3299f54e56b0d3ca210d97af

It's hard to believe but true: The spectrum analyzer stays silent! It doesn't 
output anything.

All messages on the console are same as well: The FPGA image gets loaded onto 
the USRP and it starts.
For a brief moment at startup, the spectrum analyzer shows a small tone at 
916MHz which disappears again.


Thanks,
Luke



Your gain is 0, that might have some bearing.   Also, you should see the 
main tone at 915M, because your baseband signal is at -1M.

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

2019-12-03 Thread Lukas Haase 
Hi,

Am I not supposed to put USRP blocks within a hierarchichal block and if so, 
why?

Very strange minimal example (Ettus USRP X310, Windows 10, gnuradio 3.7.13.5):

https://paste.pics/8a1cf2b2661fab2bc71b760e369997b9

Works and with a spectrum analyzer I see the tone at 916 MHz.

Then I do nothing more than putting the Signal Source and USRP Sink into a hier 
block and using it:

https://paste.pics/8c7c200035a083e218625360defc8015

https://paste.pics/bcd7969f3299f54e56b0d3ca210d97af

It's hard to believe but true: The spectrum analyzer stays silent! It doesn't 
output anything.

All messages on the console are same as well: The FPGA image gets loaded onto 
the USRP and it starts.
For a brief moment at startup, the spectrum analyzer shows a small tone at 
916MHz which disappears again.


Thanks,
Luke