Hello friends of UHD,
On behalf of everyone at NI/Ettus Research, I am pleased to announce the
release of UHD 4.2[1], the latest version of the USRP Hardware Driver! UHD
4.2 brings new enhancements to the USRP X410, notably:
* A new shipping bitfile, X410_CG_400, enabling 100 GbE 4x4 streaming
su
Hello USRP community,
A few weeks ago, I announced that UHD 4.1.0.5 had been released. I wish to
issue a minor clarification to some of the text in the release announcement
message.
I said, 'UHD 4.1.0.5 adds support for the NI Ettus USRP X410 Rev G, which
uses a different CPLD on the motherboard
Hello USRP community,
UHD 4.1.0.5 has been released!
Apart from some minor enhancements and bugfixes (see below for the complete
changelog), UHD 4.1.0.5 adds support for the NI Ettus USRP X410 Rev G,
which uses a different CPLD on the motherboard than previous revisions.
Please note that the X410
Hello USRP community,
UHD 4.1.0.4 has been released to address a minor oversight in 4.1.0.3 in
which the version identifier was not updated prior to release. While there
are no other changes between 4.1.0.3 and 4.1.0.4, we recommend the use of
the latter to prevent any confusion.
UHD 4.1.0.4 Rele
Hello USRP community,
In all the excitement of attending and presenting at last week's GNU Radio
Conference 2021, I neglected to send out the announcement for these two
releases. These releases have some late-breaking bugfixes for the NI Ettus
USRP X410, USRP B2xx, and a few other friends/issues w
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:
- T
GitHub repo[3] or by posting to the USRP-users mailing
list so that we can get it resolved.
Finally, we hope to see you in person or virtually at GNU Radio Conference
2021[4], taking place 20-24 September 2021.
With best regards,
Aaron Rossetto
[1]
https://www.ettus.com/introducing-the-most
On Thu, Feb 18, 2021 at 7:28 AM Mike via USRP-users <
usrp-users@lists.ettus.com> wrote:
That is a typo in AN-400 that should probably be fixed.
>
Indeed it is! Good catch, and my apologies for the inconvenience. Glad you
found the resolution.
I've filed an issue on GitHub to update the applicat
On Tue, Feb 16, 2021 at 10:15 AM Mike via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Any ideas?
Try changing the clock domain connection to your FFT block to this:
- { srcblk: _device_, srcport: rfnoc_chdr,dstblk: fft0, dstport:ce
}
Does that allow rfnoc_image_builder to complet
On Fri, Feb 12, 2021 at 5:53 AM Mark D via USRP-users
wrote:
> So far I’ve got the FPGA built and uploaded to the FPGA. Uhd_usrp_probe shows
> that the RFNoC routing as expected, but the name of OTT block has been
> replaced with Block#0. The OOT project appears as a folder in GNU radio with
>
On Mon, Feb 8, 2021 at 5:35 AM Askar, Ramez via USRP-users
wrote:
> Is rfnocmodtool made to create a completely new module, or it is also support
> adding the provided modules from Ettus, such as FIR, FFT, etc to the design?
> I am asking as I have noticed that the RFnoC modules are supported
Hi Ramez,
I'd like to recommend a thorough viewing of the excellent RFNoC 4
Workshop video that Jonathon Pendlum and Neel Pandeya from Ettus
Research put together for GRCon 2020, which is available on YouTube at
https://www.youtube.com/watch?v=M9ntwQie9vs. This should walk you
through the process
eError: Error with EAL
> initialization
> [00:00:00.000148] Creating the usrp device with:
> use_dpdk=1,mgmt_addr=192.168.1.88,addr=192.168.60.2...
> EAL: FATAL: already called initialization.
> EAL: already called initialization.
> [ERROR] [DPDK] Error with EAL initialization
>
On Mon, Feb 1, 2021 at 9:02 PM Rob Kossler via USRP-users
wrote:
> Has anyone successfully used DPDK with Ubuntu 20.04, UHD 4.0, Intel XL710
> NIC, and N310 (or X310)?
If I remember correctly, I believe DPDK tries to dlopen() *everything*
in the directory specified by the dpdk_driver parameter
Hi Jorge,
The '[WARNING] [DPDK] Detected use_dpdk argument, but DPDK support not
built in' message means that the version of UHD you are using (in this
case, the 3.15.LTS version you installed via PyBOMBS) was not compiled
with DPDK support. For DPDK to be available and usable, the UHD driver
has
I agree that this question is more in the domain of GNURadio, but I do
want to point out that RFNoC 4.0 blocks most certainly can have
different numbers of inputs and outputs. A good example is the RFNoC
Fosphor block:
https://github.com/EttusResearch/uhd/tree/master/fpga/usrp3/lib/rfnoc/fosphor
h
On Mon, Jan 25, 2021 at 11:33 AM Cédric Hannotier via USRP-users
wrote:
> So the action is propagated by the gain block iif the controller is
> built with UHD and hence recognized by uhd_usrp_probe.
> Building the controller as OOT makes the block unrecognized and
> hence falls back to name 'Bloc
On Thu, Jan 21, 2021 at 4:49 PM Cédric Hannotier via USRP-users
wrote:
> On a side note:
> Are we forced to implement a custom controller for each RFNoC block?
> I was expecting that I could just write the verilog part
> and use the basic noc_block_base controller to manage my blocks in C++,
> us
Hello Florian,
I believe in UHD 3.15, the keys in the uhd.conf file use dashes (-), not
underscores between words, e.g.:
[dpdk-mac=00:11:22:33:44:55]
dpdk-io-cpu = 1
dpdk-ipv4 = 192.168.10.1/24
Hope that helps,
Aaron
From: USRP-users On Behalf Of Florian
Kaltenberger via USRP-users
Sent: W
19 matches
Mail list logo
