Hi Martin, Thank you for verifying my code I was able to put in debugging printf statements, and was able to figure out what was wrong (although I couldn't get the GR logging statements like debug to show). The message was indeed getting to the UHD sink, but I realized that I needed to also specify the parameter for lo_offset otherwise the key 'freq' just sets the lo_offset to 0. I was using Bastian's gr-ieee802-11 library, and I didn't realize the way that he tunes his center freq is different than just uhd.tune_request(target_freq, lo_offset). He actually uses uhd.tune_request(target_freq, rf_freq=freq-lo_offset, rf_freq_policy = uhd.tune_request.POLICY_MANUAL). So I modified the code like below:
::uhd::tune_request_t request; request.target_freq = freq; request.rf_freq_policy = ::uhd::tune_request_t::POLICY_MANUAL; request.rf_freq = rx_freq - lo_offset; new_tune_reqest = ::uhd::tune_request_t(request); . . _update_curr_tune_req(new_tune_reqest, chan); That did the trick. Thank you for your help. -Sarah -----Original Message----- From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of usrp-users-requ...@lists.ettus.com Sent: Wednesday, January 24, 2018 7:00 AM To: usrp-users@lists.ettus.com Subject: USRP-users Digest, Vol 89, Issue 21 Send USRP-users mailing list submissions to usrp-users@lists.ettus.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com or, via email, send a message with subject or body 'help' to usrp-users-requ...@lists.ettus.com You can reach the person managing the list at usrp-users-ow...@lists.ettus.com When replying, please edit your Subject line so it is more specific than "Re: Contents of USRP-users digest..." Today's Topics: 1. Re: UHD Converter for X310 series with unsupported data format (Kei Nguyen) 2. Re: Help on UHD Python API installation (Zhongyuan Zhao) 3. Re: Help on UHD Python API installation (Zhongyuan Zhao) 4. Using both sides of an NI USRP-2953R (da...@daryllee.com) 5. Re: UHD Converter for X310 series with unsupported data format (Martin Braun) 6. Re: Help on UHD Python API installation (Martin Braun) 7. Re: Using both sides of an NI USRP-2953R (Martin Braun) 8. Re: 2 B210 synchronous problem (Martin Braun) 9. Re: USRP with different GPSDO (Martin Braun) 10. Re: Passing Messages as Commands to UHD Sink (Martin Braun) 11. Re: use 2 DDC chain of N210 with SBX (Martin Braun) 12. Re: transmit underrun in dual 10Gige X310 config (Martin Braun) 13. Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error (Adam Kurisko) 14. Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error (Martin Braun) 15. [UHD] Dependency changes: MSVC and Vivado (Martin Braun) 16. Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error (Adam Kurisko) 17. Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error (Martin Braun) 18. [UHD] Changes to uhd_images_downloader (Martin Braun) 19. uhd error with new version (Dang tien Vo-Huu) 20. Re: 2 B210 synchronous problem (Piotr Krysik) 21. Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error (EJ Kreinar) 22. Re: use 2 DDC chain of N210 with SBX (omid saeedy) 23. Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error (Adam Kurisko) ---------------------------------------------------------------------- Message: 1 Date: Tue, 23 Jan 2018 12:13:48 -0500 From: Kei Nguyen <hai.n.nguyen...@gmail.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] UHD Converter for X310 series with unsupported data format Message-ID: <CAFZDN5KooBgFRWBxRe=4sJ8WpyDmVjLjp=2q6rpjaw_z4yc...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" I mean s16 -> f32 not sc16 -> fc32, which is already implemented. I looked through the document but it's not clear to me. I'm not sure about UHD code structure. Could you explain in more details? Sorry for any confusion. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/dc837c0b/attachment-0001.html> ------------------------------ Message: 2 Date: Tue, 23 Jan 2018 01:14:11 +0000 From: Zhongyuan Zhao <zhz...@cse.unl.edu> To: Martin Braun <martin.br...@ettus.com> Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Help on UHD Python API installation Message-ID: <caewjnshc92d+phop5tunsj2qoc5jmnqm-cjk1ny76gj71z1...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" CMAKE list Python API as disabled, Moreover, Dependency PythonLibs_FOUND = Disabling LibUHD - Python API support. Zhongyuan Zhao PhD Candidate, Department of Computer Science & Engineering, University of Nebraska-Lincoln Office Hour: WF 9:30-10:00am, Avery Hall 12, Suite 117, Schorr Center, Lincoln, Nebraska 68588-0115 On Tue, Jan 23, 2018 at 12:47 AM, Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > Zhao, > > you need to first install Boost, then UHD. When you run CMake on UHD, > does it list the Python API as an enabled component? > > -- M > > On 01/22/2018 02:43 PM, Zhongyuan Zhao via USRP-users wrote: > > Could anyone provide a complete guidance of installation of UHD Python > > API on Ubuntu? > > > > I cloned the python api repo, and followed this installation of UHD from > > source > > <https://kb.ettus.com/Building_and_Installing_the_ > USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux> > > > > Then I installed Boost.Python followed here > > <http://www.boost.org/doc/libs/1_66_0/more/getting_started/>, with these > > commands > > > > |cd path/to/boost_1_66_0 ./bootstrap.sh --help ./bootstrap.sh > > --prefix=/usr/local/lib/boost --with-libraries=python | > > > > However, when I run 'import uhd' in python, it says 'no module named > > uhd'. The OS is Ubuntu running on a Mac Mini. > > > > 1. The source is python-api branch, > > > > 2. Build and installed successfully > > > > 3. PYTHONPATH: I use cmake ../ to installed on default directory > > (/usr/local/), and I put '/usr/local/bin/' to PYTHONPATH in .bashrc file > > > > > > Thank you! > > > > Zhao > > > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/e39d1f26/attachment-0001.html> ------------------------------ Message: 3 Date: Tue, 23 Jan 2018 16:36:13 +0000 From: Zhongyuan Zhao <zhz...@cse.unl.edu> To: Martin Braun <martin.br...@ettus.com> Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Help on UHD Python API installation Message-ID: <caewjnsia-ktgdmamwcad+3khgjfcy1afg+_czsc-ce9v529...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, The CMAKE shows that Python API is disabled, I was unable to enable it. It shows Dependency PythonLibs_FOUND = Is there anything missing? Zhongyuan Zhao PhD Candidate, Department of Computer Science & Engineering, University of Nebraska-Lincoln Office Hour: WF 9:30-10:00am, Avery Hall 12, Suite 117, Schorr Center, Lincoln, Nebraska 68588-0115 On Tue, Jan 23, 2018 at 12:47 AM, Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > Zhao, > > you need to first install Boost, then UHD. When you run CMake on UHD, > does it list the Python API as an enabled component? > > -- M > > On 01/22/2018 02:43 PM, Zhongyuan Zhao via USRP-users wrote: > > Could anyone provide a complete guidance of installation of UHD Python > > API on Ubuntu? > > > > I cloned the python api repo, and followed this installation of UHD from > > source > > <https://kb.ettus.com/Building_and_Installing_the_ > USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux> > > > > Then I installed Boost.Python followed here > > <http://www.boost.org/doc/libs/1_66_0/more/getting_started/>, with these > > commands > > > > |cd path/to/boost_1_66_0 ./bootstrap.sh --help ./bootstrap.sh > > --prefix=/usr/local/lib/boost --with-libraries=python | > > > > However, when I run 'import uhd' in python, it says 'no module named > > uhd'. The OS is Ubuntu running on a Mac Mini. > > > > 1. The source is python-api branch, > > > > 2. Build and installed successfully > > > > 3. PYTHONPATH: I use cmake ../ to installed on default directory > > (/usr/local/), and I put '/usr/local/bin/' to PYTHONPATH in .bashrc file > > > > > > Thank you! > > > > Zhao > > > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/44cf3258/attachment-0001.html> ------------------------------ Message: 4 Date: Tue, 23 Jan 2018 12:27:23 -0500 From: da...@daryllee.com To: usrp-users@lists.ettus.com Subject: [USRP-users] Using both sides of an NI USRP-2953R Message-ID: <20180123122723.horde.edot5fribi5melnd1kgs...@www.daryllee.com> Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes I've been using an NI USRP-2953R for several months with a trivial configuration: sending and receiving in "half-duplex" mode on the "RF 0" receive and transmit antennas. Now I need to try using the RF 0 RX antenna and the RF 1 TX antenna. I'm using this terminology because I'm a bit uncertain about the other terminology (daugherboard, front-end, sub-device, channel, port, ...). I found the application note "Frontends, Sub-Device Specifications, and Antenna Port Selection", which is very helpful, but having an example would be efven more helpful. The UHD library distribution example "txrx_loopback_to_file" leads me to believe that I need a separate multi_usrp object for each direction (tx_usrp, rx_usrp), but I also need to work out the correct sub-device specification "X:Y" to pass in the arg string. Can anyone point me to other documents/tutorials/examples of such a configuration? -- Daryl Lee ------------------------------ Message: 5 Date: Tue, 23 Jan 2018 09:58:09 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] UHD Converter for X310 series with unsupported data format Message-ID: <20180123175809.GA22320@glad0s> Content-Type: text/plain; charset="us-ascii" On Tue, Jan 23, 2018 at 12:13:48PM -0500, Kei Nguyen via USRP-users wrote: > I mean s16 -> f32 not sc16 -> fc32, which is already implemented. > I looked through the document but it's not clear to me. I'm not sure about > UHD code structure. Could you explain in more details? > Sorry for any confusion. Like I said, s16 -> fc32 is already implemented. Assuming your FPGA code produces real samples (s16), you then select f32 as your output format. Select appropriate values in your uhd::stream_args_t struct. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/d63ac9e6/attachment-0001.asc> ------------------------------ Message: 6 Date: Tue, 23 Jan 2018 10:01:12 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Help on UHD Python API installation Message-ID: <20180123180112.GA25817@glad0s> Content-Type: text/plain; charset="utf-8" On Tue, Jan 23, 2018 at 04:36:13PM +0000, Zhongyuan Zhao wrote: > Hi,?? > The CMAKE shows that Python API is disabled, > I was unable to enable it. It shows?? > Dependency PythonLibs_FOUND = > Is there anything missing??? You need Python development libraries, e.g., python2.7-dev if you're on Ubuntu. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/16cac415/attachment-0001.asc> ------------------------------ Message: 7 Date: Tue, 23 Jan 2018 10:07:04 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Using both sides of an NI USRP-2953R Message-ID: <20180123180704.GB25817@glad0s> Content-Type: text/plain; charset="us-ascii" On Tue, Jan 23, 2018 at 12:27:23PM -0500, Daryl Lee via USRP-users wrote: > I've been using an NI USRP-2953R for several months with a trivial > configuration: sending and receiving in "half-duplex" mode on the "RF 0" > receive and transmit antennas. Now I need to try using the RF 0 RX antenna > and the RF 1 TX antenna. I'm using this terminology because I'm a bit > uncertain about the other terminology (daugherboard, front-end, sub-device, > channel, port, ...). I found the application note "Frontends, Sub-Device > Specifications, and Antenna Port Selection", which is very helpful, but > having an example would be efven more helpful. The UHD library distribution > example "txrx_loopback_to_file" leads me to believe that I need a separate > multi_usrp object for each direction (tx_usrp, rx_usrp), but I also need to > work out the correct sub-device specification "X:Y" to pass in the arg > string. > > Can anyone point me to other documents/tutorials/examples of such a > configuration? Daryl, you don't need several multi_usrp instantiations (and in fact, they would point to the same underlying device due to some device caching). There are multiple ways to achieve this: 1. Set RX subdev spec to "A:0", and TX subdev spec to "B:0". This will select the A-side for RX, and the B-side for TX. Then, create one streamer on channel 0 for each direction (call get_rx_stream() and get_tx_stream() with default args). 2. Set the RX and TX subdev spec both to "A:0 B:0" (this is the default). Then, call get_rx_stream() with channels = [0] and get_tx_stream() with channels = [1] (both are vectors of length one). Both will achieve the same effect. The difference is when calling other multi_usrp calls such as set_rx_freq() or set_tx_freq(). The channel indexing is relative to the subdev spec. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/fa159c28/attachment-0001.asc> ------------------------------ Message: 8 Date: Tue, 23 Jan 2018 10:11:18 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] 2 B210 synchronous problem Message-ID: <20180123181118.GC25817@glad0s> Content-Type: text/plain; charset="utf-8" On Thu, Jan 18, 2018 at 10:34:14AM +0100, Piotr Krysik via USRP-users wrote: > Hi Hideyuki, > > Our students were working (with my help) on synchronizing two USRPs B210 > with use of Octoclock-G. > To make your code work without any race-conditions I would add a loop > that waits for pps edge before your adjustment code, like this: > ``` > ? time_last_pps = self.uhd_usrp_source_0.get_time_last_pps() > ? while(self.uhd_usrp_source_0.get_time_last_pps() == time_last_pps): > ??? time.sleep(0.01) > ``` This is good advice. You can go to multi_usrp.cpp and take a look at set_time_unknown_pps() for a reference on how to do that. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/19512338/attachment-0001.asc> ------------------------------ Message: 9 Date: Tue, 23 Jan 2018 10:18:41 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] USRP with different GPSDO Message-ID: <20180123181841.GA32667@glad0s> Content-Type: text/plain; charset="us-ascii" On Tue, Jan 23, 2018 at 01:47:57PM +0300, Ali via USRP-users wrote: > Hi to all, > Is it possible to use different GPSDO (more accurate) than the one that > Ettus sells? The device is X310. Can you suggest any brand or model? > Best, Ali, if you find a pin- and API-compatible GPSDO, you can give it a try, but keep in mind that's outside of what warranty and support covers. -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/bdcd506a/attachment-0001.asc> ------------------------------ Message: 10 Date: Tue, 23 Jan 2018 10:22:13 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Passing Messages as Commands to UHD Sink Message-ID: <20180123182213.GB32667@glad0s> Content-Type: text/plain; charset="utf-8" On Tue, Jan 23, 2018 at 02:11:21AM +0000, Sarah Tran via USRP-users wrote: > Hi All, > > I would like to change the center freq of my UHD Sink depending on who the > receiver is. So I wrote a custom block that will read what the destination > mac address is for a packet, and send a message to change the center freq > based on what destination address it is. This is the format for how I > write the message: > > { > message_port_register_out(PDU_PORT_ID); > } > command = pmt::make_dict(); > command = pmt::dict_add(command, pmt::mp(?freq?), > pmt::mp(2.412e9)); > command = pmt::dict_add(command, pmt::mp(?chan?), > pmt::mp(0)); > message_port_pub(PDU_PORT_ID, command); > > I saw from other mailing list posts, that this was the syntax they used, > but I can?t get it to actually the center frequency. Is there something I > am doing wrong? I am using uhd version 3.10 and GRC version 3.7.11.1. Sarah, this looks fine. Are you sure the messages are being received? Do you see any log statements to that effect? -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/33987d8c/attachment-0001.asc> ------------------------------ Message: 11 Date: Tue, 23 Jan 2018 10:23:47 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] use 2 DDC chain of N210 with SBX Message-ID: <20180123182347.GC32667@glad0s> Content-Type: text/plain; charset="us-ascii" On Mon, Jan 22, 2018 at 03:01:14PM +0330, omid saeedy via USRP-users wrote: > Hi > I am a master student and my thesis needs N210. > I want to use 2 DDC chains as 2 channels with SBX. > But I can't edit UHD due to this. > When I want to change subdev_spec GNURadio warn me only [A:0] is valid. Does "A:0 A:0" not work as subdev spec? -- Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/378ce9fb/attachment-0001.asc> ------------------------------ Message: 12 Date: Tue, 23 Jan 2018 10:27:24 -0800 From: Martin Braun <martin.br...@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] transmit underrun in dual 10Gige X310 config Message-ID: <20180123182724.GD32667@glad0s> Content-Type: text/plain; charset="utf-8" On Tue, Jan 16, 2018 at 02:51:44PM +0300, ??????? ???????????? via USRP-users wrote: > [...] > 2x200e6 is extremely hard to maintain from software, and we haven't been > able to sustain such rates ourselves. We are looking into it, but don't > expect any radical improvements any time soon. > > However, that explains Us, not Ss. Can you run ifconfig to see if the > NIC is dropping packets? > > [...] > > Hi, > > > > I am unable to transmit two channels simultaneously without flow > errors. > > I have X310 with dual 10 Gige interface installed, the image was > > uploaded from usrp_x310_fpga_XG.bit file. Every time I run benchmark > > utility to transmit two channels at the full rate I get a lot of 'S' > and > > then 'U'. There are no problems with receiving two channels or > > transmitting just one channel. > > > > > > $ sudo /usr/local/lib/uhd/examples/benchmark_rate --args > > "addr=192.168.30.2,second_addr=192.168.40.2"???? --tx_rate 200e6 > > --tx_channels 0,1 > > > > [...] > ifconfig shows no dropped packets nor errors. I also tried 003.010.002 > version of UHD and FPGA image but without success. > As receiving of 2x200e6 works OK I assume that is some software issue with > transmitting. > > For my application I am going to use lower sample rate so I just wanted to > know device limits. > > thanks, > Dmitry If you drop to 100 Msps, and skip second_addr, I would expect much better results. We have identified an issue on TX with using second_addr and continuous streaming, packets are fighting for bandwidth into the DRAM. Occasional underruns at 100 Msps are not unexpected. Below that, you should be fine unless you're running older hardware. Cheers, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/5f5a6f3e/attachment-0001.asc> ------------------------------ Message: 13 Date: Tue, 23 Jan 2018 18:35:01 +0000 From: Adam Kurisko <adamk...@outlook.com> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>, "martin.br...@ettus.com" <martin.br...@ettus.com> Subject: Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Message-ID: <dm5pr18mb13089b118c8950c8692ceb89d0...@dm5pr18mb1308.namprd18.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hi Martin, I apologize for the late response, but your reply, unfortunately, was not delivered to my inbox yesterday. To answer your question, I don't believe I modified any of the UHD source code from github, but just to be sure I will investigate further. Also, are you referring to the tx_dsp_core* files, because if so, then I am pretty sure I haven't touched those. It might also be worth noting that I am using UHD commit 12a34d6ef6b9666e29a23039291138f989c7c2ce of the rfnoc-devel branch. Thank you, Adam Kurisko ________________________________ From: Adam Kurisko Sent: Monday, January 22, 2018 2:29:15 PM To: usrp-users@lists.ettus.com Subject: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Hello, I am in the final stretch of implementing my custom RFNoC onto the E310, and I ran into the following error while running uhd_usrp_probe: root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe --args="fpga=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit"[INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700; UHD_4.0.0.rfnoc-devel-403-g12a34d6e] [INFO] [E300] Loading FPGA image: /home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit... [INFO] [E300] FPGA image loaded [INFO] [E300] Detecting internal GPS .... [INFO] [E300] GPSDO found [INFO] [E300] Initializing core control (global registers)... [INFO] [E300] Performing register loopback test... [INFO] [E300] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed terminate called after throwing an instance of 'uhd::lookup_error' what(): LookupError: Path not found in tree: /mboards/0/tx_dsps/0 Aborted I believe I created and edited all the necessary files in order to get it working and simulation of my custom block in Vivado shows that the block is functioning correctly. Could this be an issue with the .cpp/.hpp/.xml files I created? And if so, what can I change to correct this? Thank you, Adam Kurisko P.S. Just as some supplemental info, I was receiving the following errors prior to the one I am currently dealing with, but I corrected the error by running the error-stated commands "sysctl -w net.core.wmem_max=288000" and "sysctl -w net.core.rmem_max=288000" root@ettus-e3xx-sg1:~/localinstall/usr/share/uhd/images# uhd_usrp_probe --args="type=e3x0,addr=10.1.16.47,fpga=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bit,fw=/home/root/localinstall/usr/share/uhd/images/usrp_e310_fpga_RFNOC.bin" [INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700; UHD_4.0.0.rfnoc-devel-403-g12a34d6e] [WARNING] [UDP] The recv buffer could not be resized sufficiently. Target sock buff size: 288000 bytes. Actual sock buff size: 163840 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=288000 [WARNING] [UDP] The send buffer could not be resized sufficiently. Target sock buff size: 288000 bytes. Actual sock buff size: 163840 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.wmem_max=288000 [WARNING] [UDP] The recv buffer could not be resized sufficiently. Target sock buff size: 288000 bytes. Actual sock buff size: 163840 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=288000 [WARNING] [UDP] The send buffer could not be resized sufficiently. Target sock buff size: 288000 bytes. Actual sock buff size: 163840 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.wmem_max=288000 [WARNING] [UDP] The recv buffer could not be resized sufficiently. Target sock buff size: 288000 bytes. Actual sock buff size: 163840 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=288000 [WARNING] [UDP] The send buffer could not be resized sufficiently. Target sock buff size: 288000 bytes. Actual sock buff size: 163840 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.wmem_max=288000 Error: i2c_zc_impl recv timeout -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/4fb66704/attachment-0001.html> ------------------------------ Message: 14 Date: Tue, 23 Jan 2018 14:12:09 -0800 From: Martin Braun <martin.br...@ettus.com> To: Adam Kurisko <adamk...@outlook.com>, "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Message-ID: <3f790a4c-d6be-748e-f708-f100b8c24...@ettus.com> Content-Type: text/plain; charset=windows-1252 On 01/23/2018 10:35 AM, Adam Kurisko wrote: > Hi Martin,? > > > I apologize for the late response,?but your reply, unfortunately, was > not delivered to my inbox yesterday.?To answer your question, I don't > believe I modified any of the UHD source code from github, but just to > be sure I will investigate further.?Also, are you referring to the > tx_dsp_core* files, because if so, then I am pretty sure I haven't > touched those. Hey Adam, no, I was referring to the 'tx_dsps' property subtrees. Cheers, Martin ------------------------------ Message: 15 Date: Tue, 23 Jan 2018 14:20:03 -0800 From: Martin Braun <martin.br...@ettus.com> To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com> Subject: [USRP-users] [UHD] Dependency changes: MSVC and Vivado Message-ID: <b394f5b8-b517-638c-d27e-92be61ad3...@ettus.com> Content-Type: text/plain; charset=utf-8 Hi all, we are gearing up towards another major release (3.11.0.0), which will have two major changes in dependency requirements: - We are dropping support for MSCV 12.0. The lowest supported MSVC version is now 14.0 (aka MSVC 2015). We were having too much trouble with the lack of C++11 support in MSVC 12.0. This change has already been rolled out to master branch. gcc and clang versions are not affected, nor are CMake and Boost. - In the next few days, we'll be upgrading to Vivado 2017.4 for all of our generation-3 devices (X-Series, E310, N230, and future devices). Once we upgrade, it will no longer be possible to build FPGA images with any other version of Vivado. If you can spare the disk space, you can start downloading the new Vivado installer. Once we upgrade, we'll be re-releasing all affected FPGA images, and bumping their compat numbers (even if technically, there will be no compatibility change, but we need it to force synchronization between the UHD branch and pre-built binaries). This will force re-running uhd_images_downloader, and then upgrading the FPGA image. Cheers, Martin ------------------------------ Message: 16 Date: Tue, 23 Jan 2018 23:01:09 +0000 From: Adam Kurisko <adamk...@outlook.com> To: Martin Braun <martin.br...@ettus.com>, "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Message-ID: <dm5pr18mb130863ddae60ecf61e0fd717d0...@dm5pr18mb1308.namprd18.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi Martin, I am unsure if I had edited the property subtrees, however I decided to fresh install UHD to see if that might fix the problem. I will let you know if I experience similar errors. In the mean time while it is installing, could you explain the process for implementing the block using UHD without GNU Radio. I have my block made and it simulates/synths/impls in Vivado. I changed the Makefile.srcs in ..lib/rfnoc to include my custom block. I changed rfnoc_ce_auto_inst.v in ..top/e300 to instantiate my block. I run 'make E310_RFNOC' to generate a bitstream. I then secure copy the generated bitstream into the correct images directory on my board and finally run 'uhd_usrp_probe' with my custom .bit file. Does all that seem correct or am I missing a vital step in there somewhere? I read in one of your slide shows that I may also need to create a .xml file, but is this solely for GNU Radio or do I need to do this for UHD as well? Thank you for your help, Adam ________________________________ From: Martin Braun <martin.br...@ettus.com> Sent: Tuesday, January 23, 2018 5:12:09 PM To: Adam Kurisko; usrp-users@lists.ettus.com Subject: Re: [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error On 01/23/2018 10:35 AM, Adam Kurisko wrote: > Hi Martin, > > > I apologize for the late response, but your reply, unfortunately, was > not delivered to my inbox yesterday. To answer your question, I don't > believe I modified any of the UHD source code from github, but just to > be sure I will investigate further. Also, are you referring to the > tx_dsp_core* files, because if so, then I am pretty sure I haven't > touched those. Hey Adam, no, I was referring to the 'tx_dsps' property subtrees. Cheers, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/7d48dcec/attachment-0001.html> ------------------------------ Message: 17 Date: Tue, 23 Jan 2018 15:17:54 -0800 From: Martin Braun <martin.br...@ettus.com> To: Adam Kurisko <adamk...@outlook.com>, "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Message-ID: <b9b5d05a-e563-aeab-b1d5-bb9ba4f6e...@ettus.com> Content-Type: text/plain; charset=windows-1252 On 01/23/2018 03:01 PM, Adam Kurisko wrote: > I am unsure if I had edited the property subtrees, however I decided to > fresh install UHD to see if that might fix the problem. I will let you > know if I experience similar errors. > > > In the mean time while it is installing, could you explain the process > for implementing the block using UHD without GNU Radio. > > > I have my block made and?it simulates/synths/impls?in Vivado. > > I changed the Makefile.srcs in ..lib/rfnoc to include my custom block. > > I changed rfnoc_ce_auto_inst.v in ..top/e300 to instantiate my block. > > I run 'make E310_RFNOC' to generate a bitstream.? > > I then secure?copy the generated bitstream into the correct images > directory on my board ...this all looks good... > > and finally run 'uhd_usrp_probe' with my custom .bit file. ...and this should now list your block. Does it? > Does all that seem correct or am I missing a vital step in there somewhere? > > I read in one of your slide shows that I may also need to create a .xml > file, but is this solely for GNU Radio or do I need to do this for UHD > as well? If you change nothing on the software side, your block will be listed as "Block_0". You need one XML for UHD and GNU Radio each (so 2 total if you want to use GNU Radio, but at least 1). You can start by literally hacking up an XML file and copying it into the XML directory, on the E310 it's under /usr/share/uhd/rfnoc/blocks/*.xml. Also check out our knowledge base articles on RFNoC block writing. Cheers, Martin ------------------------------ Message: 18 Date: Tue, 23 Jan 2018 15:33:14 -0800 From: Martin Braun <martin.br...@ettus.com> To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com> Subject: [USRP-users] [UHD] Changes to uhd_images_downloader Message-ID: <57d0e808-ce1b-3a3a-db17-7237518c9...@ettus.com> Content-Type: text/plain; charset=utf-8 For the next UHD version, we will be updating uhd_images_downloader. The problem with the old uhd_images_downloader is that it refers to one big zip file for all the images. As we add more and more devices, we not only have to update the zip file more often, it also becomes bigger and bigger. If you're running uhd_images_downloader on an E310, it's most likely that you only want the E310 images, and not the megabytes of other FPGA images. The new tool fixes all those issues by breaking up the zip file into more, smaller zip files. On top of that, the new tool has a bunch of other improvements: - It maintains an inventory of downloaded files, and skips downloading them again if they didn't change. This means if we roll out a fix for the X300 only, and you run uhd_images_downloader without any arguments, it won't try and update anything else. Should you delete the inventory, it'll simply get everything, like it did before. - You can now filter by type. Use the -t switch to match against a regular expression, e.g. '-t b200mini' will only download a b200mini file. - We'll be adding more image types soon that are not FPGA images, such as filesystem updates. - 'uhd_images_downloader -l' will list all the targets you can download. In general, this should improve things and make other things easier. However, since we had to basically rewrite the tool, which had otherwise matured, it's likely that the new tool has shortcomings. We'd like to hear from you regarding those. There are a few problems we are already tracking: - We currently have no archives other than zip files. We're intending to add .tar.xz in the future, and you will be able to use uhd_images_downloader to fetch those (assuming your system can unzip xz archives) - The tool output changed, and we're still fine tuning the output. If you're a package maintainer, you probably hard-coded the URL for the FPGA images in your package creation script. We track the URLs of the individual archives, along with their SHA256 hash, in a manifest that is checked into git: https://github.com/EttusResearch/uhddev/blob/master/images/manifest.txt The base URL for all those is http://files.ettus.com/binaries/cache, so http://files.ettus.com/binaries/cache/usrp1/fpga-6bea23d/usrp1_usrp1_fpga_default.zip will fetch the USRP1 FPGA images. We're happy for any feedback -- ideally before we release the next version. Cheers, Martin ------------------------------ Message: 19 Date: Tue, 23 Jan 2018 18:45:40 -0500 From: Dang tien Vo-Huu <vo-hu...@husky.neu.edu> To: usrp-users@lists.ettus.com Subject: [USRP-users] uhd error with new version Message-ID: <CAK=zpxuzc5mh4-9pkoqmtpbfhah1osmrqsc58uzse-ghouj...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi all, Recently I've reinstall rfnoc (remove everything before rebuild with pybombs) and uhd seems to behave weird. There are 2 errors: 1/ Running uhd_rx_cfile in rfnoc: ---------------------------------------------------------------------------------------- $~/rfnoc/bin/uhd_rx_cfile -a addr=192.168.40.2 -f 5240M -A TX/RX -r 20M -g 15 test.32fc [INFO] [UHDlinux; GNU C++ version 4.8.4; Boost_105400; UHD_4.0.0.rfnoc-devel-409-gec9138eb] [INFO] [X300] X300 initialization sequence... [INFO] [X300] Determining maximum frame size... [INFO] [X300] Maximum frame size: 1472 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] pass (Throughput: 1299.0MB/s) [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1... [INFO] [RFNOC] pass (Throughput: 1296.8MB/s) [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [WARNING] [X300] For this connection, UHD recommends a receive frame size of at least 8000 for best performance, but your system's MTU will only allow 1472.This will negatively impact your maximum achievable sample rate. [WARNING] [UDP] The recv buffer could not be resized sufficiently. Target sock buff size: 576000 bytes. Actual sock buff size: 212992 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=576000 [WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input ports [INFO] [CORES] Performing timer loopback test... [INFO] [CORES] Timer loopback test passed [INFO] [CORES] Performing timer loopback test... [INFO] [CORES] Timer loopback test passed Traceback (most recent call last): File "./uhd_rx_cfile", line 263, in <module> tb = rx_cfile_block(options, filename) File "./uhd_rx_cfile", line 77, in __init__ channels=self.channels, File "/home/tienvh/rfnoc/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 122, in constructor_interceptor return old_constructor(*args) File "/home/tienvh/rfnoc/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 1981, in make return _uhd_swig.usrp_source_make(*args) RuntimeError: RuntimeError: For legacy APIs, all devices require the same number of radios, DDCs and DUCs. 2/ Running a flow graph (with FFT RFNoC block) created by GNURadio. When I change the FFT size in the flow graph, it didn't change when I ran the re-generated python file. The FFT size was always 2048 and therefore there is a mismatch to the next block. One thing I notice is that the copy block is always using 8 times greater than what I set for the FFT size. -------------------------------------------------------------------- $~/rfnoc/src/rfnoc-tutorial/examples/rfnoc_fft.py -a addr=192.168.40.2 -f 5240M -s 20M -F test.32fc --fft-size 16 [INFO] [UHDlinux; GNU C++ version 4.8.4; Boost_105400; UHD_4.0.0.rfnoc-devel-409-gec9138eb] [INFO] [X300] X300 initialization sequence... [INFO] [X300] Determining maximum frame size... [INFO] [X300] Maximum frame size: 1472 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] pass (Throughput: 1301.1MB/s) [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1... [INFO] [RFNOC] pass (Throughput: 1304.3MB/s) [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [INFO] [RFNOC RADIO] Register loopback test passed [WARNING] [X300] For this connection, UHD recommends a receive frame size of at least 8000 for best performance, but your system's MTU will only allow 1472.This will negatively impact your maximum achievable sample rate. [WARNING] [UDP] The recv buffer could not be resized sufficiently. Target sock buff size: 576000 bytes. Actual sock buff size: 212992 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=576000 [WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input ports [INFO] [CORES] Performing timer loopback test... [INFO] [CORES] Timer loopback test passed [INFO] [CORES] Performing timer loopback test... [INFO] [CORES] Timer loopback test passed Traceback (most recent call last): File "./rfnoc_fft.py", line 196, in <module> main() File "./rfnoc_fft.py", line 185, in main tb = top_block_cls(args=options.args, fft_size=options.fft_size, filename=options.filename, freq=options.freq, gain=options.gain, samp_rate=options.samp_rate) File "./rfnoc_fft.py", line 99, in __init__ self.connect((self.uhd_rfnoc_streamer_fft_0, 0), (self.blocks_copy_0_0, 0)) File "/home/tienvh/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 47, in wrapped func(self, src, src_port, dst, dst_port) File "/home/tienvh/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 110, in connect self.primitive_connect(*args) File "/home/tienvh/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 3482, in primitive_connect return _runtime_swig.top_block_sptr_primitive_connect(self, *args) ValueError: itemsize mismatch: uhd_rfnoc_FFT0:0 using 2048, copy0:0 using 128 Has anyone encountered this issue? If so, can you let me know how to fix it? I also attach the picture and the GRC file of the flow graph for the FFT issue. Hope that would make the situation clearer. Thanks in advance. Best, Tien -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/44bba2e1/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: rfnoc_fft.png Type: image/png Size: 96924 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/44bba2e1/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: rfnoc_fft.grc Type: application/gnuradio-grc Size: 31643 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/44bba2e1/attachment-0001.grc> ------------------------------ Message: 20 Date: Wed, 24 Jan 2018 09:11:08 +0100 From: Piotr Krysik <per...@o2.pl> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] 2 B210 synchronous problem Message-ID: <19a800d1-35dd-7ad3-1f72-cf244825c...@o2.pl> Content-Type: text/plain; charset=windows-1252 ?dniu 23.01.2018 o?19:11, Martin Braun via USRP-users pisze: > On Thu, Jan 18, 2018 at 10:34:14AM +0100, Piotr Krysik via USRP-users wrote: >> Hi Hideyuki, >> >> Our students were working (with my help) on synchronizing two USRPs B210 >> with use of Octoclock-G. >> To make your code work without any race-conditions I would add a loop >> that waits for pps edge before your adjustment code, like this: >> ``` >> ? time_last_pps = self.uhd_usrp_source_0.get_time_last_pps() >> ? while(self.uhd_usrp_source_0.get_time_last_pps() == time_last_pps): >> ??? time.sleep(0.01) >> ``` > This is good advice. You can go to multi_usrp.cpp and take a look at > set_time_unknown_pps() for a reference on how to do that. > Hi Martin, The problem is that even when I replicated exactly the set_time_unknown_pps() function in Python it doesn't work with USRPs B210. It works perfectly well with X310s but somehow with B210s there is some time offset (few hundreds us) that changes from one program execution to another. I still have to check on different B210s and different Octoclocks but it requires some time and in the end I don't expect a surprise (probably I will just be more sure that it is fault of the B210). So even to get information from someone like: "I checked and it works for me" would help me and others a lot. -- Best Regards, Piotr Krysik ------------------------------ Message: 21 Date: Wed, 24 Jan 2018 06:09:05 -0500 From: EJ Kreinar <ejkrei...@gmail.com> To: Martin Braun <martin.br...@ettus.com> Cc: Adam Kurisko <adamk...@outlook.com>, "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Message-ID: <CADRnH230kGtE4cS2SvVpjsMiK_TeSEGSe9rDbZk1Uc9vyH=6...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Adam, Please copy/paste your rfnoc_ce_auto_inst.v In my experience, these errors are usually due to something wrong in this file. Probably causes are that NUM_CE != the actual number of CEs. Or that when you added a new CE, you didn't increment the index of the wires, so two blocks are on the same index. Or, if you've tried to instantiate a DDC with NUM_CHAN=1, but did not change the NOC_BLOCK_ID to reflect only one channel Of course, could be something else-- those are just the problems I've personally found (multiple times) that throw similar errors. EJ On Jan 23, 2018 6:18 PM, "Martin Braun via USRP-users" < usrp-users@lists.ettus.com> wrote: > On 01/23/2018 03:01 PM, Adam Kurisko wrote: > > I am unsure if I had edited the property subtrees, however I decided to > > fresh install UHD to see if that might fix the problem. I will let you > > know if I experience similar errors. > > > > > > In the mean time while it is installing, could you explain the process > > for implementing the block using UHD without GNU Radio. > > > > > > I have my block made and it simulates/synths/impls in Vivado. > > > > I changed the Makefile.srcs in ..lib/rfnoc to include my custom block. > > > > I changed rfnoc_ce_auto_inst.v in ..top/e300 to instantiate my block. > > > > I run 'make E310_RFNOC' to generate a bitstream. > > > > I then secure copy the generated bitstream into the correct images > > directory on my board > > ...this all looks good... > > > > and finally run 'uhd_usrp_probe' with my custom .bit file. > > ...and this should now list your block. Does it? > > > Does all that seem correct or am I missing a vital step in there > somewhere? > > > > I read in one of your slide shows that I may also need to create a .xml > > file, but is this solely for GNU Radio or do I need to do this for UHD > > as well? > > If you change nothing on the software side, your block will be listed as > "Block_0". You need one XML for UHD and GNU Radio each (so 2 total if > you want to use GNU Radio, but at least 1). > > You can start by literally hacking up an XML file and copying it into > the XML directory, on the E310 it's under > /usr/share/uhd/rfnoc/blocks/*.xml. Also check out our knowledge base > articles on RFNoC block writing. > > Cheers, > Martin > > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180124/c7b016f6/attachment-0001.html> ------------------------------ Message: 22 Date: Wed, 24 Jan 2018 17:18:29 +0330 From: omid saeedy <omid.saeedy1...@gmail.com> To: Martin Braun <martin.br...@ettus.com>, usrp-users@lists.ettus.com Subject: Re: [USRP-users] use 2 DDC chain of N210 with SBX Message-ID: <CAMf6i6i5RYbqwYb2ysRnRHouwz-ikaAJ7r_yXk0KYnRPyd=o...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" thank you, It works and it can give me 2 signals, but central frequency of them is not exact. I think I must change tune_requset_t tune_request of them and I should set same rf_freq for them and change policy of them to manual On Tue, Jan 23, 2018 at 9:53 PM, Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > On Mon, Jan 22, 2018 at 03:01:14PM +0330, omid saeedy via USRP-users wrote: > > Hi > > I am a master student and my thesis needs N210. > > I want to use 2 DDC chains as 2 channels with SBX. > > But I can't edit UHD due to this. > > When I want to change subdev_spec GNURadio warn me only [A:0] is > valid. > > Does "A:0 A:0" not work as subdev spec? > > -- Martin > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180124/32269f63/attachment-0001.html> ------------------------------ Message: 23 Date: Wed, 24 Jan 2018 16:26:00 +0000 From: Adam Kurisko <adamk...@outlook.com> To: EJ Kreinar <ejkrei...@gmail.com>, Martin Braun <martin.br...@ettus.com> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Message-ID: <dm5pr18mb130820b8b5eaa871abe2735cd0...@dm5pr18mb1308.namprd18.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi EJ and Martin, Thank you for your responses. Martin: I will try to generate a bitstream without the .xml to see if my block is at least being recognized as Block_0 and create an xml from that point. I had made an xml which was used when I generated my error. I used the fir_filter xml as reference for my blocks xml, but I was suspicious that it might be the file causing the problem initially. EJ: This is the rfnoc_ce_auto_inst_e310.v that I used when I generated my error. localparam NUM_CE = 1; wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata; wire [63:0] ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1]; wire [NUM_CE-1:0] ce_o_tlast, ce_o_tvalid, ce_o_tready, ce_i_tlast, ce_i_tvalid, ce_i_tready; wire [63:0] ce_debug[0:NUM_CE-1]; // Flattern CE tdata arrays genvar k; generate for (k = 0; k < NUM_CE; k = k + 1) begin assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64]; assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k]; end endgenerate wire ce_clk = radio_clk; wire ce_rst = radio_rst; noc_block_delay_fifo inst_delay_fifo ( .bus_clk(bus_clk), .bus_rst(bus_rst), .ce_clk(ce_clk), .ce_rst(ce_rst), .i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]), .i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]), .o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]), .o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]), .debug(ce_debug[0]) ); Since my initial problem, I have fresh installed UHD and kept the rfnoc_ce_auto_inst_e310.v and I only modified the last inst of the file which by default I believe was the fir_filter. This is my current rfnoc_ce_aut_inst_e310.v file: localparam NUM_CE = 6; // Must be no more than 14 (2 ports taken by radio core & PS-PL DMA). wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata; wire [63:0] ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1]; wire [NUM_CE-1:0] ce_o_tlast, ce_o_tvalid, ce_o_tready, ce_i_tlast, ce_i_tvalid, ce_i_tready; wire [63:0] ce_debug[0:NUM_CE-1]; // Flattern CE tdata arrays genvar k; generate for (k = 0; k < NUM_CE; k = k + 1) begin assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64]; assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k]; end endgenerate wire ce_clk = radio_clk; wire ce_rst = radio_rst; noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback ( .bus_clk(bus_clk), .bus_rst(bus_rst), .ce_clk(ce_clk), .ce_rst(ce_rst), .i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]), .i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]), .o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]), .o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]), .debug(ce_debug[0])); noc_block_window inst_noc_block_window ( .bus_clk(bus_clk), .bus_rst(bus_rst), .ce_clk(ce_clk), .ce_rst(ce_rst), .i_tdata(ce_o_tdata[1]), .i_tlast(ce_o_tlast[1]), .i_tvalid(ce_o_tvalid[1]), .i_tready(ce_o_tready[1]), .o_tdata(ce_i_tdata[1]), .o_tlast(ce_i_tlast[1]), .o_tvalid(ce_i_tvalid[1]), .o_tready(ce_i_tready[1]), .debug(ce_debug[1])); noc_block_fft inst_noc_block_fft ( .bus_clk(bus_clk), .bus_rst(bus_rst), .ce_clk(ce_clk), .ce_rst(ce_rst), .i_tdata(ce_o_tdata[2]), .i_tlast(ce_o_tlast[2]), .i_tvalid(ce_o_tvalid[2]), .i_tready(ce_o_tready[2]), .o_tdata(ce_i_tdata[2]), .o_tlast(ce_i_tlast[2]), .o_tvalid(ce_i_tvalid[2]), .o_tready(ce_i_tready[2]), .debug(ce_debug[2])); noc_block_fosphor #(.MTU(12) /* Increase output FIFO size to smooth out bursts */) inst_noc_block_fosphor ( .bus_clk(bus_clk), .bus_rst(bus_rst), .ce_clk(ce_clk), .ce_rst(ce_rst), .i_tdata(ce_o_tdata[3]), .i_tlast(ce_o_tlast[3]), .i_tvalid(ce_o_tvalid[3]), .i_tready(ce_o_tready[3]), .o_tdata(ce_i_tdata[3]), .o_tlast(ce_i_tlast[3]), .o_tvalid(ce_i_tvalid[3]), .o_tready(ce_i_tready[3]), .debug(ce_debug[3])); noc_block_axi_fifo_loopback inst_axi_fifo_loopback2 ( .bus_clk(bus_clk), .bus_rst(bus_rst), .ce_clk(ce_clk), .ce_rst(ce_rst), .i_tdata(ce_o_tdata[4]), .i_tlast(ce_o_tlast[4]), .i_tvalid(ce_o_tvalid[4]), .i_tready(ce_o_tready[4]), .o_tdata(ce_i_tdata[4]), .o_tlast(ce_i_tlast[4]), .o_tvalid(ce_i_tvalid[4]), .o_tready(ce_i_tready[4]), .debug(ce_debug[4])); noc_block_delay_fifo inst_noc_block_delay_fifo ( .bus_clk(bus_clk), .bus_rst(bus_rst), .ce_clk(ce_clk), .ce_rst(ce_rst), .i_tdata(ce_o_tdata[5]), .i_tlast(ce_o_tlast[5]), .i_tvalid(ce_o_tvalid[5]), .i_tready(ce_o_tready[5]), .o_tdata(ce_i_tdata[5]), .o_tlast(ce_i_tlast[5]), .o_tvalid(ce_i_tvalid[5]), .o_tready(ce_i_tready[5]), .debug(ce_debug[5])); Thank you again for all your help. I am very close to have my first custom block up and running and I appreciate you taking the time to help me. Sincerely, Adam Kurisko ________________________________ From: EJ Kreinar <ejkrei...@gmail.com> Sent: Wednesday, January 24, 2018 6:09:05 AM To: Martin Braun Cc: Adam Kurisko; USRP-users@lists.ettus.com Subject: Re: [USRP-users] [RFNoC] uhd_usrp_probe fails and throws uhd::lookup_error Hi Adam, Please copy/paste your rfnoc_ce_auto_inst.v In my experience, these errors are usually due to something wrong in this file. Probably causes are that NUM_CE != the actual number of CEs. Or that when you added a new CE, you didn't increment the index of the wires, so two blocks are on the same index. Or, if you've tried to instantiate a DDC with NUM_CHAN=1, but did not change the NOC_BLOCK_ID to reflect only one channel Of course, could be something else-- those are just the problems I've personally found (multiple times) that throw similar errors. EJ On Jan 23, 2018 6:18 PM, "Martin Braun via USRP-users" <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: On 01/23/2018 03:01 PM, Adam Kurisko wrote: > I am unsure if I had edited the property subtrees, however I decided to > fresh install UHD to see if that might fix the problem. I will let you > know if I experience similar errors. > > > In the mean time while it is installing, could you explain the process > for implementing the block using UHD without GNU Radio. > > > I have my block made and it simulates/synths/impls in Vivado. > > I changed the Makefile.srcs in ..lib/rfnoc to include my custom block. > > I changed rfnoc_ce_auto_inst.v in ..top/e300 to instantiate my block. > > I run 'make E310_RFNOC' to generate a bitstream. > > I then secure copy the generated bitstream into the correct images > directory on my board ...this all looks good... > > and finally run 'uhd_usrp_probe' with my custom .bit file. ...and this should now list your block. Does it? > Does all that seem correct or am I missing a vital step in there somewhere? > > I read in one of your slide shows that I may also need to create a .xml > file, but is this solely for GNU Radio or do I need to do this for UHD > as well? If you change nothing on the software side, your block will be listed as "Block_0". You need one XML for UHD and GNU Radio each (so 2 total if you want to use GNU Radio, but at least 1). You can start by literally hacking up an XML file and copying it into the XML directory, on the E310 it's under /usr/share/uhd/rfnoc/blocks/*.xml. Also check out our knowledge base articles on RFNoC block writing. Cheers, Martin _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180124/98eaa178/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ------------------------------ End of USRP-users Digest, Vol 89, Issue 21 ****************************************** _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
