discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Lebowski80
Subject: Re: [Discuss-gnuradio] How to reconfigure automatically the channel used to received data in USRPs
Date: Tue, 13 Sep 2011 07:08:30 -0700 (PDT)

Hi Nick,

I just wanted tell you that I solved my problem using interprocess
communication, thank you for your advice!

Regards


Lebowski80 wrote:
> 
> Ok, thank you for your advice, I will try with interprocess communication.
> 
> Regards
> 
> 
> Nick Foster-4 wrote:
>> 
>> Short answer: You cannot open a new USRP instance to reconfigure an
>> already-running USRP instance. You must reconfigure the existing
>> instance.
>> 
>> The best advice I can give is that only one flowgraph can be operational
>> per
>> USRP device. In your setup, USRP#1 will run a single flowgraph with a
>> source
>> and/or sink, USRP#2 will run a single flowgraph with a source and/or
>> sink,
>> and USRP#3 will run a single flowgraph with a source and/or sink. If you
>> wish to change the parameters of USRP#2 while it is running, rather than
>> try
>> to open a new USRP device in your benchmark_rxr.py flowgraph, use any of
>> the
>> standard interprocess communication methods to talk to your
>> already-running
>> USRP#2 script and reconfigure it as necessary.
>> 
>> --n
>> 
>> On Wed, Sep 7, 2011 at 9:31 AM, Lebowski80 <address@hidden>
>> 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
>>>
>>>
>>>
>>> Nick Foster-4 wrote:
>>> >
>>> > On Wed, Sep 7, 2011 at 3:27 AM, Lebowski80 <address@hidden>
>>> > wrote:
>>> >
>>> >>
>>> >> Hello everyone,
>>> >>
>>> >> Before to explain my problem I give some technical information about
>>> my
>>> >> hardaware. I'm using USRPs v1 and the boards integrated are XCVR2450
>>> >> Transceivers.
>>> >>
>>> >> I'm using the script usrp_spectrum_sense.py in a USRP (called USRP1)
>>> to
>>> >> make
>>> >> sensing in the ISM band, after a few seconds it sends to another USRP
>>> >> (Called USRP2) a free sensed channel on the central frequency 2484
>>> MHz.
>>> >> USRP2 listens to the channel 2484 MHz through the script
>>> benchmark_rx.py
>>> >> and
>>> >> it can properly receive the free ISM channel sent by USRP1. Then, I
>>> want
>>> >> to
>>> >> use the USRP2 to receive data from another USRP (called USRP3) that
>>> uses
>>> >> the
>>> >> script benchmark_tx.py.
>>> >>
>>> >> In the script benchmark_rx.py (used by USRP2) that listens to channel
>>> >> 2484
>>> >> MHz I want to run another script that I called benchmark_rxr.py that
>>> >> waits
>>> >> for data sent by USRP3 to be received in the free ISM channel sent by
>>> >> USRP1.
>>> >>
>>> >> Relevant line of the code in the script benchmark_rx.py is attached
>>> >> below:
>>> >>
>>> >> p = Popen('python benchmark_rxr.py', shell =  True)
>>> >>
>>> >> While this is the error that I get:
>>> >>
>>> >> usrp_open_interface:usb_claim_interface: failed interface 2
>>> >> could not claim interface 2: Device or resource busy
>>> >> usrp_basic_rx: can't open rx interface
>>> >> Traceback (most recent call last):
>>> >>  File "benchmark_rxr.py", line 153, in <module>
>>> >>    main()
>>> >>  File "benchmark_rxr.py", line 138, in main
>>> >>    tb = my_top_block(demods[options.modulation],
>>> >> mods[options.modulation],
>>> >> rx_callback, options)
>>> >>  File "benchmark_rxr.py", line 46, in __init__
>>> >>    self.rxpath = usrp_receive_path.usrp_receive_path(demodulator,
>>> >> rx_callback, options)
>>> >>  File
>>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
>>> >> line 65, in __init__
>>> >>    self._setup_usrp_source(options)
>>> >>  File
>>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
>>> >> line 78, in _setup_usrp_source
>>> >>    self.u = usrp_options.create_usrp_source(options)
>>> >>  File
>>> "/usr/local/lib/python2.6/dist-packages/gnuradio/usrp_options.py",
>>> >> line 88, in create_usrp_source
>>> >>    gain=options.rx_gain,
>>> >>  File
>>> >>
>>> >>
>>> "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py",
>>> >> line 138, in __init__
>>> >>    _generic_usrp_base.__init__(self, **kwargs)
>>> >>  File
>>> >>
>>> >>
>>> "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py",
>>> >> line 63, in __init__
>>> >>    except: raise Exception, 'Failed to automatically setup a usrp
>>> >> device.'
>>> >> Exception: Failed to automatically setup a usrp device.
>>> >>
>>> >> I read different post with this problem such as "Full duplex and half
>>> >> duplex
>>> >> does not work" and "help: cannot send after transport endpoint
>>> shutdown"
>>> >> but
>>> >> I could not solve the problem yet. I need to close the reception in
>>> 2484
>>> >> MHz
>>> >> channel for a new reception in another channel in USRP2. The only way
>>> to
>>> >> do
>>> >> that seems to close the port manually (i.e. pressing ctrl+c) but I
>>> want
>>> >> to
>>> >> do that by code. I tried different things before the line "p =
>>> >> Popen('python
>>> >> benchmark_rxr.py', shell =  True)" such as "id_process = os.getpid()"
>>> and
>>> >> "os.killpg(id_process, 2)", or by "tb.lock()" and "tb.unlock" and so
>>> on,
>>> >> but
>>> >> nothing helped me, I keep obtaining the same error. I don't know what
>>> to
>>> >> do
>>> >> else, can I change by code reception frequency in USRP2? Any advice
>>> will
>>> >> be
>>> >> welcome, thanks a lot!
>>> >>
>>> >
>>> > You need to run both RX and TX in the same flowgraph. You can't open
>>> them
>>> > in
>>> > separate flowgraphs.
>>> >
>>> > --n
>>> >
>>> >
>>> >
>>> >>
>>> >> Regards
>>> >>
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://old.nabble.com/How-to-reconfigure-automatically-the-channel-used-to-received-data-in-USRPs-tp32414957p32414957.html
>>> >> Sent from the GnuRadio mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Discuss-gnuradio mailing list
>>> >> address@hidden
>>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >>
>>> >
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/How-to-reconfigure-automatically-the-channel-used-to-received-data-in-USRPs-tp32414957p32417577.html
>>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/How-to-reconfigure-automatically-the-channel-used-to-received-data-in-USRPs-tp32414957p32456030.html
Sent from the GnuRadio mailing list archive at Nabble.com.




reply via email to

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