This function in UHD will first look for the environmental variable and then use the UHD installation path to look for the xml files. https://github.com/EttusResearch/uhd/blob/8bb15ee133ea98d6755d392b8493966c785291dd/host/lib/rfnoc/blockdef_xml_impl.cpp#L155
which calls https://github.com/EttusResearch/uhd/blob/13c32cefcd6ea45e20e2eca97159ca26603ca533/host/lib/utils/paths.cpp#L176 The UHD_PKG_PATH default is generated by cmake here: https://github.com/EttusResearch/uhd/blob/a06eaad1f0133524daf0a40100ebeb3e06fd7498/host/lib/utils/CMakeLists.txt#L136 On Fri, Mar 23, 2018 at 7:21 PM, Rob Kossler <rkoss...@nd.edu> wrote: > Hi Derek, > Yesterday, I did a "git pull" and "make" of the "maint" HEAD. This was on > a computer that had not been used in several months. The previous version > was definitely 3.10, but I don't know how old. Anyway, following the > build, I could run the examples without getting any error message. Today, > however, when I opened a new command prompt and tried to run the example > programs, I got the error message. BTW, my typical process is to "source" > a "setup_env.sh" file. After adding the UHD_RFNOC_LOC export to my file, > everything worked fine. > > What do you mean mean you say the the default path for UHD_RFNOC_DIR is > configured automatically at build time? > > Rob > > > On Fri, Mar 23, 2018 at 3:08 PM, Derek Kozel <derek.ko...@ettus.com> > wrote: > >> Hi Rob, >> >> The default path for UHD_RFNOC_DIR is configured automatically at build >> time. The requirement has not changed since UHD 3.10. What version of UHD >> were you building when you encountered the problem. It is not impossible >> that this is a bug, though I do not believe that there have been any >> changes to that area of code recently. >> >> I agree with Marcus that Matis at least probably had another version of >> UHD installed using a prebuilt package. By default source builds end up >> installed to /usr/local, not /usr. >> >> Matis, can you check if after running make install there is now a >> /usr/local/share/uhd/rfnoc/blocks directory? If so, then you have two >> versions of UHD installed and are likely to encounter errors in the future >> where software may confuse the two. If one was installed using apt or your >> package manager then it should be removed the same way. >> >> Regards, >> Derek >> >> >> On Fri, Mar 23, 2018 at 6:23 PM, Rob Kossler <rkoss...@nd.edu> wrote: >> >>> This necessity for setting UHD_RFNOC_DIR should probably be added to the >>> UHD manual. >>> >>> On Fri, Mar 23, 2018 at 2:15 PM, Derek Kozel via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Hello Matis, >>>> >>>> UHD uses RFNoC internally at all times since the 3.10.0.0 release. The >>>> XML files are needed for standard operation. It does not expose the full >>>> API or set of features unless the rfnoc-devel branch is used. >>>> >>>> Regards, >>>> Derek >>>> >>>> On Fri, Mar 23, 2018 at 6:05 PM, Matis Alun via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> yes, I missed the make install because I thought that it was >>>>> optionnal. >>>>> >>>>> Tell me if I wrong: RFnoc is not used since we use multi_usrp wright ? >>>>> in this case, xml files are also needed ? >>>>> >>>>> Thanks. >>>>> >>>>> matis >>>>> >>>>> Le 23/03/2018 à 17:35, Marcus D. Leech via USRP-users a écrit : >>>>> >>>>> On 03/23/2018 12:30 PM, Matis Alun via USRP-users wrote: >>>>> >>>>> yes of course: >>>>> >>>>> total 76 >>>>> -rw-r--r--. 1 root root 1433 2 nov. 2016 addsub.xml >>>>> -rw-r--r--. 1 root root 363 2 nov. 2016 block.xml >>>>> -rw-r--r--. 1 root root 2944 2 nov. 2016 ddc_single.xml >>>>> -rw-r--r--. 1 root root 3875 2 nov. 2016 ddc.xml >>>>> -rw-r--r--. 1 root root 1677 2 nov. 2016 dma_fifo.xml >>>>> -rw-r--r--. 1 root root 2393 2 nov. 2016 duc.xml >>>>> -rw-r--r--. 1 root root 3845 2 nov. 2016 fft.xml >>>>> -rw-r--r--. 1 root root 899 2 nov. 2016 fifo.xml >>>>> -rw-r--r--. 1 root root 365 2 nov. 2016 fir.xml >>>>> -rw-r--r--. 1 root root 4500 2 nov. 2016 fosphor.xml >>>>> -rw-r--r--. 1 root root 1374 2 nov. 2016 keep_one_in_n.xml >>>>> -rw-r--r--. 1 root root 1262 2 nov. 2016 logpwr.xml >>>>> -rw-r--r--. 1 root root 554 2 nov. 2016 nullblock.xml >>>>> -rw-r--r--. 1 root root 624 2 nov. 2016 ofdmeq.xml >>>>> -rw-r--r--. 1 root root 1531 2 nov. 2016 packetresizer.xml >>>>> -rw-r--r--. 1 root root 1582 2 nov. 2016 radio_x300.xml >>>>> -rw-r--r--. 1 root root 3432 2 nov. 2016 siggen.xml >>>>> -rw-r--r--. 1 root root 1170 2 nov. 2016 window.xml >>>>> >>>>> I think what you did was you *built* the new version of UHD, but never >>>>> actually installed it, via sudo make install, so when you are executing >>>>> bits and >>>>> pieces from the built-but-not-yet-installed files, they're >>>>> naturally expecting to find config files, and xml files, etc, in their >>>>> "natural" places. >>>>> >>>>> You'll have to uninstall the UHD you already have, which was likely >>>>> installed from a pre-packaged release (via a PPA?), and then run the >>>>> sudo make install in the source tree. >>>>> >>>>> >>>>> >>>>> Le 23/03/2018 à 17:18, Marcus D. Leech via USRP-users a écrit : >>>>> >>>>> On 03/23/2018 11:30 AM, Matis Alun via USRP-users wrote: >>>>> >>>>> yes, I have a /usr/share/uhd/rfnoc/blocks directory with several xml >>>>> files. >>>>> >>>>> matis >>>>> >>>>> Could you do an ls -l on that directory and share it with us? >>>>> >>>>> >>>>> Le 23/03/2018 à 16:20, Marcus D. Leech via USRP-users a écrit : >>>>> >>>>> On 03/23/2018 10:32 AM, Matis Alun via USRP-users wrote: >>>>> >>>>> Hi, >>>>> >>>>> I've been working with N210 for a long time now with very successful >>>>> story. >>>>> >>>>> I recently buy an x300 with TwinRX and I try do run the demo examples >>>>> (so I am in the very first stage of testing). >>>>> I compiled the uhd 3.010.003 with succes and I can pinf the X300 at ip >>>>> 192.168.10.2. >>>>> I upload the fpga image usrp_x300_fpga_HG.bit on the board. >>>>> >>>>> Runing uhd_find_device gives: >>>>> >>>>> -------------------------------------------------- >>>>> -- UHD Device 0 >>>>> -------------------------------------------------- >>>>> Device Address: >>>>> type: x300 >>>>> addr: 192.168.10.2 >>>>> fpga: HG >>>>> name: >>>>> serial: 31402AC >>>>> product: X300 >>>>> >>>>> But runing uhd_usrp_probe gives: >>>>> >>>>> linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; >>>>> UHD_003.010.003.000-0-unknown >>>>> >>>>> -- X300 initialization sequence... >>>>> -- Determining maximum frame size... 1472 bytes. >>>>> -- Setup basic communication... >>>>> -- Loading values from EEPROM... >>>>> -- Setup RF frontend clocking... >>>>> -- Radio 1x clock:200 >>>>> Error: AssertionError: Failed to find a valid XML path for RFNoC blocks. >>>>> Try setting the enviroment variable UHD_RFNOC_DIR to the correct location >>>>> [ravard@starduck utils]$ ./uhd_usrp_probe --args >>>>> "type=x300,addr=192.168.10.2" >>>>> linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); Boost_106400; >>>>> UHD_003.010.003.000-0-unknown >>>>> >>>>> -- X300 initialization sequence... >>>>> -- Determining maximum frame size... 1472 bytes. >>>>> -- Setup basic communication... >>>>> -- Loading values from EEPROM... >>>>> -- Setup RF frontend clocking... >>>>> -- Radio 1x clock:200 >>>>> Error: AssertionError: Failed to find a valid XML path for RFNoC blocks. >>>>> Try setting the enviroment variable UHD_RFNOC_DIR to the correct location >>>>> >>>>> Can someone tell me what is the problem ? >>>>> >>>>> Thanks >>>>> >>>>> Matis >>>>> >>>>> Do you have a /usr/local/share/uhd/rfnoc/blocks directory? Or a >>>>> /usr/share/uhd/rfnoc/blocks directory? >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing >>>>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing >>>>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing >>>>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing >>>>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing >>>>> listUSRP-users@lists.ettus.comhttp://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 >>>> >>>> >>> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
