Re: [Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running

[Sean Horton]

All right, that makes me feel better. A few corrupted samples is perfectly
fine since the setting should only change before transmitting/receiving,
not during.

Thanks,
Sean

On Tue, Dec 20, 2016 at 10:21 AM, Kevin Reid  wrote:

> On Tue, Dec 20, 2016 at 8:38 AM, 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.
>>
>
> Calling the setter methods is fine. Mutexes are not necessary for simple
> numeric parameters, because one thread (the block work thread) is only
> reading and one thread is only writing (your control thread) and there are
> no particular invariants to be maintained.
>
> The worst thing that could happen is reading a half-written large value
> and producing bad data for a period, but changing parameters in many cases
> will result in some kind of “glitch” in the sample stream anyway, so this
> is merely “noisier”.
>



-- 
Sean Horton
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running

[Kevin Reid]

On Tue, Dec 20, 2016 at 8:38 AM, 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.
>

Calling the setter methods is fine. Mutexes are not necessary for simple
numeric parameters, because one thread (the block work thread) is only
reading and one thread is only writing (your control thread) and there are
no particular invariants to be maintained.

The worst thing that could happen is reading a half-written large value and
producing bad data for a period, but changing parameters in many cases will
result in some kind of “glitch” in the sample stream anyway, so this is
merely “noisier”.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running

[Sean Horton]

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,  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

Re: [Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running

[mleech]

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

[Discuss-gnuradio] What Is The Proper Way To Change Block Parameters While Running

[Sean Horton]

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