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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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 > > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> 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 > > [email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > > > > > > _______________________________________________ > > USRP-users mailing list > > [email protected] <mailto:[email protected]> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > > _______________________________________________ > USRP-users mailing list > [email protected] <mailto:[email protected]> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
