Thanks. I only know enough about gnuradio to be dangerous right now, so I wasn't sure if that was an intended way to modify block parameters. I haven't been able to test most of that yet, initial variables have been the same as what was being sent from a remote server, so if it didn't work, I wouldn't notice. I may not be able to get around to it, but I was hoping to convert as much of the code into C++ (easier for me to unit test it), so would it be easier to change block parameters in C++? I can see that a hier block made with gnuradio has functions generated to set the internal block parameters, not sure if the same would happen if the hier block were made in C++. Perhaps I should test that.
Unfortunately the code that sends the configuration is a scary mess that I'd have to spend weeks refactoring, so right now I have a block that just converts raw bytes sent over tcp back into the parameters. That might be something I want to aim for, though. Thanks again, Sean On Tue, Dec 20, 2016 at 9:16 AM, <mle...@ripnet.com> wrote: > 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 > > -- Sean Horton
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
