path: root/host/docs/usrp_e3xx.dox

/*! \page page_usrp_e3xx USRP E3xx Series

\tableofcontents

\section e3xx_feature_list Comparative features list
There are two category of devices in the E3xx series.
1. E310 series which includes E310, E312 and E313.
2. E320 - OEM board-only and with enclosure.

These devices have some differences in their hardware capabilities but both
are 2-channel transmitter/receiver based on the AD9361 transceiver IC and
provide two RF channels:

- TX band: 47 MHz to 6.0 GHz
- RX band: 70 MHz to 6.0 GHz
- 56 MHz of instantaneous bandwidth
- 2 RX DDC chains in FPGA
- 2 TX DUC chain in FPGA

\subsection e3xx_feature_list_e310 E310
The E310/E312/E313 has a motherboard and a daughterboard in an enclosed module
with one AD9361 IC with 2 RF channels.

- Hardware Capabilities:
	- External PPS reference input
	- 2 USB 2.0 Host ports
	- Configurable clock rate
	- Internal IMU
	- Internal GPS
	- Internal GPIO connector with UHD API control
	- External USB Connection for built-in JTAG debugger and serial console
	- Xilinx Zynq SoC with dual-core ARM Cortex A9 (Speed Grade 1 and 3) and
          Kintex-7 FPGA (XC7Z020)
- Software Capabilities:
	- Full Linux system running on the ARM core
	- Runs MPM (see also \ref page_mpm) (introduced in UHD v3.15.0.0)
- FPGA Capabilities:
	- RFNoC capability

\subsection e3xx_feature_list_e320 E320
The E320 is monolithic board with one AD9361 IC with 2 RF channels.

- Hardware Capabilities:
	- Single SFP+ Transceivers (can be used with 1 GigE, 10 GigE, and Aurora)
	- External PPS input
	- External 10 MHz input
	- Configurable clock rate
	- Internal IMU
	- Internal GPSDO for timing, location, and 10 MHz reference clock + PPS
	- External GPIO Connector with UHD API control
	- External USB Connection for built-in JTAG debugger and serial console
	- Xilinx Zynq SoC with dual-core ARM Cortex A9 (Speedgrade 3) and
        Kintex-7 FPGA (XC7Z045)
	- Fan connector (for board-only version)
- Software Capabilities:
	- Full Linux system running on the ARM core
	- Runs MPM (see also \ref page_mpm)
- FPGA Capabilities:
	- RFNoC capability

\section e310_overview E310 Overview

\subsection e310_zynq The Zynq CPU/FPGA and host operating system

The main CPU of the E310 is a Xilinx Zynq SoC XC7Z020. It
is both a dual-core ARM Cortex A9 CPU and Kintex-7 FPGA on a single die. The
CPU is clocked at 667 MHz (speed grade 1) and 866 MHz (speed grade 3).

The programmable logic (PL, or FPGA) section of the SoC is responsible for
handling all sampling data, DMA connections, and any other
high-speed utility such as custom RFNoC logic. The processing system (PS, or CPU)
is running a custom-build OpenEmbedded-based Linux operating system. The OS is
responsible for all the device and peripheral management, such as running MPM
(see section \ref page_mpm), running local, UHD sessions, etc.

\subsection e31x_migration E310 Migration Guide to MPM architecture

This section covers the details for porting your E310 to the new MPM architecture.
MPM is a hardware daemon running on the Linux operating system on the ARM cores
and responsible for the device to function as a USRP.

A large portion of hardware-specific setup is handled by the daemon.

Note that the SD cards shipped with E310s do not contain the latest filesystem images. In order
to use MPM (see section \ref page_mpm) and all its features, the SD cards need to be
manually flashed. Refer to \ref update_sdcard in order to upgrade to E310 with UHD v3.15.0.0 or above.

After updating the SD card, you should be able to connect your device to the host OS either via SSH or
serial console. See sections \ref e3xx_getting_started_ssh and \ref e3xx_getting_started_serial
respectively, for more details.

Once you are logged in on the device, you should be able to run uhd_usrp_probe or other UHD examples.

Here is a list of a changes with the latest E310 filesystem (UHD v3.15.0.0) that can affect customer usage
and applications:

1. Hostname:
The hostname for the devices have changed from ni-e3xx(-sg3) to `ni-e31x-$serial`.
This makes it easier to identify devices. You can change the hostname by modifying the
`/etc/hostname` file and rebooting.

2. "product" name:
The "product" name for E310 is now "e310_<speedgrade>" i.e. e310_sg1 and e310_sg3 for speed grade 1
and 3 respectively. Note that the "type" for e310 remains the same as before i.e. "e3xx".

3. FPGA bit/bin/rpt file name and image target:
    FPGA type                          | Old filename                | New filename
    -----------------------------------|-----------------------------|---------------------------------
    IDLE Image (power saving mode) SG1 | usrp_e3xx_fpga_idle.bit     | usrp_e310_sg1_idle_fpga.bit
    IDLE Image (power saving mode) SG3 | usrp_e3xx_fpga_idle_sg3.bit | usrp_e310_sg3_idle_fpga.bit
    NORMAL Image SG1                   | usrp_e310_fpga.bit          | usrp_e310_sg1_fpga.bit
    NORMAL Image SG3                   | usrp_e310_fpga_sg3.bit      | usrp_e310_sg3_fpga.bit

    The names of the FPGA build targets have been modified but the old FPGA targets would continue to
    work as before. The generated bit files names in the build directory will be new as
    mentioned above.
    - E310_<speedgrade> for default image
    - E310_<speedgrade>_RFNOC for RFNOC image (contains a few blocks)
    - E310_<speedgrade>_IDLE to build idle image (Doesn't need to modified for most cases)

4. Loading FPGA image:
The device arg "fpga=" can now only be used in the uhd_image_loader; it can no longer be used to
update the fpga image in other UHD applications. This tooling now matches X310, E320, N3XX, etc.
devices. See section \ref e3xx_getting_started_fpga_update for details.

5. With UHD v3.15.0.0. or higher, a lot of UHD dependencies have been upgraded too e.g. Boost, CMake,
etc. The filesystem now runs a newer Linux kernel (e.g. linux-yocto_4.15 or higher). Existing customer
applications might need to be updated in order to use the new filesystem and new UHD.

6. In order to build a custom filesystem, refer to \ref e3xx_fsbuild for more details.

7. E310 filesystem no longer contains GNURadio by default. Custom filesystems are need to run GNURadio.

8. The network mode (streaming through RJ-45) for the E310 is not supported. In order to use the network
mode use UHD 3.9 LTS release.

9. Refer section \ref e312_battery for changes related to the battery.

10. Subdev spec has been changed from "A:A and A:B" to "A:0 and A:1" to match X310, N3xx and E320.


\section e320_overview E320 Overview

\subsection e320_zynq The Zynq CPU/FPGA and host operating system

The main CPU of the E320 is a Xilinx Zynq SoC XC7Z045. It
is both a dual-core ARM Cortex A9 CPU and Kintex-7 FPGA on a single die. The
CPU is clocked at 1GHz (speed grade 3).

The programmable logic (PL, or FPGA) section of the SoC is responsible for
handling all sampling data, the 1/10 GigE network connections, and any other
high-speed utility such as custom RFNoC logic. The processing system (PS, or CPU)
is running a custom-build OpenEmbedded-based Linux operating system. The OS is
responsible for all the device and peripheral management, such as running MPM
(see section \ref page_mpm), configuring the network interfaces, running local
UHD sessions, etc.

It is possible to connect to the host OS either via SSH or serial console (see
sections \ref e3xx_getting_started_ssh and \ref e3xx_getting_started_serial,
respectively).

\subsection e320_micro The STM32 microcontroller

The STM32 microcontroller controls various low-level features of the E320 series
motherboard: It controls the power sequencing, reads out fan speeds and some of
the temperature sensors. It is connected to the Zynq via an I2C bus.

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

\subsection e3xx_sdcard The SD card

The E310/E312/E313/E320 use a micro SD card as its main storage. The entire root file
system (Linux kernel, libraries) and any user data are stored on this SD card.

The SD card is partitioned into four partitions:

- Boot partition (contains the bootloader). This partition usually does not
   require any modifications.
- 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:

    $ mkdir temp
    $ mount /dev/mmcblk0p3 temp
    $ 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

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

\section e3xx_getting_started Getting started

This will run you through the first steps relevant to getting your USRP E3XX
up and running.
Note: This guide was creating on an Ubuntu machine, and other distributions
or OS's may have different names/methods.

\subsection e3xx_getting_started_assembling Assembling the E3XX

Unlike the X300 or N200 series, there is no assembly required for all E3xx devices
as E310 motherboard and daughterboard comes in an enclosure and E320, on the other
hand is a monolithic board (in board-only version) or comes in an enclosure.

Checklist:
- Connect power and network
- Read security settings
- Connect clocking (if required)

\subsection e3xx_getting_started_fs_update Updating the file system

\subsubsection e31x_fs E310/E312/E313 file system

The SD cards shipped with E310s do not contain the latest filesystem images. In order
to use MPM and all its features, the SD cards need to be manually flashed. Refer to
\ref update_sdcard in order to upgrade to E310 with UHD v3.15.0.0 or above. Once it has
been upgraded to the new filesystem, Mender can be used to remotely update the filesystems.
For details on using Mender, see Section \ref e3xx_rasm_mender.

\subsubsection e320_fs E320 file system

Before doing any major work with a newly acquired USRP E320, it is
recommended to update the file system. For the OEM/Board-only version of
E320, the SD card is physically accessible and filesystem update can be
accomplished directly by using Mender or externally by manually writing
an image onto a micro SD card and inserting it. For the
enclosure version of E320, Mender update is required as there is no direct
physical access to the device.  For details on using Mender,
see Section \ref e3xx_rasm_mender .

\subsubsection update_sdcard Updating the SD card

Manual updating is simply loading an image on the micro SD card.  The first step
in that process is to obtain an image.

To obtain the default micro SD card image for a specific version of UHD, install
that version of UHD (E320 - 3.13.0.2 or later, E310 - 3.15.0.0 or later) on a host system with Internet access and run:

    $ uhd_images_downloader -t <e310/e320> -t sdimg

   The image will be downloaded to
   `<UHD_INSTALL_DIR>/share/uhd/images/usrp_<e310/e320>_fs.sdimg`,
   where `<UHD_INSTALL_DIR>` is the UHD installation directory.

To load an image onto the micro SD card, connect the card to the host and run:

    $ sudo dd if=<YOUR_IMAGE> of=/dev/<YOUR_SD_CARD> bs=1M

   The `<YOUR_IMAGE>` is the path to the micro SD card image
   (i.e.`<UHD_INSTALL_DIR>/share/uhd/images/usrp_<e310/e320>_fs.sdimg`).

   The `<YOUR_SD_CARD>` device node depends on your operating system and which
   other devices are plugged in. Typical values are `sdb` or `mmcblk0`.<br>

   CAUTION: The Linux utility `dd` or `bmap` can cause unrecoverable data loss
   if the incorrect disk is selected, or if the parameters are input incorrectly.
   Ensure you have selected the correct input and output parameters for your
   system configuration.

The micro SD card used can be the original SD card shipped with the device or
another one that is at least 8GB for E310 and at least 16 GB for E320 in size.

\section e3xx_fsbuild Building custom filesystems and SD card images

Ettus Research provides SD card images at regular intervals, but there can be
good reasons to build custom SD cards, e.g., to test the very latest UHD or MPM
for which there has not been an SD card release, to add own applications to the
SD card, or to run a modified version of UHD.

Note that building SD cards is very disk space and RAM intensive.

\subsection e3xx_fsbuild_docker Using Docker to build filesystems

Ettus Research provides a Docker containers to facilitate building filesystems.
Refer to the <a href="https://github.com/EttusResearch/ettus-docker/blob/master/oe-build/README.md"> README </a> for more details.

\subsection e3xx_getting_started_serial Serial connection

It is possible to gain root access to the device using a serial terminal
emulator. Most Linux, OSX, or other Unix flavours have a tool called 'screen'
which can be used for this purpose, by running the following command:

    $ sudo screen /dev/ttyUSB2 115200

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`:

For E310:

    $ ls /dev/serial/by-id
    /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DQ0041HO-if00-port0

For E320:

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

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

Every E310 device connected to USB will by default show up as one
device. The device labeled "FTDI_FT230X_Basic_UART_DQ0041HO" connects
to Linux.

Every E320 device connected to USB will by default show up as four
different devices. The devices labeled "USB_to_UART_Bridge_Controller" are the
devices that offer a serial prompt. The one with the `if01` suffix connects
to Linux, whereas the one with `if00` suffix connects to the STM32 microcontroller.
If you have multiple E320 devices connected, you may have to try out multiple
devices. In this case, to use this symlink instead of the raw device node
address, modify the command above to:

For E310:

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

For E320:

    $ sudo screen /dev/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6A6C-if01-port0 115200

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

    root@ni-<e31x/e320>-<serial>:~#

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.

\subsubsection e320_getting_started_serial_micro Connecting to the microcontroller

The STM32 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:

    $ sudo screen /dev/usb-Silicon_Labs_CP2105_Dual_USB_to_UART_Bridge_Controller_007F6CB5-if00-port0 115200

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 (i.e., emulating a power button press)
and other low-level diagnostics.

\subsection e3xx_getting_started_ssh SSH connection

The USRP E310 devices have just one network connection: RJ-45 connector while the
USRP E320 has two network connections: One SFP port, and an RJ-45 connector.

The RJ-45 connection is by default configured by DHCP; by plugging it into a 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
\ref e3xx_getting_started_serial. 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:

    $ ssh root@ni-<e31x/e320>-<serial> # Replace with your actual device name!

Depending on your network setup, using a `.local` domain may work:

    $ ssh root@ni-<e31x/e320>-<serial>.local

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
(`ni-<e31x/e320>-<SERIAL>`). You can change the hostname by modifying the `/etc/hostname`
file and 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:

    root@ni-<e31x/e320>-<serial>:~#

\subsection e3xx_getting_started_connectivity Network Connectivity

The RJ45 port (eth0) comes up with a default configuration of DHCP,
that will request a network address from your DHCP server (if available on your
network).

The factory settings are as follows:

    eth0 (DHCP):

        [Match]
        Name=eth0

        [Network]
        DHCP=v4

        [DHCPv4]
        UseHostname=false

E320 has an extra SFP+ (sfp0) port which is configured with static address 192.168.10.2/24.
The configuration for the sfp0 port is stored in /etc/systemd/networkd/sfp0.network.

For configuration please refer to the
<a href=https://www.freedesktop.org/software/systemd/man/systemd.network.html>systemd-networkd manual pages</a>

The factory settings are as follows:

    sfp0 (static):

        [Match]
        Name=sfp0

        [Network]
        Address=192.168.10.2/24

        [Link]
        MTUBytes=8000

Note: Care needs to be taken when editing these files on the device, since
vi / vim sometimes generates undo files (e.g. /etc/systemd/networkd/sfp0.network~),
that systemd-networkd might accidentally pick up.

Note: Temporarily setting the IP addresses via ifconfig etc will only change the
value until the next reboot or reload of the FPGA image.

\subsection e3xx_getting_started_security Security-related settings

The E320 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

    $ passwd

on the device.

\subsection e3xx_getting_started_fpga_update Updating the FPGA

Updating the FPGA follows the same procedure as other USRPs. Use the `uhd_image_loader`
command line utility to upload a new FPGA image onto the device. The command can be run
on the host to load the image via RJ-45 network connection or it can be run on the
device.

A common reason to update the FPGA image is in the case of a UHD/FPGA compat
number mismatch (for example, if UHD has been updated, and now expects a newer
version of the FPGA than is on the device). In this case, simply run

    $ uhd_images_downloader

to update the local cache of FPGA images. Then, run

    $ uhd_image_loader --args type=e3xx,addr=ni-<e31x/e320>-<serial>

to update the FPGA using the default settings. Replace the addr above with the
correct device address. If a custom FPGA image is targeted for uploading, use the
`--fpga-path` command line argument. Run

    $ uhd_image_loader --help

to see a full list of command line options. Note that updating the FPGA image
will force a reload of the FPGA, and in case of E320 it will temporarily take down
the SFP network interfaces (and temporary settings, such as applied via `ifconfig`
on the command line, will be lost).


\section e3xx_usage Using an E3XX USRP from UHD

Like any other USRP, all E series USRPs are controlled by the UHD software. To
integrate a USRP E310/E312/E313/E320 into your C++ application, you would generate a UHD
device in the same way you would for any other USRP:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto usrp = uhd::usrp::multi_usrp::make("type=e3xx");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For a list of which arguments can be passed into make(), see Section
\ref e3xx_usage_device_args.

\subsection e3xx_usage_device_args Device arguments

 Key                 | Description                                                                   | Example Value
---------------------|-------------------------------------------------------------------------------|---------------------
 addr                | IPv4 address of primary SFP+/RJ-45 port to connect to                         | addr=192.168.30.2
 find_all            | When using broadcast, find all devices, even if unreachable via CHDR.         | find_all=1
 master_clock_rate   | Master Clock Rate in Hz. Default is 16 MHz.                                   | master_clock_rate=30.72e6
 skip_dram           | Ignore DRAM FIFO block. Connect TX streamers straight into DUC or radio.      | skip_dram=1
 skip_ddc            | Ignore DDC block. Connect Rx streamers straight into radio.                   | skip_ddc=1
 skip_duc            | Ignore DUC block. Connect Tx streamers or DRAM straight into radio.           | skip_duc=1
 skip_init           | Skip the initialization process for the device.                               | skip_init=1
 discovery_port      | Override default value for MPM discovery port.                                | discovery_port=49700
 rpc_port            | Override default value for MPM RPC port.                                      | rpc_port=49701

\subsection e3xx_usage_sensors The sensor API

\subsubsection e310_sensors E31X Sensors

Like other USRPs, the E310 series has RF and motherboard sensors.
When using uhd::usrp::multi_usrp, the following API calls are relevant to
interact with the sensor API:

- uhd::usrp::multi_usrp::get_mboard_sensor_names()
- uhd::usrp::multi_usrp::get_mboard_sensor()
- uhd::usrp::multi_usrp::get_tx_sensor_names()
- uhd::usrp::multi_usrp::get_rx_sensor_names()
- uhd::usrp::multi_usrp::get_tx_sensor()
- uhd::usrp::multi_usrp::get_rx_sensor()

The following motherboard sensors are always available:
- `temp_fpga`: temperature (in Celsius) of the FPGA die
- `temp_mb`: temperature (in Celsius) of the motherboard
- `ref_locked`: This will check that all the daughter boards have locked to the
reference clock.

\subsubsection e320_sensors E320 Sensors

Like other USRPs, the E320 series has RF and motherboard sensors.
When using uhd::usrp::multi_usrp, the following API calls are relevant to
interact with the sensor API:

- uhd::usrp::multi_usrp::get_mboard_sensor_names()
- uhd::usrp::multi_usrp::get_mboard_sensor()
- uhd::usrp::multi_usrp::get_tx_sensor_names()
- uhd::usrp::multi_usrp::get_rx_sensor_names()
- uhd::usrp::multi_usrp::get_tx_sensor()
- uhd::usrp::multi_usrp::get_rx_sensor()

The following motherboard sensors are always available:
- `temp_internal`: temperature (in Celsius) of Temperature Sensor on board
- `temp_fpga`: temperature (in Celsius) of the FPGA die
- `temp_rf_channelA`: temperature (in Celsius) near power amplifier RF A
- `temp_rf_channelB`: temperature (in Celsius) near power amplifier RF B
- `temp_main_power`: temperature (in Celsius) near power supply
- `gps_locked`: GPS lock
- `gps_time`: GPS time in seconds sin ce the epch
- `gps_tpv`: A TPV report from GPSd serialized as JSON
- `gps_sky`: A SKY report from GPSd serialized as JSON
- `ref_locked`: This will check that all the daughter boards have locked to the
external/internal reference clock.
- `fan`: get fan speed (in rpm)

\section e3xx_rasm Remote Management

\subsection e3xx_rasm_mender Mender: Remote update capability

Mender is a 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. Mender servers can be self-hosted, or
hosted by Mender (see [mender.io](https://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: every SD card comes with
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. 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.
See also Section \ref e3xx_sdcard.

Note: For E310, the SD cards that are shipped with the device do not have the latest
UHD and do not support MPM by default. The SD cards will have to be flashed with
UHD v3.15.0.0 or above to be able to use mender. After the first upgrade, mender
can be used for future upgrades. Refer to the migration guide. \ref e31x_migration

To initiate an update from the device itself, download a Mender artifact
containing the update itself. These are files with a `.mender` suffix.

Then run mender on the command line:

    $ mender -rootfs /path/to/latest.mender

The artifact can also be stored on a remote server:

    $ mender -rootfs http://server.name/path/to/latest.mender

This procedure will take a while. After mender has logged a successful update,
reboot the device:

    $ reboot

If the reboot worked, and the device seems functional, commit the changes so
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:

    $ cat /etc/mender/artifact_info

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 simple way to
update groups of rack-mounted USRPs with custom file systems.

\subsection e3xx_rasm_salt Salt: Remote configuration management and execution

Salt (also known as SaltStack, see [Salt Website](https://saltstack.com)) is a
Python-based tool for maintaining fleets of remote devices. It can be used to
manage USRP E31X/E320 remotely for all types of settings that are not
controlled by UHD. For example, if an operator would like to reset the root
password on multiple devices, or install custom software, this tool might be a
suitable choice.

Salt is a third-party project with its [own documentation](https://docs.saltstack.com/en/latest/),
which should be consulted for configuring it. However, the Salt minion is
installed by default on every E31X/E320 device. To start it, simply log on to the
device and run:

    $ systemctl start salt-minion

To permanently enable it at every boot, run (this won't by itself launch the
salt-minion):

    $ systemctl enable salt-minion

To make use of Salt, both the device needs to be configured (the "minion") and,
typically, a server to act as the Salt master. Refer to the Salt documentation
on how to configure the minion and the master. A typical sequence to get started
will look like this:

1. Install the salt-master package on the server (e.g. by running `apt install salt-master`
   if the server is an Ubuntu system), and make sure the Salt master is running.
2. Add the network address / hostname of that server to the `/etc/salt/minion`
   file on the device by editing the `master:` line.
3. Launch the Salt minion on the USRP by running the command `systemctl start salt-minion`.
4. The minion will try to connect to the master. You need to authorize the
   minion by running `salt-key -a $hostname` where `$hostname` is the name of
   the minion.
5. Once the device is authorized, you can try various commands to see if the
   communication was established:

\code{.sh}
    $ [sudo] salt '*' test.ping
    ni-e3xx-$serial:
        True
    $ [sudo] salt '*' network.interfaces
    ni-e3xx-$serial:
        ----------
        eth0:
            ----------
            hwaddr:
                02:00:03:11:fe:00
            inet:
                |_
                  ----------
                  address:
                      xx.xx.xx.xx
                  broadcast:
                      xx.xx.xx.xx
                  label:
                      eth0
                  netmask:
                      255.255.254.0
            up:
                True
    # [...]
\endcode

\section e3xx_troubleshooting Troubleshooting

\subsection e3xx_troubleshooting_bist E320 Built-in Self-Test (BiST)

The E320 series devices have a built-in self-test that can be used to verify
the hardware. It is not automatically run, but it can be invoked anytime by
running the `e320_bist` executable. Calling

    e320_bist -h

will list the available options. Tests can be run by specifying their name, e.g.

    e320_bist gpsdo

will test the functionality of the GPSDO. Calling `e320_bist standard` will run
a standard set of tests, verifying some base peripherals such as the RTC, the
fan and temperature sensors, etc.

Some tests require special hardware connected. For example, for the `sfp_loopback`
tests, a loopback module must be plugged into the SFP+.

Tests may also load different FPGA images, if required. The aforementioned
SFP tests will load the Aurora FPGA image and use Aurora to run the BER tests on
the SFP port. This is particularly relevant if either a custom image was
loaded, or if there is an active SSH or other connection coming in via the SFP+
ports.

\section e3xx_theory_of_ops Theory of Operation

All E series devices are on the MPM architecture (see also: \ref page_mpm).
Inside the Linux operating system running on the ARM
cores, there is a hardware daemon which needs to be active in order for the
device to function as a USRP (it is enabled to run by default).

A large portion of hardware-specific setup is handled by the daemon.

\section e3xx_software_dev Modifying and compiling UHD and MPM for the E320

E320 devices ship with all relevant software installed on the SD card. Updating
UHD and/or MPM on the SD card is typically easiest done by updating the
filesystem image (see Section \ref e3xx_rasm_mender). However, it is certainly
possible to compile UHD and MPM by hand, e.g., in order to modify and try out
changes without having to build entire filesystems in between. At Ettus R&D,
this mode of operation is often used for rapid iteration cycles.

While on E310 the SD cards that are shipped with the device do not have the latest
UHD and do not support MPM by default. The SD cards will have to be flashed with
UHD v3.15.0.0 or above to be able to use mender. After the first upgrade, mender
can be used for future upgrades. Refer to the migration guide. \ref e31x_migration

\subsection e3xx_software_dev_mpm_native Compiling MPM natively

In general, compiling natively is not a recommended way of compiling code for
the ARM processors. However, in the case of MPM, the amount of C++ code that
needs to be compiled is very little, and a full compile of MPM will take a few
minutes even on the device. First, you need to get a copy of the MPM source code
onto your device. If you have an internet connection, you can use git to pull
it directly from the Ettus repository (all commands are run on the device
itself, inside the home directory):

    $ git clone https://github.com/EttusResearch/uhd.git

You can also SSHFS it from another computer:

    $ mkdir uhd # Create a new, empty directory called uhd
    $ sshfs user@yourcomputer:src/uhd uhd # This will mount ~/src/uhd from the remote machine to ~/uhd on the device

Now, create a build directory and use the regular cmake/make procedure to kick
off a build. It can be advantageous (especially for slow network connections)
to create the build directory outside of the repository directory:

    $ mkdir build_mpm
    $ cd build_mpm # You are now in /home/root/build_mpm
    $ cmake ../uhd/mpm
    $ make -j2 install # This will take several minutes

Note that this overwrites your system MPM. You can install MPM to another
location by specifying `-DCMAKE_INSTALL_PREFIX`, but make sure to update all of
your paths appropriately.

If you prefer cross-compiling MPM the same way as UHD, refer to the following
sections and adapt the instructions for UHD appropriately.

\subsection e3xx_software_dev_sdk Obtaining an SDK

The recommended way to develop software for the E31X/E320 is to cross-compile. By
running the compiles on a desktop or laptop computer, you will be able to speed
up compile times considerably (compiling UHD natively would take
many hours).

SDKs are distributed along with other binaries. They contain a cross-compiler,
a cross-linker, a cross-debugger, and all the libraries available on the device
to mirror its environment.
Note: The SDK for E310 has been updated for UHD versions above v.3.15.0.0. Refer to
the migration guide for details. \ref e31x_migration

To unpack the SDK, simply execute it after downloading it:

    $ cd /usr/local/share/uhd/images # Change this to where your images are stored
    $ ./oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh

If this doesn't work, the executable permissions of the file might have been
lost (this can occur with some versions of Python). In that case, add those
permissions back before executing the `.sh` file:

    $ chmod +x oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh

Executing the `.sh` file will prompt you for an installation path.  Please
ensure you have sufficient disk space, as each of the SDKs may require several
gigabytes of disk space (depending on the image flavor selected).

This will allow you to compile UHD as well as (depending on the image flavor)
other software.

Please note, that while several toolchains can be installed in parallel, they
have to be installed to different directories.

\subsection e3xx_software_dev_sdkusage SDK Usage

Having installed the toolchain in the last step,
in order to build software for your device open a new shell and type:

    $ . $SDKPATH/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi

This will modify the PATH, CC, CXX etc, environment variables and allow you to compile software for your device.
To verify all went well you can try:

    $ $CC -dumpmachine

which should return 'arm-oe-linux-gnueabi'.

\subsubsection e3xx_software_dev_uhd Building UHD

-# Obtain the UHD source code via git or tarball
-# Set up your environment as described in \ref e3xx_software_dev_sdkusage
-# Type the following in the build directory (assuming a build in host/build):

        $ cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake -DCMAKE_INSTALL_PREFIX=/usr .. # Add any CMake options you desire
        $ make # You can run make -j12 to compile on 12 processes at once

Note: The UHD you are cross-compiling will not run on your host computer (the
one where you're doing the development). Compiling UHD regularly on your host
computer (with MPMD enabled) will allow you to talk to your device.

\subsubsection e3xx_software_dev_gr Building GNU Radio

-# Obtain the GNU Radio source code via git or tarball
-# Set up your environment as described in \ref e3xx_software_dev_sdkusage
-# Use the following commands to create a build directory, configure and compile gnuradio. You only need create the build directory once.

\code{.sh}
$ mkdir build-arm
$ cd build-arm
$ cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake \-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_GR_VOCODER=OFF -DENABLE_GR_ATSC=OFF \
-DENABLE_GR_DTV=OFF -DENABLE_DOXYGEN=OFF ../ # Append any CMake options you desire
\endcode

Several GNU Radio components depend on running binaries built for the build
machine during compile. These binaries can be built and used for cross
compiling, but this is an advanced topic.

\section e31x_device E310-specific Features

\subsection e31x_hw_front_panel Front Panel

\image html e3x0_fp_overlay.png "USRP E310 Front panel"

- **RF A Group**
  + **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on frontend side A
  + **RX2 LED**: Indicates that data is streaming on the RX2 channel on frontend side A

- **RF B Group**
  + **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on frontend B
  + **RX2 LED**: Indicates that data is streaming on the RX2 channel on frontend B
- **PWR**: Power switch with integrated status LED, for status description see below.

- **SYNC**: Input port for external PPS signal

- **GPS**: Connection for the GPS antenna

The status LED in the power switch indicates the power and charge status.
Its behavior is firmware version dependent.

- **Version 1** (original E310)
  + **Off**: Indicates device is off and not charging
  + **Solid Red**: Indicates device is charging
  + **Solid Green**: Indicates device is on
  + **Fast Blinking Red**: Indicates an error code
    + 1 - Low voltage error
    + 2 - Regulator low voltage error
    + 3 - FPGA power error
    + 4 - DRAM power error
    + 5 - 1.8V rail power error
    + 6 - 3.3V rail power error
    + 7 - Daughterboard / TX power error
    + 9 - Temperature error

- **Version 2** (E312 and upgraded E310)
  + **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, if E312)
  + **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
    + 1 - Low voltage error
    + 2 - Regulator low voltage error
    + 3 - FPGA power error
    + 4 - DRAM power error
    + 5 - 1.8V rail power error
    + 6 - 3.3V rail power error
    + 7 - Daughterboard / TX power error
    + 8 - Charger error
    + 9 - Charger temperature error
    + 10 - Battery low error
    + 11 - Fuel Gauge temperature error
    + 12 - Global (case) temperature error

\subsection e31x_hw_rear_panel Rear Panel

\image html e3x0_rp_overlay.png "USRP E310 Rear Panel"

- **PWR**: Locking connector (Kycon KLDHCX-0202-A-LT) for the USRP-E Series power supply
- **1G ETH**: RJ45 port for Ethernet interfaces
- **USB**: USB 2.0 Port
- **SERIAL**: Micro USB connection for serial uart console

\subsection e31x_hw_sync Clock and Time Synchronization

Unlike most USRP devices, the E310 does not have independent reference clock and time source inputs.
It is possible, however, to discipline the internal reference clock using an external time (PPS) source
connected to the SYNC input pin. The E310 FPGA has a subsystem that can use the PPS signal from the
SYNC pin or the internal GPS to align edges of the reference clock to edges of a shared PPS signal.
This alignment happens automatically when the time source in UHD is set to "gpsdo" or "external".
Please note that because the SYNC input can only accept a PPS signal, the only supported value for
the reference clock source is "internal". Also, keep in mind that the E310
does *not* have a GPS-disciplined oscillator like other USRPs, the value "gpsdo"
for the time source was chosen for compatibility with other USRPs.

\subsection e31x_hw_pps PPS - Pulse Per Second
Using a PPS signal for timestamp synchronization requires a LVCMOS or a 5V logic input signal.
An external PPS can be used to discipline the internal reference clock. This feature is automatically
enabled with the time source is set to "external".

To test the PPS input, you can use the following tool from the UHD examples:

- `<args>` are device address arguments (optional if only one USRP device is on your machine)

    cd <install-path>/lib/uhd/examples
    ./test_pps_input --args=\<args\>

\subsection e31x_hw_gps Internal GPS

Your USRP-E Series device comes with an internal GPS.
In order to get a lock on a satellite an external GPS antenna is required.
The PPS from the internal GPS can be used to discipline the internal reference
clock. This feature is automatically enabled when the time source is set to
"gpsdo". Again, keep in mind that while the E310 does not have an actual
GPS-disciplined oscillator (GPSDO) on the board, the value "gpsdo" was named
such for better compatibility with code written for other devices.

The device provides a 3.3V supply voltage to an external antenna connected to the *GPS* port
of your device. Note that this supply voltage is turned off in order to safe power upon destruction of the software object.

\subsection e31x_hw_gpio Internal GPIO

### Connector

\image html e3x0_gpio_conn.png "E3xx GPIO Connector"

### Pin Mapping

- Pin 1:   +3.3V
- Pin 2:   Reserved
- Pin 3:   Data[5]
- Pin 4:   Reserved
- Pin 5:   Data[4]
- Pin 6:   Data[0]
- Pin 7:   Data[3]
- Pin 8:   Data[1]
- Pin 9:   0V
- Pin 10:  Data[2]

Please see the \ref page_gpio_api for information on configuring and using the GPIO bus.

\subsection e31x_hw_chipscope Debugging custom FPGA designs with Xilinx Chipscope

### Connector

\image html e3x0_jtag_conn.png "E3xx JTAG Connector"

### Pin Mapping

- Pin 1: TDO
- Pin 2: 3.3V
- Pin 3: TCK
- Pin 4: TDI
- Pin 5: 0V
- Pin 6: TMS


Xilinx chipscope allows for debugging custom FPGA designs similar to a logic analyzer.
USRP-E series devices can be used with Xilinx chipscope using the internal JTAG connector.

Further information on how to use Chipscope can be found in the *Xilinx Chipscope Pro Software and Cores User Guide (UG029)*.

\subsection e312_battery Battery notes

The USRP E312 (and with upgraded firmware E310) supports LiIon Battery packs (e.g. AA Portable Power Corp, 749801-01).

\subsubsection e312_battery_connector Connector

The connector J1 on E312's motherboard is a Molex 53014-6310. The corresponding mating connector is a Molex 51004-0300.

\image html e3xx_conn_photo.jpg "Battery pack connector"

The pins are as follows:
- Pin 1 (Red): VBat
- Pin 2 (Black): GND
- Pin 3 (White): Battery Thermistor

\subsubsection e312_battery_information Driver

The battery information is exposed on the device via the sysfs directory under:

    /sys/class/power_supply/e31x-battery/

and for the charger:

    /sys/class/power_supply/e31x-charger/

The values can be accessed via libudev or manually e.g.:

    $ root@ni-e31x-<serial>: cat /sys/class/power_supply/e31x-battery/status

The driver emits uevents on changes, that can be used to write custom UDev rules.
Using UDev rules one can configure the USRP E3xx to shut down on certain events,
such as low battery charge, high temperatures or AC power plug in.

The following example will cause the system to shut down at a reported temperature
of 73C:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SUBSYSTEM=="power_supply", ATTR{online}=="1", ATTR{temp}=="730", RUN+="/sbin/shutdown -h now"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The sysfs property "capacity" is no longer supported by the battery driver in the latest filesystem. It was removed to
comply with the Linux power supply class driver recommendations during the ongoing driver upstreaming process. The capacity
may still be calculated by the customer application using the following formula (charge_now/charge_full) * 100

For more information, please see the udev manual pages and <a href ="https://www.kernel.org/doc/Documentation/power/power_supply_class.txt"> Kernel Power Supply Docs </a>.

\subsubsection e312_battery_calibration Calibration Procedure

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

1. Completely discharge battery (e.g. by booting up without SD card, so OS doesn't auto shutdown)
2. Unplug the battery pack and external power
3. Reconnect the battery pack
4. Reconnect AC power and charge until charge completed.

A faster (less accurate) calibration procedure is as follows:

1. Completely charge battery
2. Type:

    $ echo 3200000 > /sys/class/power_supply/e31x-battery/charge_now

3. Unplug AC power
4. Replug AC power and wait until charge completes

\subsection e31x_dboards Daughterboard notes

The USRP E310 MIMO XCVR daughterboard features an integrated MIMO capable RF frontend.

\subsubsection e31x_dboard_e310_tuning Frontend tuning

The RF frontend has individually tunable receive and transmit chains.
Both transmit and receive can be used in a MIMO configuration. For
the MIMO case, both receive frontends share the RX LO, and both transmit
frontends share the TX LO. Each LO is tunable between 50 MHz and 6 GHz.

As there is a single LO for each direction (RX and TX), this means that both
channels need to use the same LO frequency (i.e., both RX channels share an LO
frequency, and both TX channels share an LO frequency). If the two channels
are supposed to receive on different frequencies, the digital tune stages need
to be used for that. The two frequencies will need to be within the currently
selected master clock rate, and the final bandwidths need to be chosen
carefully. Example: Assume the master clock rate is set to 50 MHz, and we want
to receive at 400 MHz and 440 MHz. We can set the LO to 420 MHz, which will
sample the spectrum from 395 MHz to 445 MHz. The LO offsets for both channels
need to be 20 MHz and -20 MHz respectively. However, the final bandwidth should
be less than 10 MHz (preferably lower), or the signals would exhibit aliasing.

Because both channels share an LO, tuning one channel can possibly affect the
other channel. It is advisable to read back the actual, current frequency from
software before assuming the device is tuned to a specific frequency.

\subsubsection e31x_dboard_e310_gain Frontend gain

All frontends have individual analog gain controls. The receive
frontends have 76 dB of available gain; and the transmit frontends have
89.5 dB of available gain. Gain settings are application specific, but
it is recommended that users consider using at least half of the
available gain to get reasonable dynamic range.

\subsubsection e31x_dboard_e310_pll Frontend LO lock status

The frontends provide a *lo-locked* sensor that can be queried through the UHD API.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
// assumes 'usrp' is a valid uhd::usrp::multi_usrp::sptr instance

// get status for rx frontend
usrp->get_rx_sensor("lo-locked");

// get status for tx frontend
usrp->get_tx_sensor("lo-locked");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

\subsubsection e31x_dboard_e310_band_select Frontend Filter and Antenna Switches

The transmit and receive filter banks uses switches to select between the available filters. These paths are
also dependent on the antenna switch settings. Incorrectly setting the switches generally results
in attenuated input / output power. Receive filters are band pass (series high & low pass filters),
transmit filters are low pass.

Source code related to controlling the filter band and antenna switches resides in e31x_radio_ctrl_impl.cpp. The methods set the switches depending on the state of transmit and receive streams.

The following sections provide switch setting tables for antenna and filter selection for frontends A & B receive and transmit paths.
For further details refer to the schematics.

\subsubsection e31x_dboard_e310_frontend_a_switches Frontend Side A Filter and Antenna Switches

_Note: X = don't care, T = If full duplex, set bits according to transmit table, otherwise don't care.
Filter range A – B will be selected if A <= freq < B._

__Receive__
RX Port | RX Filter (MHz) | VCTXRX2_V1,V2 | VCRX2_V1,V2 | RX2_BANDSEL[2:0] | RX2B_BANDSEL[1:0] | RX2C_BANDSEL[1:0]
:-----: | :-------------: | :-----------: | :---------: | :--------------: | :---------------: | :---------------:
TRX-A   | < 450           | 01            | 10          | 101              | XX                | 01
TRX-A   | 450 – 700       | 01            | 10          | 011              | XX                | 11
TRX-A   | 700 – 1200      | 01            | 10          | 001              | XX                | 10
TRX-A   | 1200 – 1800     | 01            | 10          | 000              | 01                | XX
TRX-A   | 1800 – 2350     | 01            | 10          | 010              | 11                | XX
TRX-A   | 2350 – 2600     | 01            | 10          | 100              | 10                | XX
TRX-A   | 2600 – 6000     | 01            | 01          | XXX              | XX                | XX
RX2-A   | 70  – 450       | TT            | 01          | 101              | XX                | 01
RX2-A   | 450 – 700       | TT            | 01          | 011              | XX                | 11
RX2-A   | 700 – 1200      | TT            | 01          | 001              | XX                | 10
RX2-A   | 1200 – 1800     | TT            | 01          | 000              | 01                | XX
RX2-A   | 1800 – 2350     | TT            | 01          | 010              | 11                | XX
RX2-A   | 2350 – 2600     | TT            | 01          | 100              | 10                | XX
RX2-A   | >= 2600         | TT            | 10          | XXX              | XX                | XX

__Transmit__
TX Port | TX Filter (MHz) | VCTXRX2_V1,V2 | TX_ENABLE2A,2B | TX_BANDSEL[2:0]
:-----: | :-------------: | :-----------: | :------------: | :-------------:
TRX-A   | < 117.7         | 10            | 01             | 111
TRX-A   | 117.7 – 178.2   | 10            | 01             | 110
TRX-A   | 178.2 – 284.3   | 10            | 01             | 101
TRX-A   | 284.3 – 453.7   | 10            | 01             | 100
TRX-A   | 453.7 – 723.8   | 10            | 01             | 011
TRX-A   | 723.8 – 1154.9  | 10            | 01             | 010
TRX-A   | 1154.9 – 1842.6 | 10            | 01             | 001
TRX-A   | 1842.6 – 2940.0 | 10            | 01             | 000
TRX-A   | >= 2940.0       | 11            | 10             | XXX
_Note: Although the transmit filters are low pass, this table describes UHD's tuning range for selecting each filter path.
The table also includes the required transmit enable state._

\subsubsection e31x_dboard_e310_frontend_b_switches Frontend Side B Filter and Antenna Switches

_Note: X = don't care, T = If full duplex, set bits according to transmit table, otherwise don't care.
Filter range A – B will be selected if A <= freq < B._

__Receive__
RX Port | RX Filter (MHz) | VCTXRX1_V1,V2 | VCRX1_V1,V2 | RX1_BANDSEL[2:0] | RX1B_BANDSEL[1:0] | RX1C_BANDSEL[1:0]
:-----: | :-------------: | :-----------: | :---------: | :--------------: | :---------------: | :---------------:
TRX-B   | < 450           | 10            | 01          | 100              | XX                | 10
TRX-B   | 450 – 700       | 10            | 01          | 010              | XX                | 11
TRX-B   | 700 – 1200      | 10            | 01          | 000              | XX                | 01
TRX-B   | 1200 – 1800     | 10            | 01          | 001              | 10                | XX
TRX-B   | 1800 – 2350     | 10            | 01          | 011              | 11                | XX
TRX-B   | 2350 – 2600     | 10            | 01          | 101              | 01                | XX
TRX-B   | 2600 – 6000     | 10            | 10          | XXX              | XX                | XX
RX2-B   | 70  – 450       | TT            | 01          | 100              | XX                | 10
RX2-B   | 450 – 700       | TT            | 01          | 010              | XX                | 11
RX2-B   | 700 – 1200      | TT            | 01          | 000              | XX                | 01
RX2-B   | 1200 – 1800     | TT            | 01          | 001              | 10                | XX
RX2-B   | 1800 – 2350     | TT            | 01          | 011              | 11                | XX
RX2-B   | 2350 – 2600     | TT            | 01          | 101              | 01                | XX
RX2-B   | >= 2600         | TT            | 10          | XXX              | XX                | XX

__Transmit__
TX Port | TX Filter (MHz) | VCTXRX1_V1,V2 | TX_ENABLE1A,1B | TX1_BANDSEL[2:0]
:-----: | :-------------: | :-----------: | :------------: | :--------------:
TRX-B   | < 117.7         | 00            | 01             | 111
TRX-B   | 117.7 – 178.2   | 00            | 01             | 110
TRX-B   | 178.2 – 284.3   | 00            | 01             | 101
TRX-B   | 284.3 – 453.7   | 00            | 01             | 100
TRX-B   | 453.7 – 723.8   | 00            | 01             | 011
TRX-B   | 723.8 – 1154.9  | 00            | 01             | 010
TRX-B   | 1154.9 – 1842.6 | 00            | 01             | 001
TRX-B   | 1842.6 – 2940.0 | 00            | 01             | 000
TRX-B   | >= 2940.0       | 11            | 10             | XXX
_Note: Although the transmit filters are low pass, the following table describes UHD's tuning range for selecting each filter path.
The table also includes the required transmit enable states._

\section e320_neon E320-specific Features

\subsection e320_panels Front and Rear Panel

Like the USRP X300 and N310 series, E320 has connectors on both the front and back
panel. The back panel holds the power connector, all network connections, USB
connections for serial console (see \ref e3xx_getting_started_serial), JTAG and
peripherals, and front-panel GPIO.

The front panel is used for all RF connections, SMA connectors for GPS antenna
input, 10 MHz external clock reference.

The connectors are labeled RF A and RF B and are powered by the two channels of
AD9361 RFIC.

\subsection e320_gpio Front Panel GPIO

### Front Panel GPIO Connections

| GPIO    | Mini HDMI (Type C)   |  HDMI (Type A)  |
|---------|----------------------|-----------------|
| Data[0] | Data 0+  - Pin 8     | Pin 7           |
| Data[1] | Data 0-  - Pin 9     | Pin 9           |
| Data[2] | Clock 0+ - Pin 11    | Pin 10          |
| Data[3] | Clock 0- - Pin 12    | Pin 12          |
| Data[4] | CEC      - Pin 14    | Pin 13          |
| Data[5] | SCL      - Pin 15    | Pin 15          |
| Data[6] | SDA      - Pin 16    | Pin 16          |
| Data[7] | Utility  - Pin 17    | Pin 14          |

\subsection e320_eeprom_flags EEPROM flags

EEPROM flags can be set with

    $ eeprom-set-flags 0xFLAGS

where FLAGS is the hex number that you can construct with the following table of bits:

| Bit | Description           |
|-----|-----------------------|
| 0   | Auto-boot (1=on)      |
| 1   | Fan  (1=present)      |
| 2   | TPM (0=present)       |
| 3   | Enclosure (1=present) |

For example, to set your device to auto-boot, with TPM, and with fans, the flag value is 0x5, so

    $ eeprom-set-flags 0x5

\section e3xx_regmap E3XX FPGA Register Map

The following tables describe how FPGA registers are mapped into the PS.
This is for reference only, most users will not even have to know about this table.


AXI Slave | Address Range         | UIO Label        | Description
----------|-----------------------|------------------|-----------------------------------
Slave 0   | 4000_0000 - 4000_3fff | -                | Ethernet DMA SFP (only for E320)
Slave 1   | 4000_4000 - 4000_4fff | misc-enet-regs   | Ethernet registers SFP (only for E320)
Slave 2   | 4001_0000 - 4001_3fff | mboard-regs      | Motherboard control
Slave 3   | 4001_4000 - 4001_41ff | dboard-regs      | Daughterboard control


<table>
<caption id="e3xx_multi_row">E3XX Register Map</caption>
<tr><th>AXI Slave              <th>Module                       <th>Address               <th>Name            <th>Read/Write  <th>Description
<tr><td rowspan="1">Slave 0    <td rowspan="1">axi_eth_dma      <td>4000_0000 - 4000_4fff <td>Ethernet DMA    <td>RW          <td>See Linux Driver (only on E320)
<tr><td rowspan="44">Slave 1   <td rowspan="7">e320_mgt_io_core <td>4000_4000             <td>PORT_INFO       <td>RO          <td>SFP port information
<tr>                                                            <td>[31:24]               <td>COMPAT_NUM      <td>RO          <td>-
<tr>                                                            <td>[23:18]               <td>6'h0	      <td>RO          <td>-
<tr>                                                            <td>[17]                  <td>activity	      <td>RO          <td>-
<tr>                                                            <td>[16]                  <td>link_up	      <td>RO          <td>-
<tr>                                                            <td>[15:8]                <td>mgt_protocol    <td>RO          <td>0 - None, 1 - 1G, 2 - XG, 3 - Aurora
<tr>                                                            <td>[7:0]                 <td>PORTNUM         <td>RO          <td>-
<tr>                           <td rowspan="8">e320_mgt_io_core <td>4000_4004             <td>MAC_CTRL_STATUS <td>RW          <td>Control 10gE and Aurora mac
<tr>                                                            <td>[0]                   <td>ctrl_tx_enable (PROTOCOL = "10GbE")<td>RW<td>-
<tr>                                                            <td>[0]                   <td>bist_checker_en (PROTOCOL = "Aurora")<td>RW<td>-
<tr>                                                            <td>[1]                   <td>bist_gen_en    <td>RW           <td>-
<tr>                                                            <td>[2]                   <td>bist_loopback_en<td>RW          <td>-
<tr>                                                            <td>[8:3]                 <td>bist_gen_rate   <td>RW          <td>-
<tr>                                                            <td>[9]                   <td>phy_areset      <td>RW          <td>-
<tr>                                                            <td>[10]                  <td>mac_clear       <td>RW          <td>-
<tr>                           <td>e320_mgt_io_core             <td>4000_4008             <td>PHY_CTRL_STATUS <td>RW          <td>Phy reset control
<tr>                           <td rowspan="3">e320_mgt_io_core <td>4000_400C             <td>MAC_LED_CTL     <td>RW          <td>Used by ethtool to indicate port
<tr>                                                            <td>[1]                   <td>identify_enable <td>RW          <td>-
<tr>                                                            <td>[0]                   <td>identify_value  <td>RW          <td>-
<tr>                           <td rowspan="4">mdio_master      <td>4000_4010             <td>MDIO_DATA       <td>RW          <td>-
<tr>                                                            <td>4000_4014             <td>MDIO_ADDR       <td>RW          <td>-
<tr>                                                            <td>4000_4018             <td>MDIO_OP         <td>RW          <td>-
<tr>                                                            <td>4000_401C             <td>MDIO_CTRL_STATUS<td>RW          <td>-
<tr>                           <td rowspan="4">e320_mgt_io_core <td>4000_4020             <td>AURORA_OVERUNS  <td>RO          <td>-
<tr>                                                            <td>4000_4024             <td>AURORA_CHECKSUM_ERRORS<td>RO    <td>-
<tr>                                                            <td>4000_4028             <td>AURORA_BIST_CHECKER_SAMPS<td>RO <td>-
<tr>                                                            <td>4000_402C             <td>AURORA_BIST_CHECKER_ERRORS<td>RO<td>-
<tr>                           <td rowspan="4">eth_switch       <td>4000_5000             <td>MAC_LSB         <td>RW          <td>Device MAC LSB
<tr>                                                            <td>4000_5004             <td>MAC_MSB         <td>RW          <td>Device MAC MSB
<tr>                                                            <td>4000_6000             <td>IP              <td>RW          <td>Device IP
<tr>                                                            <td>4000_6004             <td>PORT1, PORT0    <td>RW          <td>Device UDP port
<tr>                           <td rowspan="2">eth_dispatch     <td>4000_6008             <td>[1] ndest, [0] bcast<td>RW      <td>Enable Crossover
<tr>                                                            <td>4000_600c             <td>[1] my_icmp_type, [0] my_icmp_code<td>-
<tr>                           <td rowspan="5">eth_switch       <td>4000_6010             <td>BRIDGE_MAC_LSB  <td>            <td>Bridge SFP ports in ARM
<tr>                                                            <td>4000_6014             <td>BRIDGE_MAC_MSB  <td>            <td>-
<tr>                                                            <td>4000_6018             <td>BRIDGE_IP       <td>            <td>-
<tr>                                                            <td>4000_601c             <td>BRIDGE_PORT1, BRIDGE_PORT0<td>  <td>-
<tr>                                                            <td>4000_6020             <td>BRIDGE_EN       <td>            <td>-
<tr>                           <td rowspan="6">chdr_eth_framer  <td>4000_6108 onwards     <td>LOCAL_DST_IP    <td>W           <td>Destination IP, MAC, UDP for Outgoing Packet for 256 SIDs
<tr>                                                            <td>4000_6208 onwards     <td>LOCAL_DST_UDP_MAC_MSB<td>W      <td>Destination MAC for outgoing packets (MSB)
<tr>                                                            <td>4000_6308 onwards     <td>LOCAL_DST_MAC_LSB<td>W          <td>Destination MAC for outgoing packets (LSB)
<tr>                                                            <td>4000_7000 onwards     <td>REMOTE_DST_IP   <td>W           <td>Destination IP, MAC, UDP for Outgoing Packet for 16 local addrs
<tr>                                                            <td>4000_7400 onwards     <td>REMOTE_DST_UDP_MAC_HI<td>W      <td>Destination MAC (MSB)
<tr>                                                            <td>4000_7800 onwards     <td>REMOTE_DST_MAC_LO<td>W          <td>Destination MAC (LSB)

<tr><td rowspan="32">Slave 2   <td rowspan="27">e320_core       <td>4001_0000             <td>COMPAT_NUM      <td>R           <td>FPGA Compat Number
<tr>                                                            <td>[31:16]               <td>Major           <td>RO          <td>-
<tr>                                                            <td>[15:0]                <td>Minor           <td>RO          <td>-
<tr>                                                            <td>4001_0004             <td>DATESTAMP       <td>RO          <td>-
<tr>                                                            <td>4001_0008             <td>GIT_HASH        <td>RO          <td>-
<tr>                                                            <td>4001_000C             <td>SCRATCH         <td>RO          <td>-
<tr>                                                            <td>4001_0010             <td>NUM_CE          <td>RO          <td>Number of Computation Engines (RFNoC Blocks)
<tr>                                                            <td>4001_0014             <td>NUM_IO_CE       <td>RO          <td>Number of fixed IO CEs - Radios + DMA Fifo
<tr>                                                            <td>4001_0018             <td>CLOCK_CTRL      <td>            <td>-
<tr>                                                            <td>[0]                   <td>pps select (internal 10 MHz)<td>RW<td>One-hot encoded pps_select to use the internal PPS from GPSDO
<tr>                                                            <td>[1]                   <td>pps select (external 10 MHz)<td>RW<td>One-hot encoded pps_select to use the external PPS.
<tr>                                                            <td>[2]                   <td>refclk_select (internal/external 10 MHz)<td>RW<td>refclk_select=0 for internal (GPSDO) 10 MHz, refclk_sel=1 for external 10 MHz.
<tr>                                                            <td>4001_001C             <td>XADC_READBACK   <td>RO          <td>-
<tr>                                                            <td>[11:0]                <td>FPGA temperature<td>RO          <td>-
<tr>                                                            <td>4001_0020             <td>BUS_CLK_RATE    <td>RO          <td>-
<tr>                                                            <td>4001_0024             <td>BUS_CLK_COUNT   <td>RO          <td>-
<tr>                                                            <td>4001_0028             <td>SFP_PORT_INFO   <td>RO          <td>Same as port_info register 0x4000_4000
<tr>                                                            <td>4001_002C             <td>FP_GPIO_CTRL    <td>RW          <td>-
<tr>                                                            <td>4001_0030             <td>FP_GPIO_MASTER  <td>RW          <td>-
<tr>                                                            <td>4001_0034             <td>FP_GPIO_RADIO_SRC  <td>RW       <td>-
<tr>                                                            <td>4001_0038             <td>GPS_CTRL        <td>RW          <td>-
<tr>                                                            <td>[0]                   <td>GPS_PWR_EN      <td>RW          <td>Power on GPSDO
<tr>                                                            <td>[1]                   <td>GPS_RST_N       <td>RW          <td>-
<tr>                                                            <td>[2]                   <td>GPS_INITSURV_N  <td>RW          <td>-
<tr>                                                            <td>4001_003C             <td>GPS_STATUS      <td>RO          <td>GPSDO Status
<tr>                                                            <td>[0]                   <td>GPS_LOCK        <td>RO          <td>Returns 1 if GPSDO is locked
<tr>                                                            <td>[1]                   <td>GPS_ALARM       <td>RO          <td>-
<tr>                                                            <td>[2]                   <td>GPS_PHASELOCK   <td>RO          <td>-
<tr>                                                            <td>[3]                   <td>GPS_SURVEY      <td>RO          <td>-
<tr>                                                            <td>[4]                   <td>GPS_WARMUP      <td>RO          <td>-
<tr>                                                            <td>4001_0040             <td>DBOARD_CTRL     <td>RO          <td>-
<tr>                                                            <td>4001_0044             <td>DBOARD_STATUS   <td>RO          <td>-

<tr>                           <td rowspan="5">axi_crossbar     <td>4001_1010             <td>XBAR_VERSION    <td>RO          <td>See crossbar kernel driver
<tr>                                                            <td>4001_1014             <td>XBAR_NUM_PORTS  <td>RO          <td>See crossbar kernel driver
<tr>                                                            <td>4001_1018             <td>LOCAL_ADDR      <td>RW          <td>See crossbar kernel driver
<tr>                                                            <td>4001_1020             <td>remote_offset   <td>WO          <td>XBAR settings reg
<tr>                                                            <td>4001_1420             <td>local_offset    <td>WO          <td>XBAR settings reg

<tr><td rowspan="6">Slave 4                                     <td>4001_4000<td>4001_41FF<td>Daughterboard Registers<td>- <td>Don't exist now. TBD


*/
// vim:ft=doxygen: