Merge branch 'master' into mwest/b200_docs

34 files changed, 1858 insertions, 358 deletions

diff --git a/host/docs/CMakeLists.txt b/host/docs/CMakeLists.txt
index fa6e98918..1ee0f1ade 100644
--- a/host/docs/CMakeLists.txt
+++ b/host/docs/CMakeLists.txt
@@ -25,8 +25,10 @@ SET(manual_sources
     calibration.rst
     coding.rst
     dboards.rst
+    gpio_api.rst
     gpsdo.rst
     gpsdo_b2x0.rst
+    gpsdo_x3x0.rst
     general.rst
     images.rst
     stream.rst
@@ -37,6 +39,8 @@ SET(manual_sources
     usrp_b100.rst
     usrp_b200.rst
     usrp_e1x0.rst
+    usrp_x3x0.rst
+    usrp_x3x0_config.rst
 )
 
 ########################################################################
@@ -81,6 +85,14 @@ IF(ENABLE_MANUAL)
     #make the html manual a build-time dependency
     ADD_CUSTOM_TARGET(manual_html ALL DEPENDS ${manual_html_files})
     UHD_INSTALL(FILES ${manual_sources} DESTINATION ${PKG_DOC_DIR}/manual/rst COMPONENT manual)
+
+    #resources for html manual 
+    ADD_CUSTOM_COMMAND(
+        TARGET manual_html POST_BUILD
+        COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/res ${CMAKE_CURRENT_BINARY_DIR}/res
+    )
+    UHD_INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/res DESTINATION ${PKG_DOC_DIR}/manual/html COMPONENT manual)
+
 ENDIF(ENABLE_MANUAL)
 
 ########################################################################
@@ -128,6 +140,7 @@ SET(man_page_sources
     uhd_images_downloader.1
     uhd_usrp_probe.1
     usrp_n2xx_simple_net_burner.1
+    usrp_x3xx_fpga_burner.1
     usrp2_card_burner.1
 )
 
@@ -137,7 +150,12 @@ SET(man_page_sources
 MESSAGE(STATUS "")
 FIND_PACKAGE(GZip)
 
-LIBUHD_REGISTER_COMPONENT("Man Pages" ENABLE_MAN_PAGES ON "GZIP_FOUND;LINUX" OFF)
+# No elegant way in CMake to reverse a boolean
+IF(NOT WIN32)
+    SET(NOT_WIN32 TRUE)
+ENDIF(NOT WIN32)
+
+LIBUHD_REGISTER_COMPONENT("Man Pages" ENABLE_MAN_PAGES ON "GZIP_FOUND;NOT_WIN32" OFF)
 
 IF(ENABLE_MAN_PAGES)
     #Generate man pages
diff --git a/host/docs/build.rst b/host/docs/build.rst
index 5512e71ae..f53a56d9b 100644
--- a/host/docs/build.rst
+++ b/host/docs/build.rst
@@ -14,9 +14,11 @@ the dependencies should be available in the package repositories for your
 package manager.
 
 **Mac OS X Notes:**
-Install the "Xcode Developer Tools" to get the build tools (GCC and Make).
+Install the Xcode app to get the build tools (GCC and Make).
 Use MacPorts to get the Boost and Cheetah dependencies.
-Other dependencies can be downloaded as DMG installers from the web.
+Other dependencies can be downloaded as DMG installers from the web
+or installed via MacPorts. 
+See the UHD OS X page for more information: http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_OS_X 
 
 **Windows Notes:**
 The dependencies can be acquired through installable EXE files.
@@ -148,11 +150,6 @@ or add it to **/etc/ld.so.conf** and make sure to run:
 
     sudo ldconfig
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Setup the library path (Mac OS X)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Make sure that **libuhd.dylib** is in your **DYLD_LIBRARY_PATH**.
-
 ------------------------------------------------------------------------
 Build Instructions (Windows)
 ------------------------------------------------------------------------
@@ -220,3 +217,12 @@ Post-Install Tasks
 For USB-based devices,
 see the `USB Transport Application Notes <./transport.html#usb-transport-libusb>`_
 for platform-specific post-installation tasks.
+
+------------------------------------------------------------------------
+Post-Install Tasks (Mac OS X)
+------------------------------------------------------------------------
+Make sure that the value of **CMAKE_INSTALL_PREFIX** is at or near the 
+front of the shell **PATH** environment variable.  Do **NOT** set 
+DYLD_LIBRARY_PATH or any related DYLD environment variable 
+permanently; these work differently than under Linux and should be 
+used for testing / temporary purposes only. 
diff --git a/host/docs/calibration.rst b/host/docs/calibration.rst
index 8ba3477b8..23bef01b7 100644
--- a/host/docs/calibration.rst
+++ b/host/docs/calibration.rst
@@ -5,14 +5,15 @@ UHD - Calibration Application Notes
 .. contents:: Table of Contents
 
 ------------------------------------------------------------------------
-Self-calibration
+Self-Calibration
 ------------------------------------------------------------------------
-UHD software comes with several self-calibration utilities for minimizing IQ imbalance and DC offset.
-These utilities perform calibration sweeps using transmit leakage into the receive path
-(special equipment is not required).
-The results from a calibration are written to a CSV file in the user's home directory.
-UHD software will automatically apply corrections at runtime when the user re-tunes the daughterboard LO.
-Calibration results are specific to an individual RF board.
+UHD software comes with several self-calibration utilities for minimizing IQ
+imbalance and DC offset.  These utilities perform calibration sweeps using
+transmit leakage into the receive path (special equipment is not required).
+The results from a calibration are written to a CSV file in the user's home
+directory.  UHD software will automatically apply corrections at runtime when
+the user re-tunes the daughterboard LO.  Calibration results are specific to an
+individual RF board.
 
 **Note:**
 When a calibration table is present,
@@ -27,10 +28,10 @@ UHD software comes with the following calibration utilities:
 
 The following RF frontends are supported by the self-calibration utilities:
 
- * RFX transceiver board
- * WBX transceiver board
- * SBX transceiver board
- * CBX transceiver board
+ * RFX Series transceiver boards
+ * WBX Series transceiver boards
+ * SBX Series transceiver boards
+ * CBX Series transceiver boards
 
 ********************************************
 Calibration Utilities
@@ -54,7 +55,7 @@ may not have a serial number. If this is the case, run the following command to
 into the daughterboard's EEPROM:
 ::
 
-    <install dir>/share/uhd/utils/usrp_burn_db_eeprom --ser=<desired serial> --args=<optional device args>
+    <install dir>/lib/uhd/utils/usrp_burn_db_eeprom --ser=<desired serial> --args=<optional device args>
 
 ********************************************
 Calibration Data
diff --git a/host/docs/dboards.rst b/host/docs/dboards.rst
index 4b5a074a8..d6cbc6151 100644
--- a/host/docs/dboards.rst
+++ b/host/docs/dboards.rst
@@ -26,15 +26,15 @@ The boards have no tunable elements or programmable gains.
 Through the magic of aliasing, you can down-convert signals
 greater than the Nyquist rate of the ADC.
 
-BasicRX Bandwidth (Hz): 
+BasicRX Bandwidth:
 
-* **For Real-Mode (A or B frontend)**: 250M
-* **For Complex (AB or BA frontend)**: 500M
+* **For Real-Mode (A or B frontend)**: 250 MHz
+* **For Complex (AB or BA frontend)**: 500 MHz
 
-LFRX Bandwidth (Hz):
+LFRX Bandwidth:
 
-* **For Real-Mode (A or B frontend)**: 33M
-* **For Complex (AB or BA frontend)**: 66M
+* **For Real-Mode (A or B frontend)**: 33 MHz
+* **For Complex (AB or BA frontend)**: 66 MHz
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Basic TX and LFTX
@@ -50,15 +50,15 @@ The boards have no tunable elements or programmable gains.
 Through the magic of aliasing, you can up-convert signals
 greater than the Nyquist rate of the DAC.
 
-BasicTX Bandwidth (Hz): 250M
+BasicTX Bandwidth (Hz):
 
-* **For Real-Mode (A or B frontend**): 250M
-* **For Complex (AB or BA frontend)**: 500M
+* **For Real-Mode (A or B frontend**): 250 MHz
+* **For Complex (AB or BA frontend)**: 500 MHz
 
-LFTX Bandwidth (Hz): 33M
+LFTX Bandwidth (Hz):
 
-* **For Real-Mode (A or B frontend)**: 33M
-* **For Complex (AB or BA frontend)**: 66M
+* **For Real-Mode (A or B frontend)**: 33 MHz
+* **For Complex (AB or BA frontend)**: 66 MHz
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 DBSRX
@@ -77,7 +77,7 @@ Receive Gains:
 * **GC1**, Range: 0-56dB
 * **GC2**, Range: 0-24dB
 
-Bandwidth (Hz): 8M-66M
+Bandwidth: 8 MHz - 66 MHz
 
 Sensors:
 
@@ -100,7 +100,7 @@ Receive Gains:
 * **GC1**, Range: 0-73dB
 * **BBG**, Range: 0-15dB
 
-Bandwidth (Hz): 8M-80M
+Bandwidth (Hz): 8 MHz -80 MHz
 
 Sensors:
 
@@ -128,10 +128,10 @@ the receive antenna will always be set to RX2, regardless of the settings.
 
 Receive Gains: **PGA0**, Range: 0-70dB (except RFX400 range is 0-45dB)
 
-Bandwidths (Hz):
+Bandwidth:
 
-* **RX**: 40M
-* **TX**: 40M
+* **RX**: 40 MHz
+* **TX**: 40 MHz
 
 Sensors:
 
@@ -142,10 +142,10 @@ XCVR 2450
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The XCVR2450 has 2 quadrature frontends, one transmit, one receive.
 Transmit and Receive default to direct conversion but
-can be used in low IF mode through lo_offset in uhd::tune_request_t
+can be used in low IF mode through lo_offset in uhd::tune_request_t.
 
 The XCVR2450 has a non-contiguous tuning range consisting of a 
-high band (4.9-6.0GHz) and a low band (2.4-2.5GHz).
+high band (4.9-6.0 GHz) and a low band (2.4-2.5 GHz).
 
 Transmit Antennas: **J1** or **J2**
 
@@ -170,10 +170,10 @@ Receive Gains:
 * **LNA**, Range: 0-30.5dB
 * **VGA**, Range: 0-62dB
 
-Bandwidths (Hz):
+Bandwidths:
 
-* **RX**: 15M, 19M, 28M, 36M; (each +-0, 5, or 10%)
-* **TX**: 24M, 36M, 48M
+* **RX**: 15 MHz, 19 MHz, 28 MHz, 36 MHz; (each +-0, 5, or 10%)
+* **TX**: 24 MHz, 36 MHz, 48 MHz
 
 Sensors:
 
@@ -183,12 +183,18 @@ Sensors:
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 WBX Series
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The WBX Series boards have 2 quadrature frontends, one transmit, one receive.
-Transmit and Receive default to direct conversion but
-can be used in low IF mode through lo_offset in **uhd::tune_request_t**.
 
-The WBX Series boards have independent receive and transmit LO's and synthesizers 
-allowing full-duplex operation on different transmit and receive frequencies.
+Features:
+
+* 2 quadrature frontends (1 transmit, 1 receive)
+
+  * Defaults to direct conversion
+  * Can be used in low IF mode through lo_offset with **uhd::tune_request_t**
+
+* Independent recieve and transmit LO's and synthesizers
+
+  * Allows for full-duplex operation on different transmit and receive frequencies
+  * Can be set to use Integer-N tuning for better spur performance with **uhd::tune_request_t**
 
 Transmit Antennas: **TX/RX**
 
@@ -196,18 +202,16 @@ Receive Antennas: **TX/RX** or **RX2**
 
 * **Frontend 0:** Complex baseband signal for selected antenna
 
-The user may set the receive antenna to be TX/RX or RX2.
-However, when using an WBX board in full-duplex mode,
-the receive antenna will always be set to RX2, regardless of the settings.
+* **Note:** The user may set the receive antenna to be TX/RX or RX2. However, when using a WBX board in full-duplex mode, the receive antenna will always be set to RX2, regardless of the settings.
 
 Transmit Gains: **PGA0**, Range: 0-25dB
 
 Receive Gains: **PGA0**, Range: 0-31.5dB
 
-Bandwidths (Hz):
+Bandwidths:
 
-* **RX**: 40M
-* **TX**: 40M
+* **WBX**: 40 MHz, RX & TX
+* **WBX-120**: 120 MHz, RX & TX
 
 Sensors:
 
@@ -216,12 +220,18 @@ Sensors:
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 SBX Series
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The SBX Series boards have 2 quadrature frontends, one transmit, one receive.
-Transmit and Receive default to direct conversion but
-can be used in low IF mode through lo_offset in **uhd::tune_request_t**.
 
-The SBX Series boards have independent receive and transmit LO's and synthesizers 
-allowing full-duplex operation on different transmit and receive frequencies.
+Features:
+
+* 2 quadrature frontends (1 transmit, 1 receive)
+
+  * Defaults to direct conversion
+  * Can be used in low IF mode through lo_offset with **uhd::tune_request_t**
+
+* Independent recieve and transmit LO's and synthesizers
+
+  * Allows for full-duplex operation on different transmit and receive frequencies
+  * Can be set to use Integer-N tuning for better spur performance with **uhd::tune_request_t**
 
 Transmit Antennas: **TX/RX**
 
@@ -229,18 +239,16 @@ Receive Antennas: **TX/RX** or **RX2**
 
 * **Frontend 0:** Complex baseband signal for selected antenna
 
-The user may set the receive antenna to be TX/RX or RX2.
-However, when using an SBX board in full-duplex mode,
-the receive antenna will always be set to RX2, regardless of the settings.
+* **Note:** The user may set the receive antenna to be TX/RX or RX2. However, when using an SBX board in full-duplex mode, the receive antenna will always be set to RX2, regardless of the settings.
 
 Transmit Gains: **PGA0**, Range: 0-31.5dB
 
 Receive Gains: **PGA0**, Range: 0-31.5dB
 
-Bandwidths (Hz):
+Bandwidths:
 
-* **RX**: 40M
-* **TX**: 40M
+* **SBX**: 40 MHz, RX & TX
+* **SBX-120**: 120 MHz, RX & TX
 
 Sensors:
 
@@ -248,16 +256,56 @@ Sensors:
 
 LEDs:
 
-* All LEDs flash when dboard control is initialized
+* All LEDs flash when daughterboard control is initialized
 * **TX LD**: Transmit Synthesizer Lock Detect
 * **TX/RX**: Receiver on TX/RX antenna port (No TX)
 * **RX LD**: Receive Synthesizer Lock Detect
 * **RX1/RX2**: Receiver on RX2 antenna port
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
-CBX
+CBX Series
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
-See SBX Series for more details.
+
+Features:
+
+* 2 quadrature frontends (1 transmit, 1 receive)
+
+  * Defaults to direct conversion
+  * Can be used in low IF mode through lo_offset with **uhd::tune_request_t**
+
+* Independent recieve and transmit LO's and synthesizers
+
+  * Allows for full-duplex operation on different transmit and receive frequencies
+  * Can be set to use Integer-N tuning for better spur performance with **uhd::tune_request_t**
+
+Transmit Antennas: **TX/RX**
+
+Receive Antennas: **TX/RX** or **RX2**
+
+* **Frontend 0:** Complex baseband signal for selected antenna
+
+* **Note:** The user may set the receive antenna to be TX/RX or RX2. However, when using a CBX board in full-duplex mode, the receive antenna will always be set to RX2, regardless of the settings.
+
+Transmit Gains: **PGA0**, Range: 0-31.5dB
+
+Receive Gains: **PGA0**, Range: 0-31.5dB
+
+Bandwidths:
+
+* **CBX**: 40 MHz, RX & TX
+* **CBX-120**: 120 MHz, RX & TX
+
+Sensors:
+
+* **lo_locked**: boolean for LO lock state
+
+LEDs:
+
+* All LEDs flash when daughterboard control is initialized
+* **TX LD**: Transmit Synthesizer Lock Detect
+* **TX/RX**: Receiver on TX/RX antenna port (No TX)
+* **RX LD**: Receive Synthesizer Lock Detect
+* **RX1/RX2**: Receiver on RX2 antenna port
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 TVRX
@@ -274,7 +322,7 @@ Receive Gains:
 * **RF**, Range: -13.3-50.3dB (frequency-dependent)
 * **IF**, Range: -1.5-32.5dB
 
-Bandwidth: 6MHz
+Bandwidth: 6 MHz
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 TVRX2
@@ -294,7 +342,7 @@ Receive Gains:
 
 * **IF**, Range: 0.0-30.0dB
 
-Bandwidth: 1.7MHz, 6MHz, 7MHz, 8MHz, 10MHz
+Bandwidth: 1.7 MHz, 6 MHz, 7 MHz, 8 MHz, 10 MHz
 
 Sensors:
 
@@ -302,15 +350,6 @@ Sensors:
 * **rssi**: float for measured RSSI in dBm
 * **temperature**: float for measured temperature in degC
 
-------------------------------------------------------------------------
-Daughterboard Modifications
-------------------------------------------------------------------------
-
-Sometimes, daughterboards will require modification
-to work on certain frequencies or to work with certain hardware.
-Modification usually involves moving/removing an SMT component
-and burning a new daughterboard ID into the EEPROM.
-
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 DBSRX - Mod
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -324,20 +363,20 @@ over the standard daughterboard clock lines.
 
 **Step 1: Move the clock configuration resistor**
 
-Remove **R193** (which is 10 ohms, 0603 size), and put it on **R194**, which is empty.
+Remove **R193** (which is 10 Ohms, 0603 size), and put it on **R194**, which is empty.
 This is made somewhat more complicated by the fact that the silkscreen is not clear in that area.
 **R193** is on the back, immediately below the large beige connector, **J2**.
 **R194** is just below, and to the left of **R193**.
 The silkscreen for **R193** is ok, but for **R194**,
 it is upside down, and partially cut off.
-If you lose **R193**, you can use anything from 0 to 10 ohms there.
+If you lose **R193**, you can use anything from 0 to 10 Ohms there.
 
 **Step 2: Burn a new daughterboard id into the EEPROM**
 
 With the daughterboard plugged-in, run the following commands:
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     ./usrp_burn_db_eeprom --id=0x000d --unit=RX --args=<args> --slot=<slot>
 
 * **<args>** are device address arguments (optional if only one USRP device is on your machine)
@@ -357,14 +396,14 @@ Move **R64** to **R84**. Move **R142** to **R153**.
 **Step 2: Connect the motherboard blocks**
 
 Move **R35** to **R36**. Move **R117** to **R115**.
-These are all 0-ohm, so if you lose one, just short across the appropriate pads.
+These are all 0-Ohm, so if you lose one, just short across the appropriate pads.
 
 **Step 3: Burn the appropriate daughterboard ID into the EEPROM**
 
 With the daughterboard plugged-in, run the following commands:
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     ./usrp_burn_db_eeprom --id=<rx_id> --unit=RX --args=<args> --slot=<slot>
     ./usrp_burn_db_eeprom --id=<tx_id> --unit=TX --args=<args> --slot=<slot>
 
diff --git a/host/docs/general.rst b/host/docs/general.rst
index b116ba816..930c18188 100644
--- a/host/docs/general.rst
+++ b/host/docs/general.rst
@@ -1,16 +1,16 @@
-========================================================================
+===============================
 UHD - General Application Notes
-========================================================================
+===============================
 
 .. contents:: Table of Contents
 
-------------------------------------------------------------------------
+------------
 Tuning Notes
-------------------------------------------------------------------------
+------------
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^
 Two-stage tuning process
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^
 A USRP device has two stages of tuning:
 
 * RF front-end: translates bewteen RF and IF
@@ -28,8 +28,19 @@ easy to move the DC component out of your band-of-interest.  This can be done by
 passing your desired LO offset to the **tune_request_t** object, and letting the UHD
 software handle the rest.
 
+The **tune_request_t** object can also be used with certain daughterboards to use
+Integer-N tuning instead of the default fractional tuning, allowing for better spur
+performance. The daughterboards that support this functionality are:
+
+* WBX (all revisions)
+* WBX-120
+* SBX (all revisions)
+* SBX-120
+* CBX
+* CBX-120
+
 Tuning the receive chain:
-::
+:::::::::::::::::::::::::
 
     //tuning to a desired center frequency
     usrp->set_rx_freq(target_frequency_in_hz);
@@ -38,14 +49,15 @@ Tuning the receive chain:
 
     //advanced tuning with tune_request_t
     uhd::tune_request_t tune_req(target_frequency_in_hz, desired_lo_offset);
+    tune_req.args = uhd::device_addr_t("mode_n=integer"); //to use Int-N tuning
     //fill in any additional/optional tune request fields...
     usrp->set_rx_freq(tune_req);
 
-More information can be fonud in *tune_request.hpp*.
+More information can be found in `tune_request.hpp <./../../doxygen/html/structuhd_1_1tune__request__t.html>`_.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 RF front-end settling time
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 After tuning, the RF front-end will need time to settle into a usable state.
 Typically, this means that the local oscillators must be given time to lock
 before streaming begins.  Lock time is not consistent; it varies depending upon
@@ -54,6 +66,8 @@ should wait for the **lo_locked** sensor to become true or sleep for
 a conservative amount of time (perhaps a second).
 
 Pseudo-code for dealing with settling time after tuning on receive:
+:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
+
 ::
 
     usrp->set_rx_freq(...);
@@ -68,9 +82,10 @@ Pseudo-code for dealing with settling time after tuning on receive:
     }
     usrp->issue_stream_command(...);
 
-------------------------------------------------------------------------
+
+-------------------------------
 Specifying the Subdevice to Use
-------------------------------------------------------------------------
+-------------------------------
 A subdevice specification string for USRP family devices is composed of:
 
 ::
@@ -97,16 +112,16 @@ Ex: The subdev spec markup string to select a BasicRX on slot B.
 
     B:B
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 USRP Family Motherboard Slot Names
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 All USRP family motherboards have a first slot named **A:**.  The USRP1 has
 two daughterboard subdevice slots, known as **A:** and **B:**.  
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Daughterboard Frontend Names
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Daughterboard frontend names can be used to specify which signal path is used
 from a daughterboard.  Most daughterboards have only one frontend **:0**.  A few
@@ -114,15 +129,15 @@ daughterboards (Basic, LF and TVRX2) have multiple frontend names available.
 The frontend names are documented in the 
 `Daughterboard Application Notes <./dboards.html>`_
 
-------------------------------------------------------------------------
+------------------------
 Overflow/Underflow Notes
-------------------------------------------------------------------------
+------------------------
 **Note:** The following overflow/underflow notes do not apply to USRP1,
 which does not support the advanced features available in newer products.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^
 Overflow notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^
 When receiving, the device produces samples at a constant rate.
 Overflows occurs when the host does not consume data fast enough.
 When UHD software detects the overflow, it prints an "O" or "D" to stdout,
@@ -142,23 +157,24 @@ When the device's internal buffers become full, streaming is shut off,
 and an inline message packet is sent to the host.
 In this case the character "O" is printed to stdout as an indication.
 If the device was in continuous streaming mode,
-the UHD software will automatically restart streaming.
+the UHD software will automatically restart streaming when the buffer has
+space again.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
 Underflow notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^
 When transmitting, the device consumes samples at a constant rate.
 Underflow occurs when the host does not produce data fast enough.
 When UHD software detects the underflow, it prints a "U" to stdout,
 and pushes a message packet into the async message stream.
 
-------------------------------------------------------------------------
+---------------
 Threading Notes
-------------------------------------------------------------------------
+---------------
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^
 Thread safety notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^
 For the most part, UHD software is thread-safe.
 Please observe the following limitations:
 
@@ -175,9 +191,9 @@ This is because changing one setting could have an impact on how a call affects
 Example: setting the channel mapping affects how the antennas are set.
 It is recommended to use at most one thread context for manipulating device settings.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 Thread priority scheduling
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 When UHD software spawns a new thread it may try to boost the thread's scheduling priority.
 When setting the priority fails, the UHD software prints out an error.
@@ -187,29 +203,29 @@ This error is harmless; it simply means that the thread will have a normal sched
 
 Non-privileged users need special permission to change the scheduling priority.
 Add the following line to **/etc/security/limits.conf**:
-::
+::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 
     @<my_group>    -    rtprio    99
 
 Replace **<my_group>** with a group to which your user belongs.
 Settings will not take effect until the user is in a different login session.
 
-------------------------------------------------------------------------
+-------------------
 Miscellaneous Notes
-------------------------------------------------------------------------
+-------------------
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Support for dynamically loadable modules
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 For a module to be loaded at runtime, it must be:
 
 * found in the **UHD_MODULE_PATH** environment variable,
 * installed into the **<install-path>/share/uhd/modules** directory,
 * or installed into **/usr/share/uhd/modules** directory (UNIX only).
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Disabling or redirecting prints to stdout
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The user can disable the UHD library from printing directly to stdout by registering a custom message handler.
 The handler will intercept all messages, which can be dropped or redirected.
 Only one handler can be registered at a time.
diff --git a/host/docs/gpio_api.rst b/host/docs/gpio_api.rst
new file mode 100644
index 000000000..9fd86d081
--- /dev/null
+++ b/host/docs/gpio_api.rst
@@ -0,0 +1,129 @@
+========================================================================
+UHD - X3x0 GPIO API
+========================================================================
+
+.. contents:: Table of Contents
+
+------------------------------------------------------------------------
+The X3x0 Front Panel GPIO
+------------------------------------------------------------------------
+The X3x0 is the first USRP device to offer an auxiliary GPIO connection on the
+motherboard itself (independent of the daughterboards). These GPIO pins are
+controlled directly by the FPGA, where they are controlled by an ATR (Automatic
+Transmit / Receive). This allows them to be toggled simultaneously with other
+radio-level changes (e.g., enabling or disabling a TX or RX mixer).
+
+
+^^^^^^^^^^^^^^^^
+Front Panel GPIO
+^^^^^^^^^^^^^^^^
+
+Connector
+:::::::::
+
+.. image:: ./res/x3x0_gpio_conn.png
+   :scale: 75%
+   :align: left
+
+Pin Mapping
+:::::::::::
+
+* Pin 1:  +3.3V
+* Pin 2:  Data[0]
+* Pin 3:  Data[1]
+* Pin 4:  Data[2]
+* Pin 5:  Data[3]
+* Pin 6:  Data[4]
+* Pin 7:  Data[5]
+* Pin 8:  Data[6]
+* Pin 9:  Data[7]
+* Pin 10: Data[8]
+* Pin 11: Data[9]
+* Pin 12: Data[10]
+* Pin 13: Data[11]
+* Pin 14: 0V
+* Pin 15: 0V
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Explaining ATR
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ATR works by defining the value of the GPIO pins for certain states of the
+radio. This is the "automatic" part of it. For example, you can tell UHD that
+when the radio is transmitting and receiving (full duplex), GPIO6 should be
+high, but when it is only transmitting, GPI06 should be low. This state machine
+is set up using a series of GPIO attributes, with paired values and a mask,
+which you will want to define for the GPIO pins you intend to use. To set up
+the ATR, you use the **multi_usrp** function *set_gpio_attr*. 
+
+* **CTRL**: Is this pin controlled by ATR (automatic), or by manual control
+  only?
+* **DDR**: "Data Direction Register" - defines whether or not a GPIO is an
+  output or an input.
+* **OUT**: Manually set the value of a pin (only to be used in non-ATR mode).
+* **ATR_0X**: The status of the pins when the radio is **idle**.
+* **ATR_RX**: The status of the pins when the radio is only **receiving**.
+* **ATR_TX**: The status of the pins when the radio is only **transmitting**.
+* **ATR_XX**: The status of the pins when the radio is in **full-duplex** mode.
+
+The counterpart to setting the ATR (the "getter"), is called *get_gpio_attr*.
+It has the exact same attributes as above, and has one more:
+
+* **READBACK**: Readback the GPIOs marked as inputs.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+An Example
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The front panel X3x0 GPIO bank is enumerated in the motherboard property tree
+("*<mb_path>/gpio/FP0/*"), and so is easily accessible through the standard
+**multi_usrp** UHD interface.
+
+You can discover this using the *get_gpio_banks* function in **multi_usrp**.
+This will tell you that there is a GPIO bank on your X3x0 called "FP0". This is
+the bank we want to set-up.
+
+Let's say we want to use GPIO6 for an external amp. We want it to be
+automatically controlled by ATR as an output, and we want it to be high when we
+are transmitting, and low in all other cases. We are also using GPIO4, which
+we want to control manually, as an output. We can set this up with the following
+code:
+
+::
+
+    // set up our masks, defining the pin numbers
+    #define AMP_GPIO_MASK   (1 << 6)
+    #define MAN_GPIO_MASK   (1 << 4)
+
+    #define ATR_MASKS       (AMP_GPIO_MASK | MAN_GPIO_MASK)
+
+    // set up our values for ATR control: 1 for ATR, 0 for manual
+    #define ATR_CONTROL     (AMP_GPIO_MASK & ~MAN_GPIO_MASK)
+
+    // set up the GPIO directions: 1 for output, 0 for input
+    #define GPIO_DDR        (AMP_GPIO_MASK & ~MAN_GPIO_MASK)
+
+    // assume an existing USRP device handle, called "usrp_x300"
+
+    // now, let's do the basic ATR setup
+    usrp_x300->set_gpio_attr("FP0", "CTRL", ATR_CONTROL, ATR_MASKS);
+    usrp_x300->set_gpio_attr("FP0", "DDR", GPIO_DDR, ATR_MASKS);
+
+    // let's manually set GPIO4 high
+    usrp_x300->set_gpio_attr("FP0", "OUT", 1, MAN_GPIO_MASK);
+
+    // finally, let's set up GPIO6 as we described above
+    usrp_x300->set_gpio_attr("FP0", "ATR_0X", 0, AMP_GPIO_MASK);
+    usrp_x300->set_gpio_attr("FP0", "ATR_RX", 0, AMP_GPIO_MASK);
+    usrp_x300->set_gpio_attr("FP0", "ATR_TX", 0, AMP_GPIO_MASK);
+    usrp_x300->set_gpio_attr("FP0", "ATR_XX", 0, AMP_GPIO_MASK);
+
+After the above code is run, the ATR in the FPGA will automatically control
+GPIO6, as we have described, based on the radio state, and we have direct
+manual control over GPIO4.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Further Information
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+For more information, see the Doxygen API documentation:
+
+* `multi_usrp API <./../../doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html>`_
diff --git a/host/docs/gpsdo.rst b/host/docs/gpsdo.rst
index 3b718fc20..8ffff8672 100644
--- a/host/docs/gpsdo.rst
+++ b/host/docs/gpsdo.rst
@@ -4,8 +4,13 @@ UHD - Internal GPSDO Application Notes (USRP-N2x0/E1X0 Models)
 
 .. contents:: Table of Contents
 
-This application note describes the use of integrated GPS-disciplined
-oscillators with Ettus Research USRP devices.
+This application note describes the use of integrated GPS-disciplined oscillators (GPSDOs) for
+the USRP N-Series and E1xx. For information regarding the GPSDO that is compatible with
+the USRP X-Series, please see:
+
+`USRP-X3x0 Internal GPSDO Device Manual <./gpsdo_x3x0.html>`_
+
+=======
 
 ------------------------------------------------------------------------
 Specifications
@@ -16,11 +21,11 @@ Specifications
 * **Holdover**: <11us over 3h
 * **Phase noise**:
 
-  * **1Hz:** -80dBc/Hz
-  * **10Hz:** -110dBc/Hz
-  * **100Hz:** -135dBc/Hz
-  * **1kHz:** -145dBc/Hz
-  * **10kHz:** <-145dBc/Hz
+  * **1Hz:** -80 dBc/Hz
+  * **10Hz:** -110 dBc/Hz
+  * **100Hz:** -135 dBc/Hz
+  * **1kHz:** -145 dBc/Hz
+  * **10kHz:** <-145 dBc/Hz
 
 **Antenna Types:**
 
@@ -29,7 +34,7 @@ The GPSDO is capable of supplying a 3V for active GPS antennas or supporting pas
 ------------------------------------------------------------------------
 Installation Instructions
 ------------------------------------------------------------------------
-Installation instructions can be found here:
+Instructions for mounting the GPSDO kit onto your USRP device can be found here:
 `http://www.ettus.com/content/files/gpsdo-kit_2.pdf <http://www.ettus.com/content/files/gpsdo-kit_2.pdf>`_
 
 ********************************************
@@ -40,7 +45,7 @@ Post-installation Task (N-Series only)
 
 This is necessary if you require absolute GPS time in your application
 or need to communicate with the GPSDO to obtain location, satellite info, etc.
-If you only require 10MHz and PPS signals for reference or MIMO use
+If you only require 10 MHz and PPS signals for reference or MIMO use
 (see the `Synchronization Application Notes <./sync.html>`_),
 it is not necessary to perform this step.
 
@@ -49,7 +54,7 @@ To configure the USRP to communicate with the GPSDO, use the
 
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     ./usrp_burn_mb_eeprom --args=<optional device args> --key=gpsdo --val=internal
 
     -- restore original setting --
@@ -61,7 +66,7 @@ Using the GPSDO in Your Application
 By default, if a GPSDO is detected at startup, the USRP will be configured
 to use it as a frequency and time reference. The internal VITA timestamp
 will be initialized to the GPS time, and the internal oscillator will be
-phase-locked to the 10MHz GPSDO reference. If the GPSDO is not locked to
+phase-locked to the 10 MHz GPSDO reference. If the GPSDO is not locked to
 satellites, the VITA time will not be initialized.
 
 GPS data is obtained through the **mboard_sensors** interface. To retrieve
diff --git a/host/docs/gpsdo_b2x0.rst b/host/docs/gpsdo_b2x0.rst
index 8bc363e97..a0815d23a 100644
--- a/host/docs/gpsdo_b2x0.rst
+++ b/host/docs/gpsdo_b2x0.rst
@@ -1,5 +1,5 @@
 ========================================================================
-UHD - Internal GPSDO Application Notes (USRP-B2X0 Models)
+UHD - Internal GPSDO Application Notes (USRP-B2x0 Models)
 ========================================================================
 
 .. contents:: Table of Contents
@@ -17,21 +17,21 @@ Specifications
 
 **Phase noise**:
 
-+------------+-------------+------------+
-|            |     TCXO    |    OXCO    |
-+============+=============+============+
-| **1Hz**    | -65dBc/Hz   | -75dBc/Hz  |
-+------------+-------------+------------+
-| **10Hz**   |  -102dBc/Hz | -110dBc/Hz |
-+------------+-------------+------------+
-| **100Hz**  | -132dBc/Hz  | -132dBc/Hz |
-+------------+-------------+------------+
-| **1kHz**   | -148dBc/Hz  | -142dBc/Hz |
-+------------+-------------+------------+
-| **10kHz**  | -152dBc/Hz  | -145dBc/Hz |
-+------------+-------------+------------+
-| **100kHz** | <-155dBc/Hz | -150dBc/Hz |
-+------------+-------------+------------+
++------------+-------------+
+|            |     TCXO    |
++============+=============+
+| **1Hz**    | -65dBc/Hz   |
++------------+-------------+
+| **10Hz**   |  -102dBc/Hz |
++------------+-------------+
+| **100Hz**  | -132dBc/Hz  |
++------------+-------------+
+| **1kHz**   | -148dBc/Hz  |
++------------+-------------+
+| **10kHz**  | -152dBc/Hz  |
++------------+-------------+
+| **100kHz** | <-155dBc/Hz |
++------------+-------------+
 
 **Antenna Types:**
 
diff --git a/host/docs/gpsdo_x3x0.rst b/host/docs/gpsdo_x3x0.rst
new file mode 100644
index 000000000..0d4d31f3b
--- /dev/null
+++ b/host/docs/gpsdo_x3x0.rst
@@ -0,0 +1,82 @@
+========================================================================
+UHD - Internal GPSDO Application Notes (USRP-X3x0 Models)
+========================================================================
+
+.. contents:: Table of Contents
+
+This application note describes the use of the board-mounted GPS Disciplined OCXO, 
+as used with the USRP X300/X310.  For information regarding the GPSDO that is 
+compatible with the USRP N2xx or E1xx, please see:
+
+`USRP-N2x0/E1x0 Internal GPSDO Device Manual <./gpsdo.html>`_
+
+------------------------------------------------------------------------
+Specifications
+------------------------------------------------------------------------
+* **Receiver type**: 50 channel with WAAS, EGNOS, MSAS
+* **10 MHz ADEV**: 5e-11 over >24h
+* **1PPS RMS jitter**: <50ns 1-sigma
+* **Holdover**: <20us over 3h
+
+**Phase noise**:
+
++------------+------------+
+|            |    OCXO    |
++============+============+
+| **1Hz**    | -75dBc/Hz  |
++------------+------------+
+| **10Hz**   | -110dBc/Hz |
++------------+------------+
+| **100Hz**  | -132dBc/Hz |
++------------+------------+
+| **1kHz**   | -142dBc/Hz |
++------------+------------+
+| **10kHz**  | -145dBc/Hz |
++------------+------------+
+| **100kHz** | -150dBc/Hz |
++------------+------------+
+
+**Antenna Types:**
+
+The GPSDO is capable of supplying a 3V for active GPS antennas or supporting passive antennas.
+
+------------------------------------------------------------------------
+Installation Instructions
+------------------------------------------------------------------------
+To install the GPSDO, you must insert it into the slot on the board
+near the 10 MHz Reference SMA. Keep in mind that the two sides of the
+GPSDO have a different number of pins. When inserting the GPSDO, make
+sure to press down firmly and evenly. When turning on the USRP B2X0 device,
+a green LED should illuminate on the GPSDO. This signifies that the unit
+has successfully been placed.
+
+**NOTE: The pins on the GPSDO are very fragile. Be sure to press down
+evenly, or the pins may bend or break. Once the GPSDO is in place,
+we very highly discourage further removal, as this also risks damaging
+the pins.**
+
+------------------------------------------------------------------------
+Using the GPSDO in Your Application
+------------------------------------------------------------------------
+By default, if a GPSDO is detected at startup, the USRP will be configured
+to use it as a frequency and time reference. The internal VITA timestamp
+will be initialized to the GPS time, and the internal oscillator will be
+phase-locked to the 10MHz GPSDO reference. If the GPSDO is not locked to
+satellites, the VITA time will not be initialized.
+
+GPS data is obtained through the **mboard_sensors** interface. To retrieve
+the current GPS time, use the **gps_time** sensor:
+
+::
+
+    usrp->get_mboard_sensor("gps_time");
+
+The returned value will be the current epoch time, in seconds since
+January 1, 1970. This value is readily converted into human-readable
+format using the **time.h** library in C, **boost::posix_time** in C++, etc.
+
+Other information can be fetched as well. You can query the lock status
+with the **gps_locked** sensor, as well as obtain raw NMEA sentences using
+the **gps_gprmc**, and **gps_gpgga** sensors. Location
+information can be parsed out of the **gps_gpgga** sensor by using **gpsd** or
+another NMEA parser.
diff --git a/host/docs/identification.rst b/host/docs/identification.rst
index ba9b30898..cbae25082 100644
--- a/host/docs/identification.rst
+++ b/host/docs/identification.rst
@@ -1,38 +1,40 @@
-========================================================================
+=================================
 UHD - Device Identification Notes
-========================================================================
+=================================
 
 .. contents:: Table of Contents
 
-------------------------------------------------------------------------
+------------------------
 Identifying USRP Devices
-------------------------------------------------------------------------
+------------------------
 Devices are addressed through key/value string pairs.
 These string pairs can be used to narrow down the search for a specific device or group of devices.
 Most UHD utility applications and examples have an **--args** parameter that takes a device address, which is expressed as a delimited string.
 
 See the documentation in **types/device_addr.hpp** for reference.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^
 Common device identifiers
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^
 Every device has several ways of identifying it on the host system:
 
-+------------+------------+--------------------------------------------+
-| Identifier | Key        | Notes                                      |
-+============+============+============================================+
-| Serial     | serial     | globally unique identifier                 |
-+------------+------------+--------------------------------------------+
-| Address    | addr       | unique identifier on a network             |
-+------------+------------+--------------------------------------------+
-| Name       | name       | optional user-set identifier               |
-+------------+------------+--------------------------------------------+
-| Type       | type       | hardware series identifier                 |
-+------------+------------+--------------------------------------------+
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++------------+----------+-----------------------------------------------------------+-------------------------------
+| Identifier | Key      | Notes                                                     | Example
++============+==========+===========================================================+===============================
+| Serial     | serial   | globally unique identifier                                | 12345678
++------------+----------+-----------------------------------------------------------+----------------------------
+| Address    | addr     | unique identifier on a network                            | 192.168.10.2
++------------+----------+-----------------------------------------------------------+-------------------------------
+| Resource   | resource | unique identifier for USRP RIO devices (over PCI Express) | RIO0
++------------+----------+-----------------------------------------------------------+-------------------------------
+| Name       | name     | optional user-set identifier                              | my_usrp1 (User-defined value)
++------------+----------+-----------------------------------------------------------+----------------------------
+| Type       | type     | hardware series identifier                                | usrp1, usrp2, 
++------------+----------+-----------------------------------------------------------+----------------------------
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Device discovery via command line
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Devices attached to your system can be discovered using the **uhd_find_devices** program.
 This program scans your system for supported devices and prints
 out an enumerated list of discovered devices and their addresses.
@@ -52,9 +54,9 @@ Device address arguments can be supplied to narrow the scope of the search.
 
     uhd_find_devices --args="serial=12345678"
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Device discovery through the API
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The **device::find()** API call searches for devices and returns a list of discovered devices.
 
 ::
@@ -76,21 +78,22 @@ The **hint** argument can be populated to narrow the scope of the search.
     hint["serial"] = "12345678";
     uhd::device_addrs_t dev_addrs = uhd::device::find(hint);
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^
 Device properties
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^
 Properties of devices attached to your system can be probed with the **uhd_usrp_probe** program.
 This program constructs an instance of the device and prints out its properties,
 such as detected daughterboards, frequency range, gain ranges, etc...
 
 **Usage:**
+
 ::
 
     uhd_usrp_probe --args <device-specific-address-args>
 
-------------------------------------------------------------------------
+--------------------
 Naming a USRP Device
-------------------------------------------------------------------------
+--------------------
 For convenience purposes, users may assign a custom name to their USRP device.
 The USRP device can then be identified via name, rather than a difficult to remember serial or address.
 
@@ -100,22 +103,24 @@ A name has the following properties:
 * is 0-20 characters
 * is not required to be unique
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^
 Set a custom name
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^
 
 Run the following commands:
+
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     ./usrp_burn_mb_eeprom --args=<optional device args> --key=name --val=lab1_xcvr
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^
 Discovery via name
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^
 
 The keyword **name** can be used to narrow the scope of the search.
 Example with the find devices utility:
+
 ::
 
     uhd_find_devices --args="name=lab1_xcvr"
diff --git a/host/docs/images.rst b/host/docs/images.rst
index 95e2d96b0..37fbabf4b 100644
--- a/host/docs/images.rst
+++ b/host/docs/images.rst
@@ -12,9 +12,12 @@ The methods of loading images into the device vary among devices:
 
 * **USRP1:** The host code will automatically load the firmware and FPGA at runtime.
 * **USRP2:** The user must manually write the images onto the USRP2 SD card.
-* **USRP-N Series:** The user must manually transfer the images over ethernet.
+* **USRP-N Series:** The user programs an image into on-board storage, which
+  then is automatically loaded at runtime.
 * **USRP-E Series:** The host code will automatically load the FPGA at runtime.
 * **USRP-B Series:** The host code will automatically load the FPGA at runtime.
+* **USRP-X Series:** The user programs an image into on-board storage, which
+  then is automatically loaded at runtime. 
 
 ------------------------------------------------------------------------
 Pre-built Images
@@ -25,8 +28,6 @@ Pre-built images are available for download.
 * `Master Branch images <http://files.ettus.com/binaries/master_images/>`_
 * `Maint Branch images <http://files.ettus.com/binaries/maint_images/>`_
 
-See the UHD wiki for the download link.
-
 The pre-built images come in two forms:
 
 * bundled with UHD software in a platform-specific installer
@@ -36,11 +37,10 @@ The pre-built images come in two forms:
 UHD Images Downloader
 ^^^^^^^^^^^^^^^^^^^^^^
 
-The UHD Images Downloader is a new feature in UHD 003.005.000. This script downloads UHD images that
-are guaranteed to be compatible with the host code and places them in the default images
-directory.
+The UHD images downloader downloads UHD images compatible with the host code
+and places them in the default images directory.
 
-By default, it can be found at: **<install-path>/share/uhd/utils/uhd_images_downloader.py**
+By default, it can be found at: **<install-path>/lib/uhd/utils/uhd_images_downloader.py**
 
 By default, it installs images to: **<install-path>/share/uhd/images**
 
@@ -79,10 +79,25 @@ The build commands for a particular image can be found in **<uhd-repo-path>/imag
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Xilinx FPGA builds
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Xilinx ISE 12.x and up is required to build the Xilinx FPGA images.
+USRP Xilinx FPGA images are built with two different versions of ISE, depending
+on the device.
+
 The build requires that you have a UNIX-like environment with **Make**.
 Make sure that **xtclsh** from the Xilinx ISE bin directory is in your **$PATH**.
 
+
+**Xilinx ISE 14.4**
+* USRP X3x0 Series
+
+See **<uhd-repo-path>/fpga/usrp3/top/**.
+
+**Xilinx ISE 12.2**
+* USRP N2x0
+* USRP B2x0
+* USRP B1x0
+* USRP E1x0
+* USRP2
+
 See **<uhd-repo-path>/fpga/usrp2/top/**.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -97,7 +112,7 @@ See **<uhd-repo-path>/firmware/zpu**.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Altera FPGA builds
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Quartus is required to build the Altera FPGA images.
+Quartus is required to build the Altera FPGA image for the USRP1.
 Pre-built images can also be found in **<uhd-repo-path>/fpga/usrp1/rbf**.
 
 See **<uhd-repo-path>/fpga/usrp1/toplevel/***.
diff --git a/host/docs/index.rst b/host/docs/index.rst
index 65069059f..ffad1488d 100644
--- a/host/docs/index.rst
+++ b/host/docs/index.rst
@@ -18,25 +18,49 @@ Building and Installing UHD Software
 * `Installation Guide (Windows) <http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Windows>`_
 
 ^^^^^^^^^^^^^^^^^^^^^
-Application Notes
+General UHD Manuals
 ^^^^^^^^^^^^^^^^^^^^^
 * `General Application Notes <./general.html>`_
 * `Device Identification Notes <./identification.html>`_
 * `Firmware and FPGA Image Notes <./images.html>`_
-* `USRP1 Application Notes <./usrp1.html>`_
-* `USRP2 Application Notes <./usrp2.html>`_
-* `USRP-N2X0 Series Application Notes <./usrp2.html>`_
-* `USRP-B100 Series Application Notes <./usrp_b100.html>`_
-* `USRP-B2X0 Series Application Notes <./usrp_b200.html>`_
-* `USRP-E1X0 Series Application Notes <./usrp_e1x0.html>`_
 * `Daughterboard Application Notes <./dboards.html>`_
 * `Transport Application Notes <./transport.html>`_
 * `Synchronization Application Notes <./sync.html>`_
-* `Internal GPSDO Application Notes (USRP-N2X0/E1X0 Models) <./gpsdo.html>`_
-* `Internal GPSDO Application Notes (USRP-B2X0 Models) <./gpsdo_b2x0.html>`_
 * `Calibration Application Notes <./calibration.html>`_
 
 ^^^^^^^^^^^^^^^^^^^^^
+USRP N-Series Devices
+^^^^^^^^^^^^^^^^^^^^^
+* `USRP-N2x0 Series Device Manual <./usrp2.html>`_
+* `USRP-N2x0 Internal GPSDO Device Manual <./gpsdo.html>`_
+
+^^^^^^^^^^^^^^^^^^^^^
+USRP B-Series Devices
+^^^^^^^^^^^^^^^^^^^^^
+* `USRP-B100 Series Device Manual <./usrp_b100.html>`_
+* `USRP-B2x0 Series Device Manual <./usrp_b200.html>`_
+* `USRP1 Device Manual <./usrp1.html>`_
+
+^^^^^^^^^^^^^^^^^^^^^
+USRP E-Series Devices
+^^^^^^^^^^^^^^^^^^^^^
+* `USRP-E1x0 Series Device Manual <./usrp_e1x0.html>`_
+* `USRP-E1x0 Internal GPSDO Device Manual <./gpsdo.html>`_
+
+^^^^^^^^^^^^^^^^^^^^^
+USRP X-Series Devices
+^^^^^^^^^^^^^^^^^^^^^
+* `USRP-X3x0 Series Device Manual <./usrp_x3x0.html>`_
+* `USRP-X3x0 Internal GPSDO Device Manual <./gpsdo_x3x0.html>`_
+* `USRP-X3x0 Front Panel GPIO API <./gpio_api.html>`_
+* `USRP-X3x0 System Configuration <./usrp_x3x0_config.html>`_
+
+^^^^^^^^^^^^^^^^^^^^^
+USRP Legacy Series
+^^^^^^^^^^^^^^^^^^^^^
+* `USRP2 Device Manual <./usrp2.html>`_
+
+^^^^^^^^^^^^^^^^^^^^^
 API Documentation
 ^^^^^^^^^^^^^^^^^^^^^
 * `Doxygen <./../../doxygen/html/index.html>`_
diff --git a/host/docs/res/x3x0_fp_overlay.png b/host/docs/res/x3x0_fp_overlay.png
new file mode 100644
index 000000000..8ab88d4a3
--- /dev/null
+++ b/host/docs/res/x3x0_fp_overlay.png
diff --git a/host/docs/res/x3x0_gpio_conn.png b/host/docs/res/x3x0_gpio_conn.png
new file mode 100644
index 000000000..0147bf422
--- /dev/null
+++ b/host/docs/res/x3x0_gpio_conn.png
diff --git a/host/docs/res/x3x0_rp_overlay.png b/host/docs/res/x3x0_rp_overlay.png
new file mode 100644
index 000000000..c34936ac3
--- /dev/null
+++ b/host/docs/res/x3x0_rp_overlay.png
diff --git a/host/docs/stream.rst b/host/docs/stream.rst
index a00ef88ee..337d7ca40 100644
--- a/host/docs/stream.rst
+++ b/host/docs/stream.rst
@@ -16,7 +16,7 @@ A TX stream allows the user to transmit samples to the device.
 Link Layer Encapsulation
 ------------------------------------------------------------------------
 The VITA49 standard provides encapsulation for sample data across a link layer.
-On all generation2 hardware, samples are encapsulated into VRT IF data packets.
+On all second generation hardware (and later), samples are encapsulated into VRT IF data packets.
 These packets also provide sample decoration such as stream time and burst flags.
 Sample decoration is exposed to the user in the form of RX and TX metadata structs.
 
@@ -54,6 +54,6 @@ Conversion
 The user may request arbitrary combinations of host and link data types;
 however, not all combinations are supported.
 The user may register custom data type formats and conversion routines.
-See **uhd/convert.hpp** for futher documentation.
+See **uhd/convert.hpp** for further documentation.
 
 TODO: provide example of convert API
diff --git a/host/docs/sync.rst b/host/docs/sync.rst
index a1f6cb7df..21be60a20 100644
--- a/host/docs/sync.rst
+++ b/host/docs/sync.rst
@@ -153,7 +153,7 @@ For transmit, a burst is started when the user calls send(). The metadata should
     size_t num_tx_samps = tx_streamer->send(buffs, samps_to_send, md);
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Align LOs in the front-end (SBX/WBX + N-Series)
+Align LOs in the front-end (SBX, WBX, CBX)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Using timed commands, multiple frontends can be tuned at a specific time.
 This timed-tuning ensures that the phase offsets between VCO/PLL chains
@@ -163,7 +163,7 @@ will remain constant after each re-tune. See notes below:
 * This phase offset is different for different LO frequencies
 * This phase offset remains constant after retuning
 
-  * Due to divider, WBX phase offset will be randomly +/- 180 deg after re-tune
+  * Due to a divider, WBX phase offset will be randomly +/- 180 deg after re-tune
 
 * This phase offset will drift over time due to thermal and other characteristics
 * Periodic calibration will be necessary for phase-coherent applications
diff --git a/host/docs/transport.rst b/host/docs/transport.rst
index 79d2743a4..88f787893 100644
--- a/host/docs/transport.rst
+++ b/host/docs/transport.rst
@@ -7,14 +7,14 @@ UHD - Transport Application Notes
 ------------------------------------------------------------------------
 Introduction
 ------------------------------------------------------------------------
-A transport is the layer between the packet interface and a device IO interface.
-The advanced user can pass optional parameters
-into the underlying transport layer through the device address.
-These optional parameters control how the transport object allocates memory,
-resizes kernel buffers, spawns threads, etc.
-When not spcified, the transport layer will use values for these parameters
-that are known to perform well on a variety of systems.
-The transport parameters are defined below for the various transports in the UHD software:
+A transport is the layer between the packet interface and a device IO
+interface.  The advanced user can pass optional parameters into the underlying
+transport layer through the device address.  These optional parameters control
+how the transport object allocates memory, resizes kernel buffers, spawns
+threads, etc.  When not spcified, the transport layer will use values for these
+parameters that are known to perform well on a variety of systems.  The
+transport parameters are defined below for the various transports in the UHD
+software:
 
 ------------------------------------------------------------------------
 UDP Transport (Sockets)
@@ -147,7 +147,7 @@ so that non-root users may access the device:
 
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     sudo cp uhd-usrp.rules /etc/udev/rules.d/
     sudo udevadm control --reload-rules
     sudo udevadm trigger
diff --git a/host/docs/uhd_cal_rx_iq_balance.1 b/host/docs/uhd_cal_rx_iq_balance.1
index 073d8ce63..8c2c87ece 100644
--- a/host/docs/uhd_cal_rx_iq_balance.1
+++ b/host/docs/uhd_cal_rx_iq_balance.1
@@ -1,4 +1,4 @@
-.TH "uhd_cal_rx_iq_balance" "1" "3.5.1" "UHD" "User Commands"
+.TH "uhd_cal_rx_iq_balance" "1" "3.7.0" "UHD" "User Commands"
 .SH NAME
 uhd_cal_rx_iq_balance \- Generate RX IQ Balance Calibration Table for a UHD Device
 .SH DESCRIPTION
diff --git a/host/docs/uhd_cal_tx_dc_offset.1 b/host/docs/uhd_cal_tx_dc_offset.1
index d64120242..f0479d7ec 100644
--- a/host/docs/uhd_cal_tx_dc_offset.1
+++ b/host/docs/uhd_cal_tx_dc_offset.1
@@ -1,4 +1,4 @@
-.TH "uhd_cal_tx_dc_offset" "1" "3.5.1" "UHD" "User Commands"
+.TH "uhd_cal_tx_dc_offset" "1" "3.7.0" "UHD" "User Commands"
 .SH NAME
 uhd_cal_tx_dc_offset \- Generate TX DC Offset Calibration Table for a UHD Device
 .SH DESCRIPTION
diff --git a/host/docs/uhd_cal_tx_iq_balance.1 b/host/docs/uhd_cal_tx_iq_balance.1
index f4fdbd12f..bb8970f4c 100644
--- a/host/docs/uhd_cal_tx_iq_balance.1
+++ b/host/docs/uhd_cal_tx_iq_balance.1
@@ -1,4 +1,4 @@
-.TH "uhd_cal_tx_iq_balance" "1" "3.5.1" "UHD" "User Commands"
+.TH "uhd_cal_tx_iq_balance" "1" "3.7.0" "UHD" "User Commands"
 .SH NAME
 uhd_cal_tx_iq_balance \- Generate TX IQ Balance Calibration Table for a UHD Device
 .SH DESCRIPTION
diff --git a/host/docs/uhd_find_devices.1 b/host/docs/uhd_find_devices.1
index 08f9a789c..416f807b9 100644
--- a/host/docs/uhd_find_devices.1
+++ b/host/docs/uhd_find_devices.1
@@ -1,4 +1,4 @@
-.TH "uhd_find_devices" 1 "3.5.1" UHD "User Commands"
+.TH "uhd_find_devices" 1 "3.7.0" UHD "User Commands"
 .SH NAME
 uhd_find_devices \- USRP Hardware Driver Discovery Utility
 .SH DESCRIPTION
diff --git a/host/docs/uhd_images_downloader.1 b/host/docs/uhd_images_downloader.1
index 28310dd37..dd0fe208d 100644
--- a/host/docs/uhd_images_downloader.1
+++ b/host/docs/uhd_images_downloader.1
@@ -1,4 +1,4 @@
-.TH "uhd_images_downloader" 1 "3.5.1" UHD "User Commands"
+.TH "uhd_images_downloader" 1 "3.7.0" UHD "User Commands"
 .SH NAME
 uhd_images_downloader \- USRP Hardware Driver firmware/FPGA downloader
 .SH DESCRIPTION
@@ -12,7 +12,7 @@ matching this UHD driver release onto the host system. If the uhd-images
 package is installed, there is no need to run this installer.
 .SH SYNOPSIS
 .B uhd_images_downloader
-Usage: uhd_images_downloader.py [options]
+Usage: uhd_images_downloader [options]
 .SH OPTIONS
 This program works best without any arguments.
 .PP
@@ -38,7 +38,7 @@ usrp2_card_burner(1) usrp_n2xx_simple_net_burner(1)
 This manual page was written by Maitland Bottoms and Nicholas Corgan
 for the Debian project (but may be used by others).
 .SH COPYRIGHT
-Copyright (c) 2012 Ettus Research LLC
+Copyright (c) 2012,2014 Ettus Research LLC
 .LP
 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
diff --git a/host/docs/uhd_usrp_probe.1 b/host/docs/uhd_usrp_probe.1
index a6c7150ee..ee30b2350 100644
--- a/host/docs/uhd_usrp_probe.1
+++ b/host/docs/uhd_usrp_probe.1
@@ -1,4 +1,4 @@
-.TH "uhd_usrp_probe" 1 "3.5.1" UHD "User Commands"
+.TH "uhd_usrp_probe" 1 "3.7.0" UHD "User Commands"
 .SH NAME
 uhd_usrp_probe \- USRP Hardware Driver Peripheral Report Utility
 .SH DESCRIPTION
diff --git a/host/docs/usrp1.rst b/host/docs/usrp1.rst
index b6fd24b09..be74fe00a 100644
--- a/host/docs/usrp1.rst
+++ b/host/docs/usrp1.rst
@@ -1,5 +1,5 @@
 ========================================================================
-UHD - USRP1 Application Notes
+UHD - USRP1 Device Manual
 ========================================================================
 
 .. contents:: Table of Contents
@@ -8,12 +8,20 @@ UHD - USRP1 Application Notes
 Comparative features list
 ------------------------------------------------------------------------
 
-* 2 transceiver card slots
-* 2 RX DDC chains in FPGA
-* 2 TX DUC chains in FPGA (no TX CORDIC -> uses DAC)
-* 64 MHz fixed clock rate
-* sc16 sample modes
-* sc8 sample mode - RX only
+**Hardware Capabilities:**
+ * 2 transceiver card slots
+ * 64 MHz fixed clock rate
+
+**FPGA Capabilities:**
+ * 2 RX DDC chains in FPGA
+ * 2 TX DUC chains in FPGA (no TX CORDIC -> uses DAC)
+ * sc16 sample modes - RX & TX
+
+   - Up to 8 MHz of RF BW with 16-bit samples
+
+ * sc8 sample mode - RX only
+
+   - Up to 16 MHz of RF BW with 8-bit samples
 
 ------------------------------------------------------------------------
 Specify a Non-standard Image
@@ -93,7 +101,7 @@ so UHD software can initialize with the correct clock rate.
 Run the following commands to record the setting into the EEPROM:
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     ./usrp_burn_mb_eeprom --args=<optional device args> --key=mcr --val=<rate>
 
 The user may override the clock rate specified in the EEPROM by using a device address:
diff --git a/host/docs/usrp2.rst b/host/docs/usrp2.rst
index 8ef31af1a..361d98f01 100644
--- a/host/docs/usrp2.rst
+++ b/host/docs/usrp2.rst
@@ -1,5 +1,5 @@
 ========================================================================
-UHD - USRP2 and N2X0 Series Application Notes
+UHD - USRP2 and N2x0 Series Device Manual
 ========================================================================
 
 .. contents:: Table of Contents
@@ -8,23 +8,29 @@ UHD - USRP2 and N2X0 Series Application Notes
 Comparative features list
 ------------------------------------------------------------------------
 
-* 1 transceiver card slot
-* 2 RX DDC chains in FPGA
-* 1 TX DUC chain in FPGA
-* Timed commands in FPGA (N2x0 only)
-* Timed sampling in FPGA
-* External PPS reference
-* External 10MHz reference
-* MIMO cable shared reference
-* Fixed 100 MHz clock rate
-* Internal GPSDO option (N2x0 only)
-* sc8 and sc16 sample modes
+**Hardware Capabilities:**
+ * 1 transceiver card slot
+ * External PPS reference input
+ * External 10 MHz reference input
+ * MIMO cable shared reference
+ * Fixed 100 MHz clock rate
+ * Internal GPSDO option (N2x0 only)
+
+**FPGA Capabilities:**
+ * 2 RX DDC chains in FPGA
+ * 1 TX DUC chain in FPGA
+ * Timed commands in FPGA (N2x0 only)
+ * Timed sampling in FPGA
+ * 16-bit and 8-bit sample modes (sc8 and sc16)
+
+   * Up to 25 MHz of RF BW with 16-bit samples
+   * Up to 50 MHz of RF BW with 8-bit samples
 
 ------------------------------------------------------------------------
 Load the Images onto the SD card (USRP2 only)
 ------------------------------------------------------------------------
 **Warning!**
-Use **usrp2_card_burner.py** with caution. If you specify the wrong device node,
+Use **usrp2_card_burner** with caution. If you specify the wrong device node,
 you could overwrite your hard drive. Make sure that **--dev=** specifies the SD card.
 
 **Warning!**
@@ -41,11 +47,11 @@ Use the card burner tool (UNIX)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ::
 
-    sudo <install-path>/share/uhd/utils/usrp2_card_burner_gui.py
+    sudo <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py
 
     -- OR --
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     sudo ./usrp2_card_burner.py --dev=/dev/sd<XXX> --fpga=<path_to_fpga_image>
     sudo ./usrp2_card_burner.py --dev=/dev/sd<XXX> --fw=<path_to_firmware_image>
 
@@ -58,51 +64,46 @@ Use the card burner tool (Windows)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ::
 
-    <path_to_python.exe> <install-path>/share/uhd/utils/usrp2_card_burner_gui.py
+    <path_to_python.exe> <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py
 
 ------------------------------------------------------------------------
 Load the Images onto the On-board Flash (USRP-N Series only)
 ------------------------------------------------------------------------
-The USRP-N Series can be reprogrammed over the network
-to update or change the firmware and FPGA images.
+The USRP-N Series can be reprogrammed over the network to update or change the firmware and FPGA images.
 When updating images, always burn both the FPGA and firmware images before power cycling.
 This ensures that when the device reboots, it has a compatible set of images to boot into.
 
-**Note:**
-Different hardware revisions require different FPGA images.
-Determine the revision number from the sticker on the rear of the chassis.
-Use this number to select the correct FPGA image for your device.
-
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Use the net burner tool (UNIX)
+Use the net burner tool
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ::
 
-    <install-path>/share/uhd/utils/usrp_n2xx_net_burner_gui.py
+    Use default images:
+    usrp_n2xx_simple_net_burner --addr=<IP address>
 
-    -- OR --
+    Use custom-built images:
+    usrp_n2xx_simple_net_burner --addr=<IP address> --fw=<firmware path> --fpga=<FPGA path>
+
+**Note:**
+Different hardware revisions require different FPGA images.
+Determine the revision number from the sticker on the rear of the chassis.
+Use this number to select the correct FPGA image for your device.
 
-    cd <install-path>/share/uhd/utils
-    ./usrp_n2xx_net_burner.py --addr=<ip address> --fw=<path for firmware image>
-    ./usrp_n2xx_net_burner.py --addr=<ip address> --fpga=<path to FPGA image>
+For users who would prefer a graphical utility, a Python-based alternative exists.
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Use the net burner tool (Windows)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use the graphical net burner tool (Linux)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ::
 
-    <path_to_python.exe> <install-path>/share/uhd/utils/usrp_n2xx_net_burner_gui.py
+    <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py
 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Burning images without Python
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For users who do not wish to install Python, a new script is available in UHD 003.005.000:
-the USRP N2XX Simple Net Burner. It provides the same functionality as its Python
-counterpart, but by default, it automatically installs the default images without the user needing
-to specify their location on the command line.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use the graphical net burner tool (Windows)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+::
 
-The utility can be found at: **<install-path>/share/uhd/utils/usrp_n2xx_simple_net_burner**
+    <path_to_python.exe> <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Device recovery and bricking
@@ -190,7 +191,7 @@ and the network must be setup properly as described above.
 Run the following commands:
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     ./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr --val=192.168.10.3
 
 **Method 2 (Linux Only):**
@@ -199,7 +200,7 @@ It uses raw Ethernet packets to bypass the IP/UDP layer to communicate with the
 Run the following commands:
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     sudo ./usrp2_recovery.py --ifc=eth0 --new-ip=192.168.10.3
 
 ------------------------------------------------------------------------
@@ -271,11 +272,11 @@ Addressing the Device
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Single device configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In a single-device configuration,
-the USRP device must have a unique IPv4 address on the host computer.
-The USRP can be identified through its IPv4 address, resolvable hostname, or by other means.
-See the application notes on `device identification <./identification.html>`_.
-Use this addressing scheme with the **single_usrp** interface.
+In a single-device configuration, the USRP device must have a unique IPv4
+address on the host computer.  The USRP can be identified through its IPv4
+address, resolvable hostname, or by other means.  See the application notes on
+`device identification <./identification.html>`_.  Please note that this
+addressing scheme should also be used with the **multi_usrp** interface.
 
 Example device address string representation for a USRP2 with IPv4 address **192.168.10.2**:
 
@@ -313,7 +314,7 @@ This device will be referred to as the slave, and the other device, the master.
 * External clocking is optional and should only be supplied to the master device.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Shared ethernet mode
+Shared Ethernet mode
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In shared Ethernet mode,
 only one device in the configuration can be attached to the Ethernet.
@@ -322,7 +323,7 @@ only one device in the configuration can be attached to the Ethernet.
 * Master and slave must have different IPv4 addresses in the same subnet.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Dual ethernet mode
+Dual Ethernet mode
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In dual Ethernet mode,
 both devices in the configuration must be attached to the Ethernet.
@@ -358,7 +359,7 @@ have been programmed into the device's EEPROM.
 Run the following commands:
 ::
 
-    cd <install-path>/share/uhd/utils
+    cd <install-path>/lib/uhd/utils
     ./usrp_burn_mb_eeprom --args=<optional device args> --key=subnet --val=255.255.255.0
     ./usrp_burn_mb_eeprom --args=<optional device args> --key=gateway --val=192.168.10.1
 
@@ -400,7 +401,7 @@ The LEDs on the front panel can be useful in debugging hardware and software iss
 The LEDs reveal the following about the state of the device:
 
 * **LED A:** transmitting
-* **LED B:** mimo cable link
+* **LED B:** MIMO cable link
 * **LED C:** receiving
 * **LED D:** firmware loaded
 * **LED E:** reference lock
@@ -408,13 +409,13 @@ The LEDs reveal the following about the state of the device:
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Ref Clock - 10MHz
+Ref Clock - 10 MHz
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Using an external 10MHz reference clock, a square wave will offer the best phase
+Using an external 10 MHz reference clock, a square wave will offer the best phase
 noise performance, but a sinusoid is acceptable.  The reference clock requires the following power level:
 
-* **USRP2** 5 to 15dBm
-* **N2XX** 0 to 15dBm
+* **USRP2** 5 to 15 dBm
+* **N2XX** 0 to 15 dBm
 
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -431,7 +432,7 @@ Test the PPS input with the following app:
 
 ::
 
-    cd <install-path>/share/uhd/examples
+    cd <install-path>/lib/uhd/examples
     ./test_pps_input --args=<args>
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -466,7 +467,9 @@ which has been aptly named slot **A**.
 
 In the following example, a TVRX2 is installed.
 Channel 0 is sourced from subdevice **RX1**,
-and channel 1 is sourced from subdevice **RX2**:
+and channel 1 is sourced from subdevice **RX2** (**RX1** and **RX2**
+are the antenna ports on the TVRX2 daughterboard):
+
 ::
 
     usrp->set_rx_subdev_spec("A:RX1 A:RX2");
diff --git a/host/docs/usrp2_card_burner.1 b/host/docs/usrp2_card_burner.1
index d6a12b073..b6e1954d8 100644
--- a/host/docs/usrp2_card_burner.1
+++ b/host/docs/usrp2_card_burner.1
@@ -1,4 +1,4 @@
-.TH "usrp2_card_burner" 1 "3.5.1" UHD "User Commands"
+.TH "usrp2_card_burner" 1 "3.7.0" UHD "User Commands"
 .SH NAME
 usrp2_card_burner - USRP N-Series FPGA/Firmware Burner
 .SH DESCRIPTION
@@ -34,12 +34,12 @@ GR-UHD documentation:
 .LP
 Other UHD programs:
 .sp
-uhd_images_downloader(1) usrp_n2xx_simple_net_burner(1)
+uhd_images_downloader(1) usrp_n2xx_simple_net_burner(1) usrp_x3xx_fpga_burner(1)
 .SH AUTHOR
 This manual page was written by Nicholas Corgan
 for the Debian project (but may be used by others).
 .SH COPYRIGHT
-Copyright (c) 2012 Ettus Research LLC
+Copyright (c) 2012,2014 Ettus Research LLC
 .LP
 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
diff --git a/host/docs/usrp_b100.rst b/host/docs/usrp_b100.rst
index ac0942f5c..223ad5a90 100644
--- a/host/docs/usrp_b100.rst
+++ b/host/docs/usrp_b100.rst
@@ -1,5 +1,5 @@
 ========================================================================
-UHD - USRP-B100 Series Application Notes
+UHD - USRP-B100 Series Device Manual
 ========================================================================
 
 .. contents:: Table of Contents
@@ -8,15 +8,21 @@ UHD - USRP-B100 Series Application Notes
 Comparative features list
 ------------------------------------------------------------------------
 
-* 1 transceiver card slot
-* 1 RX DDC chain in FPGA
-* 1 TX DUC chain in FPGA
-* Timed commands in FPGA
-* Timed sampling in FPGA
-* External PPS reference
-* External 10MHz reference
-* Configurable clock rate (defaults 64 MHz)
-* sc8 and sc16 sample modes
+**Hardware Capabilities:**
+ * 1 transceiver card slot
+ * External PPS reference input
+ * External 10 MHz reference input
+ * Configurable clock rate (defaults 64 MHz)
+
+**FPGA Capabilities:**
+ * 1 RX DDC chain in FPGA
+ * 1 TX DUC chain in FPGA
+ * Timed commands in FPGA
+ * Timed sampling in FPGA
+ * sc8 and sc16 sample modes
+
+   * Up to 8 MHz of RF BW with 16-bit samples
+   * Up to 16 MHz of RF BW with 8-bit samples
 
 ------------------------------------------------------------------------
 Specify a Non-standard Image
@@ -38,17 +44,17 @@ Example device address string representations to specify non-standard images:
 Changing the Master Clock Rate
 ------------------------------------------------------------------------
 The master clock rate of the B100 feeds both the FPGA DSP and the codec chip.
-Hundreds of rates between 32MHz and 64MHz are available.
+Hundreds of rates between 32 MHz and 64 MHz are available.
 A few notable rates are:
 
-* **64MHz:** maximum rate of the codec chip
-* **61.44MHz:** good for UMTS/WCDMA applications
-* **52Mhz:** good for GSM applications
+* **64 MHz:** maximum rate of the codec chip
+* **61.44 MHz:** good for UMTS/WCDMA applications
+* **52 MHz:** good for GSM applications
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Set 61.44MHz - uses external VCXO
+Set 61.44 MHz - uses external VCXO
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To use the 61.44MHz clock rate, the USRP embedded will require one jumper to be moved,
+To use the 61.44 MHz clock rate, the USRP embedded will require one jumper to be moved,
 and X4 must be populated with a 61.44 MHz oscillator.
 
 * **J15** is a three pin header, move the jumper to (pin1, pin2)
@@ -64,7 +70,7 @@ To use other clock rates, the jumper will need to be in the default position.
 * **J15** is a three pin header, move the jumper to (pin2, pin3)
 
 To communicate the desired clock rate into UHD software,
-specify the a special device address argument,
+specify the special device address argument,
 where the key is **master_clock_rate** and the value is a rate in Hz.
 Example:
 ::
@@ -82,9 +88,9 @@ The LEDs on the front panel can be useful in debugging hardware and software iss
 The LEDs reveal the following about the state of the device:
 
 * **LED A:** transmitting
-* **LED B:** fpga loaded
+* **LED B:** FPGA loaded
 * **LED C:** receiving
-* **LED D:** fpga loaded
+* **LED D:** FPGA loaded
 * **LED E:** reference lock
 * **LED F:** board power
 
diff --git a/host/docs/usrp_b200.rst b/host/docs/usrp_b200.rst
index 7986e3b73..1b0d7b719 100644
--- a/host/docs/usrp_b200.rst
+++ b/host/docs/usrp_b200.rst
@@ -1,5 +1,5 @@
 ========================================================================
-UHD - USRP-B2X0 Series Application Notes
+UHD - USRP-B2x0 Series Device Manual
 ========================================================================
 
 .. contents:: Table of Contents
@@ -8,35 +8,26 @@ UHD - USRP-B2X0 Series Application Notes
 Comparative features list - B200
 ------------------------------------------------------------------------
 
-* integrated RF frontend (RF coverage from 70 MHz - 6 GHz)
-* 1 RX DDC chain in FPGA
-* 1 TX DUC chain in FPGA
-* Timed commands in FPGA
-* Timed sampling in FPGA
-* External PPS reference
-* External 10MHz reference
-* Configurable clock rate
-* Internal GPSDO option
+**Hardware Capabilities:**
+ * Integrated RF frontend (70 MHz - 6 GHz)
+ * External PPS reference input
+ * External 10 MHz reference input
+ * Configurable clock rate
+ * Internal GPSDO option
+ * B210 Only:
 
-------------------------------------------------------------------------
-Comparative features list - B210
-------------------------------------------------------------------------
+   * MICTOR Debug Connector
+   * JTAG Connector
 
-* integrated MIMO frontend (RF coverage from 70 MHz - 6 GHz)
-* 2 RX DDC chains in FPGA
-* 2 TX DUC chains in FPGA
-* Timed commands in FPGA
-* Timed sampling in FPGA
-* External PPS reference
-* External 10MHz reference
-* Configurable clock rate
-* Internal GPSDO option
+**FPGA Capabilities:**
+ * Timed commands in FPGA
+ * Timed sampling in FPGA
 
 ------------------------------------------------------------------------
 Specify a Non-standard Image
 ------------------------------------------------------------------------
 UHD software will automatically select the USRP B2X0 images from the installed images package.
-The image selection can be overridden with the **--fpga=** and **--fw=** device address parameters.
+The image selection can be overridden with the **fpga** and **fw** device address parameters.
 
 Example device address string representations to specify non-standard images:
 
@@ -81,9 +72,9 @@ Frontend gain
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 All frontends have individual analog gain controls.
 The receive frontends have 73 dB of available gain;
-and the transmit frontends have 89 dB of available gain.
+and the transmit frontends have 89.5 dB of available gain.
 Gain settings are application specific,
-but its recommended that users consider using at least
+but it is recommended that users consider using at least
 half of the available gain to get reasonable dynamic range.
 
 ------------------------------------------------------------------------
diff --git a/host/docs/usrp_e1x0.rst b/host/docs/usrp_e1x0.rst
index fc929e639..ea2d05a3c 100644
--- a/host/docs/usrp_e1x0.rst
+++ b/host/docs/usrp_e1x0.rst
@@ -1,5 +1,5 @@
 ========================================================================
-UHD - USRP-E1X0 Series Application Notes
+UHD - USRP-E1x0 Series Device Manual
 ========================================================================
 
 .. contents:: Table of Contents
@@ -8,23 +8,29 @@ UHD - USRP-E1X0 Series Application Notes
 Comparative features list
 ------------------------------------------------------------------------
 
-* 1 transceiver card slot
-* 2 RX DDC chains in FPGA
-* 1 TX DUC chain in FPGA
-* Timed commands in FPGA
-* Timed sampling in FPGA
-* Internal PPS reference
-* Internal 10MHz reference
-* Configurable clock rate (defaults 64 MHz)
-* Internal GPSDO option
-* sc8 and sc16 sample modes
+**Hardware Capabilities:**
+ * 1 transceiver card slot
+ * Internal PPS reference input
+ * Internal 10 MHz reference input
+ * Configurable clock rate (defaults to 64 MHz)
+ * Internal GPSDO option
+
+**FPGA Capabilities:**
+ * 2 RX DDC chains in FPGA
+ * 1 TX DUC chain in FPGA
+ * Timed commands in FPGA
+ * Timed sampling in FPGA
+ * sc8 and sc16 sample modes
+
+   * Up to 8 MHz of RF BW with 16-bit samples
+   * Up to 16 MHz of RF BW with 8-bit samples
 
 ------------------------------------------------------------------------
 Specify a Non-standard Image
 ------------------------------------------------------------------------
 UHD software will automatically select the USRP-Embedded FPGA image from the
 installed images package.  The FPGA image selection can be overridden with the
-**--fpga=** device address parameter.
+**fpga** device address parameter.
 
 Example device address string representations to specify non-standard FPGA
 image:
@@ -37,17 +43,17 @@ image:
 Changing the Master Clock Rate
 ------------------------------------------------------------------------
 The master clock rate of the USRP-Embedded feeds both the FPGA DSP and the codec
-chip.  Hundreds of rates between 32MHz and 64MHz are available.  A few notable
+chip.  Hundreds of rates between 32 MHz and 64 MHz are available.  A few notable
 rates are:
 
-* **64MHz:** maximum rate of the codec chip
-* **61.44MHz:** good for UMTS/WCDMA applications
-* **52Mhz:** good for GSM applications
+* **64 MHz:** maximum rate of the codec chip
+* **61.44 MHz:** good for UMTS/WCDMA applications
+* **52 MHz:** good for GSM applications
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Set 61.44MHz - uses external VCXO
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To use the 61.44MHz clock rate with the USRP-Embedded, two jumpers must be moved
+To use the 61.44 MHz clock rate with the USRP-Embedded, two jumpers must be moved
 on the device.
 
 * **J16** is a two pin header; remove the jumper (or leave it on pin1 only).
@@ -94,22 +100,22 @@ a connector.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 PPS - Pulse Per Second
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-An exteral PPS signal for timestamp synchronization can be supplied by soldering
+An external PPS signal for timestamp synchronization can be supplied by soldering
 a connector.
 
 * Connector **J13** (PPS) needs MCX connector **WM5541-ND** or similar.
 * Requires a square wave signal.
-* **Amplitude:** 3.3 to 5Vpp
+* **Amplitude:** 3.3 to 5 Vpp
 
-Test the PPS input with the following app:
-
-* **<args** are device address arguments (optional if only one USRP device is on your machine).
+Test the PPS input with the following app (**<args>** are device address
+arguments, optional if only one USRP device is on your machine):
 
 ::
 
-    cd <install-path>/share/uhd/examples
+    cd <install-path>/lib/uhd/examples
     ./test_pps_input --args=<args>
 
+
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Internal GPSDO
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -117,7 +123,7 @@ Please see the `Internal GPSDO Application Notes <./gpsdo.html>`_
 for information on configuring and using the internal GPSDO.
 
 UHD software will always try to detect an installed GPSDO at runtime.
-There is not a special EEPROM value to burn for GPSDO detection.
+It is not necessary to burn a special EEPROM value for GPSDO detection.
 
 ------------------------------------------------------------------------
 Hardware Setup Notes
@@ -132,7 +138,7 @@ issues.  The LEDs reveal the following about the state of the device:
 * **LED A:** transmitting
 * **LED B:** PPS signal
 * **LED C:** receiving
-* **LED D:** fpga loaded
+* **LED D:** FPGA loaded
 * **LED E:** reference lock
 * **LED F:** board power
 
diff --git a/host/docs/usrp_n2xx_simple_net_burner.1 b/host/docs/usrp_n2xx_simple_net_burner.1
index 6e8e38fae..8df38b7bd 100644
--- a/host/docs/usrp_n2xx_simple_net_burner.1
+++ b/host/docs/usrp_n2xx_simple_net_burner.1
@@ -1,4 +1,4 @@
-.TH "usrp_n2xx_simple_net_burner" 1 "3.5.1" UHD "User Commands"
+.TH "usrp_n2xx_simple_net_burner" 1 "3.7.0" UHD "User Commands"
 .SH NAME
 usrp_n2xx_simple_net_burner - USRP N-Series FPGA/Firmware Burner
 .SH DESCRIPTION
@@ -41,12 +41,12 @@ GR-UHD documentation:
 .LP
 Other UHD programs:
 .sp
-uhd_images_downloader(1) usrp2_card_burner(1)
+uhd_images_downloader(1) usrp2_card_burner(1) usrp_x3xx_fpga_burner(1)
 .SH AUTHOR
 This manual page was written by Nicholas Corgan
 for the Debian project (but may be used by others).
 .SH COPYRIGHT
-Copyright (c) 2012 Ettus Research LLC
+Copyright (c) 2012,2014 Ettus Research LLC
 .LP
 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
diff --git a/host/docs/usrp_x3x0.rst b/host/docs/usrp_x3x0.rst
new file mode 100644
index 000000000..3b7e9914e
--- /dev/null
+++ b/host/docs/usrp_x3x0.rst
@@ -0,0 +1,784 @@
+===============================
+UHD - X3x0 Series Device Manual
+===============================
+
+.. contents:: Table of Contents
+
+-------------------------
+Comparative features list
+-------------------------
+
+**Hardware Capabilities:**
+ * 2 transceiver card slots (can do 2x2 MIMO out of the box)
+ * Dual SFP+ Transceivers (can be used with 1 GigE, 10 GigE)
+ * PCI Express over cable (MXI) gen1 x4
+ * External PPS input & output
+ * External 10 MHz input & output
+ * Expandable via 2nd SFP+ interface
+ * Supported master clock rates: 200 MHz, 184.32 MHz
+ * External GPIO Connector with UHD API control
+ * External USB Connection for built-in JTAG debugger
+ * Internal GPSDO option
+ * Kintex-7 FPGA (X310: XC7K410T, X300: XC7K325T)
+
+**FPGA Capabilities:**
+ * 2 RX DDC chains in FPGA
+ * 2 TX DUC chain in FPGA
+ * Timed commands in FPGA
+ * Timed sampling in FPGA
+ * 16-bit and 8-bit sample modes (sc8 and sc16)
+ * Up to 120 MHz of RF bandwidth with 16-bit samples
+
+---------------
+Getting started
+---------------
+
+This will run you through the first steps relevant to get your USRP X300/X310
+up and running. Here, we assume you will connect your USRP using Gigabit Ethernet (1GigE),
+as this interface is readily available in most computers. For 10 Gigabit Ethernet (10GigE) or
+PCI Express (PCIe), see the corresponding sections in this manual page.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Assembling the X300/X310 kit
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Before you can start using your USRP, you might have to assemble the hardware,
+if this has not yet happened. Make sure you are grounded (e.g. by touching a radiator)
+in order not to damage sensitive electronics through static discharge!
+
+1. Unscrew the top of your X300/X310 (there are 2 screws which can be easily loosened
+   using a small Phillips screwdriver).
+2. Insert the daughterboards by inserting them into the slots and optionally screwing
+   them onto the motherboard.
+3. Connect the RF connectors on the daughterboards to the front panel. In order to avoid
+   confusion, make sure the internal connections match the labels on the front panel (i.e.
+   TX/RX is connected to TX/RX).
+4. If you have purchased an internal GPSDO, follow the instructions on
+   `the internal GPSDO manual page <./gpsdo_x3x0.html>`_ to insert the GPSDO. Note that you
+   will need an external GPS antenna connected to the rear GPS ANT connector in order to
+   make use of GPS, although your USRP will still be usable without.
+5. Connect the 1 GigE SFP+ transceiver into the Ethernet port 0 and connect the X300/X310 with
+   your computer.
+6. Connect the power supply and switch on the USRP.
+
+^^^^^^^^^^^^^^^^^^^^
+Network Connectivity
+^^^^^^^^^^^^^^^^^^^^
+
+The next step is to make sure your computer can talk to the USRP. An otherwise unconfigured
+USRP device will have the IP address 192.168.10.2 when using 1GigE.
+It is recommended to directly connect your USRP to the computer at first,
+and to set the IP address on your machine to 192.168.10.1.
+See Section `Setup the host interface`_ on details how to change your machine's IP address.
+
+**Note**: If you are running an automatic IP configuration service such as Network Manager, make
+sure it is either deactivated or configured to not change the network device! This can, in extreme cases,
+lead to you bricking the USRP!
+
+If your network configuration is correct, running ``uhd_find_devices`` will find your USRP
+and print some information about it. You will also be able to ping the USRP by running::
+
+  ping 192.168.10.2
+
+on the command line. At this point, you should also run::
+
+  uhd_usrp_probe --args addr=192.168.10.2
+
+to make sure all of your components (daughterboards, GPSDO) are correctly detected and usable.
+
+^^^^^^^^^^^^^^^^^^^^^
+Updating the firmware
+^^^^^^^^^^^^^^^^^^^^^
+
+If the output from ``uhd_find_devices`` and ``uhd_usrp_probe`` didn't show any warnings, you
+can skip this step. However, if there were warnings regarding version incompatibility, you will
+have to upate the FPGA image before you can start using your USRP.
+
+1. Download the current UHD images. You can use the ``uhd_images_downloader`` script provided
+   with UHD (see also `FPGA Image Flavors`_).
+2. Use the ``usrp_x3xx_fpga_burner`` utility to update the FPGA image. On the command line, run::
+
+          usrp_x3xx_fpga_burner --addr=192.168.10.2 --type=HGS # Since we are using 1GigE, type is HGS
+
+  If you have installed the images to a non-standard location, you might need to run (change the filename according to your device)::
+
+          usrp_x3xx_fpga_burner --addr=192.168.10.2 --fpga-path <path_to_images>/usrp_x310_fpga_HGS.bit
+
+  The process of updating the firmware will take several minutes. Make sure the process of flashing the image does not get interrupted.
+
+See `Load the Images onto the On-board Flash`_ for more details.
+
+When your firmware is up to date, power-cycle the device and re-run ``uhd_usrp_probe``. There should
+be no more warnings at this point, and all components should be correctly detected. Your USRP is now
+ready for development!
+
+--------------
+Hardware Setup
+--------------
+
+^^^^^^^^^^^^^^^^^^^^^^^^^
+Gigabit Ethernet (1 GigE)
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Installing the USRP X300/X310
+:::::::::::::::::::::::::::::
+* Prior to installing the module, the host PC can remain powered on.
+* Plug a 1 Gigabit SFP Transceiver into Ethernet Port 0 on the USRP X300/X310 device.
+* Use the Ethernet cable to connect the SFP+ transciever on the device to the host computer. For maximum throughput, Ettus Research recommends that you connect each device to its own dedicated Gigabit Ethernet interface on the host computer.
+* Connect the AC/DC power supply to the device and plug the supply into a wall outlet.
+* The OS will automatically recognize the device (e.g. when running uhd_find_devices).
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Ten Gigabit Ethernet (10 GigE)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Installing the Host Ethernet Interface
+::::::::::::::::::::::::::::::::::::::
+Ettus Research recommends the Intel Ethernet Converged Network Adapter X520-DA2 interface for communication with the USRP X300/X310 device.
+Installation instructions for this interface are available on the official Intel website.
+
+Installing the USRP X300/X310
+:::::::::::::::::::::::::::::
+* Prior to installing the module, the host PC can remain powered on.
+* Use a 10 Gigabit SFP+ cable to connect Ethernet Port 1 on the USRP X300/X310 device to the host computer. For maximum throughput, Ettus Research recommends that you connect the device to its own dedicated Ten Gigabit, Ettus Research recommended Ethernet interface on the host computer.
+* Connect the AC/DC power supply to the device and plug the supply into a wall outlet.
+* The OS will automatically recognize the device (e.g. when running uhd_find_devices).
+
+The LEDs on the front panel can be useful in debugging hardware and software issues (see Section "Front Panel")
+
+^^^^^^^^^^^^^^^^^^^^^
+PCI Express (Desktop)
+^^^^^^^^^^^^^^^^^^^^^
+*Important Note: The USRP X-Series provides PCIe connectivity over MXI cable.
+We will use the 'MXI' nomenclature for the rest of this manual.*
+
+Installing the PCI Express Interface Kit
+::::::::::::::::::::::::::::::::::::::::
+Follow the instructions listed in the `Set Up Your MXI-Express x4 System <http://www.ni.com/pdf/manuals/371976c.pdf>`_ 
+document to setup the NI PCIe-8371 module.
+
+Installing the USRP X300/X310
+:::::::::::::::::::::::::::::
+* Prior to installing the module, make sure that the PC is powered off.
+* Using a MXI-Express Cable connect the USRP X300/X310 to the NI PCIe-8371.
+* Connect the AC/DC power supply to the device and plug the supply into a wall outlet.
+* Power on the USRP X300/X310 device using the power switch located in the bottom-right corner of the front panel.
+* Power on the PC (The OS automatically recognizes the new device)
+
+NOTE: The USRP device is not hot-pluggable over PCI Express. Any connection changes with only be detected by your 
+computer after a successful reboot.
+
+Troubleshooting
+:::::::::::::::
+Two possible failure modes are your computer not booting when connected to your
+USRP device through MXI-Express, and Windows not properly discovering your
+devices (for example, there is a yellow exclamation point on a PCI to PCI
+bridge in Windows Device Manager, despite drivers for all devices being
+installed). These situations often are due to programming errors in PCI Express
+device configuration of the BIOS. To use this software, you need a MXI-Express
+device that supports Mode 1 operation. 
+Refer to `NI MXI-Express BIOS Compatibility Software Readme <http://download.ni.com/support/softlib//PXI/MXIe%20Compatibility%20Software/1.5.0/readme.html#SupportedHardware>`_ 
+for more information.
+
+The BIOS Compatibility Software can be downloaded for Windows from the `MXI-Express BIOS Compatibility Software <http://www.ni.com/download/mxi-express-bios-compatibility-software-1.5/3764/en/>`_ page
+
+^^^^^^^^^^^^^^^^^^^^
+PCI Express (Laptop)
+^^^^^^^^^^^^^^^^^^^^
+*Important Note: The USRP X-Series provides PCIe connectivity over MXI cable.
+We will use the 'MXI' nomenclature for the rest of this manual.*
+
+Installing the PCI Express Card
+:::::::::::::::::::::::::::::::
+Follow the instructions listed in the “Installing an NI ExpressCard-8360 Host Card” section of the 
+`Set Up Your MXI-Express x1 System <http://www.ni.com/pdf/manuals/373259d.pdf#page=10>`_ 
+document to setup the NI ExpressCard-8360B module.
+
+Installing the USRP X300/X310
+:::::::::::::::::::::::::::::
+Because a laptop computer is not grounded, follow this procedure to safely connect a laptop
+computer to your USRP device.
+
+* Connect the AC/DC power supply to the device and plug the supply into a wall outlet. Ensure that the USRP device is powered off.
+* Touch the NI ExpressCard-8360B and a metal part of the USRP device simultaneously. Do not install the NI ExpressCard-8360B into the laptop computer yet.
+* Connect the cable to the NI ExpressCard-8360B and USRP.
+* Plug the NI ExpressCard-8360B into an available ExpressCard slot. If your laptop computer is already running (or hibernating, suspended, etc) when you install an NI ExpressCard-8360B, you must reboot to detect the USRP. Otherwise, the USRP is detected when you start your computer.
+
+NOTE: The USRP device is not hot-pluggable over PCI Express. Any connection changes will only be detected by your computer after a successful reboot.
+
+--------------------------------
+On-Board JTAG Programmer
+--------------------------------
+The USRP X3x0 includes an on-board JTAG programmer, built into the motherboard.
+To connect to this JTAG device, simply connect your computer to the USB JTAG
+port on the front of the X3x0 device. You may now use the JTAG programmer in
+the same way you would use any other, including:
+
+* `Xilinx Programming Tools (ISE, iMPACT) <http://www.xilinx.com/support/download/index.htm>`_
+* `Xilinx Chipscope <http://www.xilinx.com/tools/cspro.htm>`_
+* `Digilent ADEPT <https://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,828&Prod=ADEPT2>`_
+
+In order to use the JTAG programmer with the Xilinx tools, the Digilent drivers and plugin have to be installed first.
+Although recent versions of ISE ship with the driver, it has to still be manually installed.
+
+Note: Sometimes the ISE shipped versions are newer than the ones available via Digilent's website. It is therefore advisable to
+use the ISE provided plugin and drivers.
+
+To install first locate your ISE installation path (default is /opt/Xilinx/<Version>).
+
+**LINUX**
+::
+
+    sudo <ise install path>/ISE_DS/common/bin/lin64/digilent/install_digilent.sh
+
+Afterwards either reboot or force udev to reload its rules by:
+::
+
+    sudo udevadm control --reload
+
+The USRP-X series device should now be usable with all the tools mentioned above.
+
+--------------------------------
+Load FPGA Images onto the Device
+--------------------------------
+The USRP-X Series device ships with a bitstream pre-programmed in the flash,
+which is automatically loaded onto the FPGA during device power-up. However,
+a new FPGA image can be configured over the PCI Express interface or the
+on-board USB-JTAG programmer. This process can be seen as a "one-time load", in
+that if you power-cycle the device, it will not retain the FPGA image.
+
+Please note that this process is *different* than replacing the FPGA image
+stored in the flash, which will then be automatically loaded the next time the
+device is reset.
+
+^^^^^^^^^^^^^^^^^^
+FPGA Image Flavors
+^^^^^^^^^^^^^^^^^^
+The USRP-X Series devices contains two SFP+ ports for the two Ethernet channels.
+Because the SFP+ ports support both 1 Gigabit (SFP) and 10 Gigabit (SFP+)
+transceivers, several FPGA images are shipped with UHD to determine the
+behavior of the above interfaces.
+
++---------------------+------------------------+------------------------+
+|  FPGA Image Flavor  |  SFP+ Port 0 Interface |  SFP+ Port 1 Interface |
++=====================+========================+========================+
+|  HGS (Default)      |  1 Gigabit Ethernet    |  10 Gigabit Ethernet   |
++---------------------+------------------------+------------------------+
+|  XGS                |  10 Gigabit Ethernet   |  10 Gigabit Ethernet   |
++---------------------+------------------------+------------------------+
+
+FPGA images are shipped in 2 formats:
+
+* **LVBITX**: LabVIEW FPGA configuration bitstream format (for use over PCI Express and Ethernet)
+* **BIT**: Xilinx configuration bitstream format (for use over Ethernet and JTAG)
+
+To get the latest images, simply use the uhd_images_downloader script:
+
+**UNIX:**
+
+::
+
+    sudo uhd_images_downloader
+
+**Windows:**
+
+::
+
+    <path_to_python.exe> <install-path>/bin/uhd_images_downloader.py
+
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use PCI Express to load FPGA images
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+UHD requires a valid LabVIEW FPGA configuration bitstream file (LVBITX) to use the USRP-X Series
+device over the PCI Express bus. LabVIEW FPGA is **NOT** required to use UHD with a USRP-X Series device.
+Because FPGA configuration is a part of normal operation over PCI Express, there is no setup required
+before running UHD.
+
+The **fpga** tag can be set in the optional device args passed to indicate the FPGA image flavor to UHD.
+If the above tag is specified, UHD will attempt to load the FPGA image with the requested flavor from the
+UHD images directory. If the tag is not specified, UHD will automatically detect the flavor of the image
+and attempt to load the corresponding configuration bitstream onto the device. Note that if UHD detects
+that the requested image is already loaded onto the FPGA then it will not reload it. 
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use JTAG to load FPGA images
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The USRP-X Series device features an on-board USB-JTAG programmer that can be accessed on the front-panel
+of the device. The iMPACT tool in the `Xilinx Programming Tools <http://www.xilinx.com/support/download/index.htm>`_ package can be used to load an image over
+the JTAG interface. This can be useful for unbricking devices.
+
+If you have iMPACT installed, you can use the impact_jtag_programmer.sh tool to install images. Make sure your X3x0 is powered on and connected to your computer using the front panel USB JTAG connector (USB 2.0 is fine for this). Then run the tool:
+
+::
+
+    <path_to_uhd_tools>/impact_jtag_programmer.sh --fpga-path=<fpga_image_path>
+
+---------------------------------------
+Load the Images onto the On-board Flash
+---------------------------------------
+To change the FPGA image stored in the on-board flash, the USRP-X Series device
+can be reprogrammed over the network or PCI Express. Once you have programmed an
+image into the flash, that image will be automatically loaded on the FPGA
+during the device boot-up sequence.
+
+**Note:**
+Different hardware revisions require different FPGA images.
+Determine the revision number from the sticker on the rear of the device.
+If you are manually specifying an FPGA path, the utility will not try to
+detect your device information, and you will need to use this number to
+select which image to burn.
+
+**Note:**
+The burner utility will default to using the appropriate BIT file if no custom
+FPGA image path is specified, but it is compatible with BIN, BIT, and LVBITX
+images.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use the burner tool over Ethernet
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+::
+
+    Automatic FPGA path, detect image type:
+    usrp_x3xx_fpga_burner --addr=<IP address>
+
+    Automatic FPGA path, select image type:
+    usrp_x3xx_fpga_burner --addr=<IP address> --type=<HGS or XGS>
+
+    Manual FPGA path:
+    usrp_x3xx_fpga_burner --addr=<IP address> --fpga-path=<path to FPGA image>
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use the burner tool over PCI Express
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+::
+
+    Automatic FPGA path, detect image type:
+    usrp_x3xx_fpga_burner --resource=<NI-RIO resource>
+
+    Automatic FPGA path, select image type:
+    usrp_x3xx_fpga_burner --resource=<NI-RIO resource> --type=<HGS or XGS>
+
+    Manual FPGA path:
+    usrp_x3xx_fpga_burner --resource=<NI-RIO resource> --fpga-path=<path to FPGA image>
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Device recovery and bricking
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+It is possible to put the device into an unusable state by loading bad images ("bricking").
+Fortunately, the USRP-X Series device can be loaded with a good image temporarily using the USB-JTAG interface.
+Once booted into the safe image, the user can once again load images onto the device over Ethernet or PCI Express.
+
+----------------
+Setup Networking
+----------------
+The USRP-X Series only supports Gigabit and Ten Gigabit Ethernet and will not work with a 10/100 Mbps interface.
+
+**Please note that 10 Gigabit Ethernet defines the protocol, not necessary the
+medium. For example, you may use 10GigE over optical with optical SFP+
+transceiver modules.**
+
+^^^^^^^^^^^^^^^^^^^^^^^^
+Setup the host interface
+^^^^^^^^^^^^^^^^^^^^^^^^
+The USRP-X Series communicates at the IP/UDP layer over the Gigabit and Ten Gigabit Ethernet.
+The default IP address for the USRP X300/X310 device depends on the Ethernet Port and interface used. 
+You must configure the host Ethernet interface with a static IP address on the same subnet as the connected 
+device to enable communication, as shown in the following table:
+
++---------------+-------------------------+----------------+----------------+---------------+
+|  Ethernet     | USRP                    |  Default USRP  |  Host Static   | Host Static   |
+| Interface     | Ethernet Port           | IP Address     | IP Address     | Subnet Mask   |
++===============+=========================+================+================+===============+
+|  Gigabit      |  Port 0 (HGS Image)     |  192.168.10.2  | 192.168.10.1   | 255.255.255.0 |
++---------------+-------------------------+----------------+----------------+---------------+
+|  Ten Gigabit  |  Port 1 (HGS/XGS Image) |  192.168.40.2  | 192.168.40.1   | 255.255.255.0 |
++---------------+-------------------------+----------------+----------------+---------------+
+|  Ten Gigabit  |  Port 0 (XGS Image)     |  192.168.30.2  | 192.168.30.1   | 255.255.255.0 |
++---------------+-------------------------+----------------+----------------+---------------+
+
+
+On a Linux system, you can add a static IP address very easily by using the
+'ip' command
+
+::
+
+    sudo ip addr add 192.168.10.1/24 dev <interface>
+
+Note that **<interface>** is usually something like **eth0**.  You can discover the
+names of the network interfaces in your computer by running:
+
+::
+
+    ip addr show
+
+**Note:**
+When using UHD software, if an IP address for the USRP-X Series device is not specified,
+the software will use UDP broadcast packets to locate the USRP-X Series device.
+On some systems, the firewall will block UDP broadcast packets.
+It is recommended that you change or disable your firewall settings.
+
+On many Linux distributions, NetworkManager or similar tools may control the network interface.
+It is important to deactivate these tools for your device before continuing!
+
+^^^^^^^^^^^^^^^
+Setting the MTU
+^^^^^^^^^^^^^^^
+As UHD by default uses receive and transmit frames larger than the standard MTU of 1500 Bytes,
+the NIC needs to be configured to use a larger MTU when used with the USRP X series devices.
+
+::
+
+    sudo ip link set mtu 8192 dev <interface>
+
+Upon initialization UHD will probe for the maximum possible path MTU along the path between the USRP X series device
+and the host, both in receive and transmit direction.
+
+If the network hardware does not support MTUs as large as 8000 Bytes, passing the **send_frame_size** and **receive_frame_size**
+arguments will make UHD use smaller MTUs:
+
+::
+
+    uhd_usrp_probe --args='send_frame_size=<max send MTU>, recv_frame_size=<max receive MTU>'
+
+**Note:** This will most likely have a severe performance penalty.
+
+
+^^^^^^^^^^^^^^^^^^^^^^^^^
+Multiple devices per host
+^^^^^^^^^^^^^^^^^^^^^^^^^
+For maximum throughput, one Ethernet interface per USRP is recommended,
+although multiple devices may be connected via an Ethernet switch.
+In any case, each Ethernet interface should have its own subnet,
+and the corresponding USRP device should be assigned an address in that subnet.
+Example:
+
+**Configuration for USRP-X Series device 0:**
+
+* Ethernet interface IPv4 address: **192.168.10.1**
+* Ethernet interface subnet mask: **255.255.255.0**
+* USRP-X Series device IPv4 address: **192.168.10.2**
+
+**Configuration for USRP-X Series device 1:**
+
+* Ethernet interface IPv4 address: **192.168.110.1**
+* Ethernet interface subnet mask: **255.255.255.0**
+* USRP-X Series device IPv4 address: **192.168.110.2**
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Change the USRP's IP address
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+You may need to change the USRP's IP address for several reasons:
+
+* to satisfy your particular network configuration
+* to use multiple USRP-X Series devices on the same host computer
+* to set a known IP address into USRP (in case you forgot)
+
+To change the USRP's IP address,
+you must know the current address of the USRP,
+and the network must be setup properly as described above.
+Run the following commands:
+
+**UNIX:**
+
+::
+
+    cd <install-path>/lib/uhd/utils
+    ./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr --val=192.168.10.3
+
+**Windows:**
+
+::
+
+    cd <install-path>\lib\uhd\utils
+    usrp_burn_mb_eeprom.exe --args=<optional device args> --key=ip-addr --val=192.168.10.3
+
+---------------------
+Addressing the Device
+---------------------
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Single device configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+In a single-device configuration,
+the USRP device must have a unique IPv4 address on the host computer.
+The USRP can be identified through its IPv4 address, resolvable hostname, NI-RIO resource name or by other means.
+See the application notes on `device identification <./identification.html>`_.
+Use this addressing scheme with the **multi_usrp** interface (not a typo!).
+
+Example device address string representation for a USRP-X Series device with IPv4 address **192.168.10.2**:
+
+::
+
+    addr=192.168.10.2
+
+Example device address string representation for a USRP-X Series device with RIO resource name **RIO0** over PCI Express:
+
+::
+
+    resource=RIO0
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Multiple device configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+In a multi-device configuration,
+each USRP device must have a unique IPv4 address on the host computer.
+The device address parameter keys must be suffixed with the device index.
+Each parameter key should be of the format <key><index>.
+Use this addressing scheme with the **multi_usrp** interface.
+
+* The order in which devices are indexed corresponds to the indexing of the transmit and receive channels.
+* The key indexing provides the same granularity of device identification as in the single device case.
+
+Example device address string representation for 2 USRPs with IPv4 addresses **192.168.10.2** and **192.168.20.2**:
+
+::
+
+    addr0=192.168.10.2, addr1=192.168.20.2
+
+
+----------------------
+Communication Problems
+----------------------
+When setting up a development machine for the first time,
+you may have various difficulties communicating with the USRP device.
+The following tips are designed to help narrow down and diagnose the problem.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+RuntimeError: no control response
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This is a common error that occurs when you have set the subnet of your network
+interface to a different subnet than the network interface of the USRP device.  For
+example, if your network interface is set to **192.168.20.1**, and the USRP device is
+**192.168.10.2** (note the difference in the third numbers of the IP addresses), you
+will likely see a 'no control response' error message.
+
+Fixing this is simple - just set the your host PC's IP address to the same
+subnet as that of your USRP device. Instructions for setting your IP address are in the
+previous section of this documentation.
+
+^^^^^^^^^^^^^^^
+Firewall issues
+^^^^^^^^^^^^^^^
+When the IP address is not specified,
+the device discovery broadcasts UDP packets from each Ethernet interface.
+Many firewalls will block the replies to these broadcast packets.
+If disabling your system's firewall
+or specifying the IP address yields a discovered device,
+then your firewall may be blocking replies to UDP broadcast packets.
+If this is the case, we recommend that you disable the firewall
+or create a rule to allow all incoming packets with UDP source port **49152**.
+
+^^^^^^^^^^^^^^^
+Ping the device
+^^^^^^^^^^^^^^^
+The USRP device will reply to ICMP echo requests ("ping").
+A successful ping response means that the device has booted properly
+and that it is using the expected IP address.
+
+::
+
+    ping 192.168.10.2
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+USRP device not enumerated (Linux)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+UHD requires the RIO device manager service to be running in order to
+communicate with an X-Series USRP over PCIe.  This service is installed as
+a part of the USRP RIO (or NI-USRP) installer. On Linux, the service is not
+started at system boot time, and is left to the user to control. To start it,
+run the following command:
+
+::
+
+    sudo niusrprio_pcie start
+
+If the device still does not enumerate after starting the device manager, make sure that the host computer
+has successfully detected it. You can do so by running the following command:
+
+::
+
+   lspci -k -d 1093:c4c4
+
+A device similar to the following should be detected:
+
+::
+
+   $ lspci -k -d 1093:c4c4
+   04:00.0 Signal processing controller: National Instruments ...
+           Subsystem: National Instruments Device 76ca
+           Kernel driver in use: niusrpriok_shipped
+
+* A USRP X300 should appear with 'Subsystem: National Instruments Device 7736'
+* A USRP X310 should appear with 'Subsystem: National Instruments Device 76ca'
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+USRP device not enumerated (Windows)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+UHD requires the RIO device manager service to be running in order to
+communicate with an X-Series USRP over PCIe.
+This service is installed as a part of the USRP RIO (or NI-USRP) installer. On Windows, it can be found in
+the **Services** section in the Control Panel and it is started at system boot time. To ensure that the 
+service is indeed started, navigate to the Services tag in the Windows Task Manager and ensure that the 
+status of **niusrpriorpc** is "Running".
+
+If the device still does not enumerate after starting the device manager, make sure that the host computer
+has successfully detected it. You can do so by checking if your device shows up in the Windows Device Manager.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Monitor the host network traffic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use Wireshark to monitor packets sent to and received from the device.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Observe Ethernet port LEDs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+When there is network traffic arriving at the Ethernet port, LEDs will light up.
+You can use this to make sure the network connection is correctly set up, e.g.
+by pinging the USRP and making sure the LEDs start to blink.
+
+--------------
+Hardware Notes
+--------------
+
+^^^^^^^^^^^
+Front Panel
+^^^^^^^^^^^
+
+.. image:: ./res/x3x0_fp_overlay.png
+   :scale: 80%
+   :align: left
+
+* **JTAG**: USB connector for the on-board USB-JTAG programmer
+* **RF A Group**
+
+  * **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on daughterboard A
+  * **RX2 LED**: Indicates that data is streaming on the RX2 channel on daughterboard A
+
+* **REF**: Indicates that the external Reference Clock is locked
+* **PPS**: Indicates a valid PPS signal by pulsing once per second
+* **AUX I/O**: Front panel GPIO connector.
+* **GPS**: Indicates that GPS reference is locked
+* **LINK**: Indicates that the host computer is communicating with the device (Activity)
+
+* **RF B Group**
+
+  * **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on daughterboard B
+  * **RX2 LED**: Indicates that data is streaming on the RX2 channel on daughterboard B
+
+* **PWR**: Power switch
+
+^^^^^^^^^^
+Rear Panel
+^^^^^^^^^^
+   
+.. image:: ./res/x3x0_rp_overlay.png
+   :scale: 80%
+   :align: left
+   
+
+* **PWR**: Connector for the USRP-X Series power supply
+* **1G/10G ETH**: SFP+ ports for Ethernet interfaces
+* **REF OUT**: Output port for the exported reference clock
+* **REF IN**: Reference clock input
+* **PCIe x4**: Connector for Cabled PCI Express link
+* **PPS/TRIG OUT**: Output port for the PPS signal
+* **PPS/TRIG IN**: Input port for the PPS signal 
+* **GPS**: Connection for the GPS antenna
+
+^^^^^^^^^^^^^^^^^^
+Ref Clock - 10 MHz
+^^^^^^^^^^^^^^^^^^
+Using an external 10 MHz reference clock, a square wave will offer the best phase
+noise performance, but a sinusoid is acceptable.  The power level of the reference clock cannot exceed +15 dBm.
+
+^^^^^^^^^^^^^^^^^^^^^^
+PPS - Pulse Per Second
+^^^^^^^^^^^^^^^^^^^^^^
+Using a PPS signal for timestamp synchronization requires a square wave signal with the following a 5Vpp amplitude.
+
+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>
+
+^^^^^^^^^^^^^^
+Internal GPSDO
+^^^^^^^^^^^^^^
+Please see the `Internal GPSDO Application Notes <./gpsdo_x3x0.html>`_
+for information on configuring and using the internal GPSDO.
+
+^^^^^^^^^^^^^^^^
+Front Panel GPIO
+^^^^^^^^^^^^^^^^
+
+Connector
+:::::::::
+
+.. image:: ./res/x3x0_gpio_conn.png
+   :scale: 75%
+   :align: left
+
+Pin Mapping
+:::::::::::
+
+* Pin 1:  +3.3V
+* Pin 2:  Data[0]
+* Pin 3:  Data[1]
+* Pin 4:  Data[2]
+* Pin 5:  Data[3]
+* Pin 6:  Data[4]
+* Pin 7:  Data[5]
+* Pin 8:  Data[6]
+* Pin 9:  Data[7]
+* Pin 10: Data[8]
+* Pin 11: Data[9]
+* Pin 12: Data[10]
+* Pin 13: Data[11]
+* Pin 14: 0V
+* Pin 15: 0V
+
+
+Please see the `GPIO API Notes <./gpio_api.html>`_ for information on configuring and using the GPIO bus.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Debugging custom FPGA designs with Xilinx Chipscope
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Xilinx chipscope allows for debugging custom FPGA designs similar to a logic analyzer.
+USRP-X series devices can be used with Xilinx chipscope using the onboard USB JTAG connector.
+
+Further information on how to use Chipscope can be found in the Xilinx Chipscope Pro Software and Cores User Guide (UG029).
+
+-------------
+Miscellaneous
+-------------
+
+^^^^^^^^^^^^^^^^^^^^
+Multiple RX channels
+^^^^^^^^^^^^^^^^^^^^
+There are two complete DDC and DUC DSP chains in the FPGA. In the single channel case, 
+only one chain is ever used. To receive from both channels, the user must set the **RX** or **TX**
+subdevice specification.
+
+In the following example, a TVRX2 is installed.
+Channel 0 is sourced from subdevice **RX1**,
+and channel 1 is sourced from subdevice **RX2** (**RX1** and **RX2** are antenna connectors on the TVRX2 daughterboard).
+
+::
+
+    usrp->set_rx_subdev_spec("A:RX1 A:RX2");
+
+
+^^^^^^^^^^^^^^^^^
+Available Sensors
+^^^^^^^^^^^^^^^^^
+The following sensors are available for the USRP-X Series motherboards;
+they can be queried through the API.
+
+* **ref_locked** - clock reference locked (internal/external)
+* Other sensors are added when the GPSDO is enabled
diff --git a/host/docs/usrp_x3x0_config.rst b/host/docs/usrp_x3x0_config.rst
new file mode 100644
index 000000000..22ef8c595
--- /dev/null
+++ b/host/docs/usrp_x3x0_config.rst
@@ -0,0 +1,297 @@
+========================================================================
+UHD - System Configuration for USRP X3x0 Series
+========================================================================
+
+.. contents:: Table of Contents
+
+------------------------------------------------------------------------
+Configuring your Host PC
+------------------------------------------------------------------------
+
+The USRP X3x0 is capable of delivering very fast sample rates to the host PC,
+and even high-powered desktops can have trouble keeping up at the higher rates.
+You can improve the performance of your host by configuring a number of
+settings that affect the performance of your computer.
+
+These are:
+
+ * Kernel Version
+ * Network Configuration
+ * Power Management Configuration
+ * Real-Time & Priority Scheduling
+ * Building with ORC & Volk
+
+These items are covered in more detail, below.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Kernel Version
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Performance issues may be encountered with Linux kernels earlier than 3.11.
+Ettus Research strongly recommends using kernel version 3.11 or higher for high
+sample rates.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Network Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+When using Ethernet interfaces to communicate with the device, it is necessary
+to configure a number of facets regarding your network connection.
+
+Configuring NetworkManager
+-------------------------------------
+Fedora and Ubuntu both use NetworkManager to manage network connections.
+Unfortunately, NetworkManager often tries to take control of a connection and
+will disconnect the interface.
+
+You should open your NetworkManager configuration and tell it to ignore the
+network interface you are using. **This is not the same as simply setting
+a static IP address.** You *must* tell NetworkManager to ignore the interface.
+
+Configuring the Socket Buffers
+-------------------------------------
+It is necessary to increase the maximum size of the socket buffers to avoid
+potential overflows and underruns at high sample rates.  Add the following
+entries into /etc/sysctl.conf (root privileges required):
+
+::
+
+    net.core.rmem_max=33554432
+    net.core.wmem_max=33554432
+
+Either restart the system or issue the following commands:
+
+::
+
+    sudo sysctl -w net.core.rmem_max=33554432
+    sudo sysctl -w net.core.wmem_max=33554432
+
+
+Configuring the MTU
+-------------------------------------
+In order to achieve maximum performance, we recommend setting the MTU size to
+9000 for 10 GigE and 1500 for 1 GigE. It is possible to use smaller MTUs, but this
+can affect performance. With some NICs, setting the MTU too high can also cause issues.
+To set the MTU to 9000, you can use the following command:
+
+::
+
+    sudo ifconfig <interface> mtu 9000 # For 10 GigE
+    sudo ifconfig <interface> mtu 1500 # For 1 GigE
+
+Using these MTUs will set the frame sizes for UHD communication to 8000 and 1472,
+respectively.
+
+In some cases, specifying the frame size manually by adding the argument
+"<send/recv>_frame_size=1472" can solve issues. Note that a frame size of 1472 will limit
+the available sampling rate, although this is not a problem on 1 GigE.
+
+
+Configuring the Firewall
+-------------------------------------
+Many Linux distributions come installed with a Firewall, by default. The
+Firewall will often interfere with your ability to communicate with your USRP.
+You should configure your firewall to "trust" the interface you are using.
+Setting this properly depends on your OS and firewall configuration method.
+
+Interface Configuration File (Fedora)
+-------------------------------------
+On Fedora systems, you can configure the network interface mostly from one
+place (with the exception of the socket buffers). Each interface on your system
+should have a file in:
+
+::
+
+    /etc/sysconfig/network-scripts/
+
+As an example, if your 1GigE interface is "em1", your "ifcfg-em1" configuration
+file should look something like this, when configured for use with a USRP X3xx:
+
+::
+
+    TYPE="Ethernet"
+    BOOTPROTO="none"
+    IPADDR0="192.168.10.1"
+    DEFROUTE="yes"
+    IPV4_FAILURE_FATAL="no"
+    IPV6INIT="no"
+    IPV6_FAILURE_FATAL="no"
+    NAME="em1"
+    UUID="<specific to your device>"
+    ONBOOT="no"
+    HWADDR"<specific to your device>"
+    PEERDNS="yes"
+    PEERROUTES="yes"
+    ZONE="trusted"
+    MTU="9000"
+    NM_MANAGED="no"
+
+The above file was generated and modified on a "Fedora 20" system.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Power Management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Power management on the host system attempts to save power by reducing clock
+frequencies or even powering off devices while not in use.  This can lead to
+significant performance issues when trying to operate at high sample rates.
+Ettus Research strongly recommends disabling all power management.
+
+
+Setting the CPU Governors
+-------------------------------------
+In Linux, the CPU governors dictate the frequency at which the CPU operates and
+attempt to reduce the CPU frequencies at certain times to save power.  When
+running at high sample rates, reduction of CPU frequencies can cause
+significant performance issues.  To prevent those issues, set the governor to
+"performance".
+
+**Ubuntu:**
+1. Install cpufrequtils:
+
+::
+
+    sudo apt-get install cpufrequtils
+
+2. Edit /etc/init.d/cpufrequtils and set GOVERNOR="performance" on the appropriate line (run as root):
+
+::
+
+    sed s/^GOVERNOR=.*$/GOVERNOR=\"performance\"/g /etc/init.d/cpufrequtils > /etc/init.d/cpufrequtils
+
+3. Restart cpufrequtils:
+
+::
+
+    sudo /etc/init.d/cpufrequtils restart
+
+**Fedora:**
+
+::
+
+    sudo cpupower frequency-set -g performance
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Real-Time & Priority Scheduling
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Enabling real-time and priority scheduling can improve the total processing
+throughput of your application. Priority scheduling should be enabled for UHD,
+and real-time scheduling can be enabled by your application.
+
+Thread Priority Scheduling with UHD
+-------------------------------------
+For information regarding how to enable priority scheduling for UHD on your
+system, please see the `General UHD Notes <./general.html#threading-notes>`_.
+
+Real-Time Scheduling in your Application
+----------------------------------------
+Please note that turning on real-time scheduling in your application **may lock
+up your computer** if the processor cannot keep up with the application. You
+should generally avoid using real-time scheduling unless you need to.
+
+Real-time scheduling is enabled via different methods depending on your
+application and operating system. In GNU Radio Companion, it can be turned on in
+each individual flowgraph.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Building with ORC & Volk
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Especially when running high-performance applications, processing performance
+can be dramatically improved by SIMD instructions. UHD uses ORC to provide SIMD
+capability, and GNU Radio includes a SIMD library called "Volk". These should
+both be used to guarantee optimum performance.
+
+Compiling UHD with ORC
+-------------------------------------
+ORC, the `Oil Runtime Compiler <http://code.entropywave.com/orc/>`_, is
+a third-party compiler that UHD uses to create efficient SIMD code for your
+particular computer. ORC is generally easily installed from your OS's package
+manager.
+
+On Fedora:
+
+::
+
+    $ sudo yum update; sudo yum install orc-compiler orc-devel
+
+On Ubuntu:
+
+::
+
+    $ sudo apt-get update; sudo apt-get install liborc-<version> liborc-<version>-dev
+
+After installing ORC, when building UHD from source, you should see "ORC" as
+one of the configured UHD components.
+
+::
+
+    -- ######################################################
+    -- # UHD enabled components                              
+    -- ######################################################
+    --   * LibUHD
+         <cut for brevity>
+    --   * ORC
+
+Compiling GNURadio with Volk
+-------------------------------------
+If you are using GNURadio to build applications, you should compile GNURadio
+with Volk. For instructions on how to do this, `refer to the GNURadio wiki
+<http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk>`_.
+
+
+------------------------------------------------------------------------
+Host PC Hardware Selection
+------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Motherboard
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Testing has shown that some motherboards do not provide enough PCIe bus
+bandwidth to support higher sample rates.  Motherboards with PCIe 3.0 are
+required and the PCIe architecture of the motherboard should be carefully
+considered.  Slots with dedicated PCIe lanes should be used for PCIe or 10GbE
+cards that will be connected to the X3x0 device.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+10GbE NIC
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Intel or Myricom 10GbE NICs are recommended.  Mellanox, SolarFlare, and Chelsio
+10GbE NICs are not currently recommended.  The Ethernet card should be plugged
+into the slot that has the most direct connection with the CPU (PCIe lanes are
+not shared with another slot).  Refer to the motherboard manual for more
+information on PCIe architecture.
+
+------------------------------------------------------------------------
+Troubleshooting Performance Issues
+------------------------------------------------------------------------
+The output on the host console provides indicators of performance issues in the
+form of single upper-case letters.  The following table lists the letters,
+their meanings, and possible causes:
+
+========= ====================== ====================================================================
+Indicator Meaning                Possible Causes
+========= ====================== ====================================================================
+O         Overflow on RX         - Data is not being consumed by user's application fast enough.
+                                 - CPU governor or other power management not configured correctly.
+D         Dropped packet on RX   - Network hardware failure.  (Check host NIC, cable, switch, etc...)
+                                 - PCIe bus on host cannot sustain throughput. (Check ethtool -S <interface>).
+                                 - CPU governor or other power management not configured correctly.
+                                 - Frame size might not work with the current NIC's MTU.
+U         Underflow on TX        - Samples are not being produced by user's application fast enough.
+                                 - CPU governor or other power management not configured correctly.
+L         Late packet            - Samples are not being produced by user's application fast enough.
+          (usually on MIMO TX)   - CPU governor or other power management not configured correctly.
+                                 - Incorrect/invalid time_spec provided.
+S         Sequence error on TX   - Network hardware failure.  (Check host NIC, cable, switch, etc...)
+                                 - Frame size might not work with the current NIC's MTU.
+========= ====================== ====================================================================
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Troubleshooting Ethernet Issues
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+1. First, check 'ifconfig <interface>' to see if there are any errors reported
+   on the interface.  If there are errors, it is most likely a network hardware
+   problem.
+2. Next, check the output of 'ethtool -S <interface>'.  The output is
+   driver-specific, but may give important clues as to what may be happening.
+   For example, a high value on rx_missed_errors for an Intel NIC indicates
+   that the bus (i.e. PCIe) is not keeping up.
+3. Finally, Wireshark can be used to validate the traffic between the host and
+   device and make sure there is no unwanted traffic on the interface.
+
diff --git a/host/docs/usrp_x3xx_fpga_burner.1 b/host/docs/usrp_x3xx_fpga_burner.1
new file mode 100644
index 000000000..3a8a27e69
--- /dev/null
+++ b/host/docs/usrp_x3xx_fpga_burner.1
@@ -0,0 +1,65 @@
+.TH "usrp_x3xx_fpga_burner" 1 "3.7.0" UHD "User Commands"
+.SH NAME
+usrp_x3xx_fpga_burner - USRP X-Series FPGA Burner
+.SH DESCRIPTION
+Burn an FPGA image onto a connected USRP X-Series device. The program takes
+two main arguments. The first is either an IP address or an NI-RIO resource 
+to decide the method of loading the FPGA image. The other is either the
+type of image to burn, in which case the program will choose the default image
+of that type and model, or a custom FPGA image path.
+.SH SYNOPSIS
+.B  usrp_x3xx_fpga_burner [OPTIONS]
+.SH OPTIONS
+.IP "Device IP Address:"
+--addr=\fI"Address"\fR
+. IP "Device NI-RIO Resource:"
+--resource=\fI"Resource"\fR
+. IP "RPC Port:"
+--rpc-port=\fI"Port"\fR (default=5444)
+. IP "Image Type (1G, HGS, or XGS):"
+--type=\fI"Type"\fR
+. IP "Custom FPGA path:"
+--fpga-path=\fI"Path"\fR
+. IP "Initialize USRP with image currently burned onto device (Ethernet only):"
+--configure
+. IP "Verify image during Ethernet burn (takes longer):"
+--verify
+. IP "List connected USRP X-Series devices:"
+--list
+.IP "This help information:"
+--help
+.SH EXAMPLES
+.SS Burning a 1-Gigabit image over Ethernet
+.sp
+usrp_x3xx_fpga_burner --addr=192.168.10.2 --type=1G
+.SS Burning a Hybrid image over PCIe
+usrp_x3xx_fpga_burner --resource=RIO0 --type=HGS
+.SS Burning a custom FPGA image over Ethernet
+usrp_x3xx_fpga_burner --addr=192.168.10.2 --fpga=path="custom_image.bit"
+.ft
+.fi
+.SH SEE ALSO
+UHD documentation:
+.B http://files.ettus.com/uhd_docs/manual/html/index.html
+.LP
+GR-UHD documentation:
+.B http://gnuradio.org/doc/doxygen/page_uhd.html
+.LP
+Other UHD programs:
+.sp
+uhd_images_downloader(1) usrp2_card_burner(1) usrp_n2xx_simple_net_burner(1)
+.SH AUTHOR
+This manual page was written by Nicholas Corgan
+for the Debian project (but may be used by others).
+.SH COPYRIGHT
+Copyright (c) 2014 Ettus Research LLC
+.LP
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+.LP
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.