Did you “git clone — recursive” then switch to the rfnoc branch? I’m not using the rfnoc branch; just the normal maintenance branch, but last time I messed with it, you had to do that.
> On May 11, 2018, at 21:16, switchlanez <switchla...@gmail.com> wrote: > > Wow good to know, Lou. > > I checked out the head of the uhd maint branch (commit 34c5610) and installed > it (set "ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I install the > head of gr-ettus master branch (commit 4ef12d) I get an error: > > /home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40: > fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory > compilation terminated. > lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target > 'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed > make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o] > Error 1 > make[2]: *** Waiting for unfinished jobs.... > [ 46%] Built target ettus_swig_swig_2d0df > Scanning dependencies of target pygen_swig_5fc0a > [ 48%] Generating ettus_swig.pyo > [ 51%] Generating ettus_swig.pyc > [ 53%] Built target pygen_swig_5fc0a > CMakeFiles/Makefile2:139: recipe for target > 'lib/CMakeFiles/gnuradio-ettus.dir/all' failed > make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2 > Makefile:138: recipe for target 'all' failed > make: *** [all] Error 2 > > I am probably building it wrong. Does anybody know the correct way? > > Andrew > >> On Fri, May 11, 2018 at 5:48 PM, Louis Brown <rfeng...@me.com> wrote: >> Tried the X310 today on the maintenance branch, and the TX light >> illuminates, but did not check for proper quadrature output. Will check it >> tomorrow. Was able to do 100 Msps full duplex. >> >> Lou >> >> >>> On May 11, 2018, at 19:18, switchlanez <switchla...@gmail.com> wrote: >>> >>> Thanks, Michael. >>> >>> So with the fix you referenced RFNoC: Radio now works in Rx mode but does >>> not seem to work work in Tx mode regardless of what's connected to its >>> input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks >>> separately). The "what(): map::at" error is resolved so there is no error >>> message but the "TX/RX" indicator light on the X310 front panel fails to >>> light up. Has that been fixed or is a fix in progress? >>> >>>> On Mon, May 7, 2018 at 9:12 AM, Michael West <michael.w...@ettus.com> >>>> wrote: >>>> Hi Andrew, >>>> >>>> First, maint was just updated with the fix for the LFTX and LFRX boards on >>>> X3x0. >>>> >>>> Second, yes, you can install multiple installations of UHD by setting the >>>> CMAKE_INSTALL_PREFIX different for each installation. You will have to >>>> set the PATH and LD_LIBRARY_PATH environment variables appropriately to >>>> switch between them. >>>> >>>> Regards, >>>> Michael >>>> >>>>> On Fri, May 4, 2018 at 11:43 AM, switchlanez <switchla...@gmail.com> >>>>> wrote: >>>>> Thanks Michael. Do you know if I were to install rfnoc under a different >>>>> prefix would the UHD version be able to be switched between the prefixes? >>>>> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant >>>>> to install the latest build and checkout that new fix if it it will >>>>> overwrite the older UHD version. >>>>> >>>>>> On Fri, May 4, 2018 at 11:25 AM, Michael West <michael.w...@ettus.com> >>>>>> wrote: >>>>>> Hi Andrew, >>>>>> >>>>>> The fix is on the master branch (commit 8922095). It is being included >>>>>> in the next set of commits on the maint branch that should be available >>>>>> in the next few days. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>>> On Wed, May 2, 2018 at 1:13 PM, switchlanez <switchla...@gmail.com> >>>>>>> wrote: >>>>>>> Hi Michael, >>>>>>> >>>>>>> I see new commits have been entered in the uhd maint branch in the last >>>>>>> couple days. Were any related to this issue? >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>>> On Mon, Apr 23, 2018 at 11:12 AM, Michael West >>>>>>>> <michael.w...@ettus.com> wrote: >>>>>>>> Hi Louis/Andrew, >>>>>>>> >>>>>>>> The root cause of the issue has been identified and a fix is in >>>>>>>> progress. We should have the fix available on the head of the maint >>>>>>>> branch very soon. Thank you for bringing it to our attention! >>>>>>>> >>>>>>>> Regards, >>>>>>>> Michael >>>>>>>> >>>>>>>>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users >>>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>>> I have an issue that may be related. Using LFTX and LFRX boards in an >>>>>>>>> X310, anytime I use the RFNoC Radio block in Rx mode the run >>>>>>>>> terminates with: >>>>>>>>> >>>>>>>>> terminate called after throwing an instance of 'std::out_of_range' >>>>>>>>> what(): map::at >>>>>>>>> >>>>>>>>> Following for updates. >>>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users >>>>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>>>> Hello Louis: >>>>>>>>>> >>>>>>>>>> Thanks for the detailed feedback. We have reproduced this issue, and >>>>>>>>>> are debugging it now. We will get back to you and post an update >>>>>>>>>> shortly. >>>>>>>>>> >>>>>>>>>> --Neel Pandeya >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 12 April 2018 at 18:46, Louis Brown via USRP-users >>>>>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>>>>> Could it be something to do with this commit for address offsets? >>>>>>>>>>> >>>>>>>>>>> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2064b0dc6fbcc04c2ded94b4a >>>>>>>>>>> >>>>>>>>>>> Lou >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Apr 12, 2018, at 16:38, Louis Brown <rfeng...@me.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Did something change with respect to daughter board addressing in >>>>>>>>>>>> UHD 3.11? >>>>>>>>>>>> I have an X310 with LFTX and LFRX in motherboard slot A. >>>>>>>>>>>> When I run benchmark_rate it core dumps as follows: >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args >>>>>>>>>>>> "addr=192.168.40.2" --tx_rate=10E6 >>>>>>>>>>>> >>>>>>>>>>>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat >>>>>>>>>>>> 7.3.1-5); Boost_106400; UHD_3.11.0.1-0-unknown >>>>>>>>>>>> [00:00:00.000006] Creating the usrp device with: >>>>>>>>>>>> addr=192.168.40.2... >>>>>>>>>>>> [INFO] [X300] X300 initialization sequence... >>>>>>>>>>>> [INFO] [X300] Determining maximum frame size... >>>>>>>>>>>> [INFO] [X300] Maximum frame size: 8000 bytes. >>>>>>>>>>>> [INFO] [X300] Setup basic communication... >>>>>>>>>>>> [INFO] [X300] Loading values from EEPROM... >>>>>>>>>>>> [INFO] [X300] Setup RF frontend clocking... >>>>>>>>>>>> [INFO] [X300] Radio 1x clock:200 >>>>>>>>>>>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0... >>>>>>>>>>>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s) >>>>>>>>>>>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1... >>>>>>>>>>>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s) >>>>>>>>>>>> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1 >>>>>>>>>>>> input ports >>>>>>>>>>>> [INFO] [RFNOC RADIO] Register loopback test passed >>>>>>>>>>>> [INFO] [RFNOC RADIO] Register loopback test passed >>>>>>>>>>>> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1 >>>>>>>>>>>> input ports >>>>>>>>>>>> [INFO] [RFNOC RADIO] Register loopback test passed >>>>>>>>>>>> [INFO] [RFNOC RADIO] Register loopback test passed >>>>>>>>>>>> [INFO] [CORES] Performing timer loopback test... >>>>>>>>>>>> [INFO] [CORES] Timer loopback test passed >>>>>>>>>>>> [INFO] [CORES] Performing timer loopback test... >>>>>>>>>>>> [INFO] [CORES] Timer loopback test passed >>>>>>>>>>>> Using Device: Single USRP: >>>>>>>>>>>> Device: X-Series Device >>>>>>>>>>>> Mboard 0: X310 >>>>>>>>>>>> RX Channel: 0 >>>>>>>>>>>> RX DSP: 0 >>>>>>>>>>>> RX Dboard: A >>>>>>>>>>>> RX Subdev: LFRX (AB) >>>>>>>>>>>> RX Channel: 1 >>>>>>>>>>>> RX DSP: 0 >>>>>>>>>>>> RX Dboard: B >>>>>>>>>>>> RX Subdev: Unknown (0xffff) - 0 >>>>>>>>>>>> TX Channel: 0 >>>>>>>>>>>> TX DSP: 0 >>>>>>>>>>>> TX Dboard: A >>>>>>>>>>>> TX Subdev: LFTX (AB) >>>>>>>>>>>> TX Channel: 1 >>>>>>>>>>>> TX DSP: 0 >>>>>>>>>>>> TX Dboard: B >>>>>>>>>>>> TX Subdev: Unknown (0xffff) - 0 >>>>>>>>>>>> >>>>>>>>>>>> [00:00:02.623786] Setting device timestamp to 0... >>>>>>>>>>>> terminate called after throwing an instance of 'std::out_of_range' >>>>>>>>>>>> what(): map::at >>>>>>>>>>>> Aborted (core dumped) >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX >>>>>>>>>>>> LED, or course I have no boards installed there. >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args >>>>>>>>>>>> "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1" >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> If I specify tx_channels "0" it core dumps with the same >>>>>>>>>>>> std::out_of_range >>>>>>>>>>>> >>>>>>>>>>>> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer >>>>>>>>>>>> run: >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> [INFO] [CORES] Timer loopback test passed >>>>>>>>>>>> terminate called after throwing an instance of 'std::out_of_range' >>>>>>>>>>>> what(): map::at >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> If I try benchmark_rate with another X310 with the UBX card in >>>>>>>>>>>> slot A, things work fine. So maybe it's specific to the use of LF >>>>>>>>>>>> cards with UHD 3.11. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Lou >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
