5 files changed, 158 insertions, 13 deletions
diff --git a/host/docs/CMakeLists.txt b/host/docs/CMakeLists.txt
index 5926e062e..88afb9c98 100644
--- a/host/docs/CMakeLists.txt
+++ b/host/docs/CMakeLists.txt
@@ -30,6 +30,7 @@ SET(manual_sources
     transport.rst
     usrp1.rst
     usrp2.rst
+    usrp_b1xx.rst
     usrp_e1xx.rst
 )
 
diff --git a/host/docs/general.rst b/host/docs/general.rst
index ff85fb0f9..cc00fc0f9 100644
--- a/host/docs/general.rst
+++ b/host/docs/general.rst
@@ -61,6 +61,42 @@ Pseudo-code for dealing with settling time after tuning on receive:
     usrp->issue_stream_command(...);
 
 ------------------------------------------------------------------------
+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 detects the overflow, it prints an "O" to stdout,
+and pushes an inline message packet into the receive stream.
+
+**Network-based devices**:
+The host does not back-pressure the receive stream.
+When the kernel's socket buffer becomes full, it will drop subsequent packets.
+UHD detects the overflow as a discontinuity in the packet's sequence numbers,
+and muxes an inline message packet into the receive stream.
+
+**Other devices**:
+The host back-pressures the receive stream.
+Therefore, overflows always occur in the device itself.
+When the device's internal buffers become full, streaming is shutoff,
+and an inline message packet is sent to the host.
+If the device was in continuous streaming mode,
+the UHD will automatically restart streaming.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Underflow notes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+When transmitting, the device consumes samples at a constant rate.
+Underflow occurs when the host does not produce data fast enough.
+When the UHD detects underflow, it prints an "U" to stdout,
+and pushes a message packet into the async message stream.
+
+------------------------------------------------------------------------
 Threading notes
 ------------------------------------------------------------------------
 
@@ -114,3 +150,21 @@ 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.
+Make "register_handler" your first call into UHD:
+
+::
+
+    #include <uhd/utils/msg.hpp>
+
+    void my_handler(uhd::msg::type_t type, const std::string &msg){
+        //handle the message...
+    }
+
+    uhd::msg::register_handler(&my_handler);
diff --git a/host/docs/index.rst b/host/docs/index.rst
index 40fe64599..b4ebdad6c 100644
--- a/host/docs/index.rst
+++ b/host/docs/index.rst
@@ -24,6 +24,7 @@ Application Notes
 * `USRP1 Application Notes <./usrp1.html>`_
 * `USRP2 Application Notes <./usrp2.html>`_
 * `USRP-N2XX Series Application Notes <./usrp2.html>`_
+* `USRP-B1XX Series Application Notes <./usrp_b1xx.html>`_
 * `USRP-E1XX Series Application Notes <./usrp_e1xx.html>`_
 * `Daughterboard Application Notes <./dboards.html>`_
 * `Transport Application Notes <./transport.html>`_
diff --git a/host/docs/sync.rst b/host/docs/sync.rst
index 152349990..9284d8e33 100644
--- a/host/docs/sync.rst
+++ b/host/docs/sync.rst
@@ -22,23 +22,44 @@ USRPs take two reference signals in order to synchronize clocks and time:
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Provide reference signals
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Most USRPs have front panel SMA connectors to source these reference signals.
+USRPs have two primary means of providing synchronization:
+
+**Method 1:**
+Connect the front panel SMA connectors to the reference sources.
 Typically, these signals are provided by an external GPSDO.
-Some USRP models can provide these signals from an optional internal GPSDO.
-For users generating their own signals,
+However, some USRP models can provide these signals from an optional internal GPSDO.
+
+**Method 2:**
+Use the MIMO Expansion cable to share reference sources (USRP2 and N-Series).
+The MIMO cable can be used synchronize one device to another device.
+Users of the MIMO cable may use method 1 to synchronize multiple pairs of devices.
+
+**Note:**
+For users generating their own signals for the external SMA connectors,
 the pulse-per-second should be clocked from the 10MHz reference.
 See the application notes for your device for specific signal requirements.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Set the clock configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In order to synchronize to an external clock, configure the USRP device
-using the "external" clock configuration:
+In order to synchronize to an external clock,
+configure the USRP device using the "external" clock configuration:
 
 ::
 
     usrp->set_clock_config(uhd::clock_config_t::external());
 
+Sometimes the delay on the PPS signal will cause it to arrive inside the timing
+margin the FPGA sampling clock, causing PPS edges to be separated by less or
+more than 100million cycles of the FPGA clock. If this is the case,
+you can change the edge reference of the PPS clock with the clock_config_t:
+
+::
+
+    uhd::clock_config_t clock_config = uhd::clock_config_t::external();
+    clock_config.pps_polarity = uhd::clock_config_t::PPS_NEG;
+    usrp->set_clock_config(clock_config);
+
 ------------------------------------------------------------------------
 Synchronizing the device time
 ------------------------------------------------------------------------
@@ -48,14 +69,6 @@ or to an absolute time such as GPS time or UTC time.
 For the purposes of synchronizing devices,
 it doesn't matter what time you initialize to when using set_time_next_pps(...).
 
-Some GPSDOs synchronize their PPS with the rising edge of the 10MHz clock,
-and some synchronize with the falling edge of the clock.
-You should find out which edge your GPSDO uses,
-and then pass that in as an argument to set_time_next_pps(...).
-
-Here are two examples of how to set the PPS time to synchronize USRPs
-to a clock source.
-
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Method 1 - poll the USRP time registers
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/host/docs/usrp_b1xx.rst b/host/docs/usrp_b1xx.rst
new file mode 100644
index 000000000..2f7385070
--- /dev/null
+++ b/host/docs/usrp_b1xx.rst
@@ -0,0 +1,76 @@
+========================================================================
+UHD - USRP-B1XX Series Application Notes
+========================================================================
+
+.. contents:: Table of Contents
+
+------------------------------------------------------------------------
+Specify a non-standard image
+------------------------------------------------------------------------
+The UHD will automatically select the USRP B-Series images from the installed images package.
+The image selection can be overridden with the "fpga" and "fw" device address parameters.
+
+Example device address string representations to specify non-standard images:
+
+::
+
+    fpga=usrp_b100_fpga_firmware.bin
+
+    -- OR --
+
+    fw=usrp_b100_fw_firmware.ihx
+
+------------------------------------------------------------------------
+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 rates are:
+
+* 64MHz - maximum rate of the codec chip
+* 61.44MHz - good for UMTS/WCDMA applications
+* 52Mhz - good for GSM applications
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Set 61.44MHz - uses external VCXO
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+To use the 61.44MHz clock rate, the USRP embedded will require two jumpers to be moved.
+
+* J16 is a two pin header, remove the jumper (or leave it on pin1 only)
+* J15 is a three pin header, move the jumper to (pin1, pin2)
+
+**Note:** See instructions below to communicate the desired clock rate into the UHD.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Set other rates - uses internal VCO
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+To use other clock rates, the jumpers will need to be in the default position.
+
+* J16 is a two pin header, move the jumper to (pin1, pin2)
+* J15 is a three pin header, move the jumper to (pin2, pin3)
+
+To communicate the desired clock rate into the UHD,
+specify the a special device address argument,
+where the key is "master_clock_rate" and the value is a rate in Hz.
+Example:
+::
+
+    uhd_usrp_probe --args="master_clock_rate=52e6"
+
+------------------------------------------------------------------------
+OS specific notes
+------------------------------------------------------------------------
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Linux - setup udev
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+On Linux, udev handles USB plug and unplug events.
+The following commands create a udev rule for the B100
+so that non-root users may access the device:
+
+::
+
+    echo 'ACTION=="add", BUS=="usb", SYSFS{idVendor}=="2500", SYSFS{idProduct}=="0001", MODE:="0666"' > tmpfile
+    sudo chown root.root tmpfile
+    sudo mv tmpfile /etc/udev/rules.d/10-usrp_b100.rules
+    sudo udevadm control --reload-rules