Re: [Discuss-gnuradio] How to reconfigure automatically the channel used to received data in USRPs

[Marcus D. Leech]

On 07/09/2011 12:31 PM, Lebowski80 wrote:
> Hello Nick,
>
> What do you mean? Actually I'm running RX and TX in two different flowgraphs
> on USRP1, the first one in usrp_spectrum_sense.py to look for a free channel
> (so the RX). In this script I also run benchmark_tx.py by the command p =
> Popen('python benchmark_tx.py', shell =  True), then my second flowgrapgh
> (the TX).
>
> My problem is that on USRP2 I want to reconfigure the RX channel by python
> (RX channel = 2484 MHz in the script benchmark_rx.py and RX channel =
> channel received by USRP1 in the script benchamrk_rxr.py run by
> benchmark_rx.py with the command p = Popen('python benchmark_rxr.py', shell
> =  True)).
>
> So I'm wondering if there exists the possibility to reconfigure the
> parameters of a script in the same USRP (i.e. RX frequency channel) while it
> is running and if this is not possible what do people mean with "USRP
> reconfigurability?"
>
> I really need an answer to understand the potentiality of my hardware,
> thanks a lot!
>
> Regards
So, presumably, your "benchmark_rxr.py" script attempts to independently 
create a USRP2 source/sink block, in order to
  change the frequency of your (executing) benchmark_rx.py.  This isn't 
allowed.  The network-level socket used to communicate
  with the USRP2 cannot be shared among multiple programs/processes.  
That's a limitation of the systems networking stack, and
  not a limitation of the hardware.

A properly constructed flow-graph will have a source block, whose 
parameters can be changed dynamically during execution of the
  flow-graph.  You can see how this works in general by building 
yourself a simple flow-graph with GRC, and observing that you can
  (for example) create a UHD/USRP2 source block, with frequency and 
gain parameters that can be changed at run-time by
  text input widgets, for example.  When I'm building flow-graphs that 
need to have parameters tweaked at run-time
  *by an external agent*, I use the XMLRPC-server block within GRC to 
allow me to modify runtime parameters from an external
  program.  Most (but not ALL) blocks in Gnu Radio that take parameters 
*that could reasonably be changed at runtime*, allow
  those parameters to be changed at runtime.  Using GRC to see how this 
all fits together (by constructing a flow-graph, and then
  examining the resulting code) lets you see how it's done.

The benchmark_* examples may not actually be the best starting point for 
doing this type of work, since they're old, they don't
  support UHD, and they were designed to fulfill a specific purpose.  
YES, they can be re-purposed, but only if you understand
  how they work, and how they use the underlying Gnu Radio architecture.