[USRP-users] Re: Maximum data rate using multiple B210s
Hello Weit, the maximum sampling rate of a B210 is 30.72 MHz per direction per frontend, so that's 61.42 MS/s per direction (TX and RX). That times 12 bit per sample makes 1.47 Gb/s. So, I don't really know where the 5 Gb/s your USRP might theoretically go. So, I must admit your question makes little sense to me! Best regards, Marcus DISCLAIMER: Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code. Use of the Code is subject to terms of the licenses to the UHD or RFNoC code with which the Code is used. Standard licenses to UHD and RFNoC can be found at https://www.ettus.com/sdr-software/licenses/. NI will only perform services based on its understanding and condition that the goods or services (i) are not for the use in the production or development of any item produced, purchased, or ordered by any entity with a footnote 1 designation in the license requirement column of Supplement No. 4 to Part 744, U.S. Export Administration Regulations and (ii) such a company is not a party to the transaction. If our understanding is incorrect, please notify us immediately because a specific authorization may be required from the U.S. Commerce Department before the transaction may proceed further. On 14.07.21 06:37, Weite Zhang wrote: > Hi, > > I am testing four B210s streaming simultaneously and using a laptop that has > four USB3.0 > ports. I found the maximum achievable data rate in my case is much lower than > what I > expect, which should be 20Gbps (4x5Gbps considering the speed limit of a > single USB3.0 > port is ~5Gbps). > > Does anyone has used multiple B210s connected to a single host PC to > streaming data > simultaneously and is able to run a data rate approaching the maximum? Are > there any > specific hardware requirements in order to do that? > > > Thank you, > Weit > > > > ___ > 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: Multi USRP TX configuration in GNURadio
Dear Jonathan Your workaround helps me to solve the issue. But what about the fact that I really need those two constant zero TX channel since I need them for receiving. Dear Marcus I didnt get your point about set sample rate to 10Msps with the same bandwidth. Would you explain more? I know that L character at console means starving for samples but what I really dont understand is that why it comes up when skip_dram argument sets to one with the same sample rate though? Regards. On 10/7/21 1:02, Jonathon Pendlum wrote: Hi Armin, What happens if you set the number of channels to 4 (with the skip_dram arg removed), and drive the two unused TX channels with a const source 0? Jonathon On Fri, Jul 9, 2021 at 11:56 AM Marcus D. Leech mailto:patchvonbr...@gmail.com>> wrote: On 07/09/2021 11:54 AM, Armin Ghani wrote: 5Msps If there's a way to up it to 10Msps (keeping the same bandwidth), that might help with the "L"--which basically means the pipeline is starving for samples. Now, it might also mean that your computer cannot "keep up" and is delivering samples a little late. On 9/7/21 17:50, Marcus D. Leech wrote: On 07/09/2021 10:31 AM, Armin Ghani wrote: Thanks Marcus. It helped to resolve the error. But UHD consistently prints "L" in the output. Would you what DRAM FIFO block actually does? It's a FIFO between the DUC and the ADC as far as I know. What is your sample rate? Regards On 9/7/21 14:41, Marcus D. Leech wrote: On 07/09/2021 07:40 AM, Armin Ghani wrote: Dear community I've been trying to make a fully synchronous multi USRP transmitter in GNURadio v3.8.2.0 and UHD v3.15.0.0. In order to have a common clock and time between 2 USRPs, an octoclock is also used. when trying to run a flowgraph which consists one multi_usrp sink block that is connected to a signal source in GNURadio and running the flowgrapth I get this error: Executing: /usr/bin/python3 -u /home/.../Documents/gnuradio-tests/octoclock_test.py [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_3.15.0.HEAD-0-gaea0e2de [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 7972 bytes. [WARNING] [X300] For the 192.168.30.2 connection, UHD recommends a receive frame size of at least 8000 for best performance, but your configuration will only allow 7972.This may negatively impact your maximum achievable sample rate. Check the MTU on the interface and/or the recv_frame_size argument. [INFO] [X300] Maximum frame size: 7972 bytes. [WARNING] [X300] For the 192.168.50.2 connection, UHD recommends a receive frame size of at least 8000 for best performance, but your configuration will only allow 7972.This may negatively impact your maximum achievable sample rate. Check the MTU on the interface and/or the recv_frame_size argument. [INFO] [X300] Radio 1x clock: 200 MHz [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000) [INFO] [X300] Radio 1x clock: 200 MHz [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1308 MB/s) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1312 MB/s) [INFO] [1/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000) [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1316 MB/s) [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1304 MB/s) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001) [INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD1001) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001) [INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD1001) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0) [INFO] [1/DUC_0] Initializing block control (NOC ID: 0xD0C0) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0) [INFO] [1/DUC_1] Initializing block control (NOC ID: 0xD0C0) [INFO] [MULTI_USRP] 1) catch time transition at pps edge [INFO] [MULTI_USRP] 2) set times next pps (synchronously) thread[thread-per-block[6]: ]: RuntimeError: Multiple sampling rates downstream of TX Terminator 0: RuntimeError: Node 0/DUC_0 specifies 1e+06, node 0/DUC_1 specifies 390625. What happens if you use the "skip_dram=1" argument in the device argument? ___ USRP-users mailing list --usrp-users@lists.ettus.co
[USRP-users] Re: Multi USRP TX configuration in GNURadio
On 07/14/2021 04:32 AM, Armin Ghani wrote: Dear Marcus I didnt get your point about set sample rate to 10Msps with the same bandwidth. Would you explain more? I know that L character at console means starving for samples but what I really dont understand is that why it comes up when skip_dram argument sets to one with the same sample rate though? Regards. I just meant that you could interpolate your signal up to a higher sample rate to see if that made the "L" go away. There were historically problems with lower sample rates on X310 in certain configurations. I don't know why there's a dependency on skip_dram, since I'm not one of the designers. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] UHD deb dependencies
Hello, I noticed there is a Docker file with Ubuntu 20.04 dependencies in the UHD repo at .ci/docker/uhd-builder-ubuntu2004.Dockerfile. I plan on building/installing UHD to a custom prefix, but not a deb package. Can I skip all the packages in "deb dependencies" section? What about libncurses and ruamel.yaml? Regards, Wan ___ 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.1.0.1 released!
Hello USRP community, Well, as Scottish poet Robbie Burns wrote in "To a Mouse"[1], "The best laid schemes o' mice an' men/ Gang aft a-gley". Or, as we might more colloquially say today, "Stuff happens". Unfortunately, that stuff was that a couple of bugs slipped their way into UHD v4.1.0.0: - The revision compatibility check for ZBX hardware (the X410 daughterboard) was broken, causing MPM to fail to start with ZBX release revisions. - A missing include caused compilation failures on certain compilers when testing is enabled. - UHD 4.1 would fail to build with using Boost 1.76.0. These issues have been addressed in the UHD v4.1.0.1 release. Be sure to see the changelog associated with the v4.1.0.1 tag[2] for the full list, and consult the updates to the X410 page in the UHD manual[3] for improved instructions on updating the filesystem and CPLD on the NI Ettus USRP X410. With best regards, Aaron [1] https://www.poetryfoundation.org/poems/43816/to-a-mouse-56d222ab36e33 [2] https://github.com/EttusResearch/uhd/releases/tag/v4.1.0.1 [3] https://files.ettus.com/manual/page_usrp_x4xx.html ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
