docs: e31x: e320: Update docs for E310 MPM version

- Also updated device args and subdev spec

1 files changed, 1287 insertions, 0 deletions

diff --git a/host/docs/usrp_e3xx.dox b/host/docs/usrp_e3xx.dox
new file mode 100644
index 000000000..9382388a3
--- /dev/null
+++ b/host/docs/usrp_e3xx.dox
@@ -0,0 +1,1287 @@
+/*! \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_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.
+
+\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: