Re: Sharing variable

GNU Radio
1

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

2

Hello Marcus,

In your original reply you said that variable sharing was a python
concept,
So I wrote my block in python.

I would like to do something like the block “variable” or the “probe
signal” block that shares a variable will all blocks in GNUradio

I want to do a block that changes the samp_rate or the center frequency
automatically if a condition is true inside my block.

Thanks

Luis

2015-05-26 8:37 GMT+02:00 [email protected]:

3

I’m a bit confused; Luis and Anil, are the two of you working on the
same project?
I might have oversimplified when I said it’s a python concept: GRC
variables are actually quite a handy tool that GRC brings, and GNU Radio
contains quite some blocks to make use of it. However,

I would like to do something like the block “variable” or the “probe
signal” block that shares a variable will all blocks in GNUradio
There is no such thing as “sharing”; if you change something for example
in a QT GUI range slider, and that changes the parametrization of
another block, then there’s an underlying callback/signalling
architecture that will, when the slider changes, call the appropriate
setter on the other block.
In fact, this depends on the GUI framework you’re using, if I’m not
mistaken (i.e. QT offers the callback/slot signalling functionality, and
GRC just “connects” QT slots to functions of the top block). The
function probe block is a terrible, terrible thing in production: if
really just polls the function and consumes CPU for nothing; I like it
for debugging purposes, and nothing else, since it’s asynchronous, gives
no guarantees on actual update rate, is CPU-hungry…

You can get a call-on-event behaviour by giving your block something
like the following:

class Luis_class …
…
def set_callback(self, callable):
self._callme = callable
def work(…):
…
if condition:
self._callme(newvalue)

and doing something like

myblock = Luis_class(…)
multiply = blocks.multiply_const_ff(1.0);
…
myblock.set_callback(lambda x: multiply.set_k(x))

in your top_block (or wherever you set up your flow graph)

However, I’d strongly discourage you to do that! Seriously, that’s
ignoring core functionality of GNU Radio, breaking what I consider
contracts, will be hard to debug, have terrible multithreading issues,
undetermined sample-time timing…

I want to do a block that changes the samp_rate or the center
frequency automatically if a condition is true inside my block.
That doesn’t sound like you should be using the GRC variable mechanism
at all. Just use message passing or stream tags, both of which were
invented for exactly this kind of thing.

Best regards,
Marcus

4

Thank you for your reply Marcus, I don’t work with Anil.

I am going to implement the message passing solutions .

Luis

2015-05-26 8:57 GMT+02:00 Marcus Müller [email protected]:

5

I didn’t actually read this entire thread, so hopefully I’m not
providing
useless info, but you might want to check out how the OFDM codes share
the
equaliser state between blocks.

Cheers,
Martin

6

That would be a typical usage scenario for stream tags (because the
estimate can actually be “attached” to specific sample). I recommend
going through [1] Chaper 1 to 5, where 5.2 explains the usage of stream
tags.

Best regards,
Marcus
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials