Merge branch 'master' into ashish/vivado

8 files changed, 122 insertions, 9 deletions

diff --git a/host/docs/build.dox b/host/docs/build.dox
index 01209bc3e..e08bc6bf3 100644
--- a/host/docs/build.dox
+++ b/host/docs/build.dox
@@ -61,7 +61,7 @@ Other compilers (or lower versions) may work, but are unsupported.
 - **Minimum Version:** 1.0
 - **Usage:** build time + runtime (optional)
 - **Download URL:** http://sourceforge.net/projects/libusb/files/libusb-1.0/
-- **Download URL (Windows):** https://github.com/libusbx/libusbx
+- **Download URL (Windows):** https://github.com/libusb/libusb
 
 ### Python
 
@@ -148,7 +148,7 @@ so we must manually tell CMake how to locate the LibUSB header and lib.
 - Recommend the static `libusb-1.0.lib` to simplify runtime dependencies.
 - Check the box to enable USB support, click "Configure" and "Generate".
 
-<b>Note:</b> On Windows, LibUSBx is required to use most USB3 controllers.
+<b>Note:</b> On Windows, LibUSB v1.0.19 is required to use most USB3 controllers.
 
 \subsection build_in_msvc Build the project in MSVC
 - Open the generated project file in MSVC.
@@ -208,7 +208,7 @@ the UHDConfig.cmake file that gets installed along with the UHD libraries.
 Using CMake, UHD can be built as a static library by switching on
 `ENABLE_STATIC_LIBS`.
 
-    cmake -DENABLE_STATIC_LIBS=On <path to UHD source>
+    cmake -DENABLE_STATIC_LIBS=ON <path to UHD source>
 
 When linking the static library, you must ensure that the library
 is loaded in its entirety, otherwise global objects aren't initialized
diff --git a/host/docs/dboards.dox b/host/docs/dboards.dox
index 3d6866a42..812a3a09e 100644
--- a/host/docs/dboards.dox
+++ b/host/docs/dboards.dox
@@ -372,6 +372,10 @@ Sensors:
 -   **rssi**: float for measured RSSI in dBm
 -   **temperature**: float for measured temperature in degC
 
+\subsection dboards_e300 E310 MIMO XCVR board
+
+Please refer to \ref e3x0_dboard_e310.
+
 \subsection dboards_dbsrxmod DBSRX - Modifying for other boards that USRP1
 
 Due to different clocking capabilities, the DBSRX will require
diff --git a/host/docs/e3x0_imu_demo.png b/host/docs/e3x0_imu_demo.png
new file mode 100644
index 000000000..cbf156224
--- /dev/null
+++ b/host/docs/e3x0_imu_demo.png
diff --git a/host/docs/images.dox b/host/docs/images.dox
index bd2ffacf6..1ff9fa7c3 100644
--- a/host/docs/images.dox
+++ b/host/docs/images.dox
@@ -85,7 +85,7 @@ 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, USRP B2x0
+- Xilinx ISE 14.7: USRP X3x0 Series, USRP B2x0
 
 See `<uhd-repo-path>/fpga/usrp3/top/`.
 
diff --git a/host/docs/uhd.dox b/host/docs/uhd.dox
index 949c710b1..fcd0a25b0 100644
--- a/host/docs/uhd.dox
+++ b/host/docs/uhd.dox
@@ -12,6 +12,7 @@ Some additional pages on developing UHD are also available here:
 \li \subpage page_coding
 \li \subpage page_converters
 \li \subpage page_stream
+\li \subpage page_rtp
 
 */
 // vim:ft=doxygen:
diff --git a/host/docs/usrp_b200.dox b/host/docs/usrp_b200.dox
index 6ee2f3445..9d3550b98 100644
--- a/host/docs/usrp_b200.dox
+++ b/host/docs/usrp_b200.dox
@@ -36,15 +36,40 @@ images:
 
 The master clock rate feeds the RF frontends and the DSP chains. Users
 may select non-default clock rates to acheive integer decimations or
-interpolations in the DSP chains. The default master clock rate defaults
-to 32 MHz, but can be set to any rate between 5 MHz and 61.44 MHz.
+interpolations in the DSP chains. The clock rate can be set to any value
+between 5 MHz and 61.44 MHz (or 30.72 MHz for dual-channel mode).
+Note that rates above 56 MHz are possible, but not recommended.
 
 The user can set the master clock rate through the usrp API call
 uhd::usrp::multi_usrp::set_master_clock_rate(), or the clock rate can be set through the
-device arguments, which many applications take: :
+device arguments, which many applications take:
 
     uhd_usrp_probe --args="master_clock_rate=52e6"
 
+The property to control the master clock rate is a double value, called `tick_rate`.
+
+\subsection b200_auto_mcr Automatic Clock Rate Setting
+
+The default clock rate setting is to automatically set a clock rate
+depending on the requested sampling rate. The automatic clock rate selection
+is disabled when either `master_clock_rate` is given in the device initialization
+arguments, or when uhd::usrp::multi_usrp::set_master_clock_rate() is called.
+
+Note that the master clock rate must be an integer multiple of the sampling
+rate. If a master clock rate is chosen for which this condition does not
+hold, a warning will be displayed and a different sampling rate is used internally.
+
+Nevertheless, there are multiple valid values for the master clock rate
+for most sampling rates. The auto clock rate selection attempts to use
+the largest possible clock rate as to enable as many half-band filters
+as possible. Expert users might have cases where a more fine-grained
+control over the resampling stages is required, in which case manually
+selecting a master clock rate might be more suitable than the automatic
+rate.
+
+The property to dis- or enable the auto tick rate is a boolean value,
+`auto_tick_rate`.
+
 \section b200_fe RF Frontend Notes
 
 The B200 features an integrated RF frontend.
diff --git a/host/docs/usrp_e3x0.dox b/host/docs/usrp_e3x0.dox
index 38bf8d926..b55fa1054 100644
--- a/host/docs/usrp_e3x0.dox
+++ b/host/docs/usrp_e3x0.dox
@@ -191,7 +191,7 @@ builds)
  $ bitbake gnuradio-dev-image
 \endcode
 
-When this completes, the files needed to create the sd card are in
+When this completes, the files needed to create the SD card are in
 `tmp-glibc/deploy/images/ettus-e300`
 
 -# Build the toolchain.
@@ -537,7 +537,7 @@ usrp->set_rx_subdev_spec("A:A A:B");
 The following sensors are available for the USRP-E Series motherboards;
 they can be queried through the API.
 
-- **fe_locked** - rx / tx frontend pll locked
+- **fe_locked** - rx / tx frontend PLL locked
 - **temp** - processor temperature value
 - **gps_time** and **gps_locked** sensors are added when the GPS is found
 
diff --git a/host/docs/vrt_chdr.dox b/host/docs/vrt_chdr.dox
new file mode 100644
index 000000000..8ab177b21
--- /dev/null
+++ b/host/docs/vrt_chdr.dox
@@ -0,0 +1,83 @@
+/*! \page page_rtp Radio Transport Protocols
+
+\tableofcontents
+
+Radio transport protocols are used to exchange samples (or other items) between host and devices.
+If one were to sniff Ethernet traffic between a USRP and a PC, the packets would conform to a
+radio transport protocol.
+
+For USRP devices, two radio transport protocols are relevent: VRT (the VITA Radio Transport protocol)
+and CVITA (compressed VITA), also known as CHDR. Generation-3 devices and the B200 use CHDR, the rest
+use VRT.
+
+\section rtp_vrt VRT
+
+VRT is an open protocol defined by the VITA-49 standard. It was designed for interoperability,
+and to allow different device types to work with different software stacks.
+
+VRT is a very verbose standard, and only a subset is implemented in UHD/USRPs.
+The full standard is available from the VITA website: http://www.vita.com .
+
+
+\section rtp_chdr CVITA (CHDR)
+
+For the third generation of Ettus devices, a new type transport protocol was designed.
+It reduces the complexity of the original standard and uses a fixed-length 64-Bit header
+for everything except the timestamp. Because this is a "compressed" form of VITA, it
+was dubbed "Compressed VITA" (CVITA). The compressed header is called CHDR, which is why
+the protocol is often called CHDR itself (pronounced like the cheese "cheddar").
+
+By compressing all information into a 64-bit line, the header can efficiently be parsed
+in newer FPGAs, where the common streaming protocol is 64-Bit AXI. The first line in a
+packet already provides all necessary information to proceed.
+
+Some CHDR-specific functions can be found in: uhd::transport::vrt::chdr.
+
+The form of a CVITA packet is the following:
+
+Address (Bytes) | Length (Bytes) | Payload
+----------------|----------------|----------------------------
+0               | 8              | Compressed Header (CHDR)
+8               | 8              | Fractional Time (Optional!)
+8/16            | -              | Data
+
+If there is no timestamp present, the data starts at address 8, otherwise, it starts at 16.
+
+The 64 Bits in the compressed header have the following meaning:
+
+Bits   | Meaning
+-------|--------------------------------------------------
+63:62  | Packet Type
+61     | Has fractional time stamp (1: Yes)
+60     | End-of-burst or error flag
+59:48  | 12-bit sequence number
+47:32  | Total packet length in Bytes
+31:0   | Stream ID (SID)
+
+
+The packet type is determined mainly by the first two bits, although
+the EOB or error flag are also taken into consideration:
+
+Bit 63 | Bit 62 | Bit 60 | Packet Type
+-------|--------|--------|--------------
+0      | 0      | 0      | Data
+0      | 0      | 1      | Data (End-of-burst)
+0      | 1      | 0      | Flow Control
+1      | 0      | 0      | Command Packet
+1      | 1      | 0      | Command Response
+1      | 1      | 1      | Command Response (Error)
+
+\section vrt_tools Tools
+
+For CHDR, we provide a Wireshark dissector under tools/chdr_dissector. It can be used
+for Ethernet links as well as USB (e.g., for the B210).
+
+\section vrt_code Code
+
+Relevent code sections for the radio transport layer are:
+* uhd::transport::vrt - Namespace for radio transport protocol related functions and definitions
+* uhd::transport::vrt::chdr - Sub-namespace specifically for CVITA/CHDR
+* uhd::sid_t - Datatype to represent SIDs
+
+*/
+// vim:ft=doxygen: