[USRP-users] Maintaining USRP Carrier Frequency Lock
Hello, I am trying to collect serveral data sets through USRP X300's. Assume each collection is 1000 samples long and is initiated by a user typing a button on the keyboard. Each time the user hits a key 1000 samples are collected and stored to a file. The time between each collect is defined by the user hitting the key. I need to make sure the USRPs are not loosing carrier lock between these collections. I want the USRPs to stay locked to whatever center frequency is set and sit there for the length of the time the user wants to collect data sets. What is the best way to ensure this? For example, if I use GNU Radio and head blocks feeding into file sinks with calls to tb.start and tb.stop, does the call to tb.stop cause the USRP to forget the carrier it was locked to and start over again on the next call to tb.start? Can I call tb.start multiple times without a call to tb.stop? Thank for any help you can provide. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Maintaining USRP Carrier Frequency Lock
On 01/30/2020 01:35 PM, Richard Bell via USRP-users wrote: Hello, I am trying to collect serveral data sets through USRP X300's. Assume each collection is 1000 samples long and is initiated by a user typing a button on the keyboard. Each time the user hits a key 1000 samples are collected and stored to a file. The time between each collect is defined by the user hitting the key. I need to make sure the USRPs are not loosing carrier lock between these collections. I want the USRPs to stay locked to whatever center frequency is set and sit there for the length of the time the user wants to collect data sets. What is the best way to ensure this? For example, if I use GNU Radio and head blocks feeding into file sinks with calls to tb.start and tb.stop, does the call to tb.stop cause the USRP to forget the carrier it was locked to and start over again on the next call to tb.start? Can I call tb.start multiple times without a call to tb.stop? Thank for any help you can provide. I think this will likely work, although I think it depends on how much "device init" is done on flow-graph start. I think a lot of it is done when the device is instantiated, and whatever happens at FG start is device-dependent. You'll have to test this in your environment. You might also chose another architecture for your software to remove the possibility of device re-init. You can for example just stream forever, and only pay attention to the samples you want to pay attention to. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Default RFNoC image for N310 does not compile
Hi Nate, I encountered the "Conflicting VCC voltages in bank 32" error while trying to build an N310 XG RFNOC image on v3.15.0.0 and noticed your user's list email below which indicated that Vivado 2018.3 requires patch AR71898 in order to overcome a bug causing this error. However, after installing the patch I am still getting the error. Perhaps the patch is not installed correctly, but the build log file (see snippets below) seems to indicate that it is. The second line in the log file shows "# Vivado v2018.3_AR71898 (64-bit)" which to me indicates that it sees the patch. However, you will find the build error mentioned above toward the end of the log. Any ideas? Is there another way to determine if the patch is successfully installed? Rob #--- # Vivado v2018.3_AR71898 (64-bit) # SW Build 2405991 on Thu Dec 6 23:36:41 MST 2018 # IP Build 2404404 on Fri Dec 7 01:43:56 MST 2018 # Start of session at: Thu Jan 30 11:51:43 2020 # Process ID: 6739 # Current directory: /afs/ crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build-N310_RFNOC_XG # Command line: vivado -mode batch -source /afs/ crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build_n3xx.tcl -log build.log -journal n3xx.jou # Log file: /afs/ crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build-N310_RFNOC_XG/build.log # Journal file: /afs/ crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build-N310_RFNOC_XG/n3xx.jou #--- ... ... ... Attempting to get a license for feature 'Implementation' and/or device 'xc7z100' INFO: [Common 17-349] Got license for feature 'Implementation' and/or device 'xc7z100' INFO: [Common 17-1540] The version limit for your license is '2019.07' and has expired for new software. A version limit expiration means that, although you may be able to continue to use the current version of tools or IP with this license, you will not be eligible for any updates or new releases. INFO: [DRC 23-27] Running DRC with 8 threads INFO: [Vivado_Tcl 4-198] DRC finished with 0 Errors INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for more information. Running DRC as a precondition to command place_design INFO: [DRC 23-27] Running DRC with 8 threads ERROR: [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34. For example, the following two ports in this bank have conflicting VCCOs: ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15] (LVCMOS18, requiring VCCO=1.800) WARNING: [DRC CHECK-3] Report rule limit reached: REQP-1839 rule limit reached: 20 violations have been found. WARNING: [DRC CHECK-3] Report rule limit reached: REQP-1840 rule limit reached: 20 violations have been found. ... ... ... INFO: [Vivado_Tcl 4-198] DRC finished with 1 Errors, 52 Warnings INFO: [Vivado_Tcl 4-199] Please refer to the DRC report (report_drc) for more information. ERROR: [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run. INFO: [Common 17-83] Releasing license: Implementation 34 Infos, 63 Warnings, 0 Critical Warnings and 2 Errors encountered. place_design failed place_design: Time (s): cpu = 00:01:07 ; elapsed = 00:00:58 . Memory (MB): peak = 9161.891 ; gain = 0.000 ; free physical = 43703 ; free virtual = 93417 ERROR: [Common 17-39] 'place_design' failed due to earlier errors. while executing "place_design -directive $pla_dir" (procedure "vivado_strategies::implement_design" line 23) invoked from within "vivado_strategies::implement_design $n3xx_strategy" (file "/afs/ crc.nd.edu/user/r/rkossler/uhd/UHD-3.15.0.0/uhd/fpga-src/usrp3/top/n3xx/build_n3xx.tcl" line 28) INFO: [Common 17-206] Exiting Vivado at Thu Jan 30 12:40:04 2020... > > > On Mon, Dec 9, 2019 at 2:43 PM Nate Temple via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi Robert, >> >> So this is a bug related to Vivado, you will need to install this linked >> below patch and it should resolve it. >> >> https://www.xilinx.com/support/answers/71898.html >> >> Regards, >> Nate Temple >> >> On Mon, Dec 9, 2019 at 10:38 AM Nate Temple >> wrote: >> >>> Hi Robert, >>> >>> Thanks for the bug report. >>> >>> If you're just trying to use RFNoC at this point, I would recommend to >>> stick with the latest stable release, which at this time is v3.14.1.1. >>> >>> Note, 3.14.x.x UHD will require Vivado 2017.4. >>> >>> >>> Regards, >>> Nate Temple >>> >>> On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> Hi all! I tried to compile the default RFNoC image for the N310, using UHD on tag v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1. Running "make N310_RFNOC_XG", the IP cores are compiled successfully, but then Vivado shows the following errors: ERROR: [Synth 8-524] part-select [15:8] out of range of prefix 'STR_SINK_FIFOSIZE'
Re: [USRP-users] RFNOC_OOT_SRCS cleared in top/n3xx/Makefile.srcs
Whoa there, I havent updated any of my code to UHD-3.15 yet so you're a bit ahead of me! I usually make the relevant PRs if/when OOT build process breaks -- so I'd recommend sending over the relevant PR to fpga repo? Will probably help me a few months down the line :P Thanks! EJ On Wed, Jan 29, 2020 at 5:28 PM Andrew Payne via USRP-users < usrp-users@lists.ettus.com> wrote: > I had the same issues! I just ended up putting my verilog file paths in > Makefile.n3xx.inc and it works. This might need to be fixed unless I did > something wrong. > > On Wed, Jan 29, 2020 at 16:18 Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> I have been struggling all day with why I can't build my OOT rfnoc blocks >> for the N310 using v3.15.0.0. It appears that the problem is that there is >> a file top/n3xx/Makefile.srcs that is clearing the RFNOC_OOT_SRCS variable >> after it is set in the users OOT makefile. I just commented the line in >> top/n3xx/Makefile.srcs and that seems to do the trick. Is this a known >> issue? >> >> >> # Makefile.n3xx.inc >> ... >> include $(BASE_DIR)/n3xx/Makefile.OOT.inc >> include $(BASE_DIR)/n3xx/Makefile.srcs >> ... >> >> # Makefile.srcs >> RFNOC_OOT_SRCS = \ >> ___ >> 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
Re: [USRP-users] RFNOC_OOT_SRCS cleared in top/n3xx/Makefile.srcs
EJ, I don't quite understand your comments. I'm talking about Ettus code in the 3.15 release. Rob On Thu, Jan 30, 2020 at 3:57 PM EJ Kreinar wrote: > Whoa there, > > I havent updated any of my code to UHD-3.15 yet so you're a bit ahead of > me! I usually make the relevant PRs if/when OOT build process breaks -- so > I'd recommend sending over the relevant PR to fpga repo? Will probably help > me a few months down the line :P > > Thanks! > EJ > > On Wed, Jan 29, 2020 at 5:28 PM Andrew Payne via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> I had the same issues! I just ended up putting my verilog file paths in >> Makefile.n3xx.inc and it works. This might need to be fixed unless I did >> something wrong. >> >> On Wed, Jan 29, 2020 at 16:18 Rob Kossler via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> I have been struggling all day with why I can't build my OOT rfnoc >>> blocks for the N310 using v3.15.0.0. It appears that the problem is that >>> there is a file top/n3xx/Makefile.srcs that is clearing the RFNOC_OOT_SRCS >>> variable after it is set in the users OOT makefile. I just commented the >>> line in top/n3xx/Makefile.srcs and that seems to do the trick. Is this a >>> known issue? >>> >>> >>> # Makefile.n3xx.inc >>> ... >>> include $(BASE_DIR)/n3xx/Makefile.OOT.inc >>> include $(BASE_DIR)/n3xx/Makefile.srcs >>> ... >>> >>> # Makefile.srcs >>> RFNOC_OOT_SRCS = \ >>> ___ >>> 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
Re: [USRP-users] RFNOC_OOT_SRCS cleared in top/n3xx/Makefile.srcs
Ah -- It's fairly common for the "OOT.inc" builds to break between releases or when new devices are added, so I usually send in the PRs to clean it up. In this case, I havent tried 3.15 yet, so I wouldnt have found any issues with the OOT builds yet. EJ On Thu, Jan 30, 2020 at 4:03 PM Rob Kossler wrote: > EJ, > I don't quite understand your comments. I'm talking about Ettus code in > the 3.15 release. > Rob > > On Thu, Jan 30, 2020 at 3:57 PM EJ Kreinar wrote: > >> Whoa there, >> >> I havent updated any of my code to UHD-3.15 yet so you're a bit ahead of >> me! I usually make the relevant PRs if/when OOT build process breaks -- so >> I'd recommend sending over the relevant PR to fpga repo? Will probably help >> me a few months down the line :P >> >> Thanks! >> EJ >> >> On Wed, Jan 29, 2020 at 5:28 PM Andrew Payne via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> I had the same issues! I just ended up putting my verilog file paths in >>> Makefile.n3xx.inc and it works. This might need to be fixed unless I did >>> something wrong. >>> >>> On Wed, Jan 29, 2020 at 16:18 Rob Kossler via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> I have been struggling all day with why I can't build my OOT rfnoc blocks for the N310 using v3.15.0.0. It appears that the problem is that there is a file top/n3xx/Makefile.srcs that is clearing the RFNOC_OOT_SRCS variable after it is set in the users OOT makefile. I just commented the line in top/n3xx/Makefile.srcs and that seems to do the trick. Is this a known issue? # Makefile.n3xx.inc ... include $(BASE_DIR)/n3xx/Makefile.OOT.inc include $(BASE_DIR)/n3xx/Makefile.srcs ... # Makefile.srcs RFNOC_OOT_SRCS = \ ___ 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
Re: [USRP-users] RFNOC_OOT_SRCS cleared in top/n3xx/Makefile.srcs
Not to change the original intent of this question: 1. What’s the recommended combination (versions) of UHD and Gnuradio? 2. Do you recommend pybombs (I installed from source which was slightly painful but now that I got the dependencies should be smoother if I do it again). On Thu, Jan 30, 2020 at 15:57 EJ Kreinar wrote: > Whoa there, > > I havent updated any of my code to UHD-3.15 yet so you're a bit ahead of > me! I usually make the relevant PRs if/when OOT build process breaks -- so > I'd recommend sending over the relevant PR to fpga repo? Will probably help > me a few months down the line :P > > Thanks! > EJ > > On Wed, Jan 29, 2020 at 5:28 PM Andrew Payne via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> I had the same issues! I just ended up putting my verilog file paths in >> Makefile.n3xx.inc and it works. This might need to be fixed unless I did >> something wrong. >> >> On Wed, Jan 29, 2020 at 16:18 Rob Kossler via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> I have been struggling all day with why I can't build my OOT rfnoc >>> blocks for the N310 using v3.15.0.0. It appears that the problem is that >>> there is a file top/n3xx/Makefile.srcs that is clearing the RFNOC_OOT_SRCS >>> variable after it is set in the users OOT makefile. I just commented the >>> line in top/n3xx/Makefile.srcs and that seems to do the trick. Is this a >>> known issue? >>> >>> >>> # Makefile.n3xx.inc >>> ... >>> include $(BASE_DIR)/n3xx/Makefile.OOT.inc >>> include $(BASE_DIR)/n3xx/Makefile.srcs >>> ... >>> >>> # Makefile.srcs >>> RFNOC_OOT_SRCS = \ >>> ___ >>> 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
