5 files changed, 119 insertions, 6 deletions
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/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 bd79c4470..1da7f2aee 100644
--- a/host/docs/usrp_b200.dox
+++ b/host/docs/usrp_b200.dox
@@ -38,15 +38,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 2965f4dad..91682f0b9 100644
--- a/host/docs/usrp_e3x0.dox
+++ b/host/docs/usrp_e3x0.dox
@@ -189,9 +189,9 @@ builds)
  $ export MACHINE="ettus-e300"
  $ bitbake gnuradio-dev-image
 \endcode
-When this completes, the files needed to create the sd card are in
-`tmp-glibc/deploy/images/ettus-e300`. See \ref e3x0_upgrade_sd_card for instructions to write the image to your sd card.
 
+When this completes, the files needed to create the SD card are in
+`tmp-glibc/deploy/images/ettus-e300`
 
 -# Build the toolchain.
 \code{.sh}
@@ -545,7 +545,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: