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
