[USRP-users] [UHD] 4.0.0.0 Release Announcement

UHD 4.0.0.0 is now available! This is a major release. It is not API or ABI compatible with earlier releases. This release includes a new architecture as well as several new features and bug fixes. UHD 4.0.0.0 was a massive development undertaking, more than just a new version it's a leap

Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers

Hi Jerrid/Brian, I wanted to follow up and let you know that the fix for this issue is now available on the UHD-3.15.LTS branch. Thank you for posting and for your patience. Regards, Michael On Thu, Jan 2, 2020 at 8:57 AM Jerrid Plymale via USRP-users < usrp-users@lists.ettus.com> wrote: >

[USRP-users] [UHD] 3.15.0.0 Release Announcement

Happy New Year! UHD 3.15.0.0 is now available! This is an API release. It is not API or ABI compatible with earlier releases. This release includes several new features and bug fixes. Installers for Windows and Fedora are available here:

[USRP-users] [UHD] 3.14.1.1 Release Announcement

UHD 3.14.1.1 is now available! This is a patch release. It is API compatible with 3.14.0.0 and ABI compatible with 3.14.1.0. This release includes several bug fixes. Installers for Windows and Fedora are available here: http://files.ettus.com/binaries/uhd/uhd_003.014.001.001-release/ The PPA

Re: [USRP-users] Using DmaFIFO for receive on X310

Hi Rob, You can increase the maximum socket buffer sizes by following the instructions here: http://files.ettus.com/manual/page_transport.html#transport_udp_linux I recommend setting the default and max values as follows: sudo sysctl -w net.core.rmem_default=200 sudo sysctl -w

Re: [USRP-users] Using DmaFIFO for receive on X310

Hi Rob, I would recommend not using the DMA FIFO block. Although the DMA FIFO block should work, setting a larger socket buffer on the host or using DPDK are much better options. To use a larger socket buffer, just use the device argument "recv_buff_size=" and set the to something reasonably

Re: [USRP-users] [UHD] 3.14.1.0 Release Announcement

Hi Matthias, The new B200 bootloader helps with failures to enumerate the device when it is plugged in before the host is booted. This only happens with some USB controllers. Loading the bootloader can be done by running: b2xx_fx3_utils --load-bootloader The bootloader file has been added to

Re: [USRP-users] E320 unable to lock to external reference

We have someone looking into this now. In the meantime, try adding the device arguments "clock_source=external,time_source=external". Regards, Michael On Tue, Jul 23, 2019 at 12:23 PM Nate Temple via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Jason, > > I'm fairly confident that this

[USRP-users] [UHD] 3.14.1.0 Release Announcement

UHD 3.14.1.0 is now available! This is an ABI release. It is API compatible with 3.14.0.0. This release includes several features and bug fixes including DPDK support for X300, a software reset utility for X300, a new bootloader for B200, and several bug fixes for TwinRX. Installers for

Re: [USRP-users] UBX coherence between TX and RX

Thanks to Michael's persistence, we did find an issue in the DUC and DDC where the phase accumulator was the wrong resolution (24-bit instead of 32-bit) and was not being reset at the end of each burst. The fix is now available on the head of the UHD-3.14 branch and will be included in the

[USRP-users] [UHD] 3.14.0.0 Release Announcement

UHD 3.14.0.0 is now available! This is an API release spawning the new UHD-3.14 branch. This API release introduces support for the N320 and N321 USRPs soon to be released (watch for the announcement on ettus.com!), a DPDK-based transport, and several other features and bug fixes. This release

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

ews! DPDK support is an interesting development. Is there any > documentation or examples which show this capability? > > Nick > > > On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> The release candidate

[USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

The release candidate of UHD version 3.14.0.0 has been tagged and is available for testing. This API release introduces support for the N320 and N321 USRPs soon to be released (watch for the announcement on ettus.com!), a DPDK-based transport, and several other features and bug fixes. This

Re: [USRP-users] Regression with setting frame size on v3.13.1.0

Hi Ron, Some buffers in the FPGA were reduced in size to only support frame sizes of 8192 on B200 series. This has been fixed in the upcoming 3.14.0.0 release. Frame sizes above 8192 are not guaranteed to work even with the fix, but I have run with send frame sizes up to 16360 successfully.

[USRP-users] [UHD] 3.13.1.0 Release Announcement

UHD 3.13.1.0 is now available. This is an ABI release on the UHD-3.13 branch. It is API compatible with all 3.13.x.x releases. Installers for Windows and Fedora are available here: http://files.ettus.com/binaries/uhd/uhd_003.013.001.000-release/ The PPA for Ubuntu will be available soon and

Re: [USRP-users] N310 time offset between TX RF Outputs

Hi Serge, I have tried to reproduce the issue on an N310 and X310 with no success. I tried several versions of UHD (including v3.13.1.0-rc1) on both and the time alignment was always good and the benchmark_rate with the increased INIT_DEALY always worked as expected. Can you try with the head

[USRP-users] [UHD] Announcing 3.13.1.0 Release Candidate 2

The second release candidate of UHD version 3.13.1.0 has been tagged and is available for testing. It has been a little while, but we deliberately slowed down to fix several issues in an attempt to make UHD more stable. There have been 150 commits since the 3.13.0.2 release just 4 months ago and

Re: [USRP-users] 2x N200 GPSDO PPS relative drift

Hi Stephan, I'm not sure if moving the power resolved your issue, but I wanted to follow up now that we have completed our root cause analysis. The GPSDO requires a minimum of 5.7V to retain accuracy and the voltage on J509 is dropping below that during TX and/or RX. The resolution is to first

Re: [USRP-users] synchronizing multiple USRP N310

Hi Florian, The device arguments are "clock_source" and "time_source". I noticed in your command you had them as "clock_src" and "time_src". That may be the source of the problem. Regards, Michael On Mon, Dec 10, 2018 at 11:33 AM Florian Kaltenberger via USRP-users <

Re: [USRP-users] 2x N200 GPSDO PPS relative drift

Hi Stephan, Try moving the GPSDO power from the J509 connector to the J102 connector on the N200 motherboard. J102 is 6V AUX power and does not sag when running. The provided cable is a little short, so you will have to get creative. Give that a try and let us know if it solves the problem.

Re: [USRP-users] N310 time offset between TX RF Outputs

Hi Serge, Thank you for making us aware of the issues. We are looking into them and consider them a priority. We will let you know what we find. Regards, Michael On Fri, Nov 9, 2018 at 11:04 AM Serge Malo via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi all, > > I have made another

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

The delay is from the time it takes to drain the DMA FIFO. The DMA FIFO default size is 32 MB. It can be controlled through the property tree or, if using RFNoC, through the DMA FIFO block control. The time to drain is a simple function of size and sample rate. We have been making improvements

Re: [USRP-users] Saturation issue with low amplitude (USRP N310)

I would like to personally thank Daniel, Ali, and Mathieu for working with me to uncover the root cause of the issue. As a result of this issue, we are discussing how we can improve the documentation for MPM and make it more obvious when there are potential bug fixes that require rebuilding MPM.

[USRP-users] [UHD] Announcing 3.13.1.0 Release Candidate 1

The release candidate of UHD version 3.13.1.0 has been tagged and is available for testing. There were several issues found and fixed since the 3.13.0.3 release candidate. Those changes resulted in an ABI incompatibility, so there will be no 3.13.0.3 release. All the commits for the former

Re: [USRP-users] Using RFNoC blocks with multi_usrp object

Hi Rob, This is definitely one of those trying to use it in a way for which it was not intended cases. I personally think you will spend more time trying to mix the multi_usrp and device APIs than just re-writing the code for the device3 API. There are a lot of subtle issues and corner cases

Re: [USRP-users] N310 timeout before streaming complete

Hi Rob, I just wanted to post an update. We have found the root cause of the issue. The primary cause is that the 2 channels are not stopping at the same time and the code is only looking at the EOB flag for channel 0. When any other channel stops before channel 0, the code hangs waiting for

Re: [USRP-users] B200 FPGA usage between 3.9 and 3.13

Hi Sylvain, You are absolutely correct. We are looking at splitting the axi_packet_gate into a buffer and a packet gate. That should effectively reduce the address FIFO to a reasonable size and reduce the resource usage back to reasonable levels. Regards, Michael On Thu, Oct 4, 2018 at 4:10

Re: [USRP-users] B200 FPGA usage between 3.9 and 3.13

Hi Silvain, Thank you for letting us know. That is quite a jump in utilization. We will take a look when we have some time. We did recently make recent bug fixes in axi_packet_gate. It looks like that, and possibly other changes, inadvertently increased resource utilization more than expected

Re: [USRP-users] N310 and set_time_source()

Hi Rob, Thanks for letting us know. We will look into that. It is hard to tell from the error if MPM is doing the work and the RPC call is just timing out or it is failing to execute in MPM altogether. We will try to reproduce it and see what is going on. In the meantime, is it possible for

Re: [USRP-users] N310 timeout before streaming complete

Hi Rob, Thanks again for the feedback. I'm glad to hear the issue is resolved on the N310. We will dig in further on the X310 and let you know what we find. I did notice the error seems to occur when the number of total samples received (including those flushed) is aligned to 1996. A possible

[USRP-users] [UHD] Announcing 3.13.0.3 Release Candidate 1

The release candidate of UHD version 3.13.0.3 has been tagged and is available for testing. This is a patch release for the UHD-3.13 branch, mainly affecting N3xx, X3xx, and B2xx devices. This release is API and ABI compatible with 3.13.0.2. The tag for this release:

Re: [USRP-users] B2X0 transmit quality degraded with UHD 3.12.0

tly, I can think of several companies in > production with B2x0 H/W with ugly legal and electrical ramifications on > the TX side > > -Ian > > On Sep 11, 2018, at 11:25 AM, Michael West via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Hi Ron, > > Tha

Re: [USRP-users] B2X0 transmit quality degraded with UHD 3.12.0

Hi Ron, Thank you for bringing this to our attention and for all the detailed reports on the issue. We will need to look into it. Is it possible for you to continue using UHD 3.11.1.0 while we look into the issue? Regards, Michael On Mon, Sep 10, 2018 at 11:49 PM, Ron Economos via USRP-users

Re: [USRP-users] N310 timeout before streaming complete

Hi Rob, Thank you once again. We have reproduced the issue and are working on tracing down the root cause and fixing the issue. We have confirmed that the issue exists on 3.13, but we have also confirmed it does not exist on 3.12.0.0. So, you can use v3.12.0.0 in the meantime. To be sure you

Re: [USRP-users] Problem building RFNoC from Master

Hi Rob, I'm assuming you were able to work through the issue because you were on the right track, but I wanted to make sure you got a response. The solution is to create a .yml file containing the blocks and parameters desired for the RFNoC image and use that as an input to uhd_image_builder.py.

Re: [USRP-users] Problems with MPM 3.13 on N310

Hi Rob, Thanks for the update. We will look into it. Regards, Michael On Fri, Aug 24, 2018 at 10:09 AM, Rob Kossler wrote: > By the way, I just changed my "flush" sequence to use the end_of_burst > flag (when streaming with STREAM_MODE_START_CONTINUOUS), but the issue > still occurs.

Re: [USRP-users] Problems with MPM 3.13 on N310

Hi Rob, Excellent feedback as always. Thank you. We will look into the RX burst behavior using STREAM_MODE_START_CONTINUOUS, but it may take some time. The flush routine should have a timeout for the recv() call and be looking for md.end_of_burst to exit, but I'm sure there is more to the issue

Re: [USRP-users] Problems with MPM 3.13 on N310

Hi Rob, We have reproduced the TX corruption issue and we are troubleshooting. In the meantime, you can try using the head of UHD-3.13 with the force_reinit=1 as Martin suggested. If that doesn't do the trick, we did find a combination that seems to work: UHD and FPGA image from the head of

Re: [USRP-users] N310 startup error: AD9371 product ID

Hi Rob, Martin meant that the product ID issue was fixed in 3.12.0.1 (current head of UHD-3.12) and 3.13.0.0. We are currently trying to reproduce the TX corruption issue using the head of UHD-3.13. Regards, Michael On Wed, Aug 15, 2018 at 2:55 PM, Martin Braun via USRP-users <

Re: [USRP-users] N310 startup error: AD9371 product ID

We are all very relieved to hear it. Thanks. Michael On Wed, Aug 15, 2018 at 1:18 PM, Rob Kossler wrote: > This fixed the problem. Thanks to all. > Rob > > On Wed, Aug 15, 2018 at 4:16 PM Rob Kossler wrote: > >> Great, thanks! >> >> On Wed, Aug 15, 2018 at 4:15 PM Michael West >> wrote: >>

Re: [USRP-users] N310 startup error: AD9371 product ID

Rob, The images for 3.13.0.2 are in the process of being posted. You can either checkout v3.13.0.1 and use those images or continue to use the head of UHD-3.13 and just recompile MPM on the device. Regards, Michael On Wed, Aug 15, 2018 at 1:11 PM, Robin Coxe via USRP-users <

Re: [USRP-users] N310 startup error: AD9371 product ID

Hi Rob, We are looking into it. It should have been fixed as of UHD 3.13.0.0 as Sayyed stated. Which version of the SD card image are you currently using? Are you running uhd_usrp_probe directly on the device or from a remote host? If from a remote host, what version of UHD are you currently

[USRP-users] [UHD] 3.13.0.1 Release Announcement

Hello all, UHD 3.13.0.1 is now available. This is a patch release on the UHD-3.13 branch. Yes, we did just release 3.13.0.0. So, why the patch release so soon? Some changes were required to support the newer versions of the N310 that will be shipping soon. So, only N310 users will need to

Re: [USRP-users] USRP X310 Remote Configuration

To expand on #2, the TX is limited by the 10 GbE link and the DRAM bandwidth. The 10 GbE link limitation is resolved by using both SFP+ ports as 10 GbE ports. The DRAM limitation is not so easy to overcome. The DRAM bandwidth is ~600 Msps, but it is used as a FIFO, so the bandwidth is cut in

[USRP-users] [UHD] Announcing 3.12.0.1 Release Candidate 1

The release candidate of UHD version 3.12.0.1 has been tagged and is available for testing. This is a patch release for the UHD-3.12 branch, mainly affecting N3xx, X3xx, and B2xx devices. This release is API and ABI compatible with 3.12.0.0. This release candidate is not to be confused with the

Re: [USRP-users] UBX-40 fails to ID on N210

Hi David, That version of UHD (UHD_003.010.HEAD-197-g053111dc) does not support that version of the UBX board. You need UHD version 3.10.0.1 or later. It looks like your master and maint branches are quite a bit out of date. Try pulling the latest master: > git checkout master > git pull

[USRP-users] [UHD] Maintenance Branches - A Fond Farewell to maint

After many years of service, the maint branch is being retired from UHD. In its place are branches for each of the minor UHD releases. In addition to the UHD-3.9.LTS branch, the following branches have been created: UHD-3.12 UHD-3.11 UHD-3.10 The master branch is once again the default branch.

Re: [USRP-users] USRP X310 Remote Configuration

Hi Farnaz, To clarify and expand on Marcus' comments, the answer is maybe. You can do burst captures and transmissions at full rate and you can even use timed commands to synchronize them, but there are limitations. If you can describe in more detail what you want to do, we can more clearly

Re: [USRP-users] USRP B-Series Issue with USB LTE Adapter Connected

1. Multiple USB transfers are queued by UHD and they pull the data into host memory as quick as they can. The transfers are re-queued when the data is retrieved by the application calling recv(). Overruns occur when all transfers are complete, data is queued in the memory, and the application

Re: [USRP-users] GNU radio receiving file, X310

Hi Nives, The warning can be ignored. It is a known issue that I believe was recently fixed. Regards, Michael On Mon, Jun 18, 2018 at 2:10 AM, Nives Novković wrote: > Hi everyone, > > Thank you for all your help. I followed EJ's advice on adding the 2nd FIFO > block, also Michael's for

Re: [USRP-users] GNU radio receiving file, X310

There may also be an issue with buffered I/O and how the flowgraph is stopped. The kill flowgraph button in the main window of GRC is like hitting Ctrl-C. Try closing the empty window that pops up. You can also try making the file sink unbuffered and see if that makes a difference. Regards,

Re: [USRP-users] GNU radio receiving file, X310

Hi Nives, It is difficult to help without more information. If you share the flowgraph and console output, people on the list might be able to help more. Regards, Michael On Mon, Jun 11, 2018 at 1:01 AM, Nives Novković via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi everyone, > > I

Re: [USRP-users] Synchronization of two X310 using C

Hello Eino, Even if you are successful getting one device to use the references of the other, it is probably not what you want to do. There are propagation delays on the 10 MHz and PPS signals that mean that the devices are not truly synchronized. The proper way to synchronize the devices is to

Re: [USRP-users] vita time

Hi Koen, The way to achieve what you want is to set the device time and then have your signal generator put timestamps in each packet relative to that time. To tell your custom block what time to use, you can have a user register that you also program with the time (or some future start time).

Re: [USRP-users] X300 FPGA: UHD 3.10.2.0 vs UHD 3.10.3.0

Hi Serge, The differences in the FPGA can be found here: https://github.com/EttusResearch/fpga/compare/UHD-3.10.2.0...UHD-3.10.3.0 There were no interface changes, so the compatibility did not get bumped. There were only a couple of bug fixes for corner cases for the X300/X310. Regards, Michael

[USRP-users] UHD 3.11.1.0 Release Announcement

Hello all, UHD 3.11.1.0 is now available. This is an update to the main series of releases. The tag for this release is located here: https://github.com/EttusResearch/uhd/releases/tag/v3.11.1.0 Installers for Windows and Fedora are available here:

[USRP-users] [UHD] Announcing 3.11.1.0 Release Candidate 1

The release candidate of UHD version 3.11.1.0 has been tagged and is available for testing. This is a maintenance release with many bug fixes, mainly affecting N3xx, X3xx, and B2xx devices. This release is API compatible with 3.11.x.x releases, but has a new ABI due to some refactoring of the

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

Hi Andrew, The fix is on the master branch (commit 8922095 ). It is being included in the next set of commits on the maint branch that should be available in the next few days. Regards, Michael On Wed, May 2,

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

Hi Louis/Andrew, The root cause of the issue has been identified and a fix is in progress. We should have the fix available on the head of the maint branch very soon. Thank you for bringing it to our attention! Regards, Michael On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <

Re: [USRP-users] examples using N310 with ext LO

Hi Rob, Your procedure and commands look fine. We are looking into the issue now and will post an update as soon as possible. Regards, Michael On Tue, Apr 10, 2018 at 6:27 PM, Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > Still hoping to get example or instructions on how

[USRP-users] UHD 3.11.0.1 Release Announcement

Hello all, UHD 3.11.0.1 is now available. This is an update to the main series of releases. The tag for this release is located here: https://github.com/EttusResearch/uhd/releases/tag/v3.11.0.1 Installers for Windows and Fedora are available here:

Re: [USRP-users] Spikes at beginning and end of transmission

t;> will >> always be some transient from that. Further, the filters in the DUC >> chain will necessarily experience a transient as new data is loaded into >> them that >> is completely unrelated to any previous samples--they will be >> processing a dis

[USRP-users] [UHD] Announcing 3.11.0.1 Release Candidate 1

The release candidate of UHD version 3.11.0.1 has been tagged and is available for testing. This is a patch release with no API or ABI changes. The main purpose of this release is to add support for the N300, but there have been a few other minor changes as well. The tag for this release:

Re: [USRP-users] Spikes at beginning and end of transmission

Hi Thomas, This is a known hardware issue with earlier revisions of the B200mini and has been fixed on newer versions. Please contact supp...@ettus.com and they can help get the boards reworked. Regards, Michael On Sun, Feb 25, 2018 at 6:54 AM, Thomas Teisberg via USRP-users <

Re: [USRP-users] UHD 3.10.3.0 Release Announcement

Hello all, Please forgive my typo in the link for the Windows and Fedora installers. The correct link is http://files.ettus.com/binaries/uhd/uhd_003.010.003.000- release/ Regards, Michael On Wed, Jan 31, 2018 at 11:59 AM, Michael West wrote: > Hello all, > > UHD

Re: [USRP-users] Buffer underruns on x310 when transmitting and receiving from same channel cont.

Hi Jason, I'm not sure if your issue has been resolved or not. There is a known issue in UHD 3.10.0.0 and later where buffer sizes that are not aligned with the maximum number of samples per transfer can result in underruns. We are working to fix it, but there is a simple workaround. Size your

Re: [USRP-users] B210 USB power only

Hi Jose, IIRC, the B210 can use up to ~800 mA and the GPSDO has a max of ~200 mA. Assuming the 2 USB 3.0 ports each supply 900 mA, it should work. Check the specs on the host system to make sure each port can deliver enough power. Some controllers limit the total power across ports. Regards,

Re: [USRP-users] JTAG connector for B200mini

Hi Jon, There are 2 cable kits available. One is 4" and the other is 24". They can be found here: https://www.ettus.com/product/details/JTAG-FX3-Cable-4 https://www.ettus.com/product/details/JTAG-FX3-Cable-24 Regards, Michael On Thu, Jan 11, 2018 at 5:18 PM, liu Jong via USRP-users <

[USRP-users] UHD 3.10.3.0 Release Candidate Anouncement

Hello all, The release candidate of UHD version 3.10.3.0 has been tagged and is available for testing. The tag for this release: https://github.com/EttusResearch/uhd/releases/tag/003_010_003_000_rc1 There have been 22 commits since the last release which can be viewed here:

Re: [USRP-users] UHD 3.10.2.0 | X300 - ERROR_CODE_TIMEOUT with low rates

Hi Kyle, Thank you for the good information. We will be increasing the timeout in the next release of UHD, so the issues should be resolved soon. Regards, Michael On Wed, Nov 15, 2017 at 9:19 AM, Guilbert, Kyle J via USRP-users < usrp-users@lists.ettus.com> wrote: > Greetings, > > I am

Re: [USRP-users] X310 exit issue

Hi Mark, It should be as simple as calling stop() on the UHD USRP Source and Sink blocks. It might also be good to sleep for a little while after calling stop() to allow the buffers to drain completely. Regards, Michael On Thu, Dec 7, 2017 at 12:35 PM, Mark Koenig <

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

Hi Kai, One more thing. To reduce the CPU load, you can try playing around with the timeout parameter on this call: https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/device3/device3_io_impl.cpp#L357 Try increasing it from 1us to something like 10ms or more. That controls the

Re: [USRP-users] UHD 3.10.2 | X300 - High CPU load even for low samples rate

Hi Kai, The increased CPU usage is expected. It was done intentionally to make the UHD code more responsive to flow control messages in order to avoid underruns at higher sample rates. Appropriate yields were put in place to avoid starvation. What is not expected are the dropped packet (D) and

Re: [USRP-users] [RFNoC] Listen Before Talking (LBT)

Hi Felipe, 1) As with any custom RFNoC block, yes it would connect to the crossbar. 2) Yes, your understanding is correct. 3) You would have to define what "high latency" is. The block would certainly add latency to the path. I would expect it to be on the order of 1 packet due to packet

Re: [USRP-users] rfnoc blocks with multiple inputs/outputs

Hi Dario, Interesting. I would expect 2 UBX-160 with 2 radio blocks into the 2 input ports to work. My best guess is that there is some issue with either the detected upstream nodes or the propagation of the stream command. It would be interesting to debug the

Re: [USRP-users] rfnoc blocks with multiple inputs/outputs

Hi Dario, OK. I dug in a bit more and I can now tell you are most likely using the 2 streams from a single TwinRX daughterboard by the nature of the issue. The root cause is that Twin RX uses ports 0 and 1 on the radio block (all other daughterboards only use port 0) and only port 0 is

Re: [USRP-users] rfnoc blocks with multiple inputs/outputs

Hi Dario, A block can have any number of inputs and outputs, so 2 inputs and 1 output is fine. The Split Stream block is an example of an asymmetric block. The UHD XML description of the Split Stream block can be found here:

Re: [USRP-users] ADC Self-Test FAILED

Hi Mark, It is the simplest. You can always play around with the source code to comment out the lines that do the ADC self test temporarily. Regards, Michael On Wed, Oct 11, 2017 at 10:38 AM, Mark Koenig < mark.koe...@iubelttechnologies.com> wrote: > Thank you for the follow up. Is this the

Re: [USRP-users] Using X310/UBX Tx/Rx antenna for single channel pulsed radar

Hi Rob, Yes. The queue is a simple FIFO and does no reordering, so the commands must be in time order. Each radio has a separate command queue, so they will not interfere with each other. All commands go to the same queue, whether timed or not, so care must be taken with all commands issued to

Re: [USRP-users] Using X310/UBX Tx/Rx antenna for single channel pulsed radar

Hi Rob, Yes, that would be a problem. There is a single command queue for both TX and RX commands to the radio, so something has to collate the T/R switching commands with the RX streaming command so none of the commands arrive late. Regards, Michael On Thu, Oct 5, 2017 at 7:48 AM, Rob Kossler

Re: [USRP-users] ADC Self-Test FAILED

Hi Mark, Update UHD to a newer version. The head of the maint branch or the latest 3.10.2.0 release should work. The ADC self test is skipped when supplying "recover_mb_eeprom" as of UHD 3.10.0.0. Regards, Michael On Tue, Oct 10, 2017 at 12:32 PM, Mark Koenig via USRP-users <

Re: [USRP-users] Reducing USB Latency

Ron is correct about the defaults. USB 3.0 has a MTU of 1024 B on the bus and USB 2.0 has a MTU of 512 B, so you might get something by reducing the send_frame_size to those values. I recommend also increasing the num_send_frames to something like 256 if you do. One thing to keep in mind is

Re: [USRP-users] X300 recovery after LATE_COMMAND or OVERFLOW_ERROR

Hi Martin, Without seeing some source code, it is difficult to say exactly what is going on. The ERROR_CODE_LATE_COMMAND means that the radio block in the FPGA received a command late. An ERROR_CODE_OVERFLOW with the out_of_sequence flag set is alarming and means that packets are getting