[USRP-users] Use both RFNoC API and multi_usrp API
Hi USRP users, I am developing a RFNoC block. And for some reasons, I need to use both RFNoC API and multi_usrp API in the application. But I am confused whether we can use these two APIs within one application. For example, the application streams data to RFNoC block for IQ processing and streams back to the host. Then it uses multi_usrp API for RF. If it’s possible, I suppose we have to create both rfnoc graph and usrp object for the same device and also different tx/rx streamer objects for different API. Can anyone give me some advice? Thank you in advance. Arman ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] USRP X410 + QSFP28 network adapter from intel
Hello, Has anybody tried to use QSFP28 network adapter from intel with USRP X410 and not Mellanox/Nvidia that is sold by NI for use with X410? Intel cards have some advantages over Mellanox. One of them is configurability of the QSFP28 port to act as four SFP+ or SFP28 ports. But I didn’t see any reports how these cards behave together with X410. Therefore if anybody tried to use intel card + X410, I would be grateful to hear how this combination worked. Best Regards,\ Piotr Krysik ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: benchmark_rate throws error
Hello, I still run into the same issue, even after I have changed to parameters. `/usr/local/lib/uhd/examples/benchmark_rate --args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=200e6" --duration 60--channels 0--rx_rate 31.25e6--rx_subdev "A:0" --tx_rate 31.25e6--tx_subdev "A:0"` And the error is here `[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.3.0.HEAD-0-g1f8fd345` `[00:00:00.000229] Creating the usrp device with: type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=200e6...` `[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n320,serial=3255102,name=ni-n3xx-3255102,fpga=XG,claimed=False,addr=192.168.10.2,master_clock_rate=200e6` `` [INFO] [MPM.PeriphManager] init() called with device args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal'. `` `[ERROR] [RFNOC::GRAPH] IO Error during GSM initialization. EnvironmentError: IOError: Timed out getting recv buff for management transaction` `[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: EnvironmentError: IOError: Timed out getting recv buff for management transaction` `` [INFO] [MPM.Rhodium-0] init() called with args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal' `` `` [INFO] [MPM.Rhodium-1] init() called with args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal' `` `Error: RuntimeError: Failure to create rfnoc_graph.` ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: benchmark_rate throws error
On 20/02/2023 11:38, jmalo...@umass.edu wrote: Hello, I still run into the same issue, even after I have changed to parameters. |/usr/local/lib/uhd/examples/benchmark_rate --args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=200e6" --duration 60 --channels 0 --rx_rate 31.25e6 --rx_subdev "A:0" --tx_rate 31.25e6 --tx_subdev "A:0"| And the error is here |[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.3.0.HEAD-0-g1f8fd345| |[00:00:00.000229] Creating the usrp device with: type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=200e6...| |[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n320,serial=3255102,name=ni-n3xx-3255102,fpga=XG,claimed=False,addr=192.168.10.2,master_clock_rate=200e6| |[INFO] [MPM.PeriphManager] init() called with device args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal'.| |[ERROR] [RFNOC::GRAPH] IO Error during GSM initialization. EnvironmentError: IOError: Timed out getting recv buff for management transaction| |[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: EnvironmentError: IOError: Timed out getting recv buff for management transaction| |[INFO] [MPM.Rhodium-0] init() called with args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal'| |[INFO] [MPM.Rhodium-1] init() called with args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal'| |Error: RuntimeError: Failure to create rfnoc_graph.| |H, I'm not sure then. I don't have an N320 myself. I'll have to dig around a little. Also, just as an FYI, and not related to this error, your sample rate has to have an integer relationship to the master clock rate. 31.25 does not evenly divide 200 |___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: benchmark_rate throws error
On 20/02/2023 11:38, jmalo...@umass.edu wrote: Hello, I still run into the same issue, even after I have changed to parameters. |/usr/local/lib/uhd/examples/benchmark_rate --args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=200e6" --duration 60 --channels 0 --rx_rate 31.25e6 --rx_subdev "A:0" --tx_rate 31.25e6 --tx_subdev "A:0"| And the error is here |[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.3.0.HEAD-0-g1f8fd345| |[00:00:00.000229] Creating the usrp device with: type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=200e6...| |[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n320,serial=3255102,name=ni-n3xx-3255102,fpga=XG,claimed=False,addr=192.168.10.2,master_clock_rate=200e6| |[INFO] [MPM.PeriphManager] init() called with device args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal'.| |[ERROR] [RFNOC::GRAPH] IO Error during GSM initialization. EnvironmentError: IOError: Timed out getting recv buff for management transaction| |[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph: EnvironmentError: IOError: Timed out getting recv buff for management transaction| |[INFO] [MPM.Rhodium-0] init() called with args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal'| |[INFO] [MPM.Rhodium-1] init() called with args `fpga=XG,master_clock_rate=200e6,mgmt_addr=192.168.1.151,name=ni-n3xx-3255102,product=n320,clock_source=internal,time_source=internal'| |Error: RuntimeError: Failure to create rfnoc_graph.| ___ USRP-users mailing list --usrp-users@lists.ettus.com To unsubscribe send an email tousrp-users-le...@lists.ettus.com Do you have a compatible system image on the N320--a UHD 4.3 image? ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: benchmark_rate throws error
I believe so. When I use uhd_usrp_probe, I get `[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.3.0.HEAD-0-g1f8fd345` `[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n320,serial=3255102,name=ni-n3xx-3255102,fpga=XG,claimed=False,addr=192.168.1.151` I am currently using the default XG image, and not my own. I can recieve samples, however, it seems to be at a limited rate. When I use rx_samples_to_file with a high rate, i will get an overflow with a seemingly lower rate than what the board should be capable of. `Press Ctrl + C to stop streaming...` `OGot an overflow indication. Please consider the following:` ` Your write medium must sustain a rate of 39.321600MB/s.` ` Dropped samples will not be written to the file.` ` Please modify this example for your purposes.` ` This message will not appear again.` `^C` `Done!` ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: benchmark_rate throws error
On 20/02/2023 12:21, jmalo...@umass.edu wrote: I believe so. When I use uhd_usrp_probe, I get |[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.3.0.HEAD-0-g1f8fd345| |[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n320,serial=3255102,name=ni-n3xx-3255102,fpga=XG,claimed=False,addr=192.168.1.151| I am currently using the default XG image, and not my own. I can recieve samples, however, it seems to be at a limited rate. When I use rx_samples_to_file with a high rate, i will get an overflow with a seemingly lower rate than what the board should be capable of. |Press Ctrl + C to stop streaming...| |OGot an overflow indication. Please consider the following:| |Your write medium must sustain a rate of 39.321600MB/s.| |Dropped samples will not be written to the file.| |Please modify this example for your purposes.| |This message will not appear again.| |^C| |Done!| ___ USRP-users mailing list --usrp-users@lists.ettus.com To unsubscribe send an email tousrp-users-le...@lists.ettus.com What the board is capable of, and what your computer/kernel/filesystem-code/disk-drives can sustain are two very different things. I like to use a (weak, I know) metaphor. "Niagara Falls cares little about what size of bucket you're trying to catch it in." ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: benchmark_rate throws error
With the HG image, things seem to be working fine. I can benchmark, and i can collect samples at not only the full rate(25e6 MS/S), but at a higher rate than the XG image, which is strange. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] GNU Radio, UHD, and AGC with USRP B205mini-i
Hello, I'm trying to figure out how the AGC operates in my setup of GNU radio (3.10.5.1), gr-uhd (UHD4.3), and USRP B205-mini-i, but it seems to too complex to figure out. My application is to receive signals from a multitude of bursty transmissions. The default AGC seems to generate large peaks at the beginning of frames, which is not so good. So, I was trying to look for ways to make it work better. I have been looking at the source code for the gr-uhd, uhd library, and AD9364 documentation, but it is not so easy to find out how it works, since gr uses the usrp-multi interface, which hides the details of accessing the actual radio interface. First of all, it seems that it is impossible to find the current gain of the RX if AGC is enabled, even though according to the IC document, the gain settings should be available even in the AGC mode. So, maybe this is a shortcoming of the gr-uhd implementation, which does not query the IC for the gain setting. This would allow me to use the knowledge about the gain values in further processing. Secondly, the seems to IC support advanced configurability of the AGC from choosing between fast and slow AGC and manual gain settings to tuning the parameters of the AGC function inside the IC. But unfortunately none of this seem to be exposed in the UHD library. This could allow tuning the AGC to behave better for my signals. I could try to work out something myself, but I was unable to find any documentation about how the UHD library is layered, and how the high-level functions eventually interface with the different radio IC:s. It is certainly possible to find out all of it from the source, but having some documentation or pointers to the right direction would make it all much easier. It is always possible to implement the AGC function in GR by setting the gr-uhd to use manual gain, but I'm a bit afraid that the loop could be too slow. Regards, Ville -- Ville Eerola ville.eer...@iki.fi 050-4804435 ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: GNU Radio, UHD, and AGC with USRP B205mini-i
On 20/02/2023 13:05, Ville Eerola wrote: Secondly, the seems to IC support advanced configurability of the AGC from choosing between fast and slow AGC and manual gain settings to tuning the parameters of the AGC function inside the IC. But unfortunately none of this seem to be exposed in the UHD library. This could allow tuning the AGC to behave better for my signals. I could try to work out something myself, but I was unable to find any documentation about how the UHD library is layered, and how the high-level functions eventually interface with the different radio IC:s. It is certainly possible to find out all of it from the source, but having some documentation or pointers to the right direction would make it all much easier. Yup. There's no "structured walk-through" documentation of code base. Part of the reason for this is that the code-base changes, but the "stability point" is the API. In my experience (only about 44 years so far), such "structured walk-through" documentation is "stale" more-or-less as soon as its born for any large codebase such as UHD. Use the source, Luke. The API is reasonably well documented: https://files.ettus.com/manual/page_coding.html#coding_api_hilevel But, as you note, UHD was *deliberately* designed to "hide" the details of the underlying hardware, to facilitate the very large number of USRP device types that exist, and to allow applications that are utterly hardware agnostic. Nearly ALL of my apps don't actually care much which hardware is underneath them--USRPs, RTL-SDRs, LimeSDRs, etc. I'll also note that Gnu Radio does have AGC functions in its family of "blocks" so you might want to experiment with those, and use a fixed-gain. In the nearly 20 years I've been playing with SDRs, I've never actually needed to use hardware AGC. But I'll admit that I only experiment in one small corner of the radio universe. It is always possible to implement the AGC function in GR by setting the gr-uhd to use manual gain, but I'm a bit afraid that the loop could be too slow. Regards, Ville -- Ville Eerola ville.eer...@iki.fi 050-4804435 ___ 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: benchmark_rate throws error
Hi Joe, The error you're getting basically means it can't communicate with the FPGA on the N320. It's sending a packet to the device, but it's not getting the response packet it expects. So it could be a network configuration issue, a cabling issue, maybe a firewall issue, or something else that's messing up the packets. Double check the cabling and make sure you have the ports connected correctly. For example, connect the host computer port with IP 192.168.10.1 to the port on the device configured to 192.168.10.2 (the first port), or port 192.168.20.1 connected to 192.168.20.2 (the second port). Sometimes cables get swapped or port IP addresses get misconfigured and that can cause issues like this. When you specify the "addr" argument, you're telling the software which port to use to do the initialization that's failing, so make sure that's correct and matches the configuration and cabling. Wade On Mon, Feb 20, 2023 at 11:57 AM wrote: > With the HG image, things seem to be working fine. I can benchmark, and i > can collect samples at not only the full rate(25e6 MS/S), but at a higher > rate than the XG image, which is strange. > ___ > 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: benchmark_rate throws error
On 20/02/2023 22:27, Wade Fife wrote: Hi Joe, The error you're getting basically means it can't communicate with the FPGA on the N320. It's sending a packet to the device, but it's not getting the response packet it expects. So it could be a network configuration issue, a cabling issue, maybe a firewall issue, or something else that's messing up the packets. Double check the cabling and make sure you have the ports connected correctly. For example, connect the host computer port with IP 192.168.10.1 to the port on the device configured to 192.168.10.2 (the first port), or port 192.168.20.1 connected to 192.168.20.2 (the second port). Sometimes cables get swapped or port IP addresses get misconfigured and that can cause issues like this. When you specify the "addr" argument, you're telling the software which port to use to do the initialization that's failing, so make sure that's correct and matches the configuration and cabling. Wade On Mon, Feb 20, 2023 at 11:57 AM wrote: With the HG image, things seem to be working fine. I can benchmark, and i can collect samples at not only the full rate(25e6 MS/S), but at a higher rate than the XG image, which is strange. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com I'm going to guess, given what Wade said above (the error messages weren't immediately obvious to me) that when you moved to XG, your physical hardware wasn't compatible. The XG images are for 10GiG ethernet, so the SFP+ adaptors on both ends have to match, AND you have to have a 10GiGe compatible network adaptor on your host, and it has to be configured correctly. ___ 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 - All LEDs are off
Hi Ali, I wonder if the FPGA is not coming up. I'm not sure what the LEDs do in that case and I don't have a device handy to check. You could try this recovery procedure to see if that fixes the problem. https://kb.ettus.com/X300/X310_Device_Recovery If not, the device may be damaged. Wade On Fri, Feb 17, 2023 at 8:07 AM wrote: > Dear all, > > I need to your help. > > Today, my machine does not detect my X310 USRP anymore. > > Fan spins. > > All LEDs are off except the power (Attached photo) > > Ethernt LEDs are off. > > > Thank you in advance. > > Regards, > > Ali > ___ > 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: USRP E320 DMA
Hi Yasir, Maybe you could add another RFNoC CHDR port to your block just for streaming the parameter data. So it would have a dedicated streamer separate from the one used for ADC data. Wade On Fri, Feb 17, 2023 at 2:53 AM Yasir Özçalık wrote: > Hi everyone, > I have a problem with DMA. I am trying to build a custom RFNoC block which > finds pulse parameters (pulse width, pulse repetition interval and > frequency) and stores them in a block ram. I have built it and it worked in > simulation. The problem is I wanna read those parameters from the host. If > I try to read them via registers, it is too slow. Therefore; I thought that > I must use DMA to do that. > > In order to reach that goal, I did the things below; > I statically connected my 2 ports to endpoints. and in the UHD > application, I connected the radios (RX) to my block and connected my block > to the radios (TX) again. In this way, I successfully took all the ADC > datas to my block in the FPGA and processed them. > > The problem is when I processed the data in the FPGA and tried to read > parameters back in the host, I needed to use the rfnoc_chdr port and it is > used by radio for ADC datas. Therefore; I thought I needed to disconnect > the connection from my port to the radio and connect my port to > rx_streamer. But, it did not work. It gave an error saying that "attempting > to reconnect the block". Can anyone give me advice to read parameters fast > that my block produced by processing the ADC datas. > > Note: I don't wanna take all the ADC datas to the host, but only the > parameters which my RFNoC block produced while not blocking the ADC signals > arriving at my block. > > Device : USRP E320 > Host : Ubuntu 20.04 - 1GbE > > Kind Regards, > Yasir. > > > ___ > 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
