12 files changed, 31 insertions, 31 deletions
diff --git a/host/docs/build.dox b/host/docs/build.dox
index 95f7bab85..674377bb2 100644
--- a/host/docs/build.dox
+++ b/host/docs/build.dox
@@ -258,7 +258,7 @@ Many UHD developers first install UHD using MacPorts in order to get all of the
 
 \b NOTE: We highly recommended that all dependencies be installed via the same package manager! When issues arise, they are much easier to track down, and updating to newer versions of UHD as well as dependencies is much easier.
 
-\b NOTE: Other package managers (e.g., Fink, HomeBrew) will require diffrent commands than the above to install all dependencies and then remove the UHD install. Please consult the specific package manager in use for how to do these commands properly; they will not be covered here.
+\b NOTE: Other package managers (e.g., Fink, HomeBrew) will require different commands than the above to install all dependencies and then remove the UHD install. Please consult the specific package manager in use for how to do these commands properly; they will not be covered here.
 
 #### Compiling UHD from Source
 
diff --git a/host/docs/calibration.dox b/host/docs/calibration.dox
index b4454aa24..4bf89a8bc 100644
--- a/host/docs/calibration.dox
+++ b/host/docs/calibration.dox
@@ -19,11 +19,11 @@ re-apply the desired setting every time the LO is re-tuned.
 
 UHD software comes with the following calibration utilities:
 
--   **uhd_cal_rx_iq_balance:** - mimimizes RX IQ imbalance vs. LO
+-   **uhd_cal_rx_iq_balance:** - minimizes RX IQ imbalance vs. LO
     frequency
--   **uhd_cal_tx_dc_offset:** - mimimizes TX DC offset vs. LO
+-   **uhd_cal_tx_dc_offset:** - minimizes TX DC offset vs. LO
     frequency
--   **uhd_cal_tx_iq_balance:** - mimimizes TX IQ imbalance vs. LO
+-   **uhd_cal_tx_iq_balance:** - minimizes TX IQ imbalance vs. LO
     frequency
 
 The following RF frontends are supported by the self-calibration
diff --git a/host/docs/coding.dox b/host/docs/coding.dox
index 6a15098d7..aab495c25 100644
--- a/host/docs/coding.dox
+++ b/host/docs/coding.dox
@@ -7,7 +7,7 @@
 \subsection coding_api_hilevel High-Level: The Multi-USRP
 
 The Multi-USRP class provides a high-level interface to a single USRP device
-with one or more channels, or multiple USRP devicess in a homogeneous
+with one or more channels, or multiple USRP devices in a homogeneous
 setup. See the documentation for uhd::usrp::multi_usrp.
 
 \subsection coding_api_hilevelclock High-Level: The Multi-USRP-Clock
diff --git a/host/docs/configuration.dox b/host/docs/configuration.dox
index 4d6a6d504..aa054b650 100644
--- a/host/docs/configuration.dox
+++ b/host/docs/configuration.dox
@@ -34,7 +34,7 @@ and possible more options.
  self_cal_adc_delay  | Run ADC transfer delay self-calibration.                                     | X3x0               | self_cal_adc_delay=1
  ext_adc_self_test   | Run an extended ADC self test (more than the usual)                          | X3x0               | ext_adc_self_test=1
  recover_mb_eeprom   | Disable version checks. Can damage hardware. Only recommended for recovering devices with corrupted EEPROMs. | X3x0, N230 | recover_mb_eeprom=1
- skip_dram           | Ignore DRAM FIFO block. Connect Tx streamers straight into DUC or radio.     | X3x0               | skip_dram=1
+ skip_dram           | Ignore DRAM FIFO block. Connect TX streamers straight into DUC or radio.     | X3x0               | skip_dram=1
  skip_ddc            | Ignore DDC block. Connect Rx streamers straight into radio.                  | X3x0               | skip_ddc=1
  skip_duc            | Ignore DUC block. Connect Rx streamers or DRAM straight into radio.          | X3x0               | skip_duc=1
 
diff --git a/host/docs/general.dox b/host/docs/general.dox
index 3e9dfc63a..ff407a304 100644
--- a/host/docs/general.dox
+++ b/host/docs/general.dox
@@ -8,7 +8,7 @@
 
 A USRP device has two stages of tuning:
 
-- RF front-end: translates bewteen RF and IF
+- RF front-end: translates between RF and IF
 - DSP: translates between IF and baseband
 
 In a typical use-case, the user specifies an overall center frequency
@@ -99,7 +99,7 @@ clock selection, allowing a broader range of sample rate selections by applicati
 pages for more details.
 
 In many cases using USRPs with flexible master-clock rates, it is possible to achieve lower sample rates without running into
-the constraints of higher decimations, simply by choosing a lower master-clock rate to keep required decimation below 128.
+the constraints of higher decimation rates, simply by choosing a lower master-clock rate to keep required decimation below 128.
 
 \subsection general_sampleratenotes_automatic Automatic master-clock selection
 
diff --git a/host/docs/octoclock.dox b/host/docs/octoclock.dox
index 23faff8f3..07ca35379 100644
--- a/host/docs/octoclock.dox
+++ b/host/docs/octoclock.dox
@@ -120,7 +120,7 @@ Device Address:
 
 \subsection eeprom Updating the device's EEPROM
 
-As a final step, the device's EEPROM will need to be updated. On the back of your device, you will see a label sticker with a serial number (labelled S/N) and a MAC address (labeled MAC). For later use, the MAC address will have to be used in a different format than is on the label. As an example, if the label lists the MAC address as <b>00802F112233</b>, you will need to format it as <b>00:80:2F:11:22:33</b>.
+As a final step, the device's EEPROM will need to be updated. On the back of your device, you will see a label sticker with a serial number (labeled S/N) and a MAC address (labeled MAC). For later use, the MAC address will have to be used in a different format than is on the label. As an example, if the label lists the MAC address as <b>00802F112233</b>, you will need to format it as <b>00:80:2F:11:22:33</b>.
 
 Update your device's EEPROM with the following command:
 
diff --git a/host/docs/transport.dox b/host/docs/transport.dox
index ab163341d..2cedcccb2 100644
--- a/host/docs/transport.dox
+++ b/host/docs/transport.dox
@@ -8,7 +8,7 @@ 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
+kernel buffers, spawns threads, etc. When not specified, 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:
@@ -29,7 +29,7 @@ see uhd::stream_args_t::args):
 -   `num_recv_frames:` The number of receive buffers to allocate
 -   `send_frame_size:` The size of a single send buffer in bytes
 -   `num_send_frames:` The number of send buffers to allocate
--   `recv_buff_fullness:` The targetted fullness factor of the the buffer (typically around 90%)
+-   `recv_buff_fullness:` The targeted fullness factor of the the buffer (typically around 90%)
 
 <b>Notes:</b>
 - `num_recv_frames` does not affect performance.
@@ -78,8 +78,8 @@ proportional to the sample rate. Therefore, to improve receive latency,
 configure the transport for a smaller frame size.
 
 <b>Note2:</b> For overall latency improvements, look for "Interrupt
-Coalescing" settings for your OS and ethernet chipset. It seems the
-Intel ethernet chipsets offer fine-grained control in Linux. Also,
+Coalescing" settings for your OS and Ethernet chipset. It seems the
+Intel Ethernet chipsets offer fine-grained control in Linux. Also,
 consult:
 
 -   <http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/interrupt_coal.htm>
diff --git a/host/docs/usrp2.dox b/host/docs/usrp2.dox
index 3f85e45b5..7f8c94b8b 100644
--- a/host/docs/usrp2.dox
+++ b/host/docs/usrp2.dox
@@ -102,7 +102,7 @@ indirectly to a USRP2 through a Gigabit Ethernet switch.
 
 \subsection usrp2_network_setuphost Setup the host interface
 
-The USRP2 communicates at the IP/UDP layer over the gigabit ethernet.
+The USRP2 communicates at the IP/UDP layer over the gigabit Ethernet.
 The default IP address of the USRP2 is **192.168.10.2**. You will need
 to configure the host's Ethernet interface with a static IP address to
 enable communication. An address of **192.168.10.1** and a subnet mask
@@ -189,7 +189,7 @@ IP address are in the previous section of this documentation.
 \subsection usrp2_commprob_firewall Firewall issues
 
 When the IP address is not specified, the device discovery broadcasts
-UDP packets from each ethernet interface. Many firewalls will block the
+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
diff --git a/host/docs/usrp_b200.dox b/host/docs/usrp_b200.dox
index 2192ba63e..1d5374b3a 100644
--- a/host/docs/usrp_b200.dox
+++ b/host/docs/usrp_b200.dox
@@ -42,7 +42,7 @@ images:
 \section b200_mcr Changing the Master Clock Rate
 
 The master clock rate feeds the RF frontends and the DSP chains. Users
-may select non-default clock rates to acheive integer decimations or
+may select non-default clock rates to achieve integer decimation rates or
 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.
diff --git a/host/docs/usrp_e3x0.dox b/host/docs/usrp_e3x0.dox
index fda5c7e1d..470f6a26b 100644
--- a/host/docs/usrp_e3x0.dox
+++ b/host/docs/usrp_e3x0.dox
@@ -31,8 +31,8 @@ up and running.
 
 There are two different methods to connect to the device
 
-- using the onboard serial to usb connector
-- using the gigabit ethernet connector and a ssh client on your host computer
+- using the onboard Serial to USB connector
+- using the gigabit Ethernet connector and a ssh client on your host computer
 
 For the first boot, booting with the serial cable connected to the device
 is recommended, as it allows to review and modify the \ref e3xx_network_configuration
@@ -118,7 +118,7 @@ in order to build software for your device open a new shell and type:
 
     $ . <yoursdkinstallpath>/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
 
-This will modifiy the PATH, CC, CXX etc, environment variables and allow you to compile software for your USRP E310 device.
+This will modify the PATH, CC, CXX etc, environment variables and allow you to compile software for your USRP E310 device.
 To verify all went well you can try:
 
     $ $CC -dumpmachine
@@ -223,7 +223,7 @@ From the build directory run:
  $ sh ../meta-ettus/scripts/build-all.sh
 \endcode
 
-When the script finishes, the SD ard image files are in ./images and the sdk
+When the script finishes, the SD card image files are in ./images and the sdk
 is in tmp-glibc/deploy/sdk/ .
 
 -# Using the environment
@@ -237,9 +237,9 @@ again by:
 \section e3x0_upgrade_sd_card Upgrading / Writing image to sd card
 
 In order to upgrade or reinitialize a sd card for the first time, you can use the 'dd' tool.
-Make sure that you are using the right block device for your sd card as failing to do so can wipe your harddrive.
+Make sure that you are using the right block device for your sd card as failing to do so can wipe your hard drive.
 
-Replace `<yourimage>`.direct with your image file name and yoursdcard with your blockdevice e.g. /dev/mmcblk0 or /dev/sdb.
+Replace `<yourimage>`.direct with your image file name and `<yoursdcard>` with your blockdevice e.g. /dev/mmcblk0 or /dev/sdb.
 
     $ sudo dd if=<yourimage>.direct of=/dev/<yoursdcard> bs=1M
 
@@ -389,7 +389,7 @@ To test the accelerometer, run:
 
     $ RTIMULibDrive
 
-This will print the current acclerometer values on the console.
+This will print the current accelerometer values on the console.
 
 To launch the IMU calibration procedure, run:
 
@@ -518,7 +518,7 @@ The procedure for calibration is as follows:
 
 A faster (less accurate) calibration procedure is as follows:
 
-1. Completly charge battery
+1. Completely charge battery
 2. Type:
 
     $ echo 3200000 > /sys/class/power_supply/BAT/charge_now
@@ -573,7 +573,7 @@ Source code related to controlling the filter band and antenna switches resides
 methods set the switches depending on the state of transmit and receive streams.
 
 The following sections provide switch setting tables for antenna and filter selection for frontends A & B receive and transmit paths.
-For futher details refer to the schematics. 
+For further details refer to the schematics. 
 
 \subsubsection e3x0_dboard_e310_frontend_a_switches Frontend Side A Filter and Antenna Switches
 
diff --git a/host/docs/usrp_x3x0.dox b/host/docs/usrp_x3x0.dox
index 5f7284a09..8a3d52a7d 100644
--- a/host/docs/usrp_x3x0.dox
+++ b/host/docs/usrp_x3x0.dox
@@ -112,7 +112,7 @@ ready for development!
 
 - 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.
+- Use the Ethernet cable to connect the SFP+ transceiver 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`).
 
@@ -157,7 +157,7 @@ We will use the 'MXI' nomenclature for the rest of this manual.</b>
 ### Installing the PCIe Kernel Drivers
 
 In order to use the USRP X-Series on a PCIe-over-MXI connection, you need to
-install the NI RIO drivers on your system. Please follow the insructions here:
+install the NI RIO drivers on your system. Please follow the instructions here:
 \ref page_ni_rio_kernel
 
 ### Installing the PCI Express Interface Kit
@@ -198,7 +198,7 @@ We will use the 'MXI' nomenclature for the rest of this manual.</b>
 ### Installing the PCIe Kernel Drivers
 
 In order to use the USRP X-Series on a PCIe-over-MXI connection, you need to
-install the NI RIO drivers on your system. Please follow the insructions here:
+install the NI RIO drivers on your system. Please follow the instructions here:
 \ref page_ni_rio_kernel
 
 ### Installing the PCI Express Card
@@ -443,7 +443,7 @@ for information specific to certain daughterboards.
 
 Not all combinations of daughterboards work within the same device, if
 daughterboard clock requirements conflict. Note that some daughterboards
-(e.g. the UBX) will try and set the daughterboard clock rate themself.
+(e.g. the UBX) will try and set the daughterboard clock rate themselves.
 
 \section x3x0_addressing Addressing the Device
 
diff --git a/host/docs/vrt_chdr.dox b/host/docs/vrt_chdr.dox
index 8ab177b21..560f0b6a3 100644
--- a/host/docs/vrt_chdr.dox
+++ b/host/docs/vrt_chdr.dox
@@ -6,7 +6,7 @@ Radio transport protocols are used to exchange samples (or other items) between
 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)
+For USRP devices, two radio transport protocols are relevant: 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.
 
@@ -74,7 +74,7 @@ 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:
+Relevant 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