Re: [USRP-users] Bandwidth to send 2CH f32 data over 10GbE interface
On 07/31/2018 11:14 PM, Young C. Park wrote: Hi Marcus, Thanks for the reply. But the situation is, I see a lot of underflow when the sample rate is 100MHz (yes, the MCR is 200MHz), whereas it works ok with 50MHz. The buffer size does not change the underflow when it's set lower than : samps_per_buff = tx_stream->get_max_num_samps(); Any hint to cure the underflow? Regards, Young C. Park 2CH x 50Msps may be the fastest the TX chain can go. I know that 1CH x 100Msps is the limit for a single channel. At the end of the day, underruns exist because your computer simply cannot keep up with demand.It's a hardware device that interacts with the "real world", there's no "flow-controlling" the real-world while your computer "catches up". ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Bandwidth to send 2CH f32 data over 10GbE interface
Hi Marcus, Thanks for the reply. But the situation is, I see a lot of underflow when the sample rate is 100MHz (yes, the MCR is 200MHz), whereas it works ok with 50MHz. The buffer size does not change the underflow when it's set lower than : samps_per_buff = tx_stream->get_max_num_samps(); Any hint to cure the underflow? Regards, Young C. Park On Wed, Aug 1, 2018 at 11:31 AM, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 07/31/2018 10:21 PM, Young C. Park via USRP-users wrote: > >> Hi, I would like to make sure about the bandwidth and sampling rate on >> X310. >> Say, I have 2channel, 1000 complex f32 samples to be sent by X310, over >> 10GbE. >> The wire format is sc16. >> >> As far as I understand, f32 (64bit IQ) is converted to sc16 (32bit IQ) >> Then the time for the transmission will be : >> >> T = 2CH*1000*(32bit/sample)/(10*10^9bps) = 6.4us >> >> Then maximum possible sampling rate for each channel would be : >> SR_max = 1/(6.4ns) = 156.25Msamples/sec >> >> This should be ok with the X310 of 100Msps rate.. >> Please correct me if my calculation is not right. >> There might be some overhead on the packet transmission, then how much >> should I take that into account? >> >> Yes, although sample-rates are necessarily strictly related to the clock, > which is 200MHz. > > > > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Youngcheol Park ycpark...@gmail.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Bandwidth to send 2CH f32 data over 10GbE interface
On 07/31/2018 10:21 PM, Young C. Park via USRP-users wrote: Hi, I would like to make sure about the bandwidth and sampling rate on X310. Say, I have 2channel, 1000 complex f32 samples to be sent by X310, over 10GbE. The wire format is sc16. As far as I understand, f32 (64bit IQ) is converted to sc16 (32bit IQ) Then the time for the transmission will be : T = 2CH*1000*(32bit/sample)/(10*10^9bps) = 6.4us Then maximum possible sampling rate for each channel would be : SR_max = 1/(6.4ns) = 156.25Msamples/sec This should be ok with the X310 of 100Msps rate.. Please correct me if my calculation is not right. There might be some overhead on the packet transmission, then how much should I take that into account? Yes, although sample-rates are necessarily strictly related to the clock, which is 200MHz. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Bandwidth to send 2CH f32 data over 10GbE interface
Hi, I would like to make sure about the bandwidth and sampling rate on X310. Say, I have 2channel, 1000 complex f32 samples to be sent by X310, over 10GbE. The wire format is sc16. As far as I understand, f32 (64bit IQ) is converted to sc16 (32bit IQ) Then the time for the transmission will be : T = 2CH*1000*(32bit/sample)/(10*10^9bps) = 6.4us Then maximum possible sampling rate for each channel would be : SR_max = 1/(6.4ns) = 156.25Msamples/sec This should be ok with the X310 of 100Msps rate.. Please correct me if my calculation is not right. There might be some overhead on the packet transmission, then how much should I take that into account? -- Youngcheol Park ycpark...@gmail.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X310 - sc8
On 07/31/2018 02:40 PM, Sirkin, Joshua F. via USRP-users wrote: Has sc8 capability been added to the X310? I know it the past it hasn't but this page seems to indicate sc8 is generally implemented https://files.ettus.com/manual/structuhd_1_1stream__args__t.html. We have an X310 with a UBX-160 daughter card and are having trouble getting the full bandwidth out of it in sc16 without getting overflows. We have tried multiple 10G cards, multiple drivers, and tweaking sys affinity and IRQ setttings. It's not likely that SC8 will fix those problems. Make sure that your 10G interface is setup for larger frame sizes. What are you *doing* with the samples, once you have them? This message is intended only for the use of the individual or entity to which it is addressed and may contain ZETA Associates confidential or proprietary information. If you are not the intended recipient, any use, dissemination, or distribution of this communication is prohibited. If you have received this communication in error, please notify the sender and delete all copies. ___ 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] Vivado not found in environment
Hassna, you can't build RFNoC images with Vivado_Lab. You need the full Vivado. -- M On 07/31/2018 12:14 PM, Ouassal, Hassna via USRP-users wrote: > Hello, > > > > I ma wokring through "Build custom image with pre-built RFNoC blocks" > > > I am running the following script: > > hassna@hassna-desktop:~/rfnoc/src/uhd-fpga/usrp3/tools/scripts$ > ./uhd_image_builder_gui.py > --Using the following blocks to generate image: > * window > * fft > Adding CE instantiation file for 'X310_RFNOC_XG' > changing temporarily working directory to > /home/hassna/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/x300 > Setting up a 64-bit FPGA build environment for the USRP-X3x0... > - Vivado: Found (/opt/Xilinx/Vivado_Lab/2017.4/bin) > > Environment successfully initialized. > make -f Makefile.x300.inc bin NAME=X310_RFNOC_XG ARCH=kintex7 > PART_ID=xc7k410t/ffg900/-2 BUILD_10G=1 SFP0_10GBE=1 SFP1_10GBE=1 > RFNOC=1 X310=1 TOP_MODULE=x300 EXTRA_DEFS="BUILD_10G=1 SFP0_10GBE=1 > SFP1_10GBE=1 RFNOC=1 X310=1 " > make[1]: Entering directory '/home/hassna/rfnoc/src/uhd-fpga/usrp3/top/x300' > BUILDER: Checking tools... > * GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu) > * Python 2.7.12 > * ERROR: Vivado not found in environment. Please run setupenv.sh > /home/hassna/rfnoc/src/uhd-fpga/usrp3/top/../tools/make/viv_preamble.mak:56: > recipe for target '.check_tool' failed > make[1]: *** [.check_tool] Error 1 > make[1]: Leaving directory '/home/hassna/rfnoc/src/uhd-fpga/usrp3/top/x300' > Makefile:129: recipe for target 'X310_RFNOC_XG' failed > make: *** [X310_RFNOC_XG] Error 2 > > Then I run : > > hassna@hassna-desktop:~$ source > ~/rfnoc/src/uhd-fpga/usrp3/top/x300/setupenv.sh > Setting up a 64-bit FPGA build environment for the USRP-X3x0... > - Vivado: Found (/opt/Xilinx/Vivado_Lab/2017.4/bin) > > Environment successfully initialized. > hassna@hassna-desktop:~$ vivado -version > vivado: command not found > > > Why vivado: command not found? > > I appreciate your help with this matter. > > Thanks, > > Hassna > > > > > > > > > > > ___ > 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] X310 - sc8
On 07/31/2018 11:40 AM, Sirkin, Joshua F. via USRP-users wrote: > Has sc8 capability been added to the X310? I know it the past it hasn't but > this page seems to indicate sc8 is generally implemented > https://files.ettus.com/manual/structuhd_1_1stream__args__t.html. We have an > X310 with a UBX-160 daughter card and are having trouble getting the full > bandwidth out of it in sc16 without getting overflows. We have tried > multiple 10G cards, multiple drivers, and tweaking sys affinity and IRQ > setttings. No, the X3x0 does not support sc8. Regards, Martin ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] N310 SFP+ ports not working (no green light)
Found the problem. Was using the wrong adapter. On Sun, Jul 29, 2018 at 9:07 PM, Sayyed Dormiani Tabatabaei < sdorm...@eng.ucsd.edu> wrote: > I just followed the online KB guide exactly (I think). I have a successful > serial connection and RJ45 connection. > > Here is the output from updating the HG (default) image (over RJ45 > connection to host laptop). > > root@noiselab-10gig-1:/usr/local/share/uhd/images# uhd_image_loader > --args type=n3xx, addr=ni-n3xx-315A35C > [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; > UHD_3.13.0.HEAD-0-gf114cfa0 > [INFO] [MPMD] Initializing 1 device(s) in parallel with args: > mgmt_addr=192.168.10.4,type=n3xx,product=n310,serial=315A35C > ,claimed=False,reachable=No,skip_init=1 > [INFO] [MPM.main] Launching USRP/MPM, version: 3.13.0.0-gunknown > [INFO] [MPM.main] Spawning RPC process... > [INFO] [MPM.PeriphManager] Device serial number: 315A35C > [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s). > [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found! > [INFO] [MPM.PeriphManager] init() called with device args `'. > [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found! > [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found! > [INFO] [MPM.RPCServer] RPC server ready! > [INFO] [MPM.RPCServer] Spawning watchdog task... > [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found! > [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found! > [INFO] [MPMD] Claimed device without full initialization. > [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while. > [INFO] [MPM.PeriphManager] Updating component `fpga' > [INFO] [MPM.PeriphManager] Updating component `dts' > [INFO] [MPM.RPCServer] Resetting peripheral manager. > [INFO] [MPM.PeriphManager] Device serial number: 315A35C > [INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s). > [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found! > [INFO] [MPM.PeriphManager] init() called with device args `'. > [INFO] [MPMD IMAGE LOADER] Update component function succeeded. > [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found! > > Here is the ifconfig given from the N310 (obtained via serial screen > terminal) > > root@ni-n3xx-315A35C:~# ifconfig > eth0 Link encap:Ethernet HWaddr 00:80:2F:19:64:4E > inet addr:192.168.10.4 Bcast:192.168.10.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:12190 errors:0 dropped:2 overruns:0 frame:0 > TX packets:1684 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:18070162 (17.2 MiB) TX bytes:119916 (117.1 KiB) > Interrupt:145 Base address:0xb000 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:65536 Metric:1 > RX packets:90 errors:0 dropped:0 overruns:0 frame:0 > TX packets:90 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:7280 (7.1 KiB) TX bytes:7280 (7.1 KiB) > > sfp0 Link encap:Ethernet HWaddr 00:80:2F:19:64:4F > UP BROADCAST MULTICAST MTU:8000 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > sfp1 Link encap:Ethernet HWaddr 00:80:2F:19:64:50 > UP BROADCAST MULTICAST MTU:8000 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > The RJ45 connection is still working after FPGA update. Neither SFP+ port > lights up when I plug in the provided adapter. Rebooting after updating the > FPGA does not help either. > > Thank you for your time, > > Ali > > > On Sun, Jul 29, 2018 at 8:47 PM, Neel Pandeya > wrote: > >> Please follow the N310 Getting Started Guide on the Ettus Research >> Knowledge Base. Do not follow the printed Getting Started Guide that was >> included in the N310 box. The on-line guide should work for you. Please let >> us know if you're able to make any progress. >> >> --Neel Pandeya (sent from my Android phone) >> >> On Mon, Jul 30, 2018, 09:11 Sayyed Dormiani Tabatabaei via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hello, >>> >>> I have an N310 running UHD 13.0.0 internally with an updated fpga image. >>> My host machine has UHD 13.0.0 and GNUradio 3.7.12.0 compiled and installed >>> from source. >>> >>> I can not get either SFP+ port to work. The light will not turn on when >>> the adapter and Ethernet cable are plugged in. This occurs for both the >>> latest HG and XG FPGA images. >>> >>> Should I try the WX image? Any help on getting these SFP+ ports working >>> is greatly appreciated. >>> >>> Thank you for your time, >>> >>> Ali
[USRP-users] Vivado not found in environment
Hello, I ma wokring through "Build custom image with pre-built RFNoC blocks" I am running the following script: hassna@hassna-desktop:~/rfnoc/src/uhd-fpga/usrp3/tools/scripts$ ./uhd_image_builder_gui.py --Using the following blocks to generate image: * window * fft Adding CE instantiation file for 'X310_RFNOC_XG' changing temporarily working directory to /home/hassna/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/x300 Setting up a 64-bit FPGA build environment for the USRP-X3x0... - Vivado: Found (/opt/Xilinx/Vivado_Lab/2017.4/bin) Environment successfully initialized. make -f Makefile.x300.inc bin NAME=X310_RFNOC_XG ARCH=kintex7 PART_ID=xc7k410t/ffg900/-2 BUILD_10G=1 SFP0_10GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1 TOP_MODULE=x300 EXTRA_DEFS="BUILD_10G=1 SFP0_10GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1 " make[1]: Entering directory '/home/hassna/rfnoc/src/uhd-fpga/usrp3/top/x300' BUILDER: Checking tools... * GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu) * Python 2.7.12 * ERROR: Vivado not found in environment. Please run setupenv.sh /home/hassna/rfnoc/src/uhd-fpga/usrp3/top/../tools/make/viv_preamble.mak:56: recipe for target '.check_tool' failed make[1]: *** [.check_tool] Error 1 make[1]: Leaving directory '/home/hassna/rfnoc/src/uhd-fpga/usrp3/top/x300' Makefile:129: recipe for target 'X310_RFNOC_XG' failed make: *** [X310_RFNOC_XG] Error 2 Then I run : hassna@hassna-desktop:~$ source ~/rfnoc/src/uhd-fpga/usrp3/top/x300/setupenv.sh Setting up a 64-bit FPGA build environment for the USRP-X3x0... - Vivado: Found (/opt/Xilinx/Vivado_Lab/2017.4/bin) Environment successfully initialized. hassna@hassna-desktop:~$ vivado -version vivado: command not found Why vivado: command not found? I appreciate your help with this matter. Thanks, Hassna ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] X310 - sc8
Has sc8 capability been added to the X310? I know it the past it hasn't but this page seems to indicate sc8 is generally implemented https://files.ettus.com/manual/structuhd_1_1stream__args__t.html. We have an X310 with a UBX-160 daughter card and are having trouble getting the full bandwidth out of it in sc16 without getting overflows. We have tried multiple 10G cards, multiple drivers, and tweaking sys affinity and IRQ setttings. This message is intended only for the use of the individual or entity to which it is addressed and may contain ZETA Associates confidential or proprietary information. If you are not the intended recipient, any use, dissemination, or distribution of this communication is prohibited. If you have received this communication in error, please notify the sender and delete all copies. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] noc_block_null_source_sink module
What I don't understand is, why is the null sink able to have one input and no outputs? I would think that it would suffer the same issues that a 2-in 1-out block would have. I tried to understand the noc_block_null_source_sink.v, but I didn't really see how to use it as a sink only. I was going to create my own, but then I had the question from above. I am a little worried about the constraints that the block-to-block messaging has, so I was going to change my block to a 2-in 1-out block, but then remembered those issues. Then my answer was to make it 2-in 2-out (like it is now), but connected a null sink to the unneeded output. Any words of wisdom? - Original Message - Subject: Re: [USRP-users] noc_block_null_source_sink module From: "Jon Pendlum" Date: 7/30/18 10:49 pm To: "Jason Matusiak" Cc: "Ettus Mail List" Hey Jason, The block is functionally complete, in fact I think it was the first block ever made. There is a UHD C++ example, rfnoc_nullsource_ce_rx.cpp, that uses it. A block controller and GRC xml for GNU Radio needs to be created though. Jonathon On Wed, Jul 18, 2018 at 4:38 AM, Jason Matusiak via USRP-users wrote: > I was having trouble finding information on this block. I could see its > usefulness in an application I am looking into, but I wasn't sure how > complete the block was (I don't really see anything using it, nor a GRC xml > file for it). > > Thanks > > ___ > 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] USRP X310 Remote Configuration
Hi Farnaz, Regarding #1, the USRP can be either Tx, Rx, or both, but it does not affect maximum streaming rates. The 10Gbe link is bi-directional and can handle a maximum of 300 MS/s on a single link in both directions. You can use both links such that you can receive both channels of the X310 at 200 MS/s. Regarding #2, yes. The USRP itself perhaps can handle the 200 MS/s per channel on transmit, but the PC just can't keep the streaming at that rate without hiccups. The best you can get is 100 MS/s per channel on Tx. Regarding 3, not sure. Rob On Tue, Jul 31, 2018 at 10:34 AM Farnaz Chamanzadeh wrote: > Dear Rob, > > 1. Can you explain if the USRP may be configured only in receive/transmit > mode or is it also possible to configure in a single mode (a pure > transmitter or a pure receiver) using both optical interfaces for the task? > > 2. In the first remark in your email, you mentioned that the host-to-USRP > streaming does not work at 200 MS/s for the transmit case. Does it mean > that in the USRP-to-host mode it supports 200MS/s per channel in > receiving mode while the host to USRP supports only 100MS/s per channel? > > 3. About storing the samples on the USRP, does anyone know that if Ettus > has any plans to add this capability to the USRPs? > > > Best, > Farnaz > > On Mon, Jul 30, 2018 at 6:27 PM, Jason Matusiak < > ja...@gardettoengineering.com> wrote: > >> I've actually done this with success, unfortunately, I am not allowed to >> share it :(. It wasn't too hard, I used a core in the block to hold the >> data, and then I just repeated it when I sent it out over and over. >> >> The catch was that there was a little bit of an issue within rfnoc at the >> time (you can see mailing lists conversations from back then in the >> archives) that kept it from kicking off at startup (an enable switch worked >> fine though). Jonathon P helped with a patch to get me going, but that >> obviously has been mainlined by now since they have a siggen working (it >> didn't exist yet when I did my block). The issue had something to do with >> the block sending data before everything have been initialized and came up >> properly. >> >> So it isn't too bad to create one. Good luck! >> >> >> >> - Original Message - >> Subject: Re: [USRP-users] USRP X310 Remote Configuration >> From: "Rob Kossler via USRP-users" >> Date: 7/30/18 9:33 am >> To: "Farnaz Chamanzadeh" >> Cc: "usrp-users" >> >> Perhaps look at the RFNoC siggen block. You will need to add some >> component such as a block memory or fifo to store the samples on the fpga >> and then you will need a way to populate the memory and then play it out >> when desired. >> >> Rob >> >> On Mon, Jul 30, 2018 at 3:49 AM Farnaz Chamanzadeh >> wrote: >> >>> Dear Rob, >>> Thanks for your helpful response. The reason that we need to use a >>> switch is due to hour host hardware limits, which only have one 10GBE. >>> About the second remark in your email, do you have an example or a >>> reference where a similar case was implemented which we can use as a >>> guideline for our implementation? >>> >>> Best regards, >>> Farnaz >>> >>> On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler wrote: >>> Hi Farnaz, A couple of remarks and questions - Remark 1: in order to get 200 MS/s transmit streaming, you will NEED to have the samples on the USRP. The host-to-USRP streaming does not work at 200 MS/s for the transmit case (unless something has recently changed). The host-to-USRP max for transmit is 100 MS/s per channel - Remark 2: that leads into your question about having the samples stored on the USRP rather than streamed from host. This is not presently a capability, but can be added with some modest FPGA work. I have been desiring such capability for a couple of years - I hope that Ettus adds such capability in the future. - Question 1: why do you plan to use a 10gbe switch with a single connection to the host PC? Why not have multiple 10Gbe links at the PC which connect to each USRP individually. A NIC such as Intel XL-710 provides 4 10gbe links. Rob On Thu, Jul 26, 2018 at 12:13 PM Farnaz Chamanzadeh via USRP-users < usrp-users@lists.ettus.com> wrote: > Dears, > > To be more specific, we want to control multiple USRPs with one > (remote) computer. We would like to stream known and periodic signal from > each USRP. The sequence on each USRP is unique and is different from other > USRPs. > > Since the samples from each USRP are known, it would be more > convenient if we can generate the samples once and preferably store them > locally on each USRP. In this configuration, we want to use the host > computer to send control commands to the USRPs specifying when each of > them > must transmit its specific samples. The USRPs are assumed to be > synchronized, so the control commands from
Re: [USRP-users] USRP X310 Remote Configuration
Dear Rob, 1. Can you explain if the USRP may be configured only in receive/transmit mode or is it also possible to configure in a single mode (a pure transmitter or a pure receiver) using both optical interfaces for the task? 2. In the first remark in your email, you mentioned that the host-to-USRP streaming does not work at 200 MS/s for the transmit case. Does it mean that in the USRP-to-host mode it supports 200MS/s per channel in receiving mode while the host to USRP supports only 100MS/s per channel? 3. About storing the samples on the USRP, does anyone know that if Ettus has any plans to add this capability to the USRPs? Best, Farnaz On Mon, Jul 30, 2018 at 6:27 PM, Jason Matusiak < ja...@gardettoengineering.com> wrote: > I've actually done this with success, unfortunately, I am not allowed to > share it :(. It wasn't too hard, I used a core in the block to hold the > data, and then I just repeated it when I sent it out over and over. > > The catch was that there was a little bit of an issue within rfnoc at the > time (you can see mailing lists conversations from back then in the > archives) that kept it from kicking off at startup (an enable switch worked > fine though). Jonathon P helped with a patch to get me going, but that > obviously has been mainlined by now since they have a siggen working (it > didn't exist yet when I did my block). The issue had something to do with > the block sending data before everything have been initialized and came up > properly. > > So it isn't too bad to create one. Good luck! > > > > - Original Message - > Subject: Re: [USRP-users] USRP X310 Remote Configuration > From: "Rob Kossler via USRP-users" > Date: 7/30/18 9:33 am > To: "Farnaz Chamanzadeh" > Cc: "usrp-users" > > Perhaps look at the RFNoC siggen block. You will need to add some > component such as a block memory or fifo to store the samples on the fpga > and then you will need a way to populate the memory and then play it out > when desired. > > Rob > > On Mon, Jul 30, 2018 at 3:49 AM Farnaz Chamanzadeh > wrote: > >> Dear Rob, >> Thanks for your helpful response. The reason that we need to use a switch >> is due to hour host hardware limits, which only have one 10GBE. >> About the second remark in your email, do you have an example or a >> reference where a similar case was implemented which we can use as a >> guideline for our implementation? >> >> Best regards, >> Farnaz >> >> On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler wrote: >> >>> Hi Farnaz, >>> A couple of remarks and questions >>> - Remark 1: in order to get 200 MS/s transmit streaming, you will NEED >>> to have the samples on the USRP. The host-to-USRP streaming does not work >>> at 200 MS/s for the transmit case (unless something has recently changed). >>> The host-to-USRP max for transmit is 100 MS/s per channel >>> - Remark 2: that leads into your question about having the samples >>> stored on the USRP rather than streamed from host. This is not presently a >>> capability, but can be added with some modest FPGA work. I have been >>> desiring such capability for a couple of years - I hope that Ettus adds >>> such capability in the future. >>> - Question 1: why do you plan to use a 10gbe switch with a single >>> connection to the host PC? Why not have multiple 10Gbe links at the PC >>> which connect to each USRP individually. A NIC such as Intel XL-710 >>> provides 4 10gbe links. >>> >>> Rob >>> >>> >>> On Thu, Jul 26, 2018 at 12:13 PM Farnaz Chamanzadeh via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> Dears, To be more specific, we want to control multiple USRPs with one (remote) computer. We would like to stream known and periodic signal from each USRP. The sequence on each USRP is unique and is different from other USRPs. Since the samples from each USRP are known, it would be more convenient if we can generate the samples once and preferably store them locally on each USRP. In this configuration, we want to use the host computer to send control commands to the USRPs specifying when each of them must transmit its specific samples. The USRPs are assumed to be synchronized, so the control commands from the host will generate a TDMA scheme. Each USRP will start signal transmission upon receiving the control command from the host computer. I would like to know that: 1. Is it possible to store the samples on the USRPs? or should we stream the samples from the host computer to the USRPs for each transmission? 2. Can we use the full bandwidth and 200MS/s in this setup? 3. After knowing the answer to the previous question, I would like to know how we can implement it? do you happen to have a demo or an example that can guide us in this implementation? Best, Farnaz On Wed, Jun 27, 2018 at 4:50 AM, Michael West wrote: > Hi
Re: [USRP-users] Changing phase with TX->RX loopback
Hi Andreas,
The timekeeper lives inside of the Radio block. However, after looking more
into the code, the DUC and DDC do already read the timestamp data from the
CHDR packets. You could modify the DUC and DDC to use the timestamp data to
jump the phase accumulator's value to compensate for the idle time between
bursts. My experience is much more on the host side code, but if you do
choose to pursue this modification I think it could be of interest to
others on the mailing list who have more knowledge of HDL.
Regards,
Derek
On Tue, Jul 31, 2018 at 8:48 AM, Andreas Leuenberger <
andreas.leuenber...@palindrome-rs.ch> wrote:
> Thank you Derek for the explanations,
>
> As workaround I will have to send continuously.
> Just a curiosity, as I am very new in rfnoc development: Where is the
> timing of the bursts done in the FPGA? In the DmaFIFO block? And would it
> be possible to modify this block such that it sends zeros while no burst is
> 'active'?
>
> Best regards,
> andreas
>
>
>
> On 24.07.2018 16:46, Derek Kozel wrote:
>
> Hello Andreas,
>
> The digital frequency offset is handled in the DUC block which does not
> run in the same clock domain as the Radio block. The phase accumulator
> register will only increment when samples are being processed. The simplest
> way to cause the phase accumulator to continuously run (from the timing
> perspective of the DAC) is to send samples continuously rather than in
> bursts. This incurs a potentially significant downside of having to push
> out the extra samples from the computer. Since the DUC does not have
> knowledge of the timestamp data of each sample it would require invasive
> changes to make the phase accumulator look as if it were continuously
> running between bursts.
>
> Regards,
> Derek
>
> On Mon, Jul 16, 2018 at 2:20 PM, Andreas Leuenberger via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello all,
>>
>> I am using a USRP X310 with a UBX-160 daughterboard. The transmit signal
>> on port TX/RX is attenuated and looped back to the receiver on port RX2.
>>
>> Every millisecond I am sending a short rectangular pulse (about 10 us
>> long)
>> using the 'time_spec' attribute of the transmit meta-data
>> ('start_of_burst' and
>> ''end_of_burst are true).
>>
>> The frequencies of the transmit and receive LO's are set to the same
>> frequency. Also the digital transmit and receive frequencies offsets are
>> set
>> to the same value.
>>
>> I receive continuously and monitor the phase difference between the
>> transmitted
>> and received pulses.
>> If the digital frequency offset is zero, the phase difference of
>> consecutive
>> pulses stays constant, as expected.
>> If the digital frequency offset is different from zero, the phase
>> difference
>> of consecutive pulses jumps.
>>
>> What causes this phase jumps?
>> Maybe the digital oscillator of the transmitter is running only while
>> sending. If yes,
>> is there a way to force the transmit digital oscillator to run
>> continuously?
>>
>> I am using the following software versions:
>> linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_4.0.0.rfnoc-devel-788-g1f8463cc
>>
>> Thanks in advance,
>> andreas
>>
>>
>> ___
>> 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] Changing phase with TX->RX loopback
Thank you Derek for the explanations,
As workaround I will have to send continuously.
Just a curiosity, as I am very new in rfnoc development: Where is the
timing of the bursts done in the FPGA? In the DmaFIFO block? And would
it be possible to modify this block such that it sends zeros while no
burst is 'active'?
Best regards,
andreas
On 24.07.2018 16:46, Derek Kozel wrote:
Hello Andreas,
The digital frequency offset is handled in the DUC block which does
not run in the same clock domain as the Radio block. The phase
accumulator register will only increment when samples are being
processed. The simplest way to cause the phase accumulator to
continuously run (from the timing perspective of the DAC) is to send
samples continuously rather than in bursts. This incurs a potentially
significant downside of having to push out the extra samples from the
computer. Since the DUC does not have knowledge of the timestamp data
of each sample it would require invasive changes to make the phase
accumulator look as if it were continuously running between bursts.
Regards,
Derek
On Mon, Jul 16, 2018 at 2:20 PM, Andreas Leuenberger via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:
Hello all,
I am using a USRP X310 with a UBX-160 daughterboard. The transmit
signal
on port TX/RX is attenuated and looped back to the receiver on
port RX2.
Every millisecond I am sending a short rectangular pulse (about 10
us long)
using the 'time_spec' attribute of the transmit meta-data
('start_of_burst' and
''end_of_burst are true).
The frequencies of the transmit and receive LO's are set to the same
frequency. Also the digital transmit and receive frequencies
offsets are set
to the same value.
I receive continuously and monitor the phase difference between
the transmitted
and received pulses.
If the digital frequency offset is zero, the phase difference of
consecutive
pulses stays constant, as expected.
If the digital frequency offset is different from zero, the phase
difference
of consecutive pulses jumps.
What causes this phase jumps?
Maybe the digital oscillator of the transmitter is running only
while sending. If yes,
is there a way to force the transmit digital oscillator to run
continuously?
I am using the following software versions:
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-788-g1f8463cc
Thanks in advance,
andreas
___
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] RFNoC and stream tags
Hello, a question that keeps popping up on the list: is there a way to tag samples within RFNoC such that it can be processed in GNU Radio? In earlier discussions, the EOB bit was suggested for such purposes: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-June/020733.html But I'm not sure the EOB can be used in the *receive* direction. Possible use cases include running a frame sync block in the FPGA that should be able to tag the beginning of a frame, or having an FFT-like block or a filter bank in the FPGA in which case the respective first samples of every block need to be recognized within GNU Radio. Possibly in a robust manner such that loss of samples does not lead to catastrophic desynchronization. Is there a good way to accomplish this kind of tagging? Best regards, Peter ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] noc_block_null_source_sink module
Hey Jon, Is it possible to connect this block to an RFNoC port and not use it? Use others. 2018-07-31 4:49 GMT+02:00 Jon Pendlum via USRP-users < usrp-users@lists.ettus.com>: > Hey Jason, > > The block is functionally complete, in fact I think it was the first > block ever made. There is a UHD C++ example, > rfnoc_nullsource_ce_rx.cpp, that uses it. A block controller and GRC > xml for GNU Radio needs to be created though. > > Jonathon > > On Wed, Jul 18, 2018 at 4:38 AM, Jason Matusiak via USRP-users > wrote: > > I was having trouble finding information on this block. I could see its > > usefulness in an application I am looking into, but I wasn't sure how > > complete the block was (I don't really see anything using it, nor a GRC > xml > > file for it). > > > > Thanks > > > > ___ > > 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] Latency between multiple daughter boards on one USRP X310
Fabian and Derek, Thanks for your comments, Yesterday I realized that 10GbE could not support my 100MSymps, complex dual channel output. That's why I've seen underflow messages. I actually have got around this underflow by putting (ms) delay between bursts. However, it seems like that there's something going on even if I dont see any underflow message after the delay.. So I'd like to know what happens how the buffers are managed especially in 2 channel case.. Q1 : In 2 channel case, does the tx buffer divided into half size ? Q2 : Do the two tx buffers are filled up simultaneously or one after another? Q3 : when underflow happens, does the kernel wait until the 2 channel buffers are filled up ? or it just starts to output as soon as the first channel buffer is filled while the second is being filled? If I got answers about these questions, the delayed output on the dual channel can be explained more clearly... Thanks, Young C. Park On Tue, Jul 31, 2018 at 12:45 AM, Derek Kozel via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello Fabian and Young, > > The suggestion about timed commands is on point, I think that is what is > missing. Using unknown PPS will not hurt as there are two radio blocks with > timekeepers and using the unknown PPS setting, or external or gpsdo if > installed, will ensure that they are aligned. > > > 3) If that does not work, maybe the FPGA can handly only one command at > a time - even if you tell him to execute two. Then it may be possible to > start one command timed before the other and extend that sequence of > samples with the correct amount of zeros. > > Each radio channel has it's own queue for timed commands so it is possible > to schedule all channels simultaneously. > > Derek > > On Mon, Jul 30, 2018 at 8:08 AM, Fabian Schwartau via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi Young, >> >> I am not an expert, but I have three suggestions: >> 1) Using 'Unknown PSS' or any other sync method should not have no >> affect, as this is for syncing two or more USRPs. You have only one FPGA >> and that is in sync with itself ;) >> 2) Did you tried using timed commands? (see function set_command_time()) >> 3) If that does not work, maybe the FPGA can handly only one command at a >> time - even if you tell him to execute two. Then it may be possible to >> start one command timed before the other and extend that sequence of >> samples with the correct amount of zeros. >> >> Best regards, >> Fabian >> >> Am 30.07.2018 um 08:34 schrieb YoungC_Park via USRP-users: >> >>> Hi all, >>> >>> I hope someone could help me on my situation. I could not find similar >>> cases on the usrp archive. >>> >>> I have one USRP X310 that has UBX-160(slot A) , LFTX board(slot B) and >>> GPS module installed. >>> >>> - my UHD is 3.11.0 >>> >>> - Using uhd API based on tx_samples from_file.cpp, I can generate dual >>> output bursts from UBX160 and LFTX with 200MHz master clock and 100Msps on >>> USRP X310. >>> >>> - However, the second output (ch 1, red in the picture) is lagged from >>> the first one (ch 0, yellow) by about (~10us with +-4us uncertainty) >>> >>> - The baseband burst is a sawtooth waveform of two cycles(2000 samples >>> long). and UBX160 modulates it into fc = 1GHz whereas LFTX generates it as >>> is. >>> >>> - This lagging is quite constant (10us) even if I change the sampling >>> rate (10,20,50, 100MSps). >>> >>> - Tried 'Unknown PPS', 'gpsdo', 'internal',,, but no difference. >>> >>> - When I switch the order of channels to (1,0) as opposed to (0,1), then >>> the ch0 lags behind the ch1, which seems that this is related to some >>> sequenced process… >>> >>> We are seeking for helps on the cause and cure about this lagging… >>> >>> Thanks, >>> >>> Young C. Park >>> >>> >>> >>> ___ >>> 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 > > -- Youngcheol Park ycpark...@gmail.com ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
