If your flow-graph is GRC based, then any block parameters that can be
changed at runtime can be tied to a variable.
Once you have that, then you can use, for example, XMLRPC to set any
variable in the flow-graph from the "outside world" (which includes
"reflexive" setting from non-flowgraph python code).
There's also controlport, which I have haven't played with.
On 2016-12-20 11:38, Sean Horton wrote:
> What is the best way to change settings such as gain, taps, frequency values,
> etc of various blocks while running? The current setup I'm refactoring
> receives new configs over tcp, and a block outputs the new config values to
> probe signals, and those probe signals are used to change various settings.
> In the case of setting some usrp source parameters (center frequency), it
> appears to not properly work, so for the usrp sink and sources, I am going to
> pass messages to change the parameters. This isn't possible for other blocks,
> though, as they do not have message inputs.
>
> If I should stick with the current method, though, I'm really curious how
> there is mutual exclusion, as the values are being changed while the
> flowgraph is running. I have looked at the source code for some of the blocks
> I'm using, and I don't see any mutexes. This makes me think this isn't the
> best way to do what is being done.
>
> Thanks,
> Sean
> --
>
> Sean Horton
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
