Merge branch 'master' of ettus.sourcerepo.com:ettus/uhdpriv into usrp_e

Conflicts:
	host/examples/rx_timed_samples.cpp

5 files changed, 92 insertions, 28 deletions

diff --git a/host/docs/build.rst b/host/docs/build.rst
index f5a8dac8d..108d8dc8b 100644
--- a/host/docs/build.rst
+++ b/host/docs/build.rst
@@ -97,7 +97,10 @@ Generate Makefiles with cmake
     cd build
     cmake ../
 
-For a custom prefix, use: cmake -DCMAKE_INSTALL_PREFIX=<prefix> ../
+**Notes:**
+
+* For a custom prefix, use: cmake -DCMAKE_INSTALL_PREFIX=<prefix> ../
+* On some Fedora 64-bit systems, cmake has trouble finding boost, use: cmake -DBOOST_LIBRARYDIR=/usr/lib64 ../
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Build and install
@@ -138,6 +141,7 @@ Generate the project with cmake
 Build the project in MSVC
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 * Open the generated project file in MSVC.
+* Change the build type from "Debug" to "Release".
 * Select the build all target, right click, and choose build.
 * Select the install target, right click, and choose build.
 
diff --git a/host/docs/coding.rst b/host/docs/coding.rst
index 689667f30..84f9abf3e 100644
--- a/host/docs/coding.rst
+++ b/host/docs/coding.rst
@@ -5,8 +5,11 @@ UHD - Coding to the API
 .. contents:: Table of Contents
 
 ------------------------------------------------------------------------
-Low-Level: The device API
+Various API interfaces
 ------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Low-Level: The device API
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 A device is an abstraction for hardware that is connected to the host system.
 For a USRP, this means that the motherboard and everything on it would be considered to be a "device".
 The device API provides ways to:
@@ -17,12 +20,12 @@ The device API provides ways to:
 * Streaming samples with metadata into and out of the device.
 * Set and get properties on the device object.
 
-See the documentation in device.hpp for reference.
+See the documentation in *device.hpp* for reference.
 
-------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 High-Level: The simple usrp
-------------------------------------------------------------------------
-The goal of the simple usrp is to wrap high level functions around the device properties.
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The goal of the simple usrp API is to wrap high level functions around the device properties.
 The simple usrp provides a fat interface to access the most common properties.
 The simple usrp provides ways to:
 
@@ -35,14 +38,32 @@ The simple usrp provides ways to:
 * Set the usrp time registers.
 * Get the underlying device (as discussed above).
 
-It is recommended that users code to the simple_usrp api when possible.
-See the documentation in usrp/simple_usrp.hpp for reference.
+See the documentation in *usrp/simple_usrp.hpp* for reference.
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+High-Level: The mimo usrp
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The mimo usrp API provides a wrapper around a device that represents several motherboards.
+This API provides convenience calls just like the simple usrp,
+however the calls either work across all channels in the configuration,
+or take a channel argument to specify which channel to configure.
+The mimo usrp provides ways to:
+
+* Set and get the sample rate across all channels.
+* Issue a stream command across all channels.
+* Set the time registers across all channels.
+* Set and get individual daughterboard gains.
+* Set and get individual daughterboard antennas.
+* Tune individual DSPs and daughterboards.
+* Get the underlying device (as discussed above).
+
+See the documentation in *usrp/mimo_usrp.hpp* for reference.
 
 ------------------------------------------------------------------------
 Integrating custom hardware
 ------------------------------------------------------------------------
 Creators of custom hardware can create drivers that use the UHD API.
-These drivers can be built as dynamically lodable modules that the UHD will load at runtime.
+These drivers can be built as dynamically loadable modules that the UHD will load at runtime.
 For a module to be loaded at runtime, it must be found in the UHD_MODULE_PATH environment variable.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/host/docs/dboards.rst b/host/docs/dboards.rst
index e14f49933..9c496ebee 100644
--- a/host/docs/dboards.rst
+++ b/host/docs/dboards.rst
@@ -23,7 +23,7 @@ The Basic RX and LFRX boards have 3 subdevices:
 
 The boards have no tunable elements or programmable gains.
 Though the magic of aliasing, you can down-convert signals
-greater than the nyquist rate of the ADC.
+greater than the Nyquist rate of the ADC.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Basic TX and and LFTX
@@ -50,7 +50,7 @@ Recieve Gains: **PGA0**, Range: 0-45dB
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 XCVR 2450
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The XCVR2450 has a non-contiguous tuning range consiting of a high band and a low band.
+The XCVR2450 has a non-contiguous tuning range consisting of a high band and a low band.
 The high band consists of frequencies between...TODO
 
 Transmit Antennas: **J1** or **J2**
@@ -65,11 +65,11 @@ The XCVR2450 uses a common LO for both receive and transmit.
 Even though the API allows the RX and TX LOs to be individually set,
 a change of one LO setting will be reflected in the other LO setting.
 
-Transmit Gains: 
+Transmit Gains:
  * **VGA**, Range: 0-30dB
  * **BB**, Range: 0-5dB
 
-Recieve Gains: 
+Receive Gains:
  * **LNA**, Range: 0-30.5dB
  * **VGA**, Range: 0-62dB
 
diff --git a/host/docs/general.rst b/host/docs/general.rst
index 6b309cba0..90a880c2e 100644
--- a/host/docs/general.rst
+++ b/host/docs/general.rst
@@ -45,7 +45,7 @@ The list of discovered devices can be narrowed down by specifying device address
 Device properties
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Properties of devices attached to your system can be probed with the "uhd_usrp_probe" program.
-The usrp probe program contructs an instance of the device and prints out its properties;
+The usrp probe program constructs an instance of the device and prints out its properties;
 properties such as detected daughter-boards, frequency range, gain ranges, etc...
 
 **Usage:**
diff --git a/host/docs/usrp2.rst b/host/docs/usrp2.rst
index 09987b3fa..d3ae1dec7 100644
--- a/host/docs/usrp2.rst
+++ b/host/docs/usrp2.rst
@@ -11,8 +11,7 @@ Building firmware and FPGA images
 ^^^^^^^^^^^^^^^^^^
 FPGA Image
 ^^^^^^^^^^^^^^^^^^
-Xilinx ISE 10.1 is required to build the FPGA image for the USRP2
-(newer version of ISE are known to build buggy images).
+Xilinx ISE 10.1 and up is required to build the FPGA image for the USRP2.
 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.
 
@@ -150,6 +149,40 @@ MAC addresses, control packets, and fast-path settings.
 Use wireshark to monitor packets sent to and received from the USRP2.
 
 ------------------------------------------------------------------------
+Addressing the device
+------------------------------------------------------------------------
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Single device configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+A USRP2 can be identified though its IPv4 address or resolvable hostname.
+The USRP2 device is referenced through the "addr" key in the device address.
+Use this addressing scheme with the *simple_usrp* interface.
+
+The device address string representation for a USRP2 with IPv4 address 192.168.10.2
+
+::
+
+    addr=192.168.10.2
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Soft-MIMO configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+In a soft-mimo configuration, each USRP2 must have a unique IPv4 address (per computer)
+and be attached to its own dedicated network port.
+The value for the addr key is a white-space separated list
+of IPv4 addresses or resolvable hostnames.
+The first address in the list will represent channel 0,
+the second channel 1, and so on...
+Use this addressing scheme with the *mimo_usrp* interface.
+
+The device address string representation for 2 USRP2s with IPv4 addresses 192.168.10.2 and 192.168.20.2
+::
+
+    addr=192.168.10.2 192.168.20.2
+
+
+------------------------------------------------------------------------
 Resize the send and receive buffers
 ------------------------------------------------------------------------
 It may be useful increase the size of the socket buffers to
@@ -158,10 +191,27 @@ buffer incoming samples faster than they can be processed.
 However, if you application cannot process samples fast enough,
 no amount of buffering can save you.
 
+By default, the UHD will try to request a reasonably large buffer size for both send and receive.
+A warning will be printed on instantiation if the actual buffer size is insufficient.
+See the OS specific notes below:
+
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+OS specific notes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+On linux, the maximum buffer sizes are capped by the sysctl values
+**net.core.rmem_max** and **net.core.wmem_max**.
+To change the maximum values, run the following commands:
+::
+
+    sudo sysctl -w net.core.rmem_max=<new value>
+    sudo sysctl -w net.core.wmem_max=<new value>
+
+Set the values permanently by editing */etc/sysctl.conf*
+
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Device address params
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-To set the size of the buffers,
+To manually set the size of the buffers,
 the usrp2 will accept two optional parameters in the device address.
 Each parameter will accept a numeric value for the number of bytes.
 
@@ -172,14 +222,3 @@ Example, set the args string to the following:
 ::
 
     addr=192.168.10.2, recv_buff_size=100e6
-
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-OS specific notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-On linux, the maximum buffer sizes are capped by the sysctl values
-**net.core.rmem_max** and **net.core.wmem_max**.
-To change the maximum values, run the following commands:
-::
-
-    sudo sysctl -w net.core.rmem_max=<new value>
-    sudo sysctl -w net.core.wmem_max=<new value>