[prev in list] [next in list] [prev in thread] [next in thread]
List: usrp-users
Subject: Re: [USRP-users] RFNOC E310 Retuning rx
From: Nick Foster via USRP-users <usrp-users () lists ! ettus ! com>
Date: 2016-01-31 0:28:30
Message-ID: CA+JMMq9pNj6v4fVxWtR_TvuOOJsgp-VgydfcAvDToypJFhQ6=w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <
usrp-users@lists.ettus.com> 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 <bistromath@gmail.com
> > <mailto:bistromath@gmail.com>> 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
> > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
> 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
> > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
[Attachment #5 (text/html)]
<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>I'm configuring two channels, and when I \
tune I get an error looking up /channels/rx/2/args.</div><div><br></div><div>Far as \
I can tell, it shouldn't even be looking for channel \
2.</div><div><br></div><div>--n</div><div><br><div><div class="gmail_quote"><div \
dir="ltr">On Sat, Jan 30, 2016, 2:58 AM Martin Braun via USRP-users <<a \
href="mailto:usrp-users@lists.ettus.com" \
target="_blank">usrp-users@lists.ettus.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">You can set channels after clearing them either with \
set_rx_channel(),<br> or even by re-setting a subdev spec.<br>
<br>
M<br>
<br>
<br>
On 01/29/2016 07:28 PM, James Wagner via USRP-users wrote:<br>
> well, just to add some more context it appears that the problem is<br>
> specifically causes by a RFNOC specific method clear_channel() which is<br>
> a method of multi_usrp.<br>
> this method simply runs<br>
> _tree->remove("/channels");<br>
><br>
> this causes an issue when the set_rx_freq() method of multi_usrp is<br>
> called which makes a number of calls eventually calling get_rx_subdev_spec.<br>
> In any case my best guess is that when the deleting the entire channel<br>
> branch also removes some nodes that are used when setting the frequency.<br>
><br>
> trying to come up with a work around but it seems like it would require<br>
> either avoiding calling clear_channel() which means we have to find some<br>
> way to clear the channel so we can setup our rx channel later or find a<br>
> way to rebuild the lost portion of the tree.<br>
> also it appears this may impact other calls that change radio parameters<br>
> since a quick glance many of the radio parameters seem to have a similar<br>
> structure to their set_methods.<br>
><br>
><br>
> On Thu, Jan 28, 2016 at 1:36 PM, Nick Foster <<a \
href="mailto:bistromath@gmail.com" target="_blank">bistromath@gmail.com</a><br> > \
<mailto:<a href="mailto:bistromath@gmail.com" \
target="_blank">bistromath@gmail.com</a>>> wrote:<br> ><br>
> This appears identical to the problem I encountered last week. \
I'd<br> > also appreciate any pointers on this.<br>
><br>
> --n<br>
><br>
> On Thu, Jan 28, 2016 at 1:09 PM James Wagner via USRP-users<br>
> <<a href="mailto:usrp-users@lists.ettus.com" \
target="_blank">usrp-users@lists.ettus.com</a> <mailto:<a \
href="mailto:usrp-users@lists.ettus.com" \
target="_blank">usrp-users@lists.ettus.com</a>>> wrote:<br> ><br>
> Hi,<br>
><br>
> I am trying to figure out how to re-tune the USRP's RX \
frequency<br> > when using RFNOC. My original assumption was that i \
could just use<br> > usrp->set_rx_freq(tune_request,radio_id)<br>
> just as i had used to set the frequency originally but if i use<br>
> this command after running<br>
><br>
> usrp->clear_channels()<br>
> usrp->get_device3()->clear()<br>
><br>
> running this command produces a runtime error with the message<br>
><br>
> terminate called after throwing an instance of \
'uhd::index_error'<br> > what(): LookupError: \
IndexError:<br> > multi_usrp::get_rx_subdev_spec(0) failed to make \
default spec -<br> > LookupError: Path not found in tree: \
/channels/rx/1/args<br> > Aborted<br>
><br>
><br>
> so any ideas on how to retune the radio?<br>
> _______________________________________________<br>
> USRP-users mailing list<br>
> <a href="mailto:USRP-users@lists.ettus.com" \
target="_blank">USRP-users@lists.ettus.com</a> <mailto:<a \
href="mailto:USRP-users@lists.ettus.com" \
target="_blank">USRP-users@lists.ettus.com</a>><br> > <a \
href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" \
rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> USRP-users mailing list<br>
> <a href="mailto:USRP-users@lists.ettus.com" \
target="_blank">USRP-users@lists.ettus.com</a><br> > <a \
href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" \
rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
><br>
<br>
<br>
_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com" \
target="_blank">USRP-users@lists.ettus.com</a><br> <a \
href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" \
rel="noreferrer" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
</blockquote></div></div></div></div>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic