[USRP-users] Updating OOT module to UHD4.7 - Error During Initialisation
Hi We are trying to update to UHD-4.7 from UHD-4.0 and have rebuilt an out-of-tree NOC block that works ok in UHD-4.0. I am looking for some hints to try and resolve this.  > > > > Power off and on does not seem to get as clean result as when I issue > > this reset. > > > > thanks, > > > > Marino > > > > > There's not a lot of info on this utility, and it isn't officially > supported, although we've recommended its use in the past. > > Most of the R&D crew at Ettus/NI/Emerson are at the Gnu Radio conference > this week, but I've reached out to someone >in our support org who might know. > > > > > > > > ___ > > USRP-users mailing list -- usrp-users@lists.ettus.com > > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] x300 reset script
Hi all, I am using this the x300_reset.py script to reset the FPGA and would like to know a bit more about what is it resetting etc. (https://github.com/EttusResearch/uhd/blob/UHD-4.0/host/utils/x300_reset.py) Power off and on does not seem to get as clean result as when I issue this reset. thanks, Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Updating OOT module to UHD4.7 - Error During Initialisation
Hi Martin, Thank you for your reply. Understood. We are making some changes and will get back to you. kind regards, Marino On Wed, 6 Nov 2024 at 09:17, Martin Braun wrote: > Sorry if unclear, I meant hard to debug just by looking at this screenshot. > > --M > > On Wed, Nov 6, 2024 at 10:17 AM Martin Braun > wrote: > >> Hey Marino, >> >> sorry, this is really hard to debug. I recommend adding lots of logging >> output in your block controller, starting with the top of the constructor. >> You can also recompile UHD to run with TRACE level logs enabled, and post >> another screenshot of that here, maybe that'll help us narrow it down. >> >> --M >> >> On Tue, Oct 22, 2024 at 7:42 PM wrote: >> >>> Hi >>> >>> We are trying to update to UHD-4.7 from UHD-4.0 and have rebuilt an >>> out-of-tree NOC block that works ok in UHD-4.0. >>> >>> I am looking for some hints to try and resolve this. >>> >>> >>> Thanks >>> >>> Marino >>> >>> >>> ___ >>> USRP-users mailing list -- usrp-users@lists.ettus.com >>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>> >> ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] UHD 4.0 - Reading FPGA core temperature - USRP2974
Hi All I would like to read the FPGA core temperature of the Kintex within the USRP2974, and any other temperature sensor available, ideally on the RF boards. Is there an API for this? thanks marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: UHD 4.0 - Reading FPGA core temperature - USRP2974
Thanks Marcus. I could not find any temperature sensors :( On Thu, 15 Jun 2023 at 14:33, Marcus D. Leech wrote: > On 15/06/2023 06:31, cyberphox wrote: > > Hi All > > > > I would like to read the FPGA core temperature of the Kintex within > > the USRP2974, and any other temperature sensor available, ideally on > > the RF boards. > > > > > > Is there an API for this? > > > > thanks > > marino > You can use the "usrp_list_sensors" examples app to list all the sensors > that are available to the API -- and look at the code >to see how it uses the sensors API. > > > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: UHD 4.0 - Reading FPGA core temperature - USRP2974
Many thanks for your quick reply Wade! All the best Marino On Wed, 21 Jun 2023 at 16:44, Wade Fife wrote: > Hi Marino, > > The register is there, but it sounds like we don't expose it through the > API. This utility is out of date, but it can still be used to read the > temperature value: > > ~/uhd/firmware/usrp3/x300$ python2 x300_debug.py --addr=192.168.10.2 > --peek=0xA02C > > In that command, 192.168.10.2 is the IP address for the USRP's SFP port > and 0xA02C is the address of the temperature register. That will return the > raw ADC code from the XADC. To convert that to a temperature, use this > equation: > > Temperature(°C) = XADC_Code * 503.975 / 4096 - 273.15 > > Thanks, > > Wade > > > On Wed, Jun 21, 2023 at 7:45 AM cyberphox wrote: > >> Thanks Marcus. I could not find any temperature sensors :( >> >> >> On Thu, 15 Jun 2023 at 14:33, Marcus D. Leech >> wrote: >> >>> On 15/06/2023 06:31, cyberphox wrote: >>> > Hi All >>> > >>> > I would like to read the FPGA core temperature of the Kintex within >>> > the USRP2974, and any other temperature sensor available, ideally on >>> > the RF boards. >>> > >>> > >>> > Is there an API for this? >>> > >>> > thanks >>> > marino >>> You can use the "usrp_list_sensors" examples app to list all the sensors >>> that are available to the API -- and look at the code >>>to see how it uses the sensors API. >>> >>> >>> ___ >>> USRP-users mailing list -- usrp-users@lists.ettus.com >>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>> >> ___ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] USRP-2974 | Unable to program FPGA using image loader
Hi all, I have a USRP where I have a problem accessing the FPGA to program it. Normally we use image loader like so: uhd_image_loader --args="type=x300,addr=192.168.40.2" --fpga-path="AnFpgaImage.bit" If I bring up enp1s0f0 like so: sudo ifconfig enp1s0f0 192.168.40.1 netmask 255.255.255.0 Once enp1s0f0 is up, I still am not able to ping 192.168.40.2, which probably explains why the image loader has a problem, in fact so does the usrp probe tool. Normally all i need is to get enp1s0f0 showing up with IFCONFIG [image: image.png] thanks marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: USRP-2974 | Unable to program FPGA using image loader
Hi Marcus, We are doing this from the embedded host PC, not from the 10G connection externally Thank you On Thu, 13 Jul 2023 at 19:17, Marcus D. Leech wrote: > On 13/07/2023 13:20, cyberphox wrote: > > Hi all, > > I have a USRP where I have a problem accessing the FPGA to program it. > Normally we use image loader like so: > uhd_image_loader --args="type=x300,addr=192.168.40.2" > --fpga-path="AnFpgaImage.bit" > > If I bring up enp1s0f0 like so: > > sudo ifconfig enp1s0f0 192.168.40.1 netmask 255.255.255.0 > > > Once enp1s0f0 is up, I still am not able to ping 192.168.40.2, which > probably explains why the image loader has a problem, in fact so does the > usrp probe tool. Normally all i need is to get enp1s0f0 showing up with > IFCONFIG > > [image: image.png] > > thanks > marino > > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > > To clarify, are you doing this from your own host, over the 10G interface, > or from the embedded X86 host that's part of the > 2974? > > > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] FPGA bit file binary differences with GIT commit (X300)
Hi all, We have built our own RFNOC block and are trying to do a clean build and compare the generated bit file against the original files from the FPGA developer. I would like to know if the bitfile generated has some dependency with the GIT commit in some way. Basically if I take the file changes from my colleague and build the FPGA starting from the same reference branch, create my own working branch off this and copy them in, build the FPGA I get the same bitfile binary with only the date/time stamp difference. Once I commit the changes and then build it once again, the bitfile has a lot of differences. Thanks for taking time to read this. All the best marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Building custom NOC block
Hi All, I have recently taken the plunge and updated from UHD 4.0 to UHD 4.7 and have encountered an error when trying to build the FPGA with a custom NOC block. This is what I get right after issuing the build command: Traceback (most recent call last): File "/usr/local/bin/rfnoc_image_builder", line 58, in from uhd.imgbuilder import grc ImportError: cannot import name 'grc' from 'uhd.imgbuilder' (/usr/local/lib/python3/dist-packages/uhd/imgbuilder/__init__.py) Thanks marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Fwd: UHD 4.7 - Building X310_XG FPGA
Hi All, I have a clone of UHD 4.7 (Tags: v4.7.0.0) and am trying to build the default X310_XG FPGA to check if my setup is OK. I ran the following commands from /uhd/fpga/usrp3/top/x300 source ./setupenv.sh rfnoc_image_builder -y x310_XG_rfnoc_image_core.yml -t X310_XG After some time I get this error: BUILDER: Adding IP: /home/gssltest/git/uhd/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/axi_fft/axi_fft.xci BUILDER: Adding IP: /home/gssltest/git/uhd/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/axi_hb31/axi_hb31.xci ERROR: [Common 17-107] Cannot change read-only property 'generate_synth_checkpoint'. Resolution: Please refer to Vivado Properties Reference Guide (UG912) for more information on setting properties. INFO: [Common 17-206] Exiting Vivado at Fri Jul 19 12:38:28 2024... Thanks for your help Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Building rfnoc-example FPGA - UHD 4.7
Hi All, Is there an example on how to build the rfnoc-example in UHD 4.7 using the rfnoc_image_builder utility? Thanks, Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Fwd: UHD 4.7 - Building X310_XG FPGA
Thanks for your reply. I resolved it once I updated Vivado with the patch from Xilinx/AMD https://support.xilinx.com/s/article/76780?language=en_US ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Building rfnoc-example FPGA - UHD 4.7
Further to my last message: After reading this: https://lists.ettus.com/empathy/thread/FZYNEWJQYBKFJWC5LASSD5LOL6J765KU?hash=5JXCSAWOZJ6UEOSK3IPXZCIVS277B2SF#5JXCSAWOZJ6UEOSK3IPXZCIVS277B2SF I tried this: ``` export UHD_FPGA_DIR=~/git/uhd/fpga/ ``` ``` export RFNOC_OOT=~/git/uhd/host/examples/rfnoc-example ``` ``` cd fpga/usrp3/top/x300/ ``` ``` source setupenv.sh ``` ``` rfnoc_image_builder -F $UHD_FPGA_DIR -I $RFNOC_OOT -y $RFNOC_OOT/icores/x310_rfnoc_image_core.yml -t X310_XG -l DEBUG ``` `gssltest@gssltest-sff:~/git/uhd/fpga/usrp3/top/x300$ rfnoc_image_builder -F $UHD_FPGA_DIR -I $RFNOC_OOT -y $RFNOC_OOT/icores/x310_rfnoc_image_core.yml -t X310_XG -l DEBUG` `[debug] Loading configuration /home/gssltest/git/uhd/host/examples/rfnoc-example/icores/x310_rfnoc_image_core.yml...` `[debug] Configuration successful loaded.` `[debug] Validating against schema rfnoc_imagebuilder_args...` `[debug] Using schema file /usr/local/share/uhd/rfnoc/core/rfnoc_imagebuilder_args.json.` `[debug] Configuration successful validated.` `Using FPGA directory /home/gssltest/git/uhd/fpga` `Selected device: x310` `[debug] Image core name: x310_rfnoc_image_core` `[debug] Using build artifacts directory: /home/gssltest/git/uhd/host/examples/rfnoc-example/icores/build-x310_rfnoc_image_core` `Build artifacts directory already exists (contents will be overwritten).` `[debug] Looking for block descriptors in:` `[debug] /usr/local/share/uhd/rfnoc/blocks` `[debug] /home/gssltest/git/uhd/host/examples/rfnoc-example/blocks` `[debug] Adding file siggen.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file radio.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file axi_ram_fifo.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file null_src_sink.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file logpwr.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file fosphor.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file fft_1x64.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file replay.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file addsub.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file license_check.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file fir_filter.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file split_stream.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file duc.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file window.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file ddc.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file siggen_sff.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file switchboard.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file moving_avg.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file vector_iir.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file keep_one_in_n.yml (/usr/local/share/uhd/rfnoc/blocks).` `[debug] Adding file gain.yml (/home/gssltest/git/uhd/host/examples/rfnoc-example/blocks).` `[debug] Looking for module descriptors in:` `[debug] /usr/local/share/uhd/rfnoc/modules` `[debug] /home/gssltest/git/uhd/host/examples/rfnoc-example/modules` `[debug] Adding file device_dna.yml (/usr/local/share/uhd/rfnoc/modules).` `[debug] Looking for transport_adapter descriptors in:` `[debug] /usr/local/share/uhd/rfnoc/transport_adapters` `[debug] /home/gssltest/git/uhd/host/examples/rfnoc-example/transport_adapters` `[debug] Adding file x4xx_eth.yml (/usr/local/share/uhd/rfnoc/transport_adapters).` `[debug] Adding file chdr_dma.yml (/usr/local/share/uhd/rfnoc/transport_adapters).` `[debug] Looking for include descriptors in:` `[debug] /usr/local/share/uhd/rfnoc/includes` `[debug] /home/gssltest/git/uhd/host/examples/rfnoc-example/includes` `[debug] Using io_signatures.yml from /usr/local/share/uhd/rfnoc/core.` `[debug] Loaded 9 IO signatures` `[debug]ctrlport [core]` `[debug]timekeeper [core]` `[debug]radio [core]` `[debug]axi4_mm [core]` `[debug]axis_chdr [core]` `[debug]pps [core]` `[debug]device_dna [device_dna.yml]` `[debug]x4xx_qsfp [x4xx_eth.yml]` `[debug]license_enable [license_check.yml]` `[debug] Using x310_bsp.yml from /usr/local/share/uhd/rfnoc/core.` `[debug] Populating config with default secure core.` `[debug] Assigning clock index 11 to clock _device_.radio.` `[debug] Assigning clock index 12 to clock _device_.ce.` `[debug] Assigning clock index 13 to clock _device_.dram.` `[debug] Adding required clock not present in BSP: rfnoc_ctrl` `[debug] Adding required clock not present in BSP: rfnoc_chdr` `⚠ Block port radio0.in_1 is not connected` `⚠ Block port radio1.in_1 is not connected` `[debug] Generating edge table...` `[debug] ep0-out0 (1,0) => duc0-in_0 (6,0)` `[debug] duc0-out_0 (6,0) => ra
[USRP-users] Re: Building rfnoc-example FPGA - UHD 4.7
Hi Martin, I tried that switch and was a bit worried that. Thanks for confirming it is OK for the time being. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Building Dissector
Hi All, I would like to try use the dissector with Wireshark and have run into some hassle building it, see error below. thank you, Marino ``` Scanning dependencies of target rfnoc64 ``` ``` [ 14%] Building C object epan/rfnoc/CMakeFiles/rfnoc64.dir/plugin.c.o ``` ``` [ 28%] Building CXX object epan/rfnoc/CMakeFiles/rfnoc64.dir/packet-rfnoc.cpp.o ``` ``` [ 42%] Building CXX object epan/rfnoc/CMakeFiles/rfnoc64.dir/home/gssltest/git/uhd/host/lib/exception.cpp.o ``` ``` [ 57%] Building CXX object epan/rfnoc/CMakeFiles/rfnoc64.dir/home/gssltest/git/uhd/host/lib/rfnoc/chdr_types.cpp.o ``` ``` [ 71%] Building CXX object epan/rfnoc/CMakeFiles/rfnoc64.dir/home/gssltest/git/uhd/host/lib/rfnoc/chdr_packet_writer.cpp.o ``` ``` make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libgcrypt.so', needed by 'epan/rfnoc/epan/rfnoc64.so'. Stop. ``` ``` make[1]: *** [CMakeFiles/Makefile2:94: epan/rfnoc/CMakeFiles/rfnoc64.dir/all] Error 2 ``` ``` make: *** [Makefile:130: all] Error 2 ``` ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Building Dissector
Just needed to do this: ``` sudo apt install libgnutls28-dev ``` ``` sudo apt install libgcrypt-dev ``` ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Is it OK to build with DPDK but not use the feature
Hi We have a OOT RFNOC project and have built the UHD framework with DPDK installed but we don’t use DPDK. Is there any side-effect in doing so? Would it be better to not have the DPDK libs installed at all? Thank you, Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: X310 Image Flashing Problem: "Error: RuntimeError: Device reported an error during initialization."
Please ignore my last post, Unfortunately there is no way to delete it. Basically I was remotely accessing the wrong USRP, the one with the above error has a hardware issue. This is why the loader is not working. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: X310 Image Flashing Problem: "Error: RuntimeError: Device reported an error during initialization."
Hi I am having the same problem using UHD 4.7 on a USRP-2974. Note I have also used the JTAG recovery method to be sure, this works fine. uhd_usrp_probe loads ok too. But when I use uhd_image_loader then there is a problem ``` uhd_image_loader --args="type=x300,addr=192.168.40.2" --fpga-path="x300_final.570080.bit" ``` ``` [INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.7.0.HEAD-0-a5ed1872 ``` ``` Unit: USRP NI-2974 (31D28CA, 192.168.40.2) ``` ``` FPGA Image: /mnt/spirent/posapp/share/posapp/bitfiles/x300_final.570080.bit ``` ``` failed. ``` ``` Error: RuntimeError: Device reported an error during initialization. Below is the output from reading the MB eeprom: Fetching current settings from EEPROM... EEPROM ["revision"] is "12" EEPROM ["revision_compat"] is "7" EEPROM ["product"] is "31131" EEPROM ["mac-addr0"] is "00:80:2f:30:7b:5d" EEPROM ["mac-addr1"] is "00:80:2f:30:7b:5e" EEPROM ["gateway"] is "192.168.10.1" EEPROM ["ip-addr0"] is "192.168.10.2" EEPROM ["subnet0"] is "255.255.255.0" EEPROM ["ip-addr1"] is "192.168.20.2" EEPROM ["subnet1"] is "255.255.255.0" EEPROM ["ip-addr2"] is "192.168.30.2" EEPROM ["subnet2"] is "255.255.255.0" EEPROM ["ip-addr3"] is "192.168.40.2" EEPROM ["subnet3"] is "255.255.255.0" EEPROM ["serial"] is "31D28CA" EEPROM ["name"] is "98AC10626140838F" Done ``` ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] How to check RFNOC is already in use
Hi I have a bit of code that finds an OOT module, eg. auto siggen_blocks = graph->find_blocks___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Sample alignment between 2x UBX160 using USRP-2794
Hi Ettus We are having a real challenge trying to align two identical streams feeding the ubx160 on a usrp-2974. It is a problem we have had for a long time. The data entering the axi bus is aligned but at the output it can be misaligned by 5 to 15ns or so. Is it possible to completely bypass this bus and feed the DACs directly? FYI, We have tried this but other stuff doesn’t function quite right, as you may expect. It was just to experiment. Definitely somewhere between we get misaligned. Any tips would be appreciated thank you for your help Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Is it OK to build with DPDK but not use the feature
Hi Marcus, Thank you for your quick response. best regards M. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Reading/Write registers - Timeout
Hi All, Is there a mechanism to set a timeout when reading or writing registers for a OOT NOC block? Thanks, Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
If I am calling poke32 or peek32 without setting the time and ack arguments (just sending the address and data), where they default to: ``` uhd::time_spec_t time = uhd::time_spec_t::ASAP ``` and ``` bool ack = false ``` Would you expect the timeout exceptions to occur? In the code comment it says if ACK is requested. Is there a way to check the fifo status? Also, is there an example that shows the use of the timespan and ack with poke32/peek32? Thank you Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Hi Martin I am still trying to investigate this issue, recreating it is difficult as it can take long time. However, on a system that crashed I observed a thread “uhd_ctrl_ep0001” specifically its CPU utilisation (I have isolated this to use a single CPU and not share it). Normally it is below \~20%, (when first starting our application is is < 10%) once there is a failure (as per the discussion here), this thread has a higher utilisation (not 100%), around 30-40%. When kill our process, and restart, the CPU utilisation is still high from the start. The only way to recover is to power off the USRP-2974 and on again. Kind regards Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Hi David,
At the start where we initialise our siggen block there this snippet of code:
---
```
std::cout << "MB Clock Source: " <<
graph->get_mb_controller(0)->get_clock_source() << std::endl;
```
```
std::cout << "MB Time Source: " <<
graph->get_mb_controller(0)->get_time_source() << std::endl;
```
```
std::cout << "MB Sync Source: " <<
graph->get_mb_controller(0)->get_sync_source().to_pp_string() << std::endl;
```
```
std::cout << "MB Ref lock status: " <<
graph->get_mb_controller(0)->get_sensor("ref_locked").to_pp_string() <<
std::endl;
```
```
std::cout <<
graph->get_mb_controller(0)->get_sensor("gps_locked").to_pp_string() <<
std::endl;
```
```
// Initialise the USRP time to zero on the next 1 PPS
```
```
graph->get_mb_controller(0)->get_timekeeper(0)->set_time_next_pps(uhd::time_spec_t(0.0));
```
```
// Call this to synchronise all the RFNoC devices (needed for phase alignment?)
```
```
bool synchronised = graph->synchronize_devices(uhd::time_spec_t(2.0), false);
```
---
Then when setting up the PLL's, to try and get phase coherence.
---
```
const uhd::time_spec_t lastPPS =
linux_uhd::get_graph()->get_mb_controller(0)->get_timekeeper(0)->get_time_last_pps();
const uhd::time_spec_t now =
linux_uhd::get_graph()->get_mb_controller(0)->get_timekeeper(0)->get_time_now();
const uhd::time_spec_t span = uhd::time_spec_t(1.0);
// Specify that the tune should occur aligned with the next 1 PPS
const uhd::time_spec_t command_time = (lastPPS + span);
// Clear any previous timed commands
radio_ctrl[radio_id]->clear_command_time(0);
// Set the time for the LO tune to occur
radio_ctrl[radio_id]->set_command_time(command_time, 0);
// Set the LO frequency in Hz
actual_lo_frequency = radio_ctrl[radio_id]->set_tx_frequency(
```
---
I am not sure if this could affect the peek and pokes
thank you
Marino
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Thanks for your reply. To answer your last question and give you some context. The ability to monitor FIFO status would be for debug purpose. The application we have that is interfacing to a custom RFNOC block via UHD can get are stuck (randomly over some period of time) and I am trying to find out if we are getting stuck in UHD layers or if something is happening at our end. We do have a try catch to handle “op_timeout” (and std::exception) when using peek32 and poke32. I have not seen this get trapped. Many thanks for your help ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Hi Martin,
I don’t fully understand you comment about it not being the block controller.
(bear with as I am not super experienced)
At the moment I have not trapped a timeout exception just yet (see snippet
below). It could well be somewhere else in the application as you say.
---
```
try
```
```
{
```
```
lock_mutex();
```
```
// Write to the calculated address
```
```
siggen_block->regs().poke32(address, data->data[0]);
```
```
unlock_mutex();
```
```
lnx_uhd_status = true;
```
```
}
```
```
catch(const uhd::op_timeout& e)
```
```
{
```
```
std::cerr << "Write exception: " << e.what() << '\n';
```
```
}
```
```
catch(const std::exception& e)
```
```
{
```
```
std::cerr << "Write exception: " << e.what() << '\n';
```
```
unlock_mutex();
```
```
}
```
---
If you don’t mind, regarding David’s email above (points 2 and 3) could you
comment on these
For point 2. this makes sense to me, would you also recommend the same?
for point 3. After setting up the LO, I am checking the lock flags in a loop
with a time-out, after which I clear the command time:-
radio_ctrl\[radio_id\]->clear_command_time(0);
Thank you for your time.
cheers,
Marino
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Thank you for your help David. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Hi Martin Thank your for your reply. This is a software question, related to register peek and poke. For example, if a register read (via ctrlport_endpoint_impl::peek32) is performed, is there a chance that the software can block (or get stuck)? Note: I am using UHD-4.7 kind regards, Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Hi Martin, If there is any other suggestion for me to try please let me know, I am not really sure what to do next. Cheers, Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Hi Martin, If it is stuck here should it not timeout (either massive @10s the default @ 1s) ? thanks Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Hi Martin, I am not able to provide the test code, likely need to do this via NI/Emmerson partner contacts. Thanks for your help so far. Kind regards Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
HI Martin I have tried setting this to 100us but it has a detrimental effect on our application and it fails over. Perhaps I will try lower time delays and see what happens. Thank you. Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Reading/Write registers - Timeout
Thank you Martin, that issue looks interesting and useful. I will certainly try the modification out and keep you posted. all the best Marino ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Dual boot USRP (Ubuntu & NI Linux)
I would like to know if it is possible to dual boot NI Linux with Ubuntu. I have tried it but have not been very successful. Ubuntu detects NI Linux but does not successfully configure the GRUB menu. Thanks Marino ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] UBX160 TX "noise figure"?
Hi Lukas, What setting do you have the digital attenuator set to? Kind regards Marino On Mon, 7 Dec 2020 at 02:05, Lukas Haase via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Marcus, > > Thanks again! > > I did now the following experiment: I connected TX to RX back-to-back with > 46.43dB attenuation in between. I set TX gain and RX gain to 20dB and > transmit a single CW at -3dBFS. > This means my output power is *Pout=11.44dBm* (cross checked with > spectrum analyzer) and on RX I sould have Pin=-34.99dBm. Indeed, > calculating the RMS of the received signal and converting to dBm, I get > *Pin=-35.0224dBm*. Spot on! > > The red line is what I receive on the PSD (blue is the TX that I send): > > > As you can see from the annotation, the measured "SNR" of the received > signal is only 38.7dB. I think this is mainly caused by the phase noise > skirt (and potentially the I/Q image). > In order to keep only consider thermal noise, I add random noise to the > original CW (using randn(...)+1i*randn(...) in MATLAB) until it matches > roughly the white noise floor of the received signal. It's > *SNRoutput=50dB* (yellow line). > > Now, according to our discussion below, at Gtx=20, we should have > *SNRoutput=72dB* (assuming thermal noise only). > > Where could the *22dB difference* in SNR come from? > > Thanks! > Lukas > > > PS: I am aware of phase noise, DC offsets, I/Q imbalance etc. But as you > can see from my plot, I am *only *considerung thermal noise. The thermal > noise of the receiver should be orders of magnitude lower (at least > -102dBm) so the receiver noise should not limit the results either. > > > *Gesendet:* Montag, 30. November 2020 um 17:08 Uhr > *Von:* "Marcus D. Leech" > > *An:* "Lukas Haase" > *Cc:* USRP-users@lists.ettus.com > *Betreff:* Re: [USRP-users] UBX160 TX "noise figure"? > On 11/30/2020 01:54 PM, Lukas Haase wrote: > > Hi Marcus, > > That makes sense, thanks. > > Would you be willing to confirm if what I am doing here is correct? > > > To first order, the DAC has an SNR of 98dB (16 bit). Then I use Fries' > equation to get the NF of the following stages (for the filter and the > attenuator, the noise figure is equal to its attenuation). The NF is > dominated by the 2nd and third term. > Then I subtract the NF from the SNR which gives me an output SNR somewhere > between 92dB and 67dB. Does that sound right? > > > > > For the attenuator term, just assign it a NF (in dB) of (31.5 - TXGAIN). > > The noise figure of an attenuator is just the attenuation value--similarly > for the filter. Just pretend it's a fixed attenuator with 0 gain. > > So the 'noise figure' after the DAC is just 2+(31.5 - TXGAIN) then factor > in the gains and noise figures of the amplifiers. > > > > ___ > 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
