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.
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
