Ettus Knowledge Base - User contributions [en]

E320 Getting Started Guide

2025-07-09T09:32:31Z

FrankDietze: update mender commands

==Kit Contents==

===E320 Board-only===
{|
|style="vertical-align:top"|
* USRP E320
* Power connector (assembly required)
* 4 M3x0.5, M3x5 Standoffs
* 1 Gb Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* 1 Gb SFP+ to RJ45 Adapter
* Getting Started Guide
* Ettus Research Sticker
|[[File:e320 board only.jpg|500px|center]]
|}

===E320 Full Enclosure===
{|
|style="vertical-align:top"|
* USRP E320 in enclosure
* DC Power Supply (12V, 7A)
* 1 Gb Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* 1 Gb SFP+ to RJ45 Adapter
* Getting Started Guide
* Ettus Research Sticker
* T8 Torx Wrench
|[[File:e320 enclosure kit.jpg|500px|center]]
|}

==Verify the Contents of Your Kit==
Ensure that your kit contains all the items listed above. If any items are missing, please contact sales@ettus.com immediately.

==You Will Need==

* For Network Mode: A host computer with an 1 or 10 Gb Ethernet interface. If operating with the 10 Gb Ethernet interface, the "XG" FPGA image must be loaded before the SFP+ port will operate at 10 Gb speeds. Optionally a second 1 Gb Ethernet interface can be used to connect to the onboard ARM CPU for remote management.

* For Embedded Mode: A host computer is only required for initial device configuration, remote control and management, or data visualization. The host computer can connect to the RJ45 1 Gb port or Serial Console port to remotely access the Open Embedded Linux operating system running on the ARM CPU. Once configured, the USRP E320 can operate as a stand-alone device without a connection to a remote host computer.

* For Board-only Version: A third-party 10-14V/3A power supply, which requires assembly with the power connect components included in the kit. An assembled power supply can be purchased here: https://www.ettus.com/product/details/12V-PWR

==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 become non-functional. Take the following precautions to prevent damage to the unit.

* Never allow anything especially metal objects to touch the board while it is powered on.
* Always properly terminate the transmit port with an antenna or 50Ω load.
* Always handle the board with proper anti-static methods.
* Never allow the board to directly or indirectly come into contact with any voltage spikes.
* Never allow any water or condensing moisture to come into contact with the device.
* Always use caution with FPGA, firmware, or software modifications.
* Never touch the circuit board or heatsink while the device is powered on.
* All connections should be made/removed while is device is powered off.

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==

To use your Universal Software Radio Peripheral (USRP™), you must have software tools correctly installed and configured on your host computer. Step-by-step guides for these software tools are found in the Application Notes for Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]].

The USRP E320 requires UHD version 3.13.0.2 or later. It is strongly recommended to use the latest stable release of UHD on both the host computer and the USRP via the filesystem on the SD card. If this release fails to work in some way, then try the maintenance branch of the latest stable version. If you are operating the device in Network Mode, the version of UHD running on the host machine and E320 USRP must match to within the same maintenance release and branch. See the [https://github.com/ettusresearch/uhd UHD GitHub repository] for the latest release and maintenance branch.

==Connecting the Device==
===Interfaces Overview===
Listed below are the interfaces to connect to the USRP E320. Each interface has specific functionality, limitations and purpose.

'''Serial Console'''

The Serial Console provides a low-level interface to the ARM CPU and STM32 microcontroller, typically used for debugging. The serial console can also be used as a JTAG connection to the FPGA.

'''1 Gb RJ45 Connection'''

The 1 Gb RJ45 Connection interfaces with the on-board ARM CPU. When operated in "Network mode", this interface can optionally be used for remote control and management traffic. Regardless of the operation mode (Host vs Embedded) this interface can be used to connect to the ARM via SSH. By default, the 1 Gb RJ45 connection is configured to use a DHCP assigned IP address.

'''SFP+ Connection'''

The SFP+ Connection supports multiple interfaces for streaming high-speed, low-latency data, depending upon which FPGA image is loaded.

===Setting up a Serial Console Connection===
It is possible to gain shell access to the device using a serial terminal emulator via the Serial Console port. Most Linux, OS X, or other Unix based operating systems have a utility called <code>screen</code> which can be used for this purpose.

If you do not have <code>screen</code> installed, it can be installed via your distribution's package manager. For Ubuntu/Debian based operating systems it can be installed with the package manager <code>apt</code> such as:

sudo apt install screen

The default Baud Rate for the Serial Console is: <code>115200</code>

The exact device node you should attach to depends on your operating system's driver and other USB devices that might already be connected. Modern Linux systems offer alternatives to simply trying device nodes; instead, the OS might have a directory of symlinks under <code>/dev/serial/by-id</code>:

$ ls /dev/serial/by-id
usb-FTDI_Dual_RS232-HS-if00-port0
usb-FTDI_Dual_RS232-HS-if01-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0

NOTE: Exact names depend on the host operating system version and may differ.

Every E320 series device connected to USB will by default show up as four different devices. The devices labeled <code>"USB_to_UART_Bridge_Controller"</code> are the devices that offer a serial prompt. The first (with the <code>if00</code> suffix) connects to the <code>STM32 Microcontroller</code>, whereas the second connects to the <code>ARM CPU</code>.

If you have multiple E320 Serial Consoles connected to a single host, you may have to empirically test nodes.

Connecting to the ARM CPU can be performed with the command:

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if01-port0 115200

Upon starting the USRP E320, boot messages will appear and rapidly update. Once the boot process successfully completes, a login prompt like the following should appear:

Alchemy 2018.04 ni-e320-serial ttyPS0
ni-e320-serial login:

Enter the username: <code>root</code>

By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.

You should now be presented with a shell prompt similar to the following:

root@ni-e320-<motherboard serial #>:~#

Using the default configuration, the serial console will show all kernel log messages (which are not available when using SSH) and give access to the boot loader (U-boot prompt). This can be used to debug kernel or boot-loader issues more efficiently than when logged in via SSH.

===Connecting to the microcontroller===

Using the Serial Console interface, it is possible to connect to the STM32 microcontroller with the command below. The STM32 controls the power sequencing and several other low-level device operations.

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A69-if00-port0 115200

The STM32 interface provides a very simple prompt. The command <code>help</code> will list all available commands. A direct connection to the microcontroller can be used to hard-reset the device without physically accessing it (i.e., emulating a power button press) and other low-level diagnostics.

===Connecting to the ARM via SSH===
By default, the RJ45 1 Gb management interface is configured to be assigned a DHCP IP address.

If you have access to a network which provides a DHCP server (such as a common router's LAN), attach the RJ45 1 Gb port to this network. Details vary by vendor, however, most router management interfaces will provide a list of attached devices to the LAN including their IP address.

Without access to a router management interface, you can identify the IP address by connecting to the ARM CPU via Serial Console as detailed in the section above and running the command <code>ip a</code>:

Example Output:

<pre>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 42865sec preferred_lft 42865sec
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
</pre>

If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:

$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.50,192.168.1.100 --except-interface=lo --bind-dynamic --no-daemon

NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.

After the device has obtained an IP address, you can remotely log into it from a Linux or macOS systems with SSH, as shown below:

$ ssh root@192.168.1.51

NOTE: The IP address may vary depending on your network setup.

NOTE: The <code>root</code> password is empty/blank.

On Microsoft Windows, the SSH connection can be established using the third-party program, such as PuTTY.

After logging in, you should be presented with a shell prompt like the following:

root@ni-e320-<motherboard serial #>:~#

==Updating the Linux File System==
Before operating the device, it is strongly recommended to update to the latest version of the Embedded Linux file system. If you are operating the device in Network Mode, the version of UHD running on the host machine and E320 USRP must match.

There is two ways to update the file system for the E320 USRP:

1. Mender

2. Physically remove microSD card from device and write a new file system to the microSD card.

===File System Partition Layout===
The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition.

Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.

===Updating the file system with Mender===
Mender is third-party software that enables remote updating of the root file system without physically accessing the device (see also the Mender website https://mender.io). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Users can host their own local Mender server, or use servers hosted by Mender as a paid service; contact Mender for more information.

====Mender Update Process====
When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted. Any data stored in the root partitions will be permanently lost with a Mender update.

After updating a partition with Mender, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched, which presumably is in a working state. Another update can be launched now to correct the previous, failed update, until it works.

To obtain the file system Mender image (these are files with a <code>.mender</code> suffix), run the following command on the host computer with Internet access:

$ sudo uhd_images_downloader -t mender -t e320 --yes

Example Output:
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
301483 kB / 301483 kB (100%) e3xx_e320_mender_default-v4.4.0.0.zip
[INFO] Images download complete.

NOTE: In the output of the command, the folder destination where the images are saved is printed out.

Next, you will need to copy this Mender file system image to the USRP E320. This can be done with the Linux utility <code>scp</code>.

$ scp /usr/local/share/uhd/images/usrp_e320_fs.mender root@192.168.1.51:~/.

Note: The path and IP may different for your configuration, the command above assumes you're using the default installation path of <code>/usr/local</code> and that the E320's IP is <code>192.168.1.51</code>.

After copying the Mender file system image to the E320, connect to the E320 using either the Serial Console, or via SSH to gain shell access.

On the E320, run <code>mender install /path/to/latest.mender</code> to update the file system:

root@ni-e320-serial:~# mender install /home/root/usrp_e320_fs.mender

Example Output:

<pre>
root@ni-e320-316E375:~# mender install /home/root/usrp_e320_fs.mender
INFO[0000] Start updating from local image file: [/home/root/usrp_e320_fs.mender] module=rootfs
Installing update from the artifact of size 399640064
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device
................................ 0% 1024 KiB
................................ 0% 2048 KiB
................................ 0% 3072 KiB
[truncated for readability]
................................ 99% 389120 KiB
................................ 99% 390144 KiB
................................ 100% 390273 KiB
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device

</pre>

The artifact can also be stored on a remote server:
$ mender install <http://server.name/path/to/latest.mender>

This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:
$ reboot

If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:
$ mender commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the E320:
$ mender show-artifact

If you are using a Mender server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and you can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.

For more information on updating the file-system, refer to the E3xx page in the Devices section of the UHD Manual at http://uhd.ettus.com.

===Updating the files system by writing the disk image===
The microSD card is accessible directly on the Board-only version of the E320 USRP. The E320 Full Enclosure version must be opened with the included Torx wrench.

NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.

Please see the separate application note, [[Writing the USRP File System Disk Image to a SD Card]], for step-by-step instructions on writing the file system image to the microSD card.

==Updating the Network Configurations==
The USRP E320 systemd network configuration files are located either at: <code>/etc/systemd/network/</code>

# ls /etc/systemd/network/
eth0.network sfp0.network

or for newer versions of the file system: <code>/data/network/</code>

# ls /data/network/
eth0.network int0.network sfp0.network

For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].

The factory settings are as follows:
<pre>
eth0 (DHCP):

[Match]
Name=eth0

[Network]
DHCP=v4

[DHCPv4]
UseHostname=false

sfp0 (static):

[Match]
Name=sfp0

[Network]
Address=192.168.10.2/24

[Link]
MTUBytes=8000
</pre>

Additional notes on networking:

* Care needs to be taken when editing these files on the device, since <code>vi</code> / <code>vim</code> sometimes generates undo files (e.g. <code>/data/network/sfp0.network~</code>), that <code>systemd-networkd</code> might accidentally pick up.
* Temporarily setting the IP addresses or MTU sizes via <code>ifconfig</code> or other command line tools will only change the value until the next reboot or reload of the FPGA image.
* If the MTU of the device and host computers differ, streaming issues can occur.
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code>
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>8000</code>

For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_e320.html#e320_network_configuration

==Updating the FPGA Image==

===Network mode FPGA Image Update===
The FPGA image should match the version of UHD installed on the host computer when operated in Network mode.

Network mode FPGA image updates must be made through the RJ45 management interface.

To obtain all the FPGA images for your installed version of UHD, run the following command on the host computer with internet access:

$ sudo uhd_images_downloader -t e320 -t fpga

Example Output:

$ uhd_images_downloader -t e320 -t fpga
[INFO] Images destination: /usr/local/share/uhd/images
[INFO] No inventory file found at /usr/local/share/uhd/images/inventory.json. Creating an empty one.
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip
[INFO] Images download complete.

There is two versions of the E320 FPGA images shipped with UHD:

- <code>1G</code> for 1 Gb rates on the SFP+ port (default image)

- <code>XG</code> for 10 Gb rates on the SFP+ port

In this example, we load the <code>XG</code> variant of the FPGA image.

$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>,fpga=XG"

Example Output:

$ uhd_image_loader --args "mgmt_addr=192.168.1.51,type=e3xx,fpga=XG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.51,type=e3xx,product=e320,serial=316E375,claimed=False,skip_init=1
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 316E375
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

The FPGA is immediately updated, and this FPGA image will continue to be used. The device does not need to be power cycled to use the new image.

To load a different FPGA image (i.e. <code>1G</code>), modify the device argument <code>fpga=</code> to a value of <code>fpga=1G</code>.

To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.

$ uhd_image_loader --args "type=e3xx,mgmt_addr=<E320_RJ45_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |The Verilog code for the FPGA in the USRP E320 is open-source, and users are free to modify and customize it for their needs. However, certain modifications may result in either bricking the device, or even in physical damage to the unit. Please note that modifications to the FPGA are made at the risk of the user, and may not be covered by the warranty of the device.
|-
|}

===Embedded Mode FPGA Image Update===

It is possible to update the FPGA image when operated in Embedded mode. Connect to the ARM CPU [[#Setting_up_a_Serial_Console_Connection|via Serial Console]] or [[E320_Getting_Started_Guide#Connecting_to_the_ARM_via_SSH| via SSH]]. It is generally recommend to use SSH over the RJ45 interface for remote management.

Run the command <code>uhd_images_downloader</code> to download the FPGA images to the device's file system:

NOTE: The 1 Gb RJ45 management interface will require Internet access for this next step.

<pre>
root@ni-e320-serial:~# python3 /usr/bin/uhd_images_downloader -t e320 -t fpga
[INFO] Images destination: /usr/share/uhd/images
[INFO] No inventory file found at /usr/share/uhd/images/inventory.json. Creating an empty one.
05920 kB / 05920 kB (100%) e3xx_e320_fpga_default-g494ae8bb.zip
[INFO] Images download complete.
</pre>

NOTE: The default UHD FPGA Images destination within the E320's file-system is <code>/usr/share/uhd/images</code>. The default UHD FPGA Images destination on a typical host installation is <code>/usr/local/share/uhd/images</code>.

Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update:

<pre>
root@ni-e320-serial:~# uhd_image_loader --args "type=e3xx,fpga=1G"
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.13.1.0-0-unknown
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=e3xx,product=e320,serial=316E375,claimed=False,skip_init=1
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 316E375
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

</pre>

For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com.

==Setting Up a Streaming Connection==
The device supports multiple high-speed, low-latency interfaces on the SFP+ port for streaming samples to the host computer.

===1 Gb Streaming via SFP+ Port ===
Complete the steps below to set up a streaming connection over the 1 Gb Ethernet interface on the <code>SFP+ Port</code>.

NOTE: The <code>1G</code> FPGA image must be loaded for the <code>SFP+ Port</code> to operate at 1 Gb speeds. If the <code>XG</code> image is loaded, the port will be unresponsive at 1Gb speeds.

1. Configure your Host's 1 Gb Ethernet interface as shown below. This interface should be separate from the 1 Gb NIC/network which is connected to the 1 Gb RJ45 management interface.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 1500

NOTE: When operating the <code>SFP+ Port</code> at 1 Gb speeds, it is important to set a MTU of <code>1500</code> and not a value of <code>automatic</code>. Mismatched MTU values on either the Host or E320 may cause flow control errors. Your computer may need to be restarted for the MTU value to take effect.

2. Insert the RJ45-to-SFP+ adapter into the <code>SFP+ Port</code>.

3. Connect the SFP+ adapter on the device to an Ethernet port on the host computer using a standard Ethernet cable.

The Green LED above the <code>SFP+ Port</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

5. Verify your MTU is set correctly for 1 Gb speeds on the E320. See the section [[E320_Getting_Started_Guide#Updating_the_Network_Configurations|Updating the Network Configurations]] for additional details.

Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].

===10 Gb Streaming via SFP+ Port===
Load the <code>XG</code> FPGA image for 10 Gb streaming as detailed in the section [[E320_Getting_Started_Guide#Updating_the_FPGA_Image|Updating the FPGA Image]]. You will need to use a 10 GigE cable that can be plugged in directly to the SFP+ connector on the board.

NOTE: The <code>XG</code> FPGA image must be loaded for the <code>SFP+ Port</code> to operate at 10 Gb speeds. If the <code>1G</code> image is loaded, the port will be unresponsive at 10 Gb speeds. Mismatched MTU values on either the Host or E320 may cause flow control errors.

1. Configure your Host's 10 Gb Ethernet interface as shown below.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 8000

NOTE: When operating the <code>SFP+ Port</code> at 10 Gb speeds, it is important to set a MTU of <code>8000</code> and not a value of <code>automatic</code>. Mismatched MTU values on either the Host or E320 may cause flow control errors. Your computer may need to be restarted for the MTU value to take effect.

2. Connect the SFP+ port on the device to an Ethernet port on the host computer using a 10 Gb SFP+ copper or fiber cable.

The Green LED above the <code>SFP+ Port</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

5. Verify your MTU is set correctly for 10 Gb speeds on the E320. See the section [[E320_Getting_Started_Guide#Updating_the_Network_Configurations|Updating the Network Configurations]] for additional details.

Proceed to the next section [[E320_Getting_Started_Guide#Verifying_Device_Operation|Verifying Device Operation]].

==Verifying Device Operation==
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the include UHD utilities.

===Subdevice Specification Mapping===
The USRP E320 contains 2 channels, each represented on the front panel as <code>RF A</code> and <code>RF B</code>. Below is the <code>subdev</code> mapping of RF Ports.

'''E320'''
* RF A = A:0
* RF B = A:1

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

===Supported Sample Rates===

The USRP E320 supports master clock rate from 200 kHz to 61.44 MHz and can be changed by adding <code>master_clock_rate=<rate></code> to the default UHD args. The default master clock rate is 16 MHz.

Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.

It is important to understand that strictly-integer decimation and interpolation are used within USRP hardware to meet the requested sample rate requirements of the application at hand. That means that the desired sample rate must meet the requirement that master-clock-rate/desired-sample-rate be an integer ratio. Further, it is strongly desirable for that ratio to be even. This ratio is the decimation (down-conversion) or interpolation (up-conversion) factor. The decimation or interpolation factor may be between 1 and 1024. There are further constraints on the decimation or interpolation factor. If the decimation or interpolation factor exceeds 128, then it must be evenly divisible by 2. If the decimation or interpolation factor exceeds 256, then it must be evenly divisible by 4.

Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes

===Probe the USRP E320===
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.

From your host computer, run the command <code>uhd_usrp_probe</code>:

<pre>
$ uhd_usrp_probe --args "addr=192.168.10.2"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=316E375,claimed=False,addr=192.168.10.2
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1343 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1335 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
_____________________________________________________
/
| Device: E300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-e320-316E375
| | eeprom_version: 2
| | mpm_version: 3.13.1.0-gd3b7e90a
| | pid: 58144
| | product: e320
| | rev: 2
| | rpc_connection: remote
| | serial: 316E375
| | type: e3xx
| | MPM Version: 1.2
| | FPGA Version: 3.0
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_locked, temp_main_power, ref_locked, temp_rf_channelA, temp_fpga, gps_sky, temp_rf_channelB, fan, temp_internal, gps_tpv, gps_time
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Neon
| | | | Antennas: RX2, TX/RX
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock
| | | | Freq range: 70.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Neon
| | | | Antennas: RX2, TX/RX
| | | | Sensors: lo_locked, ad9361_temperature, rssi, lo_lock
| | | | Freq range: 70.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: AD9361 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Neon
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9361_temperature
| | | | Freq range: 47.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Neon
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9361_temperature
| | | | Freq range: 47.000 to 6000.000 MHz
| | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB
| | | | Bandwidth range: 20000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: AD9361 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * DDC_0
| | | * DUC_0

</pre>

===ASCII Art Example===
The UHD driver includes several example programs, which may serve as test programs or the basis for your application program. The source code can be obtained from the UHD repository on github at: https://github.com/EttusResearch/uhd/tree/master/host/examples

You can quickly verify the operation of your USRP E320 by running the <code>rx_ascii_art_dft</code> UHD example program.

The <code>rx_ascii_art_dft</code> utility is a simple console based, real-time FFT display tool. It is not graphical in nature, so it can be easily run over an SSH connection within a terminal window, and does not need any graphical capability, such as X Windows, to be installed. It can also be run over a serial console connection, although this is not recommended, as the formatting may not render correctly.

You can run a simple test of the E320 USRP by connecting an antenna and observing the spectrum of a commercial FM radio station in real-time, following the steps below:

1. Attach an antenna to the <code>RF A / RX2</code> antenna port of the E320.

2. From your host computer, run the command:

$ /usr/local/lib/uhd/examples/rx_ascii_art_dft \
--args "addr=192.168.10.2" \
--freq 98.5e6 \
--rate 2e6 \
--gain 40 \
--ref-lvl="-30" \
--dyn-rng 90 \
--ant "RX2" \
--subdev "A:0"

NOTE: Modify the commandline argument <code>freq</code> above to specify a tuning frequency for a strong local FM radio station. You will also need to update the IP Address to match your device IP.

3. You should see a real-time FFT display of 2 MHz of spectrum, centered at the specified tuning frequency.

4. Type "<code>Q</code>" to stop the program and to return to the Linux command line.

5. You can run with the <code>--help</code> argument to see a description of all available command-line options.

Example Output:

<pre>
$ ./rx_ascii_art_dft --args "addr=192.168.10.2" --freq 98.5e6 --rate 2e6 --gain 40 --ref-lvl="-30" --dyn-rng 90 --ant "RX2" --subdev "A:0"

Creating the usrp device with: addr=192.168.10.2...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.0-1-gd3b7e90a
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=316E375,claimed=False,addr=192.168.10.2
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1334 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1325 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000003320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [MPM.PeriphManager] init() called with device args `product=e320,mgmt_addr=192.168.10.2'.
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
[INFO] [0/Radio_0] Performing CODEC loopback test...
[INFO] [0/Radio_0] CODEC loopback test passed
Using Device: Single USRP:
Device: E300-Series Device
Mboard 0: ni-e320-316E375
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Neon
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Neon
TX Channel: 1
TX DSP: 1
TX Dboard: A
TX Subdev: Neon

Setting RX Rate: 2.000000 Msps...
Actual RX Rate: 2.000000 Msps...

Setting RX Freq: 98.500000 MHz...
Actual RX Freq: 98.500000 MHz...

Setting RX Gain: 40.000000 dB...
Actual RX Gain: 40.000000 dB...

Checking RX: all_los: locked ...

Done!
</pre>

===Benchmarking your system===
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.

A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.

====1 Gb Interface====
NOTE: This example requires the <code>1G</code> FPGA image to be loaded.

This example will test one full-duplex stream using "RFA/A:0", at a rate of 2 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2" \
--duration 60 \
--channels "0" \
--rx_rate 2e6 \
--rx_subdev "A:0" \
--tx_rate 2e6 \
--tx_subdev "A:0"

This example will test two full-duplex streams at 2 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2" \
--duration 60 \
--channels "0,1" \
--rx_rate 2e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 2e6 \
--tx_subdev "A:0 A:1"

This example will test two full-duplex streams at 12.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=25e6" \
--duration 60 \
--channels "0,1" \
--rx_rate 12.5e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 12.5e6 \
--tx_subdev "A:0 A:1"

When streaming samples over a 1 Gb transport link, the maximum accumulative rate for all channels is 25 MS/s with a <code>sc16</code> OTW format. To achieve higher streaming rates, it is recommended to use the 10 Gb interfaces.

====10 Gb Interface ====
NOTE: These examples require the <code>XG</code> FPGA image to be loaded.

This example will test one full-duplex stream using "RFA/A:0", at a rate of 61.44 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \
--duration 60 \
--channels "0" \
--rx_rate 61.44e6 \
--rx_subdev "A:0" \
--tx_rate 61.44e6 \
--tx_subdev "A:0"

This example will test two full-duplex stream, at a rate of 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "addr=192.168.10.2,master_clock_rate=61.44e6" \
--duration 60 \
--channels "0,1" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 A:1" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 A:1"

==USRP E320 Device Specific Operations==

===Turning the Device Off/On===
To avoid damaging the file system and causing any corruption, do not turn the device off with the power button without first shutting down the system. Use this command to cleanly and properly shut the system down:

shutdown -h now

=== Autoboot ===

The USRP E320 can be configured to power on and boot automatically when power is applied. By default, autoboot is disabled on all USRPs that support it. To control autoboot on the USRP E320, first determine the current value for <code>MCU_FLAGS[0]</code> by running <code>eeprom-dump</code>; the meaning of the <code>MCU_FLAGS[0]</code> [https://files.ettus.com/manual/page_usrp_e3xx.html#e320_eeprom_flags is found in the UHD manual]. The least significant bit when <code>MCU_FLAGS[0]</code> is viewed as a binary value controls the autoboot.

For example
<pre>
root@ni-e320-XXXXXXX:~# eeprom-dump
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
</pre>
shows <code>-- MCU_FLAGS[0]: 00000008</code>; <code>0x08</code> (<code>0b00001000</code> in binary) indicates that autoboot is disabled. If this value were <code>0x09</code> (<code>0b00001001</code> in binary) it would indicate that autoboot is enabled because least significant bit is 1; same would be true if this value is <code>0x01</code> (<code>0b00000001</code> in binary).

To enable or disable autoboot, copy the existing value of <code>MCU_FLAGS[0]</code> retrieved by <code>eeprom-dump</code> into <code><MCU_FLAGS[0]></code> below and run the command:

* Disable autoboot on USRP E320 (sets least significant bit to 0), regardless of whether currently enabled or disabled:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> & ~0x1))
</pre>
Thus, for the value noted above (autoboot is already disabled, so this command doesn't actually change anything):
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 & ~0x1))
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
-- Reading back
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: 448fb572 (matches)
</pre>

* Enable autoboot on USRP E320 (sets least significant bit to 1), regardless of whether currently enabled or disabled. For example when changing from autoboot disabled to enabled:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x<MCU_FLAGS[0]> | 0x1))
</pre>
Thus, for the value noted above:
<pre>
root@ni-e320-XXXXXXX:~# eeprom-set-flags $((0x00000008 | 0x1))
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000008
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: cbd79a61 (matches)
-- Reading back
-- PID/REV: e320 0002
-- MCU_FLAGS[0]: 00000009
-- MCU_FLAGS[1]: 00000000
-- MCU_FLAGS[2]: 00000000
-- MCU_FLAGS[3]: 00000000
-- Serial: XXXXXXX
-- eth_addr0: XX:XX:XX:XX:XX:XX
-- eth_addr1: XX:XX:XX:XX:XX:XX
-- eth_addr2: XX:XX:XX:XX:XX:XX
-- DT-Compat/MCU-Compat: 0000 0002
-- CRC: 448fb572 (matches)
</pre>

If setting this flag ''does not'' allow autoboot control on the USRP E320, then the device boot firmware needs to be updated. This update is accomplished via the following instructions.

On the USRP E320 via ssh or serial terminal, [https://files.ettus.com/binaries/misc/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-7.tar.gz download the update MCU firmware] and extract it:
<pre>
root@ni-e320-XXXXXXX:~# curl https://files.ettus.com/binaries/misc/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-7.tar.gz | tar zxf -
</pre>
This will create a directory <code>upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-7</code>. Go into this directory and run the firmware flash script:
<pre>
root@ni-e320-XXXXXXX:~# cd upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-7
root@ni-e320-XXXXXXX:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-7# ./flash-firmware.sh
This script updates the microcontroller firmware (RO part). The change is
persistent across power cycles. Incorrect updates can only fixed be a manual
process which requires opening the enclosure.

Updating the microcontroller firmware (RO part) is only required if the Ettus
Research support told you to do so.

Press "y" to continue
</pre>
At the prompt, press the <code>y</code> key to continue. Pressing any other key aborts the procedure:
<pre>
Press "y" to continue n

aborting
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-7#
</pre>
Pressing the <code>y</code> key:
<pre>
Press "y" to continue y

This script will flash ec-neon-rev3.RO.flat to the device
old RO version: neon_vX.X.XXXX-XXXXXXX
new RO version: neon_v1.1.7358-a190641

Press "y" to continue
</pre>
At the prompt, press the <code>y</code> key ''again'' to continue. Pressing any other key aborts the procedure as before.
<pre>
Press "y" to continue y

./ectool --interface=dev reboot_ec RW
./ectool --interface=dev flashread 0x0 65536 ec-neon-rev3.RO.flat.old
Reading 65536 bytes at offset 0...
done.
./ectool --interface=dev flasherase 0x0 65536
Erasing 65536 bytes at offset 0...
done.
./ectool --interface=dev flashwrite 0x0 ec-neon-rev3.RO.flat
Reading 49592 bytes from ec-neon-rev3.RO.flat...
Writing to offset 0...
Write size 112...
done.

copying new firmware files
'ec-neon-rev3.bin' -> '/lib/firmware/ni/ec-neon-rev3.bin'
'ec-neon-rev3.RW.bin' -> '/lib/firmware/ni/ec-neon-rev3.RW.bin'
root@ni-e320-317F9BF:~/upgrade_mcu_neon_v1.1.7358-a190641-musl-glibc-rev3-7#
</pre>

Once the script is done, reboot the USRP (e.g., <code>shutdown -r now</code>), and when it comes up the autoboot flag should now work as desired. If these instructions ''do not'' work, then email [mailto:support@ettus.com support@ettus.com] and ask for alternative instructions on how to update the USRP E320 RO and RW boot firmware such that this EEPROM flag setting is honored.

===Default Password===
The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-e320-serial:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

==Known Issues==
===Problematic NICs===
In some streaming modes, the Intel I219-LM NIC can produce flow control and sequence errors. It is recommended to use a USB3 to 1 Gb Ethernet Adapter for hosts which have an I219-LM NIC.

==Technical Support and Community Knowledge Base==
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.

We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.

Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].

Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].

Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].

The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].

==Legal Considerations==
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]
[[Category:E320]]

Ettus USRP E300 Embedded Family Getting Started Guides

2025-07-09T09:31:28Z

FrankDietze: update mender commands

==Kit Contents==

===E310===

{|
|style="vertical-align:top"|
* E310 USRP
* Power supply
* 2x SMB-to-SMA adapter
* 1 Gigabit Ethernet cable
* USB2-to-microUSB cable
* Imaged microSD card
* Getting started guide
|[[File:Product e310.png|250px|center]]
|}

===E312===

{|
|style="vertical-align:top"|
* E312 USRP
* Power supply
* 2x SMB-to-SMA adapter
* 1 Gigabit Ethernet cable
* USB2-to-microUSB cable
* Imaged microSD card
* Getting started guide
|[[File:Product e312.png|250px|center]]
|}

===E313===

{|
|style="vertical-align:top"|
* Protective caps for input ports
* Surface mounting accessory
* Pole mounting accessory
* End conduit interface for USB devices
* Waterproof sleeve for DC power connector
* Waterproof sleeve for PoE (RJ45) connector
* Torx T-20 key
* Mounting accessory assembly guide
* Imaged microSD card
|[[File:E313.png|250px|center]]
''The USRP E313 is a fully assembled device that includes an USRP E310.''
|}

==Verify the Contents of Your Kit==

Make sure that your kit contains all the items listed above. If any items are missing, please contact your sales agent or Ettus Research Technical support immediately.

==You Will Need==

* A host computer with an available USB 2.0 or 3.0 port

==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 easily cause the device to become non-functional. Listed below are some examples of actions which can prevent damage to the unit:

*Never allow metal objects to touch the circuit board while powered.
*Always properly terminate the transmit port with an antenna or 50Ω load.
*Always handle the board with proper anti-static methods.
*Never allow the board to directly or indirectly come into contact with any voltage spikes.
*Never allow any water, or condensing moisture, to come into contact with the boards.
*Always use caution with FPGA, firmware, or software modifications.
{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than 0 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==

In order to use your Universal Software Radio Peripheral (USRP™), you must have the software tools correctly installed and configured on your host computer. A step-by-step guide for doing this is available at the Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]] Application Notes. See the [[Ettus_USRP_E300_Embedded_Family_Hardware_Resources#Hardware_Specifications|Hardware Specifications]] section of the USRP Embedded Series Hardware Resources for additional details on which version of the USRP Hardware Driver, UHD, is required. It is recommended to use the latest stable version of UHD that is available.

If you have a USB stick with the [[Live SDR Environment]] installed on it, then you may boot your host computer from that. The LiveUSB SDR Environment does not require anything to be installed on your host computer, and contains a Linux-based environment with the UHD software and the GNU Radio framework already installed. More information about the [[Live SDR Environment]] is available at the [[Live SDR Environment Getting Started Guides]] page.

== USRP E31x Device Specific Operations ==

=== Powering On the Hardware ===

With older USRP E31x devices running Firmware version 1, connecting the AC power supply to the device will cause the unit to turn on and boot. By default with Firmware 2.0 and newer the device no longer turns on when AC power is plugged in. To determine the firmware version, once the device is fully booted, login to it and execute

$ dmesg | grep -i "firmware version"

If this is the first time powering on a USRP E312 (with battery), allow the battery to fully charge before disconnecting the AC power source.

Once the device has completed the boot process, you are ready to start using the device over your preferred method of connectivity (Serial Console, Network, or USB peripherals)!

=== Turning the Device Off/On ===

You can power the device on and off by pressing the power button. To power the device off, hold the power button down until the button’s LED turns off -- this will take a couple of seconds, and then another 15 seconds for the device to fully shut down. To turn the device on, hold down the power button until the LED turns on.

To avoid damaging the file system and causing any corruption, do not turn the device off with the power button without first shutting down the system. Use this command to cleanly and properly shut the system down:

$ shutdown -h now

=== Autoboot ===

The USRP E31x can be configured to power on and boot automatically when power is applied. If the firmware is older than 2.0 then it will ''probably'' need to be updated for autoboot to work reliably; email [mailto:support@ettus.com support@ettus.com] for more information.

To control autoboot on the USRP E31x, first determine the version of UHD, for example by running

$ uhd_config_info --version

on the device. The UHD version determines the filesystem location where the <code>autoboot</code> file is located.

* For UHD 4 and newer

To enable autoboot:

$ echo 1 > /sys/devices/soc0/fpga-full/fpga-full:pmu/autoboot

To disable autoboot:

$ echo 0 > /sys/devices/soc0/fpga-full/fpga-full:pmu/autoboot

* For UHD 3.15 and older:

To enable autoboot:

$ echo 1 > /sys/devices/axi_pmu.3/autoboot

To disable autoboot:

$ echo 0 > /sys/devices/axi_pmu.3/autoboot

Settings take place immediately; no reboot is required.

=== Default Password ===

The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-e3x0-SERIAL:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

==Serial Console Connectivity==

The easiest way to first communicate with your E31x device is by using the USB Serial Console. Connect a microUSB cable to the Serial Console port on the E31x and connect the other end to a PC. The console will appear as an “FTDI Serial Device” thus, it will likely appear as a ttyUSB device in Linux or a COM port on Windows. In Windows, you will need to edit the properties of the device in ‘Device Manager’ and ‘Enable VCP’. On the PC, open a serial terminal to the E31x using the following parameters: Baud Rate:115200, Data:8bit, Parity: None, Stop:1bit, Flow Control:None.

On Linux, the following command will typically handle the serial connection:

sudo screen /dev/ttyUSB0 115200

You may have to change the device name.

For additional information about using the serial console and instructions for communicating with the device over other methods (such as connecting with SSH over the network or using and LCD screen, keyboard, and mouse), please refer to the UHD Manual online: https://files.ettus.com/manual/page_usrp_e3xx.html

==Network Connectivity==

By default, the E31x device will run a DHCP client on its 1 Gigabit Ethernet port. Assuming your network resolves hostnames (depends on your routers / switches), if you connect the device to your network, you should see it appear with the hostname ettuse300.You can then access the device over SSH.

If the hostname does not resolve, you can discover the IP address by logging into the device over the serial connection, or checking your network’s DHCP tables.

Once you have logged in to the device, you can reconfigure the network settings (e.g., you could configure it for a static IP address, if you wish).

==Updating the Linux File System==

Before operating the device, it is strongly recommended to update to the latest version of the Embedded Linux file system. If you are operating the device in Network Mode, the version of UHD running on the host machine and E310 USRP must match.

There are two ways to update the file system for the E310 USRP:

1. Mender, which is available starting with UHD 4.0.0.0 release only. If you are using UHD 3.15 or prior you'll need to update the microSD card to UHD4 before being able to use Mender to do updates.

2. Physically remove microSD card from device and write a new file system to the microSD card.

NOTE: File System Partition Layout

The SD Card is divided into four partitions. There are two root file system partitions, a "boot" partition and a "data" partition.

Any data you would like to preserve through Mender updates should be saved to the "data" partition, which is mounted at <code>/data</code>.

===1. Updating the file system with Mender===

Mender is third-party software that enables remote updating of the root file system without physically accessing the device (see also the Mender website https://mender.io/ ). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Users can host their own local Mender server, or use servers hosted by Mender as a paid service; contact Mender for more information.

====Mender Update Process====

When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted. Any data stored in the root partitions will be permanently lost with a Mender update.

After updating a partition with Mender, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched, which presumably is in a working state. Another update can be launched now to correct the previous, failed update, until it works.

The USRP E31x release images come in two varieties, sg1 and sg1. The variety that you will need depends on the product number of your E31x, which is printed on the bottom of the device. You must use the appropriate files for your specific device. Incorrect files will not work, and will only boot as far as the U-Boot boot loader before stopping.

For the E310, the product number will be <code>156333X-01L</code>, where X is a letter from A to Z. For devices where X is A, B, C, D, use the <code>sg1</code> files. For devices where X is E or later, use the <code>sg3</code> files.

For the E312, the product number will be <code>140605X-01L</code>, where X is a letter from A to Z. All E312 USRPs use the <code>sg3</code> files.

To obtain the file system Mender image (these are files with a <code>.mender</code> suffix), run the following command on the host computer with Internet access:

$ sudo uhd_images_downloader -t mender -t e310 -t sg# --yes

where "sg#" is the correct file type as found above, with "#" being either 1 or 3. Example Output:

$ sudo uhd_images_downloader -t mender -t e310 -t sg3 --yes
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
292014 kB / 292014 kB (100%) e3xx_e310_sg3_mender_default-v4.0.0.0.zip
[INFO] Images download complete.

NOTE: In the output of the command, the folder destination where the images are saved is printed out.

NOTE: Regardless of which file type is specified, the extracted mender file will have the same name: <code>usrp_e310_fs.mender</code>.

Next, you will need to copy this Mender file system image to the USRP E310. This can be done with the Linux utility <code>scp</code>.

Example code to execute:

$ scp /usr/local/share/uhd/images/usrp_e310_fs.mender root@192.168.1.51:~/.

Note: The path and IP may different for your configuration, the command above assumes you're using the default installation path of <code>/usr/local</code> and that the E310's IP is <code>192.168.1.51</code>.

After copying the Mender file system image to the E310, connect to the E310 using either the Serial Console, or via SSH to gain shell access.

On the E310, run <code>mender install /path/to/latest.mender</code> to update the file system:

root@ni-e310-serial:~# mender install /home/root/usrp_e310_fs.mender

Example Output:

<pre>
root@ni-e310-serial:~# mender install /home/root/usrp_e310_fs.mender
INFO[0000] Start updating from local image file: [/home/root/usrp_e310_fs.mender] module=rootfs
Installing update from the artifact of size 399640064
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device
INFO[0000] partition /dev/mmcblk0p3 size: 2046820352 module=block_device
................................ 0% 1024 KiB
................................ 0% 2048 KiB
................................ 0% 3072 KiB
[truncated for readability]
................................ 99% 389120 KiB
................................ 99% 390144 KiB
................................ 100% 390273 KiB
INFO[0740] wrote 2046820352/2046820352 bytes of update to device /dev/mmcblk0p3 module=device
INFO[0744] Enabling partition with new image installed to be a boot candidate: 3 module=device
</pre>

The artifact can also be stored on a remote server:
$ mender install <http://server.name/path/to/latest.mender>

This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:
$ reboot

If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:
$ mender commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the E310:
$ mender show-artifact

If you are using a Mender server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and you can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.

For more information on updating the file-system, refer to the [https://files.ettus.com/manual/page_usrp_e3xx.html UHD Manual].

=====Troubleshooting Mender Update=====

When updating an E31x USRP using mender, it is possible that the update will not apply. For example, if the E31x v3.15.0.0 bootloader is misconfigured then it will not boot into an upgraded mender image. There are 2 solutions to this:

A. Reimage SD card with full sdimg using dd or bmaptool

This is the recommended solution. Follow the steps to [[Writing the USRP File System Disk Image to a SD Card|update using the sdimg]]. E31x v4.0.0.0 and later contains the bootloader fix to enable future mender updates.

B. Manually reconfigure bootloader

This solution requires some effort, but isn't too difficult. That said, because the SD card is easily accessible on most E31x this is not the recommended solution.

1) Connect to the [[E310/E312_Getting_Started_Guides#Serial_Console_Connectivity|E31x via serial]]

2) Boot the device and quickly enter "noautoboot" into the serial console. It can be helpful to have "noautoboot" copied to the clipboard. If completed successfully, you should have a prompt like this:

Automatic boot in 3s...
Enter 'noautoboot' to enter prompt without timeout
ni-e31x-uboot>

If you don't get this prompt, restart the device and try again.

3) Configure the bootargs to support mender updates

setenv bootargs 'root=${mender_kernel_root} rw rootwait uio_pdrv_genirq.of_id=usrp-uio'
saveenv

4) Reboot device and apply mender image

NOTE: This solution may brick the E31x USRP if done incorrectly. To unbrick the USRP, follow the solution of overwriting the full SD card image.

===2. Updating the files system by writing the disk image===

The microSD card is accessible directly on the Board-only version of the E310 USRP. The E310 Full Enclosure version must be opened with the included Torx wrench.

NOTE: This method will overwrite all data saved on the microSD card, including any data saved to the <code>/data</code> partition.

Please see [[Writing the USRP File System Disk Image to a SD Card|this application note]] for step-by-step instructions on writing the file system image to the microSD card.

==Subdevice Specification Mapping==

===E310/E312/E313===

The USRP E31x contains 2 channels, each represented on the front panel as <code>TRX-A / RX2-A</code> and <code>TRX-B / RX2-B</code>. Below is the <code>subdev</code> mapping of RF

====UHD <3.15.x.x====
* TRX-A / RX2-A = A:0
* TRX-B / RX2-B = B:0

====UHD 3.15.x.x+====
* TRX-A / RX2-A = A:0
* TRX-B / RX2-B = A:1

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

==Example Programs==
The UHD driver includes several example programs, which may serve as test programs or the basis for your application program. These example programs are already installed on the E31x device, and the source code can be obtained from the UHD repository on GitHub at: https://github.com/EttusResearch/uhd/tree/master/host/examples

==Test and Verify the Operation of the USRP==
You can quickly verify the operation of your USRP E31x by running the <code>rx_ascii_art_dft</code> UHD example program.
The <code>rx_ascii_art_dft</code> utility is a simple console based, realtime FFT display tool. It is not graphical in nature, so it can be easily run over an SSH connection within a terminal window, and does not need any graphical capability, such as X Windows, to be installed. It can also be run over a serial console connection, although this is not recommended, as the formatting may not render correctly.

You can run a simple test of the E31x device by connecting an antenna and observing the spectrum of a commercial FM radio station in realtime. Please follow the steps listed below.

1. Attach an antenna to the RX2A antenna port of the E31x.

2. Log into the E31x from an external host computer over Ethernet using an SSH client.

3. At a terminal prompt running on the E31x, run:

/usr/lib/uhd/examples/rx_ascii_art_dft --freq 88.1e6 --rate 400e3 --gain 30 --ref-lvl -30

4. Modify the commandline argument "<code>freq</code>" above to specify a tuning frequency for a strong local FM radio station.

5. You should see a realtime FFT display of 400 KHz of spectrum, centered at the specified tuning frequency.

6. Type "<code>Q</code>" or <code>Ctrl-C</code> to stop the program and to return to the Linux command line.

7. You can adjust the size of your terminal window and then rerun the command to enlarge or shrink the FFT display.

8. You can run with the "help"option to see a description of all available commandline options.

Additional information is available at the [[Verifying the Operation of the USRP Using UHD and GNU Radio]] Application Note.

==Battery (E312 Only)==
The USRP E312 is equipped with an integrated 3.7V, 3200mAh lithiumion battery cell. After unboxing the USRP E312 , plug in the power adapter to an AC power source and fully charge the battery. This process with take approximately 2 hours. Do not leave the USRP E312 unit plugged in for more than 24 hours.

The status LED in the power button indicates the power and charge status of the battery:

Off: Indicates device is off and not charging.
*Slow Blinking Green: Indicates device is off and charging.
*Fast Blinking Green: Indicates device is on and charging.
*Solid Green: Indicates device is on and not charging (Battery is finished charging).
*Solid Orange: Indicates device is on and discharging.
*Fast Blinking Orange: Indicates device is on, discharging, and charge is below 10% charge.
*Fast Blinking Red: Indicates an error code:

#Low Voltage Error
#Regulator Low Voltage Error
#FPGA Power Error
#DRAM Power Error
#1.8V Power Rail Error
#3.3V Power Rail Error
#Daughterboard / TX Power Error
#Charger Error
#Charger Temperature Error
#Battery Low Error
#Fuel Gauge Temperature Error
#Global (Enclosure) Temperature Error

The battery life of the USRP E312 in idle mode is approximately 5 1/2 hours. The battery will enable the USRP E312 to operate for approximately 2 hours 20 minutes, when transmitting and receiving on both channels (2x2 MIMO), with maximum gain settings, at 5 GHz center frequency, and 1 MS/s sample rate. When the power button status LED is in the “Fast Blinking Orange” mode, plug the USRP E312 into an AC power source as soon as possible to recharge the battery.

If the power button status LED indicates a “Low Voltage Error” (codes 1, 2, 3, 4, 5, 6, 7) or a “Battery Low Error” (code 10), plug the USRP E312 into an AC power source as soon as possible to recharge the battery.

When the power button status LED indicates at “Temperature Error” or “Charger Error” (codes 8, 9, 11, or 12), power off the USRP E312 unit and allow it to cool down to room temperature. Then, plug in the USRP E312 to and AC power source and fully charge the battery.

If error codes persist after cooling down and/or recharging the USRP E312, please contact [mailto:support@ettus.com support@ettus.com].

You can purchase a replacement battery for the E312 at [https://www.ettus.com/product/details/E312-battery https://www.ettus.com/product/details/E312-battery].

An Application Note covering the replacement of the E312 battery can be found at [[USRP E312 Battery Replacement Instructions]].

==Battery Calibration Procedure==
In order for the battery gauge to give a usable indication of remaining charge it needs to be calibrated. The procedure for calibration is as follows:

#Completely charge the battery.
#Type: <code>echo 3200000 >/sys/class/power_supply/BAT/charge_now</code>
#Unplug AC power.
#Replug AC power, and wait until charging completes.

==Battery Safety Information==
To ensure proper use of the battery, please read the the battery specification sheet. This document is available at: [[Media:34118 datasheet.pdf]]

Because batteries utilize a chemical reaction, battery performance will deteriorate over time even if stored for a long period of time without being used. In addition, if the various usage conditions such as charge, discharge, ambient temperature, etc. are not maintained within the specified ranges, the life expectancy of the battery may be shortened or the device in which the battery is used may be damaged by electrolyte leakage.

===Handling===
*Do not expose the battery to flame or dispose of it in a fire.
*Do not put the battery in a charger or equipment with the wrong terminals connected.
*Do not short circuit the battery.
*Avoid excessive physical shock or vibration.
*Do not disassemble or deform the battery.
*Do not immerse in water.
*Do not use the battery mixed with other different make, type, or model batteries.
*Keep out of the reach of children.
*Do not use the battery if it appears damaged.

===Charge and Discharge===
*Always charge the battery while it is installed in the USRP E312 and only use the DC power supply provided in the USRP E312 kit.
*Do not leave the battery charging for longer than 24 hours.
*Never use a modified or damaged USRP E312 DC power supply to charge the battery.

===Storage===
*Store the battery in a cool, dry, and well-ventilated area.

===Disposal===
*Regulations vary for different countries. Dispose of the battery in accordance with local regulations.

==Technical Support and Community Knowledge Base==
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.

We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.

Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].

Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].

Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].

The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].

==Legal Considerations==
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]
[[Category:E310]]
[[Category:E312]]
[[Category:E313]]

USRP X410/X440 Getting Started Guide

2025-07-09T09:30:09Z

FrankDietze: update mender commands

==Kit Contents==
===X4x0===
{|
|style="vertical-align:top"|
* NI Ettus USRP X410 or X440
* DC Power Supply (12V, 20A)
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to USB-C Cable (1m)
* Getting Started Guide URL (QR Code)
* Safety, Environmental, and Regulatory Information
||[[File:X410.jpg|450px|center]]
||[[File:X440.jpg|450px|center]]
|}

==USRP X440 Design Considerations==
* https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440

==You Will Need==
* For Network Mode: A host computer with an available 1 or 10 Gigabit Ethernet interface for sample streaming. In addition to the Ethernet interface used for sampling streaming, your host computer will require a separate 1 Gigabit Ethernet interface for command and control streaming.

* For Stand-Alone Embedded Mode: 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.

==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 become non-functional. Take the following precautions to prevent damage to the unit.

* Never allow metal objects to touch the circuit board while powered.
* Always properly terminate the transmit port with an antenna or 50Ω load.
* Always handle the board with proper anti-static methods.
* Never allow the board to directly or indirectly come into contact with any voltage spikes.
* Never allow any water or condensing moisture to come into contact with the device.
* Always use caution with FPGA, firmware, or software modifications.

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |X410: Never apply more than +14 dBm continuous <=3GHz, +17 dBm continuous >3GHz, or +20dBm more than 5 minutes >3GHz of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |X440: Never apply more than +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 of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |X410: Always use at least 30dB attenuation if operating in loopback configuration.
|-
|}

==Install and Setup the Software Tools on Your Host Computer==
In order to use your Universal Software Radio Peripheral (USRP™), you must have the software tools correctly installed and configured on your 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 the UHD manual about [https://files.ettus.com/manual/page_install.html Binary Installation]. 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 the Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]] Application Notes.

To find the latest release of UHD, see the UHD repository at https://github.com/EttusResearch/uhd.

The USRP X410 requires UHD version 4.1 or later.
The USRP X440 requires UHD version 4.5 or later.

'''When you receive a brand-new device, it is strongly recommended that you download the latest filesystem image from the Ettus Research website update the unit. It is not recommended that you use the filesystem from the factory as-is. Instructions on downloading the latest filesystem image and updating it is listed below.'''

'''Note that if you are operating the device in Network Mode, the version of UHD running on the host computer and the USRP X4x0 must match.'''

==Assembling the X4x0==
Inside the kit you will find the X4x0 and an X4x0 power supply. Plug these in, connect the 1GbE RJ45 interface to your network, and power on the device by pressing the power button.

==The STM32 Microcontroller==

The STM32 microcontroller (also referred to as the "SCU") controls various low-level features of the X4x0 series motherboard: It controls the power sequencing, reads out fan speeds and some of the temperature sensors. It is connected to the RFSoC via an I2C bus. It is running software based on Chromium EC.

It is possible to log into the STM32 using the serial interface (see Connecting to the Microcontroller). This will allow certain low-level controls, such as remote power cycling should the CPU have become unresponsive for whatever reason.

===Updating the SCU===

The writable SCU image file is stored on the filesystem under /lib/firmware/ni/ec-titanium-revX.RW.bin (where X is a revision compatibility number). To update, simply replace the .bin file with the updated version and reboot.

==eMMC Storage==

The main non-volatile storage of the USRP is an eMMC:

* USRP X410: 16 GB (Module Revision H or earlier) or 32 GB (Module Revision J and later)

* USRP X440: 16 GB (Module Revision D or earlier) or 32 GB (Module Revision E and later)

This storage can be made accessible as a USB Mass Storage device through the USB-OTG connector on the back panel.

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 modification.
A data partition, mounted in /data. This is the only partition that is not erased during file system updates.
Two identical 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). The reason there are two of these is to enable remote updates: An update running on one partition can update the other one without any effect to the currently running system. Note that the system partitions are erased during updates and are thus unsuitable for permanently storing information.
Note: It is possible to access the currently inactive root file system by mounting it. After logging into the device using serial console or SSH (see the following two sections), run the following commands:

<pre>
$ mkdir temp

$ mount /dev/mmcblk0p3 temp # This assumes mmcblk0p3 is currently not mounted

$ ls temp # You are now accessing the idle partition:

bin data etc lib media proc sbin tmp usr
boot dev home lost+found mnt run sys uboot var
</pre>

The device node in the mount command might differ, depending on which partition is currently already mounted.

==USB Access to eMMC==

While Mender should be used for routine filesystem updates (see Updating Filesystems), it is also possible to access the X4x0's internal eMMC from an external host over USB. This allows accessing or modifying the filesystem, as well as the ability to flash the device with an entirely new filesystem.

In order to do so, you'll need an external computer with two USB ports, and two USB cables to connect the computer to your X4x0. The instructions below assume a Linux host.

First, connect to the APU serial console at a baud rate of 115200. Boot the device, and stop the boot sequence by typing noautoboot at the prompt. Then, run the following command in the U-boot command prompt:

<code>ums 0 mmc 0</code>

This will start the USB mass storage gadget to expose the eMMC as a USB mass storage device. You should see a spinning indicator on the console, which indicates the gadget is active.

Next, connect your external computer to the X4x0's USB to PS port using an OTG cable. Your computer should recognize the X4x0 as a mass storage device, and you should see an entry in your kernel logs (dmesg) that looks like this:

<pre>
usb 3-1: New USB device found, idVendor=3923, idProduct=7a7d, bcdDevice= 2.23
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: USB download gadget
usb 3-1: Manufacturer: National Instruments
sd 6:0:0:0: [sdc] 30932992 512-byte logical blocks: (15.8 GB/14.8 GiB)
sdc: sdc1 sdc2 sdc3 sdc4
sd 6:0:0:0: [sdc] Attached SCSI removable disk
</pre>

The exact output will depend on your machine, but from this log you can see that the X4x0 was recognized and /dev/sdc is the block device representing the eMMC, with 4 partitions detected (see eMMC Storage for details on the partition layout).

It is now possible to treat the X4x0's eMMC as you would any other USB drive: the individual partitions can be mounted and accessed, or the entire block device can be read/written.

Once you're finished accessing the device over USB, the u-boot gadget may be stopped by hitting Ctrl-C at the APU serial console.

== Flashing the eMMC ==

Once the X4x0's eMMC is accessible over USB, it's possible to write the filesystem image and thus change the device's filesystem. You can obtain the latest filesystem image by running:

<code>uhd_images_downloader -t sdimg -t x4xx</code>

The output of this command will indicate where the downloaded images were put, or specify a custom location using using the <code>-i INSTALL_LOCATION</code> argument.

There are 2 ways to write the image to the X4x0's eMMC: using <code>dd</code> and <code>bmaptool</code>. Run one of the following commands, replacing <code>/dev/sdX</code> with the block device of the X4x0's eMMC (found in the device's kernel log or by running <code>lsblk</code>). Take care to use the correct block device or else you might overwrite the wrong drive!

<code>sudo dd if=/path/to/usrp_x4xx_fs.sdimg of=/dev/sdX bs=1M</code>

<code>sudo bmaptool copy --bmap /path/to/usrp_x4xx_fs.sdimg.bmap /path/to/usrp_x4xx_fs.sdimg /dev/sdX</code>

The former is generally preferred as it will always work, even if it slower than the latter.

==Using a USRP X4x0 from UHD==
Like any other USRP, all X4x0 USRPs are controlled by the UHD software. To integrate a USRP X4x0 into your C++ application, you would generate a UHD device in the same way you would for any other USRP:

<code>auto usrp = uhd::usrp::multi_usrp::make("type=x4xx");</code>

For a list of which arguments can be passed into make(), see Section Device Arguments.

==Updating Filesystems==

Mender is a third-party software that enables remote updating of the root file system without physically accessing the device (see also the [https://mender.io/ Mender website]). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Mender servers can be self-hosted, or hosted by Mender (see mender.io for pricing and availability).

When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted (note: the onboard flash storage contains two separate root file system partitions, only one is ever used at a single time). Any data stored on that partition will be permanently lost, including the currently loaded FPGA image. After updating that partition, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched (which presumably is in a working state). Another update can be launched now to correct the previous, failed update, until it works.

To obtain the file system Mender image (these are files with a <code>.mender</code> suffix), run the following command on the host computer with Internet access:

$ sudo uhd_images_downloader -t mender -t x4xx --yes

NOTE: In the output of the command, the folder destination where the images are saved is printed out.

Next, you will need to copy this Mender file system image to the USRP X4xx. This can be done with the Linux utility <code>scp</code>.

$ scp /usr/local/share/uhd/images/usrp_x4xx_fs.mender root@192.168.1.51:~/.

Note: The path and IP may different for your configuration, the command above assumes you're using the default installation path of <code>/usr/local</code> and that the X4xx's IP is <code>192.168.1.51</code>.

After copying the Mender file system image to the X4xx, connect to the X4xx using either the Serial Console, or via SSH to gain shell access.

On the X4xx, run <code>mender install /path/to/latest.mender</code> to update the file system:

$ mender install /home/root/usrp_x4xx_fs.mender

The artifact can also be stored on a remote server:
$ mender install <nowiki>http://server.name/path/to/latest.mender</nowiki>

This procedure will take a few minutes to complete. After mender has logged a successful update, reboot the device:
$ reboot

If the reboot worked, and the device seems functional, commit the changes so that the boot loader knows to permanently boot into this partition:
$ mender commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the X4x0:
$ mender show-artifact

If you are using a Mender server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and you can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.

If you are running a hosted server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.

==Network Interfaces==
The Ettus USRP X4x0 has various network interfaces:

eth0: RJ45 port.

The RJ45 port comes up with a default configuration of DHCP, that will request a network address from your DHCP server (if available on your network). This interface is agnostic of FPGA image flavor.

int0: internal interface for network communication between the embedded ARM processor and FPGA.

The internal network interface is configured with a static address: 169.254.0.1/24. This interface is agnostic of FPGA image flavor.

sfpX [, sfpX_1, sfpX_2, sfpX_3]: QSFP28 network interface(s), up-to four (one per lane) based on implemented protocol.

Each QSFP28 port has four high-speed transceiver lanes. Therefore, depending on the FPGA image flavor, up-to four different network interfaces may exist per QSFP28 port, using the sfpXfor the first lane, and sfpX_1-3 for the other three lanes. Each network interface has a default static IP address. Note that for multi-lane protocols, such as 100 GbE, a single interface is used (sfpX).
The configuration files for these network interfaces are stored in: <code>/data/network/</code>

{| class="wikitable"
|-
! Interface Name
! Description
! Default Configuration
! Configuration File
! Example: X4_200/X4_400 FPGA image
|-
| eth0
| RJ45
| style="vertical-align:middle; background-color:#FFF;" | DHCP
| style="vertical-align:middle; background-color:#FFF;" | eth0.network
| DHCP
|-
| int0
| Internal
| style="vertical-align:middle; background-color:#FFF;" | 169.254.0.1/24
| style="vertical-align:middle; background-color:#FFF;" | int0.network
| style="vertical-align:middle; background-color:#FFF;" | 169.254.0.1/24
|-
| sfp0
| QSFP28 0 (4-lanes interface or lane 0)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.10.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp0.network
| style="vertical-align:middle; background-color:#FFF;" | 192.168.10.2/24
|-
| style="background-color:#FFF;" | sfp0_1
| QSFP28 0 (lane 1)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.11.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp0_1.network
| style="vertical-align:middle; background-color:#FFF;" | 192.168.11.2/24
|-
| style="background-color:#FFF;" | sfp0_2
| QSFP28 0 (lane 2)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.12.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp0_2.network
| style="vertical-align:middle; background-color:#FFF;" | 192.168.12.2/24
|-
| sfp0_3
| QSFP28 0 (lane 3)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.13.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp0_3.network
| style="vertical-align:middle; background-color:#FFF;" | 192.168.13.2/24
|-
| sfp1
| QSFP28 1 (4-lanes interface or lane 0)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.20.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp1.network
| style="vertical-align:middle; background-color:#FFF;" | N/C
|-
| sfp1_1
| QSFP28 1 (lane 1)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.21.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp1_1.network
| style="vertical-align:middle; background-color:#FFF;" | N/C
|-
| style="background-color:#FFF;" | sfp1_2
| QSFP28 1 (lane 2)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.22.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp1_2.network
| style="vertical-align:middle; background-color:#FFF;" | N/C
|-
| style="background-color:#FFF;" | sfp1_3
| QSFP28 1 (lane 3)
| style="vertical-align:middle; background-color:#FFF;" | 192.168.23.2/24
| style="vertical-align:middle; background-color:#FFF;" | sfp1_3.network
| style="vertical-align:middle; background-color:#FFF;" | N/C
|-
|}

==Network Connectivity==
Once the X4x0 has booted, determine the IP address and verify network connectivity by running uhd_find_devices on the host computer:

X410:
<pre>
$ uhd_find_devices

-- UHD Device 0

Device Address:
serial: 1234ABC
addr: 10.2.161.10
claimed: False
mgmt_addr: 10.2.161.10
product: x410
type: x4xx
</pre>

X440:
<pre>
$ uhd_find_devices

-- UHD Device 0

Device Address:
serial: 1234ABC
addr: 10.2.161.10
claimed: False
mgmt_addr: 10.2.161.10
product: x440
type: x4xx
</pre>

By default, an X4x0 will use DHCP to attempt to find an address.

At this point, you should run:

<code>uhd_usrp_probe --args addr=<IP address></code>
to ensure functionality of the device.

Note: If you receive the following error:

<code>Error: RuntimeError: Graph edge list is empty for rx channel 0</code>
then you will need to download a UHD-compatible FPGA as described in Updating the FPGA or using the following command (it assumes that FPGA images have been downloaded previously using uhd_images_downloader, or that the command is run on the device itself):

X410:
<code>uhd_image_loader --args type=x4xx,addr=<ip address>,fpga=X4_200</code>

X440:
<code>uhd_image_loader --args type=x4xx,addr=<ip address>,fpga=X4_400</code>

When running on the device, use <code>127.0.0.1</code> as the IP address.

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.

See Network Interfaces for further details on the various network interfaces available on the X4x0.

===Network Status LEDs===
The Ettus USRP X4x0 is equipped with status LEDs for its network-capable ports: RJ45 and QSFP28s, see RJ45 LED Behavior and QSFP28 LED Behavior accordingly.

====RJ45 LED Behavior====
The RJ45 port has two independent LEDs: green (right) and yellow (left). The table below summarizes the LEDs' behavior. Note that link speed indication is not currently supported.

{| class="wikitable"
|- style="font-weight:bold; text-align:center; vertical-align:middle;"
! Link / Activity
! Green LED
! Yellow LED
|-
| style="vertical-align:middle; background-color:#FFF;" | No Link
| Off
| Off
|-
| style="vertical-align:middle; background-color:#FFF;" | Link / No Activity
| On
| Off
|-
| style="vertical-align:middle; background-color:#FFF;" | Link / Activity
| On
| Blinking
|}

====QSFP28 LED Behavior====
Each QSFP28 connector has four LEDs, one for each high-speed transceiver lane. The table below summarizes the LEDs' behavior, note that for multi-lane protocols, such as 100 GbE, the corresponding LEDs are ganged together. Within the same image, multiple speeds on the same port (e.g., both 10 GbE and 100 GbE) are not supported, therefore link speed indication is not supported.

{| class="wikitable"
|- style="font-weight:bold; text-align:center; vertical-align:middle;"
! Link / Activity
! QSFP28 LED (4 Total)
|-
| style="vertical-align:middle; background-color:#FFF;" | No Link
| Off
|-
| style="vertical-align:middle; background-color:#FFF;" | Link / No Activity
| Green (solid)
|-
| style="vertical-align:middle; background-color:#FFF;" | Link / Activity
| Amber (blinking)
|}

==Security-related Settings==
The X4x0 ships without a root password set. It is possible to ssh into the device by simply connecting as root, and thus gaining access to all subsystems. To set a password, run the command

<code>$ passwd</code>
on the device.

==Serial Connection==
It is possible to gain access to the device using a serial terminal emulator. To do so, the USB debug port needs to be connected to a separate computer to gain access. Most Linux, OSX, or other Unix flavors have a tool called 'screen' which can be used for this purpose, by running the following command:

<code>$ sudo screen /dev/ttyUSB2 115200</code>
In this command, we prepend 'sudo' to elevate user privileges (by default, accessing serial ports is not available to regular users), we specify the device node (in this case, /dev/ttyUSB2), and the baud rate (115200).

The exact device node depends on your operating system's driver and other USB devices that might be already connected. Modern Linux systems offer alternatives to simply trying device nodes; instead, the OS might have a directory of symlinks under /dev/serial/by-id:

<pre>$ ls /dev/serial/by-id
usb-Digilent_Digilent_USB_Device_2516351DDCC0-if02-port0
usb-Digilent_Digilent_USB_Device_2516351DDCC0-if03-port0
</pre>

Note: Exact names depend on the host operating system version and may differ.

The first (with the if02 suffix) connects to the STM32 microcontroller (SCU), whereas the second (with the if03 suffix) connects to Linux running on the RFSoC APU.

<code>$ sudo screen /dev/serial/by-id/usb-Digilent_Digilent_USB_Device_2516351DDCC0-if03-port0 115200</code>
After entering the username root (no password is set by default), you should be presented with a shell prompt similar to the following:

<code>root@ni-x4xx-1234ABC:~#</code>
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). This can be used to debug kernel or bootloader issues more efficiently than when logged in via SSH.

==Connecting to the Microcontroller==
The microcontroller (which controls the power sequencing, among other things) also has a serial console available. To connect to the microcontroller, use the other UART device. In the example above:

<code>$ sudo screen /dev/serial/by-id/usb-Digilent_Digilent_USB_Device_2516351DDCC0-if02-port0 115200</code>

It provides a very simple prompt. The command 'help' will list all available commands. A direct connection to the microcontroller can be used to hard-reset the device without physically accessing it and other low-level diagnostics. For 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.

==SSH Connection==
The USRP X4x0 has two network connections: The dual QSFP28 ports, and an RJ45 connector. The latter is by default configured by DHCP; by plugging it into into 1 Gigabit switch on a DHCP-capable network, it will get assigned an IP address and thus be accessible via ssh.

In case your network setup does not include a DHCP server, refer to the section Serial Connection. A serial login can be used to assign an IP address manually.

After the device obtained an IP address you can log in from a Linux or OSX machine by typing:

<code>$ ssh root@ni-x4xx-1234ABC # Replace with your actual device name!</code>
Depending on your network setup, using a .local domain may work:

<code>$ ssh root@ni-x4xx-1234ABC.local</code>
Of course, you can also connect to the IP address directly if you know it (or set it manually using the serial console).

Note: The device's hostname is derived from its serial number by default (<code>ni-x4xx-$SERIAL</code>). You can change the hostname by creating the file <code>/data/network/hostname</code>, saving the desired hostname in it, then rebooting.

On Microsoft Windows, the connection can be established using a tool such as PuTTY, by selecting a username of root without password.

Like with the serial console, you should be presented with a prompt like the following:

<code>root@ni-x4xx-1234ABC:~#</code>

== Autoboot ==

The USRP X4x0 can be configured to power on and boot automatically when power is applied. This setting can be controlled using the <code>eeprom-set-autoboot</code> script. This script is executed directly on the USRP X4x0. To enable autoboot, run <code>eeprom-set-autoboot on</code>; to disable autoboot, run <code>eeprom-set-autoboot off</code>.

==Updating the FPGA==

The FPGA can be updated simply using uhd_image_loader:

<code>uhd_image_loader --args type=x4xx,addr=<IP address of device> --fpga-path <path to .bit></code>
or

<code>uhd_image_loader --args type=x4xx,addr=<IP address of device>,fpga=FPGA_TYPE</code>
A UHD install will likely have pre-built images in /usr/share/uhd/images/. Up-to-date images can be downloaded using the uhd_images_downloader script:

<code>uhd_images_downloader</code>
will download images into /usr/share/uhd/images/ (the path may differ, depending on how UHD was installed).

Also note that the USRP already ships with compatible FPGA images on the device - these images can be loaded by SSH'ing into the device and running:

X410:
<code>uhd_image_loader --args type=x4xx,mgmt_addr=127.0.0.1,fpga=X4_200</code>

X440:
<code>uhd_image_loader --args type=x4xx,mgmt_addr=127.0.0.1,fpga=X4_400</code>

==FPGA Image Flavors==
Unlike the USRP X310 or other third-generation USRP devices, the FPGA image flavors do not only encode how the QSFP28 connectors are configured, but also which master clock rates are available. This is because the data converter configuration is part of the FPGA image (the ADCs/DACs on the X4x0 are on the same die as the FPGA). The image flavors consist of two short strings, separated by an underscore, e.g. X4_200 (X410) or X4_400 (X440) is an image flavor which contains 4x 10 GbE, and can handle an analog bandwidth of 200 MHz or 400 MHz respectively. The first two characters describe the configuration of the QSFP28 ports: 'X' stands for 10 GbE, 'C' stands for 100 GbE. For details see [https://files.ettus.com/manual/page_usrp_x4xx.html#x4xx_updating_fpga_types FPGA Image Flavor] in the [https://files.ettus.com/manual USRP Hardware Driver and USRP Manual].

The analog bandwidth determines the available master clock rates.

X410: As of UHD 4.1, only the X4_200 image is shipped with UHD, which allows a 245.76 MHz or 250 MHz master clock rate. With UHD 4.2, the CG_400 image was added allowing for 491.52 MHz and 500 MHz master clock rates. With UHD 4.5, the UC_200 image (245.76 MHz and 250 MHz master clock rate) was added.

X440: As of UHD 4.5, UHD ships with X4_400, X4_1600, CG_400 and CG_1600 images. The X4_400 and CG_400 images allow master clock rates between 125 MHz and 512 MHz and the usage of all 8 channels while the X4_1600 and CG_1600 images allow master clock rates between 125 MHz and 2048 MHz but only the usage of channels 0 and 4.

Any other images are considered experimental (unsupported).

==Device Arguments==

{| class="wikitable" style="vertical-align:middle;"
|- style="font-weight:bold; text-align:center;"
! Key
! Description
! Example Value
|-
| addr
| IPv4 address of primary SFP+ port to connect to.
| addr=192.168.30.2
|-
| second_addr
| IPv4 address of secondary SFP+ port to connect to.
| second_addr=192.168.40.2
|-
| mgmt_addr
| IPv4 address or hostname to which to connect the RPC client. Defaults to `addr'.
| mgmt_addr=ni-sulfur-311FE00
|-
| find_all
| When using broadcast, find all devices, even if unreachable via CHDR.
| find_all=1
|-
| master_clock_rate
| Master Clock Rate in Hz.
| master_clock_rate=250e6
|-
| converter_rate
| Converter Rate in Hz. Only X440 and together with master_clock_rate.
| master_clock_rate=250e6,converter_rate=1000e6
|-
| serialize_init
| Force serial initialization of daughterboards.
| serialize_init=1
|-
| skip_init
| Skip the initialization process for the device.
| skip_init=1
|-
| time_source
| Specify the time (PPS) source.
| time_source=internal
|-
| clock_source
| Specify the reference clock source.
| clock_source=internal
|-
| ref_clk_freq
| Specify the external reference clock frequency, default is 10 MHz.
| ref_clk_freq=20e6
|-
| discovery_port
| Override default value for MPM discovery port.
| discovery_port=49700
|-
| rpc_port
| Override default value for MPM RPC port.
| rpc_port=49701
|}

This is only a subset of the existing device arguments. For a complete list please consult the [https://files.ettus.com/manual/page_usrp_x4xx.html#x4xx_usage_args UHD user manual of the X4x0 device series].

==GPS==

The USRP X4x0 includes a Jackson Labs LTE-Lite GPS module. Its antenna port is on the rear panel. When the X4x0 has access to GPS satellite signals, it can use this module to read out the current GPS time and location as well as to discipline an onboard OCXO.

To use the GPS as a clock and time reference, set the device arguments <code>time_source</code> and <code>clock_source</code> to <code>gpsdo</code>.

Note the GPS module is not enabled when the clock source is not set to <code>gpsdo</code>.

Its power-on status can be queried using the <code>gps_enabled</code> GPS sensor. When disabled, none of the sensors will return useful
(if any) values.

Note that acquiring a GPS lock can take some time after enabling the GPS, so if a UHD application is enabling the GPS dynamically, it might take some time before a GPS lock is reported.

To set the clock source and time source dynamically, see the following code:

<pre>
// Set clock/time individually:
usrp->set_clock_source("gpsdo");
usrp->set_time_source("gpsdo");
// This is equivalent to the previous commands, but faster, as it sets
// both settings simultaneously and avoids duplicating settings that are shared
// between these calls.
usrp->set_sync_source("clock_source=gpsdo,time_source=gpsdo");
</pre>

==Front-Panel Programmable GPIOs==

The USRP X4x0 has two HDMI front-panel connectors, which are connected to the FPGA. For a
description of the GPIO control API, see the
[https://files.ettus.com/manual/page_x400_gpio_api.html USRP X4x0 GPIO UHD Manual Entry],
[https://files.ettus.com/manual/page_usrp_x4xx.html#x4xx_usage_gpio the USRP X4x0 Series Manual],
the [https://files.ettus.com/manual/page_zbx.html#zbx_atr ZBX ATR section] (X410) and the
[https://files.ettus.com/manual/page_fbx.html#fbx_atr FBX ATR section] (X440).

==Subdev Specifications==

The RF ports on the front panel of the X410 + ZBX correspond to the following subdev specifications:

{| class="wikitable"
|-
! Label
! style="text-align:center; vertical-align:middle; font-weight:bold;" | Subdev Spec
|- style="vertical-align:middle; background-color:#FFF;"
| DB 0 / RF 0
| A:0
|- style="vertical-align:middle; background-color:#FFF;"
| DB 0 / RF 1
| A:1
|- style="vertical-align:middle; background-color:#FFF;"
| DB 1 / RF 0
| B:0
|- style="vertical-align:middle; background-color:#FFF;"
| DB 1 / RF 1
| B:1
|}

The RF ports on the front panel of the X440 + FBX correspond to the following subdev specifications (for xx_400 FPGA images):

{| class="wikitable"
|-
! Label
! style="text-align:center; vertical-align:middle; font-weight:bold;" | Subdev Spec
|- style="vertical-align:middle; background-color:#FFF;"
| DB 0 / RF 0
| A:0
|- style="vertical-align:middle; background-color:#FFF;"
| DB 0 / RF 1
| A:1
|- style="vertical-align:middle; background-color:#FFF;"
| DB 0 / RF 2
| A:2
|- style="vertical-align:middle; background-color:#FFF;"
| DB 0 / RF 3
| A:3
|- style="vertical-align:middle; background-color:#FFF;"
| DB 1 / RF 0
| B:0
|- style="vertical-align:middle; background-color:#FFF;"
| DB 1 / RF 1
| B:1
|- style="vertical-align:middle; background-color:#FFF;"
| DB 1 / RF 2
| B:2
|- style="vertical-align:middle; background-color:#FFF;"
| DB 1 / RF 3
| B:3
|}

When using a xx_1600 FPGA image on X440, only A:0 and B:0 are available.

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 uhd::usrp::multi_usrp::set_tx_subdev_spec() as with other USRPs.

==Rear Panel Status LEDs==

The USRP X4x0 is equipped with four LEDs located on the device's rear panel. Each LED supports four different states: Off, Green, Red, and Amber. One LED (PWR) indicates the device's power state (see Power LED below). The other three LEDs (LED 0, LED 1, and LED 2) are user-configurable, different behaviors are supported for each of these LEDs (see User-configurable LEDs below).

[[File:x4xx_rearpanel_status_leds.png|125px]]

===X4x0 Rear Panel Status LEDs===
Power LED
The USRP X4x0's PWR LED is reserved to visually indicate the user the device's power state. Power LED Behavior describes what each LED state represents.

===Power LED Behavior===

{| class="wikitable" style="background-color:#FFF;"
|- style="font-weight:bold; text-align:center;"
! PWR LED State
! style="vertical-align:middle;" | Meaning
|- style="vertical-align:middle;"
| Off
| No power is applied
|- style="vertical-align:middle;"
| Amber
| Power is good but X4x0 is powered off
|- style="vertical-align:middle;"
| Green
| Power is good and X4x0 is powered on
|- style="vertical-align:middle;"
| Red
| Power error state
|}

===User-configurable LEDs===
The USRP X4x0's user-configurable rear panel status LEDs (LED 0, LED 1, and LED 2) allow the user to have visual indication of various device conditions. Supported LED Behaviors provides a complete list of the supported behaviors for each user-configurable LED. By default, these LEDs are configured as described in LEDs Default Behavior.

The user may alter the default LEDs behavior either temporarily or persistently, see the Temporarily change the LED Behavior or Persistently in the UHD manual to change the LED Behavior accordingly.

https://files.ettus.com/manual/page_usrp_x4xx.html

==Technical Support and Community Knowledge Base==
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.

We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.

Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].

Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].

Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].

The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].

==Legal Considerations==
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]
[[Category:X4x0]]

USRP N300/N310/N320/N321 Getting Started Guide

2025-07-09T09:28:56Z

FrankDietze: update mender commands

==Kit Contents==
===N300===
{|
|style="vertical-align:top"|
* USRP N300
* DC Power Supply (12V, 7A)
* 1 RJ45 – SFP+ Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n300 kit.png|450px|center]]
|}
===N310===

{|
|style="vertical-align:top"|
* USRP N310
* DC Power Supply (12V, 7A)
* 1 RJ45 – SFP+ Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n310 kit.png|500px|center]]
|}

===N320===

{|
|style="vertical-align:top"|
* USRP N320
* DC Power Supply (12V, 7A)
* 1 RJ45 – SFP+ Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
|[[File:n320 kit.png|500px|center]]
|}

===N321===

{|
|style="vertical-align:top"|
* USRP N321
* DC Power Supply (12V, 7A)
* 1 RJ45 – SFP+ Adapter
* 1 Gigabit Ethernet Cat-5e Cable (3m)
* USB-A to Micro USB-B Cable (1m)
* Getting Started Guide
* Ettus Research Sticker
||[[File:n321 kit.png|500px|center]]
|}
==Verify the Contents of Your Kit==
Ensure that your kit contains all the items listed above. If any items are missing, please contact sales@ettus.com immediately.

==You Will Need==
* microSD Card Writer

* For Network Mode: A host computer with an available 1 or 10 Gigabit Ethernet interface for sample streaming. In addition to the Ethernet interface used for sampling streaming, your host computer will require a separate 1 Gigabit Ethernet interface for command and control streaming.

* For Stand-Alone Embedded Mode: 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.

==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 become non-functional. Take the following precautions to prevent damage to the unit.

* Never allow metal objects to touch the circuit board while powered.
* Always properly terminate the transmit port with an antenna or 50Ω load.
* Always handle the board with proper anti-static methods.
* Never allow the board to directly or indirectly come into contact with any voltage spikes.
* Never allow any water or condensing moisture to come into contact with the device.
* Always use caution with FPGA, firmware, or software modifications.

{|
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Never apply more than -15 dBm of power into any RF input.
|-
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |[[File:Caution.png|24px|center]]
|style="padding-left:10px; padding-right:10px; padding-bottom:10px;" |Always use at least 30dB attenuation if operating in loopback configuration
|-
|}

==Install and Setup the Software Tools on Your Host Computer==
In order to use your Universal Software Radio Peripheral (USRP™), you must have the software tools correctly installed and configured on your host computer. A step-by-step guide for doing this is available at the Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux|Linux]], [[Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on OS X|OS X]] and [[Building and Installing the USRP Open Source Toolchain (UHD and GNU Radio) on Windows|Windows]] Application Notes.

To find the latest release of UHD, see the UHD repository at https://github.com/EttusResearch/uhd.

The USRP N310 requires UHD version 3.11.0.0 or later.

The USRP N300 requires UHD version 3.12.0.0 or later.

The USRP N320/N321 requires UHD version 3.14.0.0 or later.

White Rabbit Ethernet-Based Synchronization of the N3xx USRP requires UHD version 3.12.0.0 or later. For additional details on White Rabbit Ethernet-Based Synchronization, please see the application note, [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]].

'''When you receive a brand-new device, it is strongly recommended that you download the most recent filesystem image from the Ettus Research website and write it to the SD card that comes with the unit. It is not recommended that you use the SD card from the factory as-is. Instructions on downloading the latest filesystem image and writing it to the SD card are listed below.'''

'''Note that if you are operating the device in Network Mode, the version of UHD running on the host computer and the USRP N3xx must match.'''

==Connecting the Device==
===Interfaces Overview===
Listed below are the interfaces to connect to the USRP N3xx. Each interface has specific functionality, limitations and purpose.

'''Serial Console'''

The Serial Console provides a low level interface to the device typically used for debugging.

'''1 Gigabit RJ45 Connection'''

The 1 Gigabit RJ45 Connection interfaces with the on-board ARM CPU. When operated in "Network mode", this interface can optionally be used for UHD management traffic. Regardless of the operation mode (Network vs Embedded) this interface can be used to connect to the ARM via SSH. By default, the 1Gb RJ45 connection is configured to use a DHCP assigned IP address.

'''Dual SFP+ Connections'''

The Dual SFP+ Connections support multiple configurations for streaming high-speed, low-latency data, depending upon the FPGA image which is loaded.

'''QSFP+ Connection (N320/ N321 Only)'''

The QSFP+ Connection supports 2 x 10Gb lanes for streaming high-speed, low-latency data, while the onboard SFP0 connection is used for White Rabbit Ethernet-Based Synchronization.

===Setting up a Serial Console Connection===
It is possible to gain shell access to the device using a serial terminal emulator via the Serial Console port. Most Linux, OSX, or other Unix based operating systems have a tool called <code>screen</code> which can be used for this purpose.

If you do not have <code>screen</code> installed, it can be installed via your package manager. For Ubuntu/Debian based operating systems it can be installed with <code>apt</code> such as:

sudo apt install screen

The default Baud Rate for the Serial Console is: <code>115200</code>

The exact device node you should attach to depends on your operating system's driver and other USB devices that might already be connected. Modern Linux systems offer alternatives to simply trying device nodes; instead, the OS might have a directory of symlinks under <code>/dev/serial/by-id</code>:

$ ls /dev/serial/by-id
usb-Digilent_Digilent_USB_Device_25163511FE00-if00-port0
usb-Digilent_Digilent_USB_Device_25163511FE00-if01-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0
usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if01-port0

NOTE: Exact names depend on the host operating system version and may differ.

Every N3XX series device connected to USB will by default show up as four different devices. The devices labeled <code>"USB_to_UART_Bridge_Controller"</code> are the devices that offer a serial prompt. The first (with the <code>if00</code> suffix) connects to the <code>ARM CPU</code>, whereas the second connects to the <code>STM32 Microcontroller</code>.

If you have multiple N3xx Serial Consoles connected to a single host, you may have to empirically test nodes.

Connecting to the ARM CPU can be performed with the command:

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0 115200

Upon starting the USRP N3xx, boot messages will appear and rapidly update. Once the boot process successfully completes, a login prompt like the following should appear:

OpenEmbedded test ni-n3xx-313ABDA ttyPS0

ni-n3xx-313ABDA login:

Enter the username: <code>root</code>

By default, the <code>root</code> user's password is left blank. Press the <code>Enter</code> key when prompted for a password.

You should now be presented with a shell prompt similar to the following:

root@ni-n3xx-<motherboard serial #>:~#

Using the default configuration, the serial console will show all kernel log messages (which are not available when using SSH), and give access to the boot loader (U-boot prompt). This can be used to debug kernel or boot-loader issues more efficiently than when logged in via SSH.

====Connecting to the microcontroller====

Using the Serial Console interface, it is possible to connect to the STM32 microcontroller with the command below. The STM32 controls the power sequencing and several other low level device operations.

$ sudo screen /dev/serial/by-id/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if01-port0 115200

The STM32 interface provides a very simple prompt. The command <code>help</code> will list all available commands. A direct connection to the microcontroller can be used to hard-reset the device without physically accessing it (i.e., emulating a power button press) and other low-level diagnostics.

===Connecting to the ARM via SSH===
By default, the RJ45 1Gb management interface is configured to be assigned a DHCP IP address.

If you have access to a network which provides a DHCP server (such as a common router's LAN), attach the RJ45 1Gb port to this network. Details vary by vendor, however, most router management interfaces will provide a list of attached devices to the LAN including their IP address.

Without access to a router management interface, you can identify the IP address by connecting to the ARM CPU via Serial Console as detailed in the section above and running the command <code>ip a</code>:

Example Output:

<pre>
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 42865sec preferred_lft 42865sec
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
4: sfp1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
</pre>

If you do not have access to a network with a DHCP server, you can create one using the Linux utility <code>dnsmasq</code>:

$ sudo dnsmasq -i <ETHERNET_ADAPTER_NAME> --dhcp-range=192.168.1.151,192.168.1.254 --except-interface=lo --bind-dynamic --no-daemon

NOTE: Modify the value <code><ETHERNET_ADAPTER_NAME></code> to match the interface you would like to create a DHCP server on.

After the device has obtained an IP address, you can remotely log into it from a Linux or macOS system with SSH, as shown below:

$ ssh root@192.168.1.151

NOTE: The IP address may vary depending on your network setup.

NOTE: The <code>root</code> password default password is empty/blank.

On Microsoft Windows, the SSH connection can be established using the third-party program Putty.

After logging in, you should be presented with a shell like the following:

root@ni-n3xx-<motherboard serial #>:~#

==Updating the Linux File System==
Before operating the device, it is strongly recommended to update to the latest version of the Embedded Linux file system. If you are operating the device in Network Mode, the version of UHD running on the host machine and N3xx USRP must match.

There is two ways to update the file system for the N3xx USRP:

1. Mender

2. Physically remove microSD card from device and write a new file system to the microSD card.

===File System Partition Layout===
The SD Card is divided into four partitions. There is two root file system partitions, a boot partition and a data partition.

Any data you would like to preserve through Mender updates should be saved to the <code>data</code> partition, which is mounted at <code>/data</code>.

===Updating the file system with Mender===
Mender is third-party software that enables remote updating of the root file system without physically accessing the device (see also the Mender website https://mender.io). Mender can be executed locally on the device, or a Mender server can be set up which can be used to remotely update an arbitrary number of USRP devices. Users can host their own local Mender server, or use servers hosted by Mender as a paid service; contact Mender for more information.

====Mender Update Process====

When updating the file system using Mender, the tool will overwrite the root file system partition that is not currently mounted. Any data stored in the root partitions will be permanently lost with a Mender update.

After updating a partition with Mender, it will reboot into the newly updated partition. Only if the update is confirmed by the user, the update will be made permanent. This means that if an update fails, the device will be always able to reboot into the partition from which the update was originally launched, which presumably is in a working state. Another update can be launched now to correct the previous, failed update, until it works.

To obtain the file system Mender image (these are files with a <code>.mender</code> suffix), run the following command on the host computer with Internet access:
$ sudo uhd_images_downloader -t mender -t n3xx --yes

Example Output:
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /usr/local/share/uhd/images
365684 kB / 365684 kB (100%) n3xx_common_mender_default-v4.6.0.0.zip
[INFO] Images download complete.

The downloaded "zip" archive is extracted into the <code>Images destination</code> directory with the filename <code>usrp_n3xx_fs.mender</code>. Next, you will need to copy this Mender file system image from the <code>Images destination</code> directory to the USRP N3xx to have its filesystem changed. This can be done with the Linux utility <code>scp</code>, for example as follows:

$ scp /usr/local/share/uhd/images/usrp_n3xx_fs.mender root@192.168.1.51:~/.

Note: The path and IP may be different for your configuration; the command above assumes you're using the default UHD installation path of <code>/usr/local</code> and that the N3xx's IP is <code>192.168.1.51</code>.

After copying the Mender file system image to the N3xx, connect to the N3xx to gain shell access via either the Serial Console or SSH.

On the N3xx, you first need to determine the version of UHD currently running on the USRP; an easy way to do this is via the command
# uhd_config_info --version

Example output:
UHD 3.14.1.1-0-g0347a6d8

The mender command to execute is different for UHD version 4.0 or newer versus prior to version 4.0. For the former use <code>mender install</code> followed by the mender file; for the latter use <code>mender -f -rootfs</code> followed by the mender file. Starting with UHD version 4.0 one can use mender to upgrade or downgrade the UHD filesystem version between any UHD v4 versions (e.g., 4.1 to 4.6; 4.6 to 4.1). The following commands assume that the UHD filesystem is version 4; if not then substitute the other mender command.

Run <code>mender install /path/to/latest.mender</code> to update the file system, e.g.:

# mender install usrp_n3xx_fs.mender

The artifact can also be stored on a remote server:
# mender install <nowiki>http://server.name/path/to/latest.mender</nowiki>

This procedure will take a quite a few minutes to complete. While executing, mender will show progress, e.g.:
................................ 0% 1024 KiB
...
................................ 1% 4096 KiB
...
................................ 99% 386048 KiB
............ 100% 386458 KiB
INFO[3865] wrote 7851737088/7851737088 bytes of update to device /dev/mmcblk0p3 module=device
INFO[3871] Enabling partition with new image installed to be a boot candidate: 3 module=device

After mender has logged a successful update, reboot the device:
# reboot

Upon reboot log back in to the USRP N3xx and run the command <code>uhd_find_devices</code> to verify that the UHD version is as desired and that the command runs successfully -- it should find at a minimum the USRP it is being executed on and will find more if other USRPs are on the same network.

If upon reboot the device is not working or the UHD version is not as desired, then the easiest way forward is to [https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_files_system_by_writing_the_disk_image overwrite the sdcard filesystem manually] with the desired UHD version.

If upon reboot everything is as desired and the device seems functional, then commit the changes so that the boot loader knows to permanently boot into this partition:
# mender commit

To identify the currently installed Mender artifact from the command line, the following file can be queried on the N3xx:
# mender show-artifact

If you are using a Mender server, the updates can be initiated from a web dashboard. From there, you can start the updates without having to log into the device, and you can update groups of USRPs with a few clicks in a web GUI. The dashboard can also be used to inspect the state of USRPs. This is a simple way to update groups of rack-mounted USRPs with custom file systems.

For more information on updating the filesystem, refer to the [https://files.ettus.com/manual/ UHD Manual].

===Updating the files system by writing the disk image===
Please see the separate application note, [[Writing the USRP File System Disk Image to a SD Card]], for step-by-step instructions on writing the file system image to the SD card.

==Updating the Network Configurations==
The USRP N3xx systemd network configuration files are located at: <code>/data/network/</code>

# ls /data/network/
eth0.network int0.network sfp0.network sfp1.network

or for older versions of the file system: <code>/etc/systemd/network/</code>

# ls /etc/systemd/network/
eth0.network sfp0.network sfp1.network

For details on configuration please refer to the [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd-networkd manual pages].

The factory settings are as follows:
<pre>
eth0 (DHCP):

[Match]
Name=eth0

[Network]
DHCP=ipv4

[DHCP]
UseHostname=false

sfp0 (static):

[Match]
Name=sfp0

[Network]
Address=192.168.10.2/24

[Link]
MTUBytes=9000

sfp1 (static):

[Match]
Name=sfp1

[Network]
Address=192.168.20.2/24

[Link]
MTUBytes=9000
</pre>

Additional notes on networking:

* Care needs to be taken when editing these files on the device, since <code>vi</code> / <code>vim</code> sometimes generates undo files (e.g. <code>/etc/systemd/network/sfp0.network~</code>), that <code>systemd-networkd</code> might accidentally pick up.
* Temporarily setting the IP addresses or MTU sizes via <code>ifconfig</code> or other command line tools will only change the value until the next reboot or reload of the FPGA image.
* If the MTU of the device and host computers differ, streaming issues can occur.
* Streaming via SFP0 at 1 Gb rates requires a MTU of <code>1500</code>
* Streaming via SFP0 at 10 Gb rates requires a MTU of <code>9000</code>

For addition details on network configuration here: https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_network_configuration

==Updating the FPGA Image==

===Network Mode FPGA Image Update===
The FPGA image should match the version of UHD installed on the host computer, when operated in Network mode. Connect the device to the host computer using either the RJ45 or SFP+ port, refer to the section above for detailed instructions.

To obtain all the FPGA images for a specific version of UHD, run the following command on the host computer with internet access:

$ sudo uhd_images_downloader

Example Output:

$ sudo uhd_images_downloader
[INFO] Images destination: /usr/local/share/uhd/images
00006 kB / 00006 kB (100%) usrp1_b100_fw_default-g6bea23d.zip
19810 kB / 19810 kB (100%) x3xx_x310_fpga_default-gf1ba32fe.zip
02757 kB / 02757 kB (100%) usrp2_n210_fpga_default-g6bea23d.zip
02123 kB / 02123 kB (100%) n230_n230_fpga_default-ge57dfe0.zip
00522 kB / 00522 kB (100%) usrp1_b100_fpga_default-g6bea23d.zip
00491 kB / 00491 kB (100%) b2xx_b200_fpga_default-ge57dfe0.zip
02415 kB / 02415 kB (100%) usrp2_n200_fpga_default-g6bea23d.zip
08988 kB / 08988 kB (100%) e3xx_e320_fpga_default-g3de8954a.zip
23045 kB / 23045 kB (100%) n3xx_n310_fpga_default-g3de8954a.zip
00523 kB / 00523 kB (100%) b2xx_b205mini_fpga_default-ge57dfe0.zip
18937 kB / 18937 kB (100%) x3xx_x300_fpga_default-gf1ba32fe.zip
00017 kB / 00017 kB (100%) octoclock_octoclock_fw_default-g14000041.zip
00007 kB / 00007 kB (100%) usrp2_usrp2_fw_default-g6bea23d.zip
00009 kB / 00009 kB (100%) usrp2_n200_fw_default-g6bea23d.zip
00450 kB / 00450 kB (100%) usrp2_usrp2_fpga_default-g6bea23d.zip
00144 kB / 00144 kB (100%) b2xx_common_fw_default-ga69ab0c.zip
25107 kB / 25107 kB (100%) n3xx_n320_fpga_default-g3de8954a.zip
00464 kB / 00464 kB (100%) b2xx_b200mini_fpga_default-ge57dfe0.zip
00319 kB / 00319 kB (100%) usrp1_usrp1_fpga_default-g6bea23d.zip
04839 kB / 04839 kB (100%) usb_common_windrv_default-g14000041.zip
00009 kB / 00009 kB (100%) usrp2_n210_fw_default-g6bea23d.zip
16065 kB / 16065 kB (100%) n3xx_n300_fpga_default-g3de8954a.zip
05578 kB / 05578 kB (100%) e3xx_e310_fpga_default-g4bc2c6f.zip
00885 kB / 00885 kB (100%) b2xx_b210_fpga_default-ge57dfe0.zip
[INFO] Images download complete.

NOTE: In the above example output, the Images Destination folder is printed:

[INFO] Images destination: /usr/local/share/uhd/images

To list the N3xx FPGA images with a full path, run the command:

$ ls -w 1 /usr/local/share/uhd/images/usrp_n3*.bit

/usr/local/share/uhd/images/usrp_n300_fpga_AA.bit
/usr/local/share/uhd/images/usrp_n300_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n300_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n300_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n310_fpga_AA.bit
/usr/local/share/uhd/images/usrp_n310_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n310_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n310_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_AQ.bit
/usr/local/share/uhd/images/usrp_n320_fpga_HG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_WX.bit
/usr/local/share/uhd/images/usrp_n320_fpga_XG.bit
/usr/local/share/uhd/images/usrp_n320_fpga_XQ.bit

To update the default <code>HG</code> variant of FPGA image, run the command:

$ uhd_image_loader --args "type=n3xx,addr=<N3xx_IP_ADDR>,fpga=HG"

Example Output:

uhd_image_loader --args "type=n3xx,addr=192.168.1.151,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.1.HEAD-0-gad6b0935
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n310,serial=313ABDA,claimed=False,skip_init=1
[INFO] [MPM.main] Launching USRP/MPM, version: 3.11.1.0-gunknown
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.

To load a different default FPGA image (i.e. <code>XG</code>, <code>WG</code>), modify the device argument <code>fpga=</code> to a value of <code>fpga=XG</code> or <code>fpga=WG</code>.

To specify the path to a custom FPGA image, use the <code>--fpga-path</code> argument.

$ uhd_image_loader --args "type=n3xx,addr=<N3xx_IP_ADDR>" --fpga-path=/path/to/custom/fpga.bit

The Verilog code for the FPGA in the USRP N3xx is open-source, and users are free to modify and customize it for their needs. However, certain modifications may result in either bricking the device, or even in physical damage to the unit. Please note that modifications to the FPGA are made at the risk of the user, and may not be covered by the warranty of the device.

===Embedded Mode FPGA Image Update===

It is possible to update the FPGA image when operated in Embedded mode. Connect to the ARM CPU via Serial Console or SSH as detailed in the section above.

Updating the FPGA image from the ARM CPU is the same as detailed above for a Network mode update, except it is not required to provide an <code>addr</code> device argument.

uhd_image_loader --args "type=n3xx,fpga=HG"

<pre>
root@ni-n3xx-313ABDA:~# uhd_image_loader --args "type=n3xx,fpga=HG"
[INFO] [UHD] linux; GNU C++ version 7.2.0; Boost_106400; UHD_3.11.1.0-0-unknown
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=n3xx,product=n310,serial=313ABDA,claimed=False,skip_init=1
[INFO] [MPMD] Claimed device without full initialization.
[INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
[INFO] [MPM.PeriphManager] Updating component `fpga'
[INFO] [MPM.PeriphManager] Updating component `dts'
[INFO] [MPM.RPCServer] Resetting peripheral manager.
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPMD IMAGE LOADER] Update component function succeeded.
</pre>

For more information on updating the FPGA image, refer to the UHD Manual at http://uhd.ettus.com .

==Setting Up a Streaming Connection==
The device supports multiple, high-speed, low-latency interfaces on the SFP+ ports for streaming samples to the host computer.

===1Gb Streaming SFP Port 0===
Complete the steps below to set up a streaming connection over the 1 Gigabit Ethernet interface on <code>SFP Port 0</code>.

When streaming via SFP Port 0 at 1 Gb speeds, it is important that the connection is direct between the Host and USRP. Placing a switch or other network gear between the Host and USRP can reduce throughput of the transport link. It is also generally recommended to avoid using USB to Ethernet Adapters for the high speed streaming interface, as they may limit performance or cause periodic flow control errors.

NOTE: The <code>HG</code> FPGA image must be loaded for <code>SFP Port 0</code> to operate at 1Gb speeds. If the <code>XG</code> image is loaded, the port will be unresponsive at 1Gb speeds.

1. Configure your Host's Ethernet adapter as shown below. This interface should be separate from the 1Gb NIC/network which is connected to the 1Gb RJ45 management interface.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 1500

NOTE: When operating <code>SFP Port 0</code> at 1Gb speeds, it is important to set a MTU of <code>1500</code> and not a value of <code>automatic</code>.

2. Insert the RJ45 – SFP+ adapter into <code>SFP Port 0</code> .

3. Connect the adapter to a host computer using the Ethernet cable to SFP0.

The Green LED above <code>SFP Port 0</code> should illuminate.

4. To test the connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown
below:

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=1.06 ms
^C
--- 192.168.10.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.065/1.065/1.065/0.000 ms

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

===10Gb Streaming SFP Port 1===
Complete the steps below to set up a streaming connection over the 10 Gigabit Ethernet interface on <code>SFP Port 1</code>.

NOTE: Both the <code>HG</code> and <code>XG</code> FPGA images support 10Gb speeds over SFP Port 1.

1. Configure your Host's 10Gb Ethernet adapter as shown below.

IP Address: 192.168.20.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

NOTE: When operating at 10Gb speeds, it is important to set a MTU of <code>9000</code> and not a value of <code>automatic</code>.

2. Connect the USRP to a host computer using either a 10Gb SFP or Fiber cable to <code>SFP Port 1</code>.

The Green LED above <code>SFP Port 1</code> should illuminate.

3. To test the connection, <code>ping</code> the device at address <code>192.168.20.2</code> from the host, as shown
below:

$ ping 192.168.20.2

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

===Dual 10Gb Streaming SFP Ports 0/1===
Complete the steps below to set up a streaming connections over the Dual 10 Gigabit Ethernet interface on <code>SFP Ports 0/1</code>.

NOTE: The <code>XG</code> FPGA image must be loaded for <code>SFP Port 0</code> to operate at 10 Gb speeds. If the <code>HG</code> image is loaded, the port will be unresponsive at 10 Gb speeds.

1. Configure your Host's #1 10Gb Ethernet adapter as shown below.

IP Address: 192.168.10.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

2. Configure your Host's #2 10Gb Ethernet adapter as shown below.

IP Address: 192.168.20.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0
MTU: 9000

NOTE: When operating at 10Gb speeds, it is important to set a MTU of <code>9000</code> and not a value of <code>automatic</code>.

3. Connect the USRP to a host computer using either a 10Gb SFP or Fiber cables to <code>SFP Ports 0/1</code>.

The Green LEDs above <code>SFP Ports 0/1</code> should illuminate.

4. To test the <code>SFP Port 0</code> connection, <code>ping</code> the device at address <code>192.168.10.2</code> from the host, as shown below:

$ ping 192.168.10.2

Press <code>CTRL+C</code> to stop the ping program.

5. To test the <code>SFP Port 1</code> connection, <code>ping</code> the device at address <code>192.168.20.2</code> from the host, as shown below:

$ ping 192.168.20.2

Press <code>CTRL+C</code> to stop the ping program.

Proceed to the next section "Verifying Device Operation".

For more details on Network Setup and Configuration, please see the “Interfaces and Connectivity” section on the [[N300/N310]] or [[N320/N321]] hardware resources pages.

==Verifying Device Operation==
Once you have successfully setup a management interface and streaming interface, you can now verify the devices operation using the included UHD utilities.

===Subdevice Specification Mapping===
====N300====
The USRP N300 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = A:1

====N310====
The USRP N310 contains 4 channels, each represented on the front panel as <code>RF0-3</code>. Below is the <code>subdev</code> mapping of RF Ports.

=====UHD 3.11.x.x - 3.12.x.x=====
* RF0 = A:0
* RF1 = B:0
* RF2 = C:0
* RF3 = D:0

=====UHD 3.13.x.x+=====
* RF0 = A:0
* RF1 = A:1
* RF2 = B:0
* RF3 = B:1

====N320====
The USRP N320 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = B:0

====N321====
The USRP N321 contains 2 channels, each represented on the front panel as <code>RF0-1</code>. Below is the <code>subdev</code> mapping of RF Ports.

* RF0 = A:0
* RF1 = B:0

Additional details of UHD Subdevice Specifications can be found here in the UHD Manual: http://files.ettus.com/manual/page_configuration.html#config_subdev

===Supported Sample Rates===

The USRP N300/N310 supports the three fixed Master Clock Rates listed below.

* 122.88 MHz
* 125.00 MHz
* 153.60 MHz

The USRP N320/N321 supports the three fixed Master Clock Rates listed below.

* 200.00 MHz
* 245.76 MHz
* 250.00 MHz

Sample rates as delivered to/from the host computer for USRP devices are constrained to follow several important rules.

It is important to understand that strictly-integer decimation and interpolation are used within USRP hardware to meet the requested sample rate requirements of the application at hand. That means that the desired sample rate must meet the requirement that master-clock-rate/desired-sample-rate be an integer ratio. Further, it is strongly desirable for that ratio to be even. This ratio is the decimation (down-conversion) or interpolation (up-conversion) factor. The decimation or interpolation factor may be between 1 and 1024. There are further constraints on the decimation or interpolation factor. If the decimation or interpolation factor exceeds 128, then it must be evenly divisible by 2. If the decimation or interpolation factor exceeds 256, then it must be evenly divisible by 4.

====Example Sample Rates====
Listed below are common sample rates for the given master clock rates. This is not a complete listing of the supported sample rates.

{| class="wikitable"
!Master Clock Rate
!colspan="20"|Decimation / Interpolation Rate <br> Host Sample Rate [Msps]
|-

|style="text-align:center;"| 1
|style="text-align:center;"| 2
|style="text-align:center;"| 4
|style="text-align:center;"| 6
|style="text-align:center;"| 8
|style="text-align:center;"| 10
|style="text-align:center;"| 12
|style="text-align:center;"| 14
|style="text-align:center;"| 16
|style="text-align:center;"| 18
|style="text-align:center;"| 20
|style="text-align:center;"| 30
|style="text-align:center;"| 32
|style="text-align:center;"| 64
|style="text-align:center;"| 100
|style="text-align:center;"| 128
|style="text-align:center;"| 200
|style="text-align:center;"| 256
|style="text-align:center;"| 512
|style="text-align:center;"| 1024
|-

|style="text-align:center;"| 122.88e6
|style="text-align:center;"| 61.44e6
|style="text-align:center;"| 30.72e6
|style="text-align:center;"| 20.48e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.288e6
|style="text-align:center;"| 10.24e6
|style="text-align:center;"| 8.7771e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 6.8267e6
|style="text-align:center;"| 6.144e6
|style="text-align:center;"| 4.096e6
|style="text-align:center;"| 3.84e6
|style="text-align:center;"| 1.92e6
|style="text-align:center;"| 1.2288e6
|style="text-align:center;"| 960e3
|style="text-align:center;"| 614.4e3
|style="text-align:center;"| 480e3
|style="text-align:center;"| 240e3
|style="text-align:center;"| 120e3
|-

|style="text-align:center;"| 125e6
|style="text-align:center;"| 62.5e6
|style="text-align:center;"| 31.25e6
|style="text-align:center;"| 20.833e6
|style="text-align:center;"| 15.625e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 10.417e6
|style="text-align:center;"| 8.9286e6
|style="text-align:center;"| 7.8125e6
|style="text-align:center;"| 6.9444e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 4.1667e6
|style="text-align:center;"| 3.90625e6
|style="text-align:center;"| 1.953125e6
|style="text-align:center;"| 1.25e6
|style="text-align:center;"| 976.5625e3
|style="text-align:center;"| 625e3
|style="text-align:center;"| 488.28125e3
|style="text-align:center;"| 244.14e3
|style="text-align:center;"| 122.07e3

|-

|style="text-align:center;"| 153.6e6
|style="text-align:center;"| 76.8e6
|style="text-align:center;"| 38.4e6
|style="text-align:center;"| 25.6e6
|style="text-align:center;"| 19.2e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.8e6
|style="text-align:center;"| 10.971e6
|style="text-align:center;"| 9.6e6
|style="text-align:center;"| 8.5333e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 5.12e6
|style="text-align:center;"| 4.8e6
|style="text-align:center;"| 2.4e6
|style="text-align:center;"| 1.536e6
|style="text-align:center;"| 1.2e6
|style="text-align:center;"| 768e3
|style="text-align:center;"| 600e3
|style="text-align:center;"| 300e3
|style="text-align:center;"| 150e3

|-

|}

====N320/N321 Example Sample Rates====
Listed below are common sample rates for the given master clock rates. This is not a complete listing of the supported sample rates.

{| class="wikitable"
!Master Clock Rate
!colspan="20"|Decimation / Interpolation Rate <br> Host Sample Rate [Msps]
|-

|style="text-align:center;"| 1
|style="text-align:center;"| 2
|style="text-align:center;"| 4
|style="text-align:center;"| 6
|style="text-align:center;"| 8
|style="text-align:center;"| 10
|style="text-align:center;"| 12
|style="text-align:center;"| 14
|style="text-align:center;"| 16
|style="text-align:center;"| 18
|style="text-align:center;"| 20
|style="text-align:center;"| 30
|style="text-align:center;"| 32
|style="text-align:center;"| 64
|style="text-align:center;"| 100
|style="text-align:center;"| 128
|style="text-align:center;"| 200
|style="text-align:center;"| 256
|style="text-align:center;"| 512
|style="text-align:center;"| 1024
|-

|style="text-align:center;"| 200e6
|style="text-align:center;"| 100e6
|style="text-align:center;"| 50e6
|style="text-align:center;"| 33.33e6
|style="text-align:center;"| 25e6
|style="text-align:center;"| 20e6
|style="text-align:center;"| 16.66e6
|style="text-align:center;"| 14.2857e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 11.11e6
|style="text-align:center;"| 10e6
|style="text-align:center;"| 6.667e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 3.125e6
|style="text-align:center;"| 2e6
|style="text-align:center;"| 1.5625e6
|style="text-align:center;"| 1e6
|style="text-align:center;"| 781.25e3
|style="text-align:center;"| 390.625e3
|style="text-align:center;"| 195.3125e3

|-

|style="text-align:center;"| 245.76e6
|style="text-align:center;"| 122.88e6
|style="text-align:center;"| 61.44e6
|style="text-align:center;"| 30.72e6
|style="text-align:center;"| 20.48e6
|style="text-align:center;"| 15.36e6
|style="text-align:center;"| 12.288e6
|style="text-align:center;"| 10.24e6
|style="text-align:center;"| 8.7771e6
|style="text-align:center;"| 7.68e6
|style="text-align:center;"| 6.8267e6
|style="text-align:center;"| 6.144e6
|style="text-align:center;"| 4.096e6
|style="text-align:center;"| 3.84e6
|style="text-align:center;"| 1.92e6
|style="text-align:center;"| 1.2288e6
|style="text-align:center;"| 960e3
|style="text-align:center;"| 614.4e3
|style="text-align:center;"| 480e3
|style="text-align:center;"| 240e3
|-

|style="text-align:center;"| 250e6
|style="text-align:center;"| 125e6
|style="text-align:center;"| 62.5e6
|style="text-align:center;"| 31.25e6
|style="text-align:center;"| 20.833e6
|style="text-align:center;"| 15.625e6
|style="text-align:center;"| 12.5e6
|style="text-align:center;"| 10.417e6
|style="text-align:center;"| 8.9286e6
|style="text-align:center;"| 7.8125e6
|style="text-align:center;"| 6.9444e6
|style="text-align:center;"| 6.25e6
|style="text-align:center;"| 4.1667e6
|style="text-align:center;"| 3.90625e6
|style="text-align:center;"| 1.953125e6
|style="text-align:center;"| 1.25e6
|style="text-align:center;"| 976.5625e3
|style="text-align:center;"| 625e3
|style="text-align:center;"| 488.28125e3
|style="text-align:center;"| 244.14e3

|-

|}

Additional information on Sample Rates can be found here in the UHD Manual: http://files.ettus.com/manual/page_general.html#general_sampleratenotes

===Probe the USRP===

====N300/N310====
The UHD utility <code>uhd_usrp_probe</code> provides detailed information of the USRP device.

From your host computer, run the command <code>uhd_usrp_probe</code>:

<pre>
$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.HEAD-0-ga0a71d10
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.2,type=n3xx,product=n310,serial=313ABDA,claimed=False,addr=192.168.10.2
[INFO] [MPM.main] Launching USRP/MPM, version: 3.13.1.0-gd3b7e90a
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1355 MB/s)
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.10.2,clock_source=internal,time_source=internal,product=n310'.
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1358 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1355 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1345 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000011312)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000002)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000002)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-313ABDA
| | eeprom_version: 1
| | mpm_version: 3.13.1.0-gd3b7e90a
| | pid: 16962
| | product: n310
| | rev: 3
| | rpc_connection: remote
| | serial: 313ABDA
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.2
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_tpv, ref_locked, gps_time, gps_locked, temp, gps_sky, fan
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: AD9371 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX, RX2, CAL, LOCAL
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 75.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: AD9371 Dual ADC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: AD9371 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 1
| | | | Name: Magnesium
| | | | Antennas: TX/RX
| | | | Sensors: lo_locked, ad9371_lo_locked, lowband_lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 65.0 step 0.5 dB
| | | | Gain range rfic: 0.0 to 0.0 step 0.0 dB
| | | | Gain range dsa: 0.0 to 0.0 step 0.0 dB
| | | | Gain range amp: 0.0 to 0.0 step 0.0 dB
| | | | Bandwidth range: 20000000.0 to 100000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: AD9371 Dual DAC
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1

</pre>

====N320====

<pre>

$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; UHD_3.14.0.0-0-g6875d061
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=127.0.0.1,type=n3xx,product=n320,serial=3181FFA,claimed=False
[INFO] [MPM.main] Launching USRP/MPM, version: 3.14.0.0-g6875d061
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 3181FFA
[INFO] [MPM.Rhodium-0] Successfully loaded all peripherals!
[INFO] [MPM.Rhodium-1] Successfully loaded all peripherals!
[INFO] [MPM.PeriphManager] Initialized 2 daughterboard(s).
[INFO] [MPM.PeriphManager] No QSFP board detected: Assuming it is disabled in the device tree overlay (e.g., HG, XG images).
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal'.
[INFO] [MPM.Rhodium-0] init() called with args `time_source=internal,clock_source=internal'
[INFO] [MPM.Rhodium-1] init() called with args `time_source=internal,clock_source=internal'
[INFO] [MPM.Rhodium-0.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.init.LMK04828] LMK initialized and locked!
[INFO] [MPM.Rhodium-1.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-1.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-1.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.Rhodium-0.DAC37J82] DAC PLL Locked!
[INFO] [MPM.Rhodium-0.AD9695] ADC PLL Locked!
[INFO] [MPM.Rhodium-0.init] JESD204B Link Initialization & Training Complete
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'.
[INFO] [MPM.Rhodium-0] init() called with args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'
[INFO] [MPM.Rhodium-1] init() called with args `mgmt_addr=127.0.0.1,clock_source=internal,time_source=internal,product=n320'
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-3181FFA
| | eeprom_version: 2
| | mpm_version: 3.14.0.0-g6875d061
| | pid: 16962
| | product: n320
| | rev: 6
| | rpc_connection: local
| | serial: 3181FFA
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.3
| | FPGA git hash: 3de8954.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_tpv, temp, gps_sky, fan, gps_time, gps_locked, ref_locked, gps_gpgga
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 3175A79
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 3175A67
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 3175A79
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 3175A67
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Replay_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
| | | * FIFO_1

</pre>

====N321====

<pre>
$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.1 20180712 (Red Hat 7.3.1-6); Boost_106400; UHD_3.14.0.0-0-g6875d061
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.20.2,type=n3xx,product=n320,serial=3166646,claimed=False,addr=192.168.20.2
[INFO] [MPM.PeriphManager] init() called with device args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'.
[INFO] [MPM.Rhodium-0] init() called with args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'
[INFO] [MPM.Rhodium-1] init() called with args `time_source=internal,clock_source=internal,product=n320,mgmt_addr=192.168.20.2'
[INFO] [0/Replay_0] Initializing block control (NOC ID: 0x4E91A00000000004)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000320)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0000000000000)
[INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0000000000000)
_____________________________________________________
/
| Device: N300-Series Device
| _____________________________________________________
| /
| | Mboard: ni-n3xx-3166646
| | eeprom_version: 2
| | mpm_version: 3.14.0.0-g6875d061
| | pid: 16962
| | product: n320
| | rev: 6
| | rpc_connection: remote
| | serial: 3166646
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.3
| | FPGA git hash: 3de8954.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_sky, gps_time, gps_gpgga, gps_locked, fan, gps_tpv, ref_locked, temp
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 316D814
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 316D810
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, RX2, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ad9695-625
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: Unknown (0x0152)
| | | Serial: 316D814
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: Unknown (0x0152)
| | | Serial: 316D810
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Rhodium
| | | | Antennas: TX/RX, CAL, TERM
| | | | Sensors: lo_locked
| | | | Freq range: 1.000 to 6000.000 MHz
| | | | Gain range all: 0.0 to 60.0 step 1.0 dB
| | | | Bandwidth range: 250000000.0 to 250000000.0 step 0.0 Hz
| | | | Connection Type:
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: dac37j82
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * Replay_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
| | | * FIFO_1

</pre>

If you see warnings such as:

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

You need to resize the socket buffers for your network interface card:

sudo sysctl -w net.core.rmem_max=288000
sudo sysctl -w net.core.wmem_max=288000
sudo sysctl -w net.core.rmem_max=33554432

===ASCII Art Example===
The UHD driver includes several example programs, which may serve as test programs or the basis for your application program. The source code can be obtained from the UHD repository on github at: https://github.com/EttusResearch/uhd/tree/master/host/examples

You can quickly verify the operation of your USRP N3xx by running the <code>rx_ascii_art_dft</code> UHD example program.

The <code>rx_ascii_art_dft</code> utility is a simple console based, real-time FFT display tool. It is not graphical in nature, so it can be easily run over an SSH connection within a terminal window, and does not need any graphical capability, such as X Windows, to be installed. It can also be run over a serial console connection, although this is not recommended, as the formatting may not render correctly.

You can run a simple test of the N3xx USRP by connecting an antenna and observing the spectrum of a commercial FM radio station in real-time, following the steps below:

1. Attach an antenna to the <code>Ch0/RX2</code> antenna port of the N3xx.

2. From your host computer, run the command:

'''N300/N310'''
<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"
</pre>

'''N320/N321'''
<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=250e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"
</pre>

NOTE: Modify the command line argument <code>freq</code> above to specify a tuning frequency for a strong local FM radio station. You will also need to update the IP Address to match your device IP.

3. You should see a real-time FFT display of 2.5 MHz of spectrum, centered at the specified tuning frequency.

4. Type "<code>Q</code>" or <code>Ctrl-C</code> to stop the program and to return to the Linux command line.

5. You can run with the <code>--help</code> argument to see a description of all available command-line options.

Example Output:

<pre>
$ /usr/local/lib/uhd/examples/rx_ascii_art_dft --args "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" --subdev "A:0"

Creating the usrp device with: master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2...
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.1.HEAD-0-gad6b0935
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.1.151,type=n3xx,product=n310,serial=313ABDA,claimed=False,master_clock_rate=125e6,addr=192.168.10.2
[INFO] [MPM.main] Launching USRP/MPM, version: 3.11.1.0-gunknown
[INFO] [MPM.main] Spawning RPC process...
[INFO] [MPM.PeriphManager] Device serial number: 313ABDA
[INFO] [MPM.PeriphManager] Found 2 daughterboard(s).
[INFO] [MPM.RPCServer] RPC server ready!
[INFO] [MPM.RPCServer] Spawning watchdog task...
[INFO] [MPM.PeriphManager] init() called with device args `mgmt_addr=192.168.1.151,product=n310,master_clock_rate=125e6'.
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D00000000004)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1338 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1346 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1350 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_2] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/Radio_3] Initializing block control (NOC ID: 0x12AD100000000310)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_2] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DDC_3] Initializing block control (NOC ID: 0xDDC0000000000001)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_2] Initializing block control (NOC ID: 0xD0C0000000000000)
[INFO] [0/DUC_3] Initializing block control (NOC ID: 0xD0C0000000000000)
Using Device: Single USRP:
Device: N300-Series Device
Mboard 0: ni-n3xx-313ABDA
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: Magnesium
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: Magnesium
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: Magnesium
TX Channel: 2
TX DSP: 0
TX Dboard: C
TX Subdev: Magnesium
TX Channel: 3
TX DSP: 0
TX Dboard: D
TX Subdev: Magnesium

Setting RX Rate: 2.500000 Msps...
Actual RX Rate: 2.500000 Msps...

Setting RX Freq: 98.500000 MHz...
Actual RX Freq: 98.500000 MHz...

Setting RX Gain: 50.000000 dB...
Actual RX Gain: 50.000000 dB...

Checking RX: all_los: locked ...

Done!
</pre>

===Benchmarking your system===
Included with the UHD driver example programs is a utility, <code>benchmark_rate</code> to benchmark the transport link of the system.

A system's maximum performance is dependent upon many factors. <code>benchmark_rate</code> will exercise the transport link and CPU of the system.

====1 Gb Interface====
NOTE: This example requires the <code>HG</code> FPGA image to be loaded.

'''N300/N310'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 3.84 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=122.88e6" \
--duration 60 \
--channels "0" \
--rx_rate 3.84e6 \
--rx_subdev "A:0" \
--tx_rate 3.84e6 \
--tx_subdev "A:0"

'''N310'''

This example will test four full-duplex streams at 1.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 1.25e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 1.25e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 3.84 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,master_clock_rate=245.76e6" \
--duration 60 \
--channels "0" \
--rx_rate 3.84e6 \
--rx_subdev "A:0" \
--tx_rate 3.84e6 \
--tx_subdev "A:0"

When streaming samples over a 1 Gb transport link, the maximum accumulative rate for all channels is 25 MS/s with a <code>sc16</code> OTW format. To achieve higher streaming rates, it is recommended to use the 10 Gb interfaces.

====10 Gb Interface SFP 1====
NOTE: This example will work with either the <code>HG</code> or <code>XG</code> FPGA image.

'''N300/N310'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 31.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0" \
--rx_rate 31.25e6 \
--rx_subdev "A:0" \
--tx_rate 31.25e6 \
--tx_subdev "A:0"

'''N320/N321'''

This example will test one full-duplex stream using "RF0/A:0", at a rate of 31.25 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=250e6" \
--duration 60 \
--channels "0" \
--rx_rate 31.25e6 \
--rx_subdev "A:0" \
--tx_rate 31.25e6 \
--tx_subdev "A:0"

'''N310'''

This example will test four full-duplex streams at 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=122.88e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test two full-duplex streams at 30.72 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.20.2,master_clock_rate=245.76e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 30.72e6 \
--rx_subdev "A:0 B:0" \
--tx_rate 30.72e6 \
--tx_subdev "A:0 B:0"

====Dual 10 Gb Interface====
NOTE: This example requires the <code>XG</code> FPGA image to be loaded.

'''N310'''

This example will test four full-duplex streams at 62.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=125e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 62.5e6 \
--rx_subdev "A:0 A:1 B:0 B:1" \
--tx_rate 62.5e6 \
--tx_subdev "A:0 A:1 B:0 B:1"

'''N320/N321'''

This example will test two full-duplex streams at 62.5 MS/s, for 60 seconds:

/usr/local/lib/uhd/examples/benchmark_rate \
--args "type=n3xx,mgmt_addr=192.168.1.151,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=250e6" \
--duration 60 \
--channels "0,1,2,3" \
--rx_rate 62.5e6 \
--rx_subdev "A:0 B:0" \
--tx_rate 62.5e6 \
--tx_subdev "A:0 B:0"

==USRP N3xx Device Specific Operations==

===White Rabbit Ethernet-Based Synchronization===
* [[Using Ethernet-Based Synchronization on the USRP™ N3xx Devices]]

===N320/N321===
* [[USRP N320/N321 LO Distribution]]
* [[5G NR EVM Measurements with the USRP N320/N321]]

===Turning the Device Off/On===
To avoid damaging the file system and causing any corruption, do not turn the device off with the power button without first shutting down the system. Use this command to cleanly and properly shut the system down:

shutdown -h now

===Enable Auto Booting===
Auto booting of the N3xx when power is applied can be configured by enabling the flag on the device's EEPROM with the following command:

eeprom-set-flags 0x1

===Default Password===
The default user is <code>root</code> and the password is empty (no password).

It is recommended to update the <code>root</code> password, which can be done with the command <code>passwd</code>:

Example Output:

root@ni-n3xx-serial:~# passwd
Changing password for root
New password:
Re-enter new password:
passwd: password changed.

==Technical Support and Community Knowledge Base==
Technical support for USRP hardware is available through email only. If the product arrived in a nonfunctional state or you require technical assistance, please contact [mailto:support@ettus.com support@ettus.com]. Please allow 24 to 48 hours for response by email, depending on holidays and weekends, although we are often able to reply more quickly than that.

We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.

Discussions involving the USRP hardware and the UHD software itself are best addressed through the '''usrp-users''' mailing list at [http://usrp-users.ettus.com http://usrp-users.ettus.com].

Discussions involving the use of [http://gnuradio.org/ GNU Radio] with USRP hardware and UHD software are best addressed through the '''discuss-gnuradio''' mailing list at [https://lists.gnu.org/mailman/listinfo/discussgnuradio https://lists.gnu.org/mailman/listinfo/discussgnuradio].

Discussions involving the use of [http://openbts.org/ OpenBTS®] with USRP hardware and UHD software are best addressed through the '''openbts-discuss''' mailing list at [https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss].

The support page on our website is located at [https://www.ettus.com/support https://www.ettus.com/support]. The Knowledge Base is located at [https://kb.ettus.com https://kb.ettus.com].

==Legal Considerations==
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.

*NOTE: This USRP product is a piece of test equipment.

==Sales and Ordering Support==
If you have any non-technical questions related to your order, then please contact us by email at [mailto:orders@ettus.com orders@ettus.com], or by phone at +14086106399 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.

==Terms and Conditions of Sale==
Terms and conditions of sale can be accessed online at the following link: http://www.ettus.com/legal/terms-and-conditions-of-sale

[[Category:Getting Started Guides]]
[[Category:N300]]
[[Category:N310]]

[[Category:N320]]

[[Category:N321]]