discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] [USRP-users] RFNOC E310 Retuning rx


From: Martin Braun
Subject: Re: [Discuss-gnuradio] [USRP-users] RFNOC E310 Retuning rx
Date: Sun, 31 Jan 2016 10:18:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

f773e72b34abafb6371fb57c357ce9844a6e9550 should fix this, but it wasn't
pushed public. Can you confirm? Thanks!

M

On 01/31/2016 01:28 AM, Nick Foster wrote:
> Martin, take another look at the error we're seeing. The index of the
> channel in the error is one greater than the channels we've configured.
> 
> In other words, James has configured a single channel after calling
> clear_channels(), and he gets an error looking up /channels/rx/1/args
> when he tunes.
> 
> I'm configuring two channels, and when I tune I get an error looking
> up /channels/rx/2/args.
> 
> Far as I can tell, it shouldn't even be looking for channel 2.
> 
> --n
> 
> On Sat, Jan 30, 2016, 2:58 AM Martin Braun via USRP-users
> <address@hidden <mailto:address@hidden>> wrote:
> 
>     You can set channels after clearing them either with set_rx_channel(),
>     or even by re-setting a subdev spec.
> 
>     M
> 
> 
>     On 01/29/2016 07:28 PM, James Wagner via USRP-users wrote:
>     > well, just to add some more context it appears that the problem is
>     > specifically causes by a RFNOC specific method clear_channel()
>     which is
>     > a method of multi_usrp.
>     > this method simply runs
>     > _tree->remove("/channels");
>     >
>     > this causes an issue when the set_rx_freq() method of multi_usrp is
>     > called which makes a number of calls eventually calling
>     get_rx_subdev_spec.
>     > In any case my best guess is that when the deleting the entire channel
>     > branch also removes some nodes that are used when setting the
>     frequency.
>     >
>     > trying to come up with a work around but it seems like it would
>     require
>     > either avoiding calling clear_channel() which means we have to
>     find some
>     > way to clear the channel so we can setup our rx channel later or
>     find a
>     > way to rebuild the lost portion of the tree.
>     > also it appears this may impact other calls that change radio
>     parameters
>     > since a quick glance many of the radio parameters seem to have a
>     similar
>     > structure to their set_methods.
>     >
>     >
>     > On Thu, Jan 28, 2016 at 1:36 PM, Nick Foster <address@hidden
>     <mailto:address@hidden>
>     > <mailto:address@hidden <mailto:address@hidden>>> wrote:
>     >
>     >     This appears identical to the problem I encountered last week. I'd
>     >     also appreciate any pointers on this.
>     >
>     >     --n
>     >
>     >     On Thu, Jan 28, 2016 at 1:09 PM James Wagner via USRP-users
>     >     <address@hidden
>     <mailto:address@hidden>
>     <mailto:address@hidden
>     <mailto:address@hidden>>> wrote:
>     >
>     >         Hi,
>     >
>     >         I am trying to figure out how to re-tune the USRP's RX
>     frequency
>     >         when using RFNOC. My original assumption was that i could
>     just use
>     >         usrp->set_rx_freq(tune_request,radio_id)
>     >         just as i had used to set the frequency originally but if
>     i use
>     >         this command after running
>     >
>     >         usrp->clear_channels()
>     >         usrp->get_device3()->clear()
>     >
>     >         running this command produces a runtime error with the message
>     >
>     >         terminate called after throwing an instance of
>     'uhd::index_error'
>     >           what():  LookupError: IndexError:
>     >         multi_usrp::get_rx_subdev_spec(0) failed to make default
>     spec -
>     >         LookupError: Path not found in tree: /channels/rx/1/args
>     >         Aborted
>     >
>     >
>     >         so any ideas on how to retune the radio?
>     >         _______________________________________________
>     >         USRP-users mailing list
>     >         address@hidden
>     <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >       
>      http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > USRP-users mailing list
>     > address@hidden <mailto:address@hidden>
>     > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>     >
> 
> 
>     _______________________________________________
>     USRP-users mailing list
>     address@hidden <mailto:address@hidden>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




reply via email to

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