Yes, I did: git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git
and the "what(): map::at" error is reproduced when I use that branch. So then I checked out the uhd maint head like you but can't build it properly. What branch of gr-ettus are you using? Did you install it after installing the uhd maint head? Note: I ran into similar gr-ettus build issues when I checked out the uhd maint branch commit Michael mentioned earlier. My workaround for that was to instead the uhd rfnoc-devel branch head then modify the radio_ctrl_impl.hpp and radio_ctrl_impl.cpp files to match what was checked into uhd maint branch (commit 8922095 <https://github.com/EttusResearch/uhd/commit/8922095b2c3a8dd1c764d7b80d3128c44721597b>). So I never actually got uhd maint branch to build with with gr-ettus master branch. On Fri, May 11, 2018 at 7:21 PM, Louis Brown <rfeng...@me.com> wrote: > 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 > <https://github.com/EttusResearch/uhd/commit/34c5610449736f540785c169debbe01ee7e2d36d>) > and installed it (set "ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I > install the head of gr-ettus master branch (commit 4ef12d > <https://github.com/EttusResearch/gr-ettus/commit/4ef12d28f689d69d20fa2e38b9f06c8ab8397ca8>) > 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 >>>>> <https://github.com/EttusResearch/uhd/commit/8922095b2c3a8dd1c764d7b80d3128c44721597b>). >>>>> 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/8ee22529f33a63c2 >>>>>>>>>> 064b0dc6fbcc04c2ded94b4a >>>>>>>>>> >>>>>>>>>> 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.ett >>>>>>>>>> us.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
