hero123457/uhd
1
0
Fork 0
mirror of https://github.com/EttusResearch/uhd.git synced 2026-10-25 17:36:10 +00:00
Code Issues Projects Releases Wiki Activity

docs: x4xx: Added information on locked FPGA variants

Browse Source
This commit is contained in:
Jörg Hofrichter 2026-07-24 09:24:02 +02:00 committed by mkoop-ni
parent 218975dd22
commit 7d26845c08
1 changed files with 223 additions and 171 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

394
host/docs/devices/usrp_x4xx.dox
View File

@ -42,6 +42,37 @@
frequencies 30 MHz - 4 GHz (tunable 1 MHz - 4 GHz), with a maximum sampling
rate of 2048 Msps, using \subpage page_fbx
\section x4xx_variants X410/X420/X440 Model Variants
The X410, X420 and X440 USRPs each come in two variants: a standard variant and
a variant with locked FPGA.
The standard variant supports operation with NI-provided FPGA images and
custom FPGA development workflows, including deployment of user-generated
FPGA images.
The Locked FPGA variant supports operation with NI-provided FPGA images
and supported software workflows. The Locked FPGA variant does not support
deployment of user-generated FPGA images or custom FPGA development
workflows.
You can identify a Locked FPGA variant by the <b>L</b> marking on the
front panel product label.
The locked FPGA designation does not change the RF hardware, interfaces,
or performance characteristics of the device.
Device Sticker | Description | Supports FPGA bitfiles \n from UHD releases | Supports custom \n FPGA bitfiles |
--------------------|-------------------------------------|---------------------------------------------|----------------------------------|
Ettus USRP X410 | Ettus USRP X410 standard variant | yes | yes |
Ettus USRP X410 (L) | Ettus USRP X410 Locked FPGA variant | yes | no |
Ettus USRP X420 | Ettus USRP X420 standard variant | yes | yes |
Ettus USRP X420 (L) | Ettus USRP X420 Locked FPGA variant | yes | no |
Ettus USRP X440 | Ettus USRP X440 standard variant | yes | yes |
Ettus USRP X440 (L) | Ettus USRP X440 Locked FPGA variant | yes* | no |
\*Note: Certain FPGA image flavor are not available. See section \ref x4xx_updating_fpga_types for details.
\section x4xx_overview Overview and Features
The X4x0 series of USRPs comes in three variants: The USRP X410, the USRP X420,
@ -202,15 +233,17 @@ for whatever reason.
The main non-volatile storage of the USRP is a 32 GB eMMC storage*. This storage
can be made accessible as a USB Mass Storage device through the USB-OTG connector
on the back panel.
on the back panel.
\* USRP X410 up until revision H had an NVM storage of 16 GB only.
The entire root file system (Linux kernel, libraries) and any user data are
stored on the eMMC. It is partitioned into four partitions:
- Boot partition (contains the bootloader). This partition usually does not
require any modifications.
- Boot partition (contains the bootloader). <b>Do not modify the boot.bin, boot0001.bin,
etc. files on the partition, otherwise the device may not be able to boot from eMMC
anymore. Also don't partially erase the eMMC. Locked FPGA variants may be rendered
permanently unusable in this case, which is not covered by warranty.</b>
- Two system partitions (root file systems). These contain the operating system
and the home directory (anything mounted under / that is not the data or boot
partition). Up until UHD 4.6/Yocto release zeus, the two rootfs partitions are
@ -289,7 +322,7 @@ specify the \ref x4xx_usage_args "mgmt_addr argument" with the IP address of the
eth0 interface when setting up UHD sessions on X420 and X440 devices. Otherwise,
timeouts may occur if clocking-related settings change between UHD sessions as
these changes require an automatic restart of the USRP Hardware Daemon (MPM)
and cause the QSFP28 interfaces to become temporarily unavailable.
and cause the QSFP28 interfaces to become temporarily unavailable.
Interface Name | Description | Default Configuration | Configuration File | Ex.: X4_xxx FPGA image | Ex.: CG_xxx FPGA image |
---------------|---------------------------------------|-----------------------|--------------------|------------------------|------------------------|
@ -367,22 +400,22 @@ Link / No Activity | Green (solid) |
Link / Activity | Amber (blinking) |
\section x4xx_getting_started Getting Started
In this section, users will learn how to set up a device received from the factory
In this section, users will learn how to set up a device received from the factory
to successfully run an application by completing the following steps:
- Start with setting up the device
- Update the Filesystem
- Updating the FPGA image
- Start with setting up the device
- Update the Filesystem
- Updating the FPGA image
- Verifying the setup
- Make necessary network connections
- Now you are ready to run applications on the device!
- Now you are ready to run applications on the device!
\subsection x4xx_getting_started_install_uhd_host Installing UHD on the Host Computer
Firstly, download and install UHD on a Linux/OS X/Windows host computer. The easiest way to install USRP Hardware Driver
(UHD) is by getting a binary installer package for your operating system as described in \ref page_install_binary.
If no binary packages are available for your operating system or you want to modify the sources by yourself,
a step-by-step guide is available at \ref page_build_guide.
Firstly, download and install UHD on a Linux/OS X/Windows host computer. The easiest way to install USRP Hardware Driver
(UHD) is by getting a binary installer package for your operating system as described in \ref page_install_binary.
If no binary packages are available for your operating system or you want to modify the sources by yourself,
a step-by-step guide is available at \ref page_build_guide.
The following minimum UHD versions are required:
@ -416,26 +449,26 @@ pressing the power button.
\subsubsection x4xx_getting_started_setting_up_host Host System Requirements
You can choose to run operations on the device by directly logging into it (Stand-alone
You can choose to run operations on the device by directly logging into it (Stand-alone
mode) or establishing a remote connection to it (Network mode).
Host system requirements:
<blockquote>
<b>For Network Mode:</b> A host computer with at least one 10 or one 100 Gigabit
Ethernet interface available for sample streaming. In addition to the Ethernet interface
used for sample streaming, your host computer will require a separate 1 Gigabit
Ethernet interface for command and control streaming. The exact interface requirement
<b>For Network Mode:</b> A host computer with at least one 10 or one 100 Gigabit
Ethernet interface available for sample streaming. In addition to the Ethernet interface
used for sample streaming, your host computer will require a separate 1 Gigabit
Ethernet interface for command and control streaming. The exact interface requirement
varies based on the FPGA image from \ref x4xx_updating_fpga_types loaded to the device.
<b>For Stand-Alone Mode:</b> A host computer with an available 1 Gigabit Ethernet
port or a USB 2.0 port to remotely access the embedded Linux operating system
<b>For Stand-Alone Mode:</b> A host computer with an available 1 Gigabit Ethernet
port or a USB 2.0 port to remotely access the embedded Linux operating system
running on ARM CPU.
</blockquote>
<br/><b> Network Mode Setup</b>
The Getting Started Guide refers to the network mode setup for the operations
in the following sections. Ensure the host computer and the device are on the same
The Getting Started Guide refers to the network mode setup for the operations
in the following sections. Ensure the host computer and the device are on the same
subnet network.
<br/>
@ -451,19 +484,19 @@ subnet network.
9. QSFP28 to 4xSFP28 Ethernet Breakout Cable (optional)
10. Power Supply
To successfully run applications, either cable from 6. or 9. is required. In this context, when using the
default `X4_200` FPGA image, the Ethernet Breakout Cable from 9. is required. Please proceed to make the
To successfully run applications, either cable from 6. or 9. is required. In this context, when using the
default `X4_200` FPGA image, the Ethernet Breakout Cable from 9. is required. Please proceed to make the
connections as shown in the figure above.
\subsection x4xx_updating_filesystems Updating the Filesystem
It is strongly recommended to start with upgrading the filesystem on the device to have an up-to-date
firmware running the latest UHD version. Ensure that, in Network Mode, the version of UHD running on the host
computer and the UHD version on USRP X4x0 match.
It is strongly recommended to start with upgrading the filesystem on the device to have an up-to-date
firmware running the latest UHD version. Ensure that, in Network Mode, the version of UHD running on the host
computer and the UHD version on USRP X4x0 match.
This section explains how to update the filesystem directly on the device, which
requires the device to have an active internet connection.
Alternatively, it is possible to update the filesystem via:
- Mender: when the device does not have an internet connection or to update without physically
- Mender: when the device does not have an internet connection or to update without physically
accessing the device (see \ref x4xx_updating_filesystems_mender)
- Internal eMMC: in stand-alone mode (see \ref x4xx_accessing_emmc_usb)
Alternatively, it is possible to access the internal eMMC from an external host to flash the device
@ -475,11 +508,11 @@ To directly update the filesystem on the device, you need to first log in to the
The USRP X4x0-Series devices have an RJ45 connector that is by default configured by DHCP. By
plugging it into 1 Gigabit switch on a DHCP-capable network, it will get
assigned an IP address and thus be accessible via ssh. If so, continue with
assigned an IP address and thus be accessible via ssh. If so, continue with
\ref x4xx_getting_started_ssh.
In case your network setup does not include a DHCP server, refer to the section
\ref x4xx_getting_started_serial to access the device.
\ref x4xx_getting_started_serial to access the device.
\paragraph x4xx_getting_started_ssh SSH Connection
@ -494,20 +527,27 @@ connectivity by running `uhd_find_devices` on the host computer:
serial: 1234ABC
addr: 10.2.161.10
claimed: False
locked_fpga: True
mgmt_addr: 10.2.161.10
name: ni-4xx-1234ABC
product: x410
type: x4xx
By default, the device will use DHCP to attempt to find an IP address and the host
By default, the device will use DHCP to attempt to find an IP address and the host
name "ni-x4xx-<serial>" (in this case `ni-x4xx-1234ABC`).
Verify the serial number printed on the devices matches the corresponding
device serial number returned by the command.
Verify the serial number printed on the devices matches the corresponding
device serial number returned by the command.
All X4x0 variants will report their `type` as 'x4xx'. The `product` key can be
used to identify the X410/X420/X440 variant.
If a firewall is enabled on the host computer, allow UDP port 49600 to detect X4x0 devices.
The `locked_fpga` parameter determines if the device is a standard variant or
a locked FPGA variant:
- standard variant: `locked_fpga: False`
- locked FPGA variant: `locked_fpga: True`
If a firewall is enabled on the host computer, allow UDP port 49600 to detect X4x0 devices.
On a Linux host, add a new bi-directional rule under iptables.
After obtaining the device's IP address you can log in from the host
@ -533,7 +573,7 @@ You should be presented with a prompt like the following:
root@ni-x4xx-1234ABC:~#
\subsubsection x4xx_update_filesystem_direct Device Utility to Update Filesystem
The easiest and recommended way to update the filesystem is directly from the X4x0
The easiest and recommended way to update the filesystem is directly from the X4x0
via the built-in `usrp_update_fs` utility.
To reset the current filesystem version, run:
@ -549,14 +589,14 @@ To update to a specific version of the filesystem (e.g. 4.7.0.0), run:
$ usrp_update_fs -t v4.7.0.0
Note: The `usrp_update_fs` utility will trigger a reboot to switch to the new
filesystem. After the reboot, verify that the device is in a working state by running `uhd_find_devices`.
filesystem. After the reboot, verify that the device is in a working state by running `uhd_find_devices`.
If MPM is started and the default FPGA image was successfully loaded, run:
$ mender commit
on the device to make the change permanent.
If you run into a boot issue or need to update components such as the Motherboard CPLD
If you run into a boot issue or need to update components such as the Motherboard CPLD
or the SCU, refer \ref x4xx_troubleshooting.
\subsection x4xx_updating_fpga Updating the FPGA
@ -597,39 +637,39 @@ The following port types are available:
| C | 100 GbE |
| U | Unused |
If the QSFP 1 configuration is not specified, then that port is unused. CG
If the QSFP 1 configuration is not specified, then that port is unused. CG
indicates that each QSFP port has a single 100 GbE, respectively
(same as previous USRPs). The 'G' in this case is short for 'gigabit'.
As of UHD 4.5, the following USRP X410 images flavors are shipped with UHD:
As of UHD 4.11, the following USRP X410 images flavors are shipped with UHD:
| FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM |
|-------------------|-----------------------|--------------------------|-------------------------|-------------------------|---------|----------------------------|
| X4_200 | 4 (2 per ZBX) | 200 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (legacy) | Yes (4 GiB, 4-Ch Replay) |
| UC_200 | 4 (2 per ZBX) | 200 MHz | Unused | 100 GbE | Yes (legacy) | Yes (4 GiB, 4-Ch Replay) |
| CG_400 | 4 (2 per ZBX) | 400 MHz | 100 GbE | 100 GbE | Yes (multisample) | No |
| FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM | Available on \n locked FPGA variant |
|-------------------|-----------------------|--------------------------|-------------------------|-------------------------|-------------------|----------------------------|-------------------------------------|
| X4_200 | 4 (2 per ZBX) | 200 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (legacy) | Yes (4 GiB, 4-Ch Replay) | Yes |
| UC_200 | 4 (2 per ZBX) | 200 MHz | Unused | 100 GbE | Yes (legacy) | Yes (4 GiB, 4-Ch Replay) | Yes |
| CG_400 | 4 (2 per ZBX) | 400 MHz | 100 GbE | 100 GbE | Yes (multisample) | No | Yes |
As of UHD 4.11, the following USRP X420 images flavors are shipped with UHD:
| FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM |
|-------------------|-----------------------|--------------------------|-------------------------|-------------------------|---------|---------------------------|
| X4_200 | 2 (1 per HBX) | 200 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (legacy) | Yes (8 GiB, 2-Ch Replay*) |
| X4_400 | 2 (1 per HBX) | 400 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) |
| CG_400 | 2 (1 per HBX) | 400 MHz | 100 GbE | 100 GbE | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) |
| X4_1000 | 2 (1 per HBX) | 1000 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) |
| CG_1000 | 2 (1 per HBX) | 1000 MHz | 100 GbE | 100 GbE | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) |
| FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM | Available on \n locked FPGA variant |
|-------------------|-----------------------|--------------------------|-------------------------|-------------------------|------------------|----------------------------|-------------------------------------|
| X4_200 | 2 (1 per HBX) | 200 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (legacy) | Yes (8 GiB, 2-Ch Replay*) | Yes |
| X4_400 | 2 (1 per HBX) | 400 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes |
| CG_400 | 2 (1 per HBX) | 400 MHz | 100 GbE | 100 GbE | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes |
| X4_1000 | 2 (1 per HBX) | 1000 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes |
| CG_1000 | 2 (1 per HBX) | 1000 MHz | 100 GbE | 100 GbE | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes |
As of UHD 4.11, the following USRP X440 images flavors are shipped with UHD:
| FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM | Dual-Rate Support |
|-------------------|-----------------------|--------------------------|-------------------------|-------------------------|---------|---------------------------|--------------------------------------------|
| X4_200 | 8 (4 per FBX) | 200 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (legacy) | No | Yes until UHD 4.10, No with later versions |
| X4_400 | 8 (4 per FBX) | 400 MHz | 4x 10 GbE (All Lanes) | Unused | No | Yes (8 GiB, 8-Ch Replay*) | Yes |
| CG_400 | 8 (4 per FBX) | 400 MHz | 100 GbE | 100 GbE | No | No | Yes |
| X4_800 | 2 (1 per FBX) | 800 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes |
| CG_800 | 2 (1 per FBX) | 800 MHz | 100 GbE | 100 GbE | Yes (multisample) | No | Yes |
| X4_1600 | 2 (1 per FBX) | 1600 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes |
| CG_1600 | 2 (1 per FBX) | 1600 MHz | 100 GbE | 100 GbE | Yes (multisample) | No | Yes |
| FPGA Image Flavor | Number of \n Channels | Bandwidth \n per Channel | QSFP28 Port 0 Interface | QSFP28 Port 1 Interface | DDC/DUC | DRAM | Dual-Rate Support | Available on \n locked FPGA variant |
|-------------------|-----------------------|--------------------------|-------------------------|-------------------------|-------------------|---------------------------|--------------------------------------------|-------------------------------------|
| X4_200 | 8 (4 per FBX) | 200 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (legacy) | No | Yes until UHD 4.10, No with later versions | Yes |
| X4_400 | 8 (4 per FBX) | 400 MHz | 4x 10 GbE (All Lanes) | Unused | No | Yes (8 GiB, 8-Ch Replay*) | Yes | Yes |
| CG_400 | 8 (4 per FBX) | 400 MHz | 100 GbE | 100 GbE | No | No | Yes | Yes |
| X4_800 | 2 (1 per FBX) | 800 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes | Yes |
| CG_800 | 2 (1 per FBX) | 800 MHz | 100 GbE | 100 GbE | Yes (multisample) | No | Yes | Yes |
| X4_1600 | 2 (1 per FBX) | 1600 MHz | 4x 10 GbE (All Lanes) | Unused | Yes (multisample) | Yes (8 GiB, 2-Ch Replay*) | Yes | No |
| CG_1600 | 2 (1 per FBX) | 1600 MHz | 100 GbE | 100 GbE | Yes (multisample) | No | Yes | No |
<span>*</span> (Implemented as two separate Replay blocks, each providing half the total amount of channels and memory)
@ -670,16 +710,16 @@ The following list shows some potential use-cases for different FPGA images:
Radio0 are not supported by default.
(For USRP X410 this design is available as source, and not shipped
as precompiled bitfile.)
- `X4_1000`: (USRP X420 only): 1000 MHz analog bandwidth streaming per channel to/from
- `X4_1000`: (USRP X420 only): 1000 MHz analog bandwidth streaming per channel to/from
on-board DRAM using the RFNoC Record/Replay block. Up to 4 x 10 GbE connections may be
used to access the DRAM from an external host computer. Note that 10 GbE is
not fast enough for continuous full-rate streaming at this rate.
Additionally, this image can also be used with master clock rates of 245.76 MHz,
250 MHz and 491.52 MHz.
- `CG_1000`: (USRP X420 only): Like the X4_1000, but with 2x 100 GbE connections
for streaming to/from an external host computer.
- `CG_1600` (USRP X440 only): Highest bandwidth streaming between the X440 and
an external host computer. Streaming requires one 100 GbE connections per
for streaming to/from an external host computer.
- `CG_1600` (USRP X440 only): Highest bandwidth streaming between the X440 and
an external host computer. Streaming requires one 100 GbE connections per
channel. Due to the available FPGA bandwidth only 2 channels are enabled,
the first channel on each daughterboard.
- `X4_1600` (USRP X440 only): Highest bandwidth streaming including DRAM support.
@ -696,12 +736,12 @@ experimental (unsupported).</blockquote>
The analog bandwidth determines the available master clock rates. See section
\ref x4xx_usage_mcrs for more information on available master clock rates.
Applications that require 200 MHz bandwidth or less,
should use the 200 MHz images and make use of the DDC/DUC for lower rates.
Applications that require higher bandwidth and use limited signal durations
Applications that require 200 MHz bandwidth or less,
should use the 200 MHz images and make use of the DDC/DUC for lower rates.
Applications that require higher bandwidth and use limited signal durations
should use the DRAM enabled X4_xxx images to ease streaming requirements.
Applications that require the full device bandwidth or require on-the-fly
data access should use the CG_xxx images.
Applications that require the full device bandwidth or require on-the-fly
data access should use the CG_xxx images.
\subsubsection x4xx_updating_fpga_load Loading the FPGA Image
@ -711,7 +751,7 @@ The UHD installation path can be queried by running the command:
uhd_config_info --print-all
If pre-built images are not found at the UHD installation path, up-to-date images
If pre-built images are not found at the UHD installation path, up-to-date images
can be downloaded using the `uhd_images_downloader` script:
sudo uhd_images_downloader
@ -723,7 +763,7 @@ can be downloaded by setting the device type specifier:
sudo uhd_images_downloader --args "type=x4xx"
The FPGA can be updated to one of the available FPGA images using `uhd_image_loader` on the host computer
The FPGA can be updated to one of the available FPGA images using `uhd_image_loader` on the host computer
by explicitly providing the FPGA bitfile path:
uhd_image_loader --args "type=x4xx,addr=<IP address of device>" --fpga-path <path to .bit>
@ -759,15 +799,15 @@ on the device.
\subsection x4xx_getting_started_verify_setup Verifying the Setup
Ensure right network connection and QSFP network setup before you start.
When using the default `X4_200` image, connect a QSFP28 to 4xSFP28 Ethernet
Breakout Cable between the X4x0 device and the host computer.
Alternatively, to use the `CG_400` image, connect a QSFP28 to QSFP28 Ethernet
Ensure right network connection and QSFP network setup before you start.
When using the default `X4_200` image, connect a QSFP28 to 4xSFP28 Ethernet
Breakout Cable between the X4x0 device and the host computer.
Alternatively, to use the `CG_400` image, connect a QSFP28 to QSFP28 Ethernet
Cable between the X4x0 device and the host computer.
See \ref x4xx_getting_started_network_connectivity_ifcs for further details on
the various network interfaces available on the X4x0. In order to communicate with the
QSFP Ethernet interfaces, modify either the host IP address or device sfp network
See \ref x4xx_getting_started_network_connectivity_ifcs for further details on
the various network interfaces available on the X4x0. In order to communicate with the
QSFP Ethernet interfaces, modify either the host IP address or device sfp network
configuration such that they are on the same subnet.
At this point, you should run:
@ -775,9 +815,9 @@ At this point, you should run:
uhd_usrp_probe --args "addr=<IP address>"
to ensure proper installation, network connectivity and operation of the device.
This command should run without any errors and return device details including
unit names, revision numbers, and available sensors on all attached USRP
motherboards and daughterboards. Verify that the number of radio blocks on the
This command should run without any errors and return device details including
unit names, revision numbers, and available sensors on all attached USRP
motherboards and daughterboards. Verify that the number of radio blocks on the
device matches the output of the command.
Example output of ´uhd_usrp_probe´:
@ -978,7 +1018,7 @@ issues.
You can now use existing UHD examples or applications (such as
rx_sample_to_file, rx_ascii_art_dft, or tx_waveforms) or other UHD-compatible
applications to start receiving and transmitting with the device.
applications to start receiving and transmitting with the device.
\subsection x4xx_getting_started_iq_dc IQ & DC Offset Correction (X420 only)
@ -991,8 +1031,8 @@ implemented in a Python script. Refer to \ref calibration_iq_dc_utils for more
details on the correction procedure.
\subsection x4xx_getting_started_handling Proper Care and Handling
All Ettus Research products are individually tested before shipment. The USRP is guaranteed to be functional
at the time it is received by the customer. Improper use or handling of the USRP can cause the device to
All Ettus Research products are individually tested before shipment. The USRP is guaranteed to be functional
at the time it is received by the customer. Improper use or handling of the USRP can cause the device to
become non-functional. Take the following precautions to prevent damage to the unit.
- Never allow metal objects to touch the circuit board while powered.
@ -1002,12 +1042,12 @@ become non-functional. Take the following precautions to prevent damage to the u
- Never allow any water or condensing moisture to come into contact with the device.
- Always use caution with FPGA, firmware, or software modifications.
<b> Caution! X410: Never feed a signal at power levels exceeding {+14 dBm continuous <=3GHz, +17 dBm continuous >3GHz,
<b> Caution! X410: Never feed a signal at power levels exceeding {+14 dBm continuous <=3GHz, +17 dBm continuous >3GHz,
or +20dBm for longer than 5 minutes >3GHz} into any RF input. </b>
<b> Caution! X420: Never feed a signal at power levels exceeding {0 dBm} into any RF input.</b>
<b> Caution! X440: Never feed a signal at power levels exceeding {+13 dBm continuous <=2.5GHz, +17 dBm continuous between
<b> Caution! X440: Never feed a signal at power levels exceeding {+13 dBm continuous <=2.5GHz, +17 dBm continuous between
2.5GHz and 3.6 GHz, or +20dBm continuous between 3.6 GHz and 4 GHz} into any RF input. </b>
<b> Caution! X410: Always use at least 30dB attenuation if operating in loopback configuration. </b>
@ -1055,7 +1095,7 @@ After entering the username `root` (no password is set by default), you should b
On this prompt, you can enter any Linux command available. Using the default
configuration, the serial console will also show all kernel log messages (unlike
when using SSH, for example), and give access to the boot loader (U-boot
prompt).
prompt).
\subsubsection x4xx_getting_started_serial_micro Connecting to the Microcontroller
@ -1072,7 +1112,7 @@ example, running the command `reboot` will emulate a reset button press,
resetting the state of the device, while the command `powerbtn` will emulate a
power button press, turning the device back on again.
The filesystem can be updating using the `usrp_update_fs` utility and the
The filesystem can be updating using the `usrp_update_fs` utility and the
device will automatically boot with the standard fpga image.
Note that the final 6 digits of the serial number match between the device and
@ -1101,9 +1141,9 @@ works.
\subsubsection x4xx_updating_filesystems_mender_artifact Downloading a Mender Artifact
To initiate an update directly from the X4x0 device or from a host computer with Internet
access (say, when X4x0 does not have internet acess), download a Mender artifact containing the
update itself. These are files with a `.mender` suffix. They can be downloaded by using the
To initiate an update directly from the X4x0 device or from a host computer with Internet
access (say, when X4x0 does not have internet acess), download a Mender artifact containing the
update itself. These are files with a `.mender` suffix. They can be downloaded by using the
`uhd_images_downloader` utility:
$ sudo uhd_images_downloader -t mender -t x4xx --yes
@ -1127,10 +1167,10 @@ Second, use the `-m` switch to use the new manifest file:
$ uhd_images_downloader -t mender -t x4xx -m manifest.txt
If downloading on a host computer, you will need to copy this Mender filesystem image to the USRP
If downloading on a host computer, you will need to copy this Mender filesystem image to the USRP
X4xx. This can be done with the Linux utility `scp`:
$ scp /path/to/usrp_x4xx_fs.mender root@<usrp_ipaddr>:~/.
$ scp /path/to/usrp_x4xx_fs.mender root@<usrp_ipaddr>:~/.
\subsubsection x4xx_updating_filesystems_mender_install Installing the Mender Artifact
@ -1217,6 +1257,10 @@ stopped by hitting Ctrl-C at the APU serial console.
\subsubsection x4xx_flash_emmc Flashing eMMC with the Filesystem
<b>Note for locked FPGA variant devices: Do not flash any filesystem image from a
release prior to UHD 4.11, as doing so will make the device unable to boot from eMMC
and render it permanently unusable. Flashing a wrong filesystem voids warranty.</b>
Once the X4x0's eMMC is accessible over USB, it's possible to write the
filesystem image using `dd`. You can obtain the latest filesystem image by
running:
@ -1242,15 +1286,21 @@ When copying has completed, hit Ctrl-C on the U-boot
prompt to terminate the mass storage mode. Then, power-cycle the device to load
the new filesystem.
<b>Take extra care to unmount the partitions cleanly, if they were mounted
on the host PC. Also take care not to modify the boot.bin, boot0001.bin, etc.
files on the first partition. Otherwise, the device may no longer be able to boot.
On locked FPGA variants, this can render the device permanently unusable.
Such damage is not covered by the warranty.</b>
\subsection Autoboot
The USRP X4x0 can be configured to power on and boot automatically when power is applied. This setting
can be controlled using the `eeprom-set-autoboot` script. This script is executed directly on the USRP X4x0.
The USRP X4x0 can be configured to power on and boot automatically when power is applied. This setting
can be controlled using the `eeprom-set-autoboot` script. This script is executed directly on the USRP X4x0.
To enable autoboot, run `eeprom-set-autoboot on`; to disable autoboot, run `eeprom-set-autoboot off`.
\subsection x4xx_updating_cpld Updating the Motherboard CPLD
<b>Caution! Updating the motherboard CPLD has the potential to brick your
device if done improperly. Bricked devices will need to be sent back for repair,
device if done improperly. Bricked devices will need to be sent back for repair,
visit [support](https://www.ettus.com/support/) for more details.</b>
After updating the filesystem, you may have to update your motherboard CPLD. If
@ -1318,12 +1368,12 @@ reboot.
\section x4xx_troubleshooting Troubleshooting
Refer [Ettus USRP X410/X420/X440 Getting Started Guide](https://kb.ettus.com/USRP_X410/X440_Getting_Started_Guide)
Refer [Ettus USRP X410/X420/X440 Getting Started Guide](https://kb.ettus.com/USRP_X410/X440_Getting_Started_Guide)
for Support, Legal Considerations and T&C.
\subsection x4xx_network_troubleshooting Network Troubleshooting
If you are not familiar with the X4xx and its network interface, please
If you are not familiar with the X4xx and its network interface, please
refer to \ref page_usrp_x4xx. Most of the network related problems are
similar among different embedded or MPM based USRPs. You might notice
differences in error messages or interface configurations. Please go through
@ -1358,20 +1408,20 @@ When running on the device, use `127.0.0.1` as the IP address.
<b>Issue 2:</b> uhd_usrp_probe --args addr=\<x4xx_DHCP_IP\> gives timeout waiting
for ACK error.
The setup includes a host PC connected to a x4xx with both 10Gb Ethernet
QSFP28 cables. Both remote PC and x4xx are connected to a network switch
and are in the same sub-net. uhd_usrp_probe on x4xx works fine but when
The setup includes a host PC connected to a x4xx with both 10Gb Ethernet
QSFP28 cables. Both remote PC and x4xx are connected to a network switch
and are in the same sub-net. uhd_usrp_probe on x4xx works fine but when
you try to execute it on a remote host, it throws below error:
<blockquote>[ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
RfnocError: OpTimeout: Control operation timed out waiting for ACK</blockquote>
Solution: Ensure both switch ports show LED blinking green and Ethernet cables
are fine.
- If the LEDs on the switch ports are not green, connect with different
Ethernet ports on the switch. LED should blink green. If not try with
- If the LEDs on the switch ports are not green, connect with different
Ethernet ports on the switch. LED should blink green. If not try with
another network switch. Try running uhd_usrp_probe again.
- If you still get errors, make sure that the Ethernet cables connecting host
and x4xx to the network switch are not damaged. Replace the Ethernet cables
and x4xx to the network switch are not damaged. Replace the Ethernet cables
and check again by running uhd_usrp_probe.
- If you are still unable to probe your x4xx without errors, contact
Ettus support.
@ -1383,23 +1433,23 @@ The setup includes a host PC connected to a x4xx with both 10Gb Ethernet
QSFP28 cables. Both the remote PC and x4xx are connected to a network switch
and are in the same sub-net. uhd_usrp_probe on x4xx works fine but when
you try to execute it on the remote host, it throws below error:
<blockquote>[ERROR] [RFNOC::GRAPH] IO Error during GSM initialization.
EnvironmentError: IOError: Timed out getting recv buff for management
transaction</blockquote>
<blockquote>[ERROR] [RFNOC::GRAPH] IO Error during GSM initialization.
EnvironmentError: IOError: Timed out getting recv buff for management
transaction</blockquote>
Solution: Such errors are noticed when the SFP cables are swapped between
the SFP ports of the device and host Ethernet ports.
the SFP ports of the device and host Ethernet ports.
- Verify the FPGA image flavor loaded in x4xx. Refer section
\ref x4xx_updating_fpga_types.
- Verify that the host is configured with the correct IP addresses to
communicate with the loaded FPGA image.
\ref x4xx_updating_fpga_types.
- Verify that the host is configured with the correct IP addresses to
communicate with the loaded FPGA image.
Refer \ref x4xx_getting_started_network_connectivity_ifcs.
- Check and ensure that the SFP cables connect the ports between the
- Check and ensure that the SFP cables connect the ports between the
x4xx and the host with the corresponding ip addresses.
- Verify single 10/100GbE network connections by pinging the USRP
- Verify single 10/100GbE network connections by pinging the USRP
network ports separately.
- Try to run uhd_usrp_probe, this should return results without errors.
- If you are still unable to probe your x4xx without errors, contact
- If you are still unable to probe your x4xx without errors, contact
Ettus support.
\subsection x4xx_resetting_boot_environment Resetting Boot Environment
@ -1424,6 +1474,8 @@ Otherwise, let the boot continue as normal.
\subsection x4xx_jtag_boot Booting X4x0 over JTAG
<b>Note: Booting from JTAG is not available for Locked FPGA variants.</b>
If the X4x0 is no longer able to boot from eMMC, it is possible to boot the
device into u-boot over JTAG. This will allow the filesystem to be reflashed
using the process described in \ref x4xx_accessing_emmc_usb.
@ -1506,15 +1558,15 @@ currently installed on the device (see \ref x4xx_updating_fpga_types).
For all devices, changing the master clock rate during a running session is not
supported. Once a UHD session is initialized, the master clock rate is fixed.
For that reason, uhd::usrp::multi_usrp::get_master_clock_rate_range() will
not return a list of multiple entries, but only the currently active
For that reason, uhd::usrp::multi_usrp::get_master_clock_rate_range() will
not return a list of multiple entries, but only the currently active
master clock rate. This behavior is identical to that of the USRP X3x0.\n
When the master clock rate or clock and time sources change, UHD needs to
perform clock reconfigurations. On X420/X440 this currently requires that UHD
restarts MPM during session creation, which may cause non-persistent
network configurations for the QSFP28 interfaces to be reset. See
\ref x4xx_getting_started_network_connectivity_ifcs for a persistent
configuration option that is maintained during MPM reboots.
restarts MPM during session creation, which may cause non-persistent
network configurations for the QSFP28 interfaces to be reset. See
\ref x4xx_getting_started_network_connectivity_ifcs for a persistent
configuration option that is maintained during MPM reboots.
In contrast to X410, when selecting a master clock rate on a USRP X420 or X440,
UHD will coerce to the next available master clock rate. Example:
@ -1584,20 +1636,20 @@ further digital down or up conversion, equals to the IQ sample rate.
│ │ ││ DAC │ │ Mixer │ │ Interpolation││ │ Block │ │ Data Rate [Bit/s]│
│ │ │└─────────┘ └─────────┘ └──────────────┘│ │ │ └──────────────────┘
└─────────────┘ └─────^────────────^────────────────────────┘ └─────────────┘
│ │
│ │
Converter NCO
│ │
│ │
Converter NCO
Clock Clock
[1..4.096 GHz] [0..4 GHz]
```
For a full clocking block diagram see \ref x4xx_too_clocking.
By default, UHD will choose the highest possible converter rate that can be
achieved with one of the available RFDC dividers (2,4,8). If an MCR can be
achieved with multiple converter rates, then the converter rate can be
overridden with the `converter_rate` device argument (see also
\ref x4xx_usage_args). The broad range of available MCR required a focus on a
By default, UHD will choose the highest possible converter rate that can be
achieved with one of the available RFDC dividers (2,4,8). If an MCR can be
achieved with multiple converter rates, then the converter rate can be
overridden with the `converter_rate` device argument (see also
\ref x4xx_usage_args). The broad range of available MCR required a focus on a
select set of MCR during testing and design validation. For the X440, these are:
| Master Clock \n Rate (MCR) | Converter \n Rate (Fc) | RFDC Divider | Digital Bandwidth \n (0.8 * MCR) | Available in\n Default Bitfile | Motivation/ \n Common Usage |
|:--:|:--:|:--:|:--:|:--:|--|
@ -1617,11 +1669,11 @@ Examples of Supported Sampling Rates
|2.048 GSps|Highest sample rate|
|125MSps|Lowest sample rate without DSP|
|2GSps, 1.5GSps, 1GSps, 500MSps, 250MSps | Even multiples of 250MSps |
|20MSps*, 40MSps*, 80MSps*, 160MSps, 320MSps | IEEE 802.11 (Wi-Fi) rates |
|30.72MSps*, 61.44MSps*, 122.88MSps*, 245.76MSps, 491.52MSps| 3GPP Wireless Communications rates|
|20MSps*, 40MSps*, 80MSps*, 160MSps, 320MSps | IEEE 802.11 (Wi-Fi) rates |
|30.72MSps*, 61.44MSps*, 122.88MSps*, 245.76MSps, 491.52MSps| 3GPP Wireless Communications rates|
\*= achievable via DDC/DUC in FPGA fabric
Note: See KB article [About Sampling Rates and Master Clock Rates for the USRP X440](https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440)
Note: See KB article [About Sampling Rates and Master Clock Rates for the USRP X440](https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440)
for the full list of supported rates. See [X440 specifications](https://www.ni.com/docs/en-US/bundle/ettus-usrp-x440-specs/page/specs.html) for additional information.
\paragraph x440_usage_mcr_dualrate Dual Rate
@ -1659,17 +1711,17 @@ auto graph = uhd::rfnoc::rfnoc_graph::make("type=x4xx,master_clock_rate=1024e6;1
for more details.
Note: Not all master clock rates can be combined. Refer to
Note: Not all master clock rates can be combined. Refer to
[About Sampling Rates and Master Clock Rates for the USRP X440]
(https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440)
(https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440)
for possible master clock rates and master clock rate combinations. When configuring
two rates, UHD will go through the following steps:
1. Coerce both MCRs to the closest possible values individually.
2. Check if those two values can be combined.
2a) If they can be combined, the session will be set up with these values.
2a) If they can be combined, the session will be set up with these values.
2b) If they cannot be combined, UHD will fall back to the MCR of radio 0 and report
this in a warning log message.
this in a warning log message.
3. The chosen MCR and converter rate values will be shown in the info log.
Note: When using dual rate on X440, the multi-tile synchronization (MTS) is disabled. That means
@ -1760,18 +1812,18 @@ FPGA. For a description of the GPIO control API, see \subpage page_x400_gpio_api
There are multiple sources that can control the state of the GPIO lines.
UHD has the capability of controlling which source each pin is driven from.
The source control block is located in the X4x0 core logic block in the FPGA,
and is also accessible via MPM. There are also local registers in the
source control block that control the state of GPIOs manually if none of the
The source control block is located in the X4x0 core logic block in the FPGA,
and is also accessible via MPM. There are also local registers in the
source control block that control the state of GPIOs manually if none of the
additionally supported control schemes are required.
Source selection is performed via an array of muxes, each accessible via an
independent register. The diagram below indicates the arrangement of muxes
Source selection is performed via an array of muxes, each accessible via an
independent register. The diagram below indicates the arrangement of muxes
controlling GPIO source selection.
\image html x4xx_dio_source_muxes.svg "X4x0 GPIO Source Control" width=60%
UHD has access to all radio-controlled blocks. In the diagram above,
this includes one ATR DIO control block and one digital interface block
UHD has access to all radio-controlled blocks. In the diagram above,
this includes one ATR DIO control block and one digital interface block
for each radio.
When ATR control is selected as the source, it uses the Daughterboard state to determine
@ -1807,9 +1859,9 @@ subdev specifications:
Label | Subdev Spec
------------|------------
DB 0 / RF 0 | A:0
DB 1 / RF 0 | B:0
DB 1 / RF 0 | B:0
The RF ports on the front panel of the X440 + FBX (xx_400 images) correspond
The RF ports on the front panel of the X440 + FBX (xx_400 images) correspond
to the following subdev specifications:
Label | Subdev Spec
@ -1823,8 +1875,8 @@ DB 1 / RF 1 | B:1
DB 1 / RF 2 | B:2
DB 1 / RF 3 | B:3
The RF ports on the front panel of the X440 + FBX (xx_1600 images) correspond
to the following subdev specifications (Note: The xx_1600 images enable the
The RF ports on the front panel of the X440 + FBX (xx_1600 images) correspond
to the following subdev specifications (Note: The xx_1600 images enable the
use of only 2 channels, corresponding to the first channel of each daughterboard):
Label | Subdev Spec
@ -1832,8 +1884,8 @@ Label | Subdev Spec
DB 0 / RF 0 | A:0
DB 1 / RF 0 | B:0
The subdev spec slot identifiers "A" and "B" are not reflected on the
front panel. They were set to match valid subdev specifications of previous
The subdev spec slot identifiers "A" and "B" are not reflected on the
front panel. They were set to match valid subdev specifications of previous
USRPs, maintaining backward compatibility.
These values can be used for uhd::usrp::multi_usrp::set_rx_subdev_spec() and
@ -2047,7 +2099,7 @@ The NI Ettus USRP X4x0 is compatible with most brands of QSFP fiber adapters. In
cases, other equipment in the systems such as 1/10/100 Gigabit Ethernet switches are
only compatible with specific brands of SFP/QSFP adapters and cables. As a general rule,
we recommend checking compatibility with the switches and network cards in your system
before purchasing an adapter.
before purchasing an adapter.
\subsection x4xx_benchmarks Data Throughput Benchmarks
@ -2111,10 +2163,10 @@ All X410 benchmarks were performed using the CG_400 FPGA image.
- Ubuntu 22.04 (6.8.0-106-generic), DPDK 21.11, with AMD Ryzen Threadripper 3960X 24-Core
Processor - 48 CPU - 3.6 GHz CPU freq - 64 GB RAM. Mellanox/NVIDIA ConnectX-5 EX 100 GbE
NIC (MCX516A-CDAT (PCIe Gen4 x16)). Mellanox/NVIDIA 3m QSFP28 MCP1600-C003E26N cables.
NIC (MCX516A-CDAT (PCIe Gen4 x16)). Mellanox/NVIDIA 3m QSFP28 MCP1600-C003E26N cables.
- Ubuntu 24.04 (6.11.0-25-generic), DPDK 23.11, with Intel I9 13900K 24-Core
Processor - 32 CPU - 5.4 GHz CPU freq - 64 GB RAM, Mellanox/NVIDIA ConnectX-6 DX, 100 GbE
NIC (MCX623106AE-CDAT (PCIe Gen4 x16)). Mellanox/NVIDIA 3m QSFP28 MCP1600-C003E26N cables.
NIC (MCX623106AE-CDAT (PCIe Gen4 x16)). Mellanox/NVIDIA 3m QSFP28 MCP1600-C003E26N cables.
\paragraph x420_benchmark_results Benchmark Results
@ -2202,18 +2254,18 @@ high rates.
\subsection x4xx_too_convrate Converter Rates
The USRP X4x0 uses a Xilinx RFSoC Gen1, whose RFDC includes a decimation/interpolation
block which can resample by a factor of up to 8. For example, if the converter
is running at 2 GHz, then the RFSoC can produce a signal at a master clock
rate of 1 Gsps, 500 Msps, or 250 Msps (it must resample at least by 2 to
convert the signal to a complex one). In the USRP X4x0 design all ADC and DAC
converter rates are identical and use the same RFDC decimation/interpolation
The USRP X4x0 uses a Xilinx RFSoC Gen1, whose RFDC includes a decimation/interpolation
block which can resample by a factor of up to 8. For example, if the converter
is running at 2 GHz, then the RFSoC can produce a signal at a master clock
rate of 1 Gsps, 500 Msps, or 250 Msps (it must resample at least by 2 to
convert the signal to a complex one). In the USRP X4x0 design all ADC and DAC
converter rates are identical and use the same RFDC decimation/interpolation
settings.
\subsubsection x410_too_convrate USRP X410
The USRP X410 only supports a few fixed master clock rates (see \ref x410_usage_mcrs),
with predefined converter rates around 3 GHz, and uses in addition to the RFDC
decimation/interpolation block also a 3/2 decimation (2/3 interpolation) block
The USRP X410 only supports a few fixed master clock rates (see \ref x410_usage_mcrs),
with predefined converter rates around 3 GHz, and uses in addition to the RFDC
decimation/interpolation block also a 3/2 decimation (2/3 interpolation) block
implemented in FPGA fabric.
\subsubsection x420_too_convrate USRP X420
@ -2223,29 +2275,29 @@ and converter rates as described in \ref x420_usage_mcrs.
\subsubsection x440_too_convrate USRP X440
The USRP X440 supports a large, finite number of master clock rates (see
\ref x440_usage_mcrs), and utilizes converter rates between 1GHz and the maximum
\ref x440_usage_mcrs), and utilizes converter rates between 1GHz and the maximum
supported converter rate of 4.096 GHz. The resulting master clock rates are
derived by decimating by 8, 4 or 2 and vice versa. The smallest possible master
clock rate is thus 125 Msps (1 GHz resampled by eight), and the maximum possible
master clock rate is 2.048 Gsps (4.096 GHz resampled by two).
\n By default, UHD will choose the largest converter rate available. This can
be overridden by specifying the `converter_rate` device argument (see also
\ref x4xx_usage_args).
\n By default, UHD will choose the largest converter rate available. This can
be overridden by specifying the `converter_rate` device argument (see also
\ref x4xx_usage_args).
After opening a UHD session the current converter rate can be read from the
After opening a UHD session the current converter rate can be read from the
rfdc_rate sensor. Example:
~~~{.cpp}
// Assumption: We are using a USRP X440, with a 1600 MHz FPGA image
auto usrp = uhd::usrp::multi_usrp::make("type=x4xx,master_clock_rate=1000e6");
// Verify selected master clock rate
std::cout << usrp->get_master_clock_rate() << std::endl; // Prints 1000.00e6
// Read 'rfdc_rate' either rx or tx sensor
// Read 'rfdc_rate' either rx or tx sensor
std::cout << usrp->get_rx_sensor('rfdc_rate').to_real() << std::endl; //Prints 4000.00e6
~~~
Note: The selected FPGA bitfile may further limit the maximum supported
master clock.
Note: The selected FPGA bitfile may further limit the maximum supported
master clock.
When using dual rate in X440, the above code snippet will only report back the
master clock rate and converter rate of radio 0. To verify configured rates in
@ -2488,8 +2540,8 @@ a loopback connection between TX and RX.
To loop in a CW tone for calibration, MPM offers the `set_dac_mux_data`
function which takes two signed 16 bit values for I and Q of the tone. Using
`set_dac_mux_enable` with parameters for daughterboard, channel number and
a value of 1 to enable transmitting this tone at the corresponding channel
`set_dac_mux_enable` with parameters for daughterboard, channel number and
a value of 1 to enable transmitting this tone at the corresponding channel
on the daughterboard. Use a value of 0 to return back to the signal generated
by UHD. The DAC mux does not affect the ATR state of the device.
From an UHD perspective it looks like no data is transmitted in TX or
@ -2500,7 +2552,7 @@ used at which the ADC self-calibration is run.
To cover corner-cases especially in X440, the ADC self calibration can
be parameterized with the following parameters (see \ref x4xx_usage_args):
- `cal_freq`: The frequency of the cal tone. Must be within the first Nyquist
- `cal_freq`: The frequency of the cal tone. Must be within the first Nyquist
zone (converter rate / 2)
- `cal_dac_mux_i`: 16 bit I value for the cal tone
- `cal_dac_mux_q`: 16 bit Q value for the cal tone