[Top][All Lists]

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

Re: [Discuss-gnuradio] How to reconfigure automatically the channel used

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] How to reconfigure automatically the channel used to received data in USRPs
Date: Wed, 07 Sep 2011 12:53:19 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1

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

I really need an answer to understand the potentiality of my hardware,
thanks a lot!


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.

reply via email to

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