discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Other block as parameter in GRC


From: Julius Durst
Subject: Re: [Discuss-gnuradio] Other block as parameter in GRC
Date: Tue, 19 Aug 2014 15:32:51 +0200

On 19.08.2014 14:25, Koslowski, Sebastian (CEL) wrote:

On 08/19/2014 01:07 PM, Julius Durst wrote:
Hi,

how can I pass an other block from my flowgraph to a self written block
in the gnuradio-companion? What I want to do is invoking a method of
that passed block in my own one (or maybe there's an other way to do that?).

I have tried passing the ID of the block to a parameter of type "raw",
but it says
Param - <param_name>(param_key):
        Value "<ID_of_ohter_block>" cannot be evaluated:
        name '<ID_of_ohter_block>' is not defined in the block properties in
the GRC.

I thought that is what raw was for?

What I exactly want to do is switching filters or, what I am trying with
the above, change the taps of one filter, at runtime. So if you have any
suggestions for that, please also tell me.


raw is for python code. Blocks are not instantiated at design time so
they are not in the namespace when GRC does the FG validation. Consider
putting those taps in variable and use a callback. Or, if your tap
update is triggered from within the flowgraph, use message passing.


Thanks, now I understand the purpose of raw.

For using a callback I would have to change the variable in the top_block, which is AFAIK not easily possible (Function Probe is a possibility, but I do not really want any polling). Correct me if I'm wrong.

For using message passing I would have to create a custom filter block (that updates upon messages). I will consider that if there is no easier solution.

Is there any way to pass that block-ID in the GRC and avoid an error in the FG validation? Because the FG works after correcting the python code generated by the GRC by putting the block-ID/object into the parameters of the other one. I just realize that this of course requires the filter-block to be instanciated first. Which is probably the reason why it is not such a good idea to let the companion do it.

Cheers
Julius



reply via email to

[Prev in Thread] Current Thread [Next in Thread]