Merge branch 'maint'

21 files changed, 79 insertions, 33 deletions

diff --git a/host/docs/calibration.dox b/host/docs/calibration.dox
index eecb7af5c..02ad41699 100644
--- a/host/docs/calibration.dox
+++ b/host/docs/calibration.dox
@@ -39,19 +39,19 @@ utilities:
 UHD software installs the calibration utilities into
 `<install-path>/bin`. **Disconnect** any external hardware from the
 RF antenna ports, and run the following from the command line. Each
-utility will take several minutes to complete. :
+utility will take several minutes to complete:
 
     uhd_cal_rx_iq_balance --verbose --args=<optional device args>
     uhd_cal_tx_iq_balance --verbose --args=<optional device args>
     uhd_cal_tx_dc_offset --verbose --args=<optional device args>
 
-See the output given by --help for more advanced options, such as:
+See the output given by `--help` for more advanced options, such as
 manually choosing the frequency range and step size for the sweeps.
 
 <b>Note:</b> Your daughterboard needs a serial number to run a calibration
 utility. Some older daughterboards may not have a serial number. If this
 is the case, run the following command to burn a serial number into the
-daughterboard's EEPROM: :
+daughterboard's EEPROM:
 
     <install dir>/lib/uhd/utils/usrp_burn_db_eeprom --ser=<desired serial> --args=<optional device args>
 
@@ -76,7 +76,9 @@ recovered by the user.
 
 \subsection ignore_cal_file Ignoring Calibration Files
 
-At runtime, the user can choose to ignore a daughterboard's calibration file by adding "ignore-cal-file" to the arguments. With the UHD API, it can be done as follows:
+At runtime, the user can choose to ignore a daughterboard's calibration file by
+adding "ignore-cal-file" to the arguments. With the UHD API, it can be done as
+follows:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
     uhd::device_addr_t hint;
diff --git a/host/docs/dboards.dox b/host/docs/dboards.dox
index a0188b25c..99314b105 100644
--- a/host/docs/dboards.dox
+++ b/host/docs/dboards.dox
@@ -80,7 +80,7 @@ Sensors:
 \subsection dboards_dbsrx2 DBSRX2
 
 The DBSRX2 board has 1 quadrature frontend. It defaults to direct
-conversion, but can use a low IF through lo_offset in uhd::tune_request_t.
+conversion, but can use a low IF through `lo_offset` in uhd::tune_request_t.
 
 Receive Antennas: **J3**
 
@@ -387,13 +387,14 @@ the standard daughterboard clock lines.
 
 \subsubsection dboards_dbsrxmod_1 Step 1: Move the clock configuration resistor
 
-Remove **R193** (which is 10 Ohms, 0603 size), and put it on **R194**,
-which is empty. This is made somewhat more complicated by the fact that
-the silkscreen is not clear in that area. **R193** is on the back,
-immediately below the large beige connector, **J2**. **R194** is just
-below, and to the left of **R193**. The silkscreen for **R193** is ok,
-but for **R194**, it is upside down, and partially cut off. If you lose
-**R193**, you can use anything from 0 to 10 Ohms there.
+Remove **R193** (which is 10 Ohms, 0603 size), and put it on **R194**, which is
+empty. This is made somewhat more complicated by the fact that the silkscreen
+is not clear in that area. **R193** is on the back, immediately below the large
+beige connector, **J2**. **R194** is just below, and to the left of **R193**.
+
+The silkscreen for **R193** is ok, but for **R194**, it is upside down, and
+partially cut off. If you lose **R193**, you can use anything from 0 to 10 Ohms
+there.
 
 \subsubsection dboards_dbsrxmod_2 Step 2: Burn a new daughterboard id into the EEPROM
 
@@ -402,9 +403,9 @@ With the daughterboard plugged-in, run the following commands:
     cd <install-path>/lib/uhd/utils
     ./usrp_burn_db_eeprom --id=0x000d --unit=RX --args=<args> --slot=<slot>
 
--   **\<args\>** are device address arguments (optional if only one USRP
+-   `<args>` are device address arguments (optional if only one USRP
     device is on your machine)
--   **\<slot\>** is the name of the daughterboard slot (optional if the
+-   `<slot>` is the name of the daughterboard slot (optional if the
     USRP device has only one slot)
 
 \subsection dboards_rfxmod RFX - Modify to use motherboard oscillator
diff --git a/host/docs/gpsdo_x3x0.dox b/host/docs/gpsdo_x3x0.dox
index 24997d50b..9577b930d 100644
--- a/host/docs/gpsdo_x3x0.dox
+++ b/host/docs/gpsdo_x3x0.dox
@@ -46,12 +46,22 @@ pins.</b>
 
 \section gpsdox_using Using the GPSDO in Your Application
 
-By default, if a GPSDO is detected at startup, the USRP will be
-configured to use it as a frequency and time reference. The internal
-VITA timestamp will be initialized to the GPS time, and the internal
-oscillator will be phase-locked to the 10MHz GPSDO reference. If the
-GPSDO is not locked to satellites, the VITA time will not be
-initialized.
+If a GPSDO is detected at startup, the USRP will have `gpsdo` clock and time
+source options.
+
+Select these by using UHD's
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    usrp->set_clock_source("gpsdo");
+    usrp->set_time_source("gpsdo");
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+That will lock the reference clock to the disciplined 10MHz oscillator, and
+will make the USRP listen for time signal pulses coming from the GPSDO.
+
+However, you will still need to explicitly set the device time on such a PPS
+edge, using the `set_time_next_pps` or `set_time_unknown_pps`
+calls.
 
 GPS data is obtained through the **mboard_sensors** interface. To
 retrieve the current GPS time, use the **gps_time** sensor:
@@ -65,12 +75,43 @@ January 1, 1970. This value is readily converted into human-readable
 format using the **time.h** library in C, **boost::posix_time** in C++,
 etc.
 
+\subsection Setting Device Time to GPS time
+
+If you want to set the device time to GPS time, the following procedure makes
+sure you don't encounter timing problems while doing so:
+
+1. Wait for GPS lock, and then set the time source to GPSDO,
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    while(! (usrp->get_mboard_sensor("gps_locked",0).to_bool()) ) {
+       boost::this_thread::sleep(boost::posix_time::seconds(2));
+    }
+    usrp->set_time_source("gpsdo");
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+2. poll on `usrp->get_time_last_pps()` until a change is seen, and then sleep 200ms to allow new time data coming from the GPSDO to propagate through the system,
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    uhd::time_spec_t last = usrp->get_time_last_pps();
+    uhd::time_spec_t next = usrp->get_time_last_pps();
+    while(next == last) {
+       boost::this_thread::sleep(boost::posix_time::seconds(0.05));
+       last = next;
+       next = usrp->get_time_last_pps();
+    }
+    boost::this_thread::sleep(boost::posix_time::seconds(0.2));
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+3.  use
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+usrp->set_time_next_pps(uhd::time_spec_t(usrp->get_mboard_sensor("gps_time").to_int()+1));
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+to set the time,
+4.  poll on `usrp->get_time_last_pps()` until a change is seen and sleep 200ms (allow NMEA string to propagate),
+5.  Verify that `usrp->get_time_last_pps()` and `usrp->get_mboard_sensor("gps_time")` return the same time.
+
+\subsection Further GPS sensors
+
 Other information can be fetched as well. You can query the lock status
 with the **gps_locked** sensor, as well as obtain raw NMEA sentences
 using the **gps_gprmc**, and **gps_gpgga** sensors. Location
 information can be parsed out of the **gps_gpgga** sensor by using **gpsd**
 or another NMEA parser.
-
-
 */
 // vim:ft=doxygen:
diff --git a/host/docs/res/N2xx-JTAG.jpg b/host/docs/res/N2xx-JTAG.jpg
index acecc0592..64cc43242 100644
--- a/host/docs/res/N2xx-JTAG.jpg
+++ b/host/docs/res/N2xx-JTAG.jpg
diff --git a/host/docs/res/TRRS.png b/host/docs/res/TRRS.png
index 78619c869..8dc9bf9eb 100755
--- a/host/docs/res/TRRS.png
+++ b/host/docs/res/TRRS.png
diff --git a/host/docs/res/e3x0_fp_overlay.png b/host/docs/res/e3x0_fp_overlay.png
index c8f1af1be..416a75e9b 100644
--- a/host/docs/res/e3x0_fp_overlay.png
+++ b/host/docs/res/e3x0_fp_overlay.png
diff --git a/host/docs/res/e3x0_imu_demo.png b/host/docs/res/e3x0_imu_demo.png
index cbf156224..72be046b1 100644
--- a/host/docs/res/e3x0_imu_demo.png
+++ b/host/docs/res/e3x0_imu_demo.png
diff --git a/host/docs/res/e3x0_rp_overlay.png b/host/docs/res/e3x0_rp_overlay.png
index f351ffc24..e7dc24098 100644
--- a/host/docs/res/e3x0_rp_overlay.png
+++ b/host/docs/res/e3x0_rp_overlay.png
diff --git a/host/docs/res/e3xx_conn_photo.jpg b/host/docs/res/e3xx_conn_photo.jpg
new file mode 100644
index 000000000..a63a1c67c
--- /dev/null
+++ b/host/docs/res/e3xx_conn_photo.jpg
diff --git a/host/docs/res/e3xx_conn_photo.png b/host/docs/res/e3xx_conn_photo.png
deleted file mode 100644
index dd12f5ac2..000000000
--- a/host/docs/res/e3xx_conn_photo.png
+++ /dev/null
diff --git a/host/docs/res/e3xx_conn_render.png b/host/docs/res/e3xx_conn_render.png
index 52e6ce5d9..c37024ce8 100644
--- a/host/docs/res/e3xx_conn_render.png
+++ b/host/docs/res/e3xx_conn_render.png
diff --git a/host/docs/res/x3x0_gpio_conn.png b/host/docs/res/x3x0_gpio_conn.png
index 0147bf422..f09363dea 100644
--- a/host/docs/res/x3x0_gpio_conn.png
+++ b/host/docs/res/x3x0_gpio_conn.png
diff --git a/host/docs/res/x3x0_rp_overlay.png b/host/docs/res/x3x0_rp_overlay.png
index c34936ac3..4665dc88b 100644
--- a/host/docs/res/x3x0_rp_overlay.png
+++ b/host/docs/res/x3x0_rp_overlay.png
diff --git a/host/docs/sync.dox b/host/docs/sync.dox
index 59f849e1a..1789a70a9 100644
--- a/host/docs/sync.dox
+++ b/host/docs/sync.dox
@@ -166,7 +166,7 @@ chains will remain constant after each re-tune. See notes below:
 -   This phase offset will drift over time due to thermal and other characteristics
 -   Periodic calibration will be necessary for phase-coherent applications
 
-Code snippet example, tuning with timed commands: :
+Code snippet example, tuning with timed commands:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
     //we will tune the frontends in 100ms from now
diff --git a/host/docs/transport.dox b/host/docs/transport.dox
index eb7232f36..72d59fb2a 100644
--- a/host/docs/transport.dox
+++ b/host/docs/transport.dox
@@ -16,7 +16,7 @@ for the various transports in the UHD software:
 \section transport_udp UDP Transport (Sockets)
 
 The UDP transport is implemented with user-space sockets. This means
-standard Berkeley sockets API using send()/recv().
+standard Berkeley sockets API using `send()`/`recv()`.
 
 \subsection transport_udp_params Transport parameters
 
@@ -97,12 +97,12 @@ Set the values permanently by editing `/etc/sysctl.conf`.
 
 \subsection transport_udp_windows Windows specific notes
 
-**UDP send fast-path:** It is important to change the default UDP
+<b>UDP send fast-path:</b> It is important to change the default UDP
 behavior such that 1500 byte packets still travel through the fast path
 of the sockets stack. This can be adjusted with the
-FastSendDatagramThreshold registry key:
+`FastSendDatagramThreshold` registry key:
 
--   FastSendDatagramThreshold registry key documented here:
+-   `FastSendDatagramThreshold` registry key documented here:
 
     -   <http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx#appendix_e>
 
diff --git a/host/docs/usrp1.dox b/host/docs/usrp1.dox
index e82df0a7b..2f7b26e05 100644
--- a/host/docs/usrp1.dox
+++ b/host/docs/usrp1.dox
@@ -87,7 +87,7 @@ Run the following commands to record the setting into the EEPROM:
     ./usrp_burn_mb_eeprom --args=<optional device args> --values="mcr=<rate>"
 
 The user may override the clock rate specified in the EEPROM by using a
-device address: Example:
+device address. Example:
 
     uhd_usrp_probe --args="mcr=52e6"
 
diff --git a/host/docs/usrp_b100.dox b/host/docs/usrp_b100.dox
index a7d67f50f..89bc6ea64 100644
--- a/host/docs/usrp_b100.dox
+++ b/host/docs/usrp_b100.dox
@@ -64,7 +64,7 @@ position.
 
 To communicate the desired clock rate into UHD software, specify the
 special device address argument, where the key is
-**master_clock_rate** and the value is a rate in Hz. Example: :
+`master_clock_rate` and the value is a rate in Hz. Example:
 
     uhd_usrp_probe --args="master_clock_rate=52e6"
 
diff --git a/host/docs/usrp_b200.dox b/host/docs/usrp_b200.dox
index 0afcf99da..be63b8fe8 100644
--- a/host/docs/usrp_b200.dox
+++ b/host/docs/usrp_b200.dox
@@ -20,7 +20,7 @@
 
 \section b200_power Power
 In most cases, USB 3.0 bus power will be sufficient to power the device.
-If using USB 2.0 or a internal GPSDO, an external power supply or a cable designed
+If using USB 2.0 or an internal GPSDO, an external power supply or a cable designed
 to pull power from 2 USB ports (USB 3.0 dual A to micro-B or B) must be used.
 
 \section b200_imgs Specifying a Non-standard Image
diff --git a/host/docs/usrp_e3x0.dox b/host/docs/usrp_e3x0.dox
index 807d82e4d..bdcfe8bfb 100644
--- a/host/docs/usrp_e3x0.dox
+++ b/host/docs/usrp_e3x0.dox
@@ -443,7 +443,7 @@ The USRP E312 (and with upgraded firmware E310) supports LiIon Battery packs (e.
 
 The connector J1 on E312's motherboard is a Molex 53014-6310. The corresponding mating connector is a Molex 51004-0300.
 
-\image html e3xx_conn_photo.png "Battery pack connector"
+\image html e3xx_conn_photo.jpg "Battery pack connector"
 
 The pins are as follows:
 - Pin 1 (Red): VBat
diff --git a/host/examples/rx_samples_c.c b/host/examples/rx_samples_c.c
index abea812fe..0ecb89153 100644
--- a/host/examples/rx_samples_c.c
+++ b/host/examples/rx_samples_c.c
@@ -222,7 +222,7 @@ int main(int argc, char* argv[])
         EXECUTE_OR_GOTO(close_file,
             uhd_rx_metadata_error_code(md, &error_code)
         )
-        if(return_code != UHD_RX_METADATA_ERROR_CODE_NONE){
+        if(error_code != UHD_RX_METADATA_ERROR_CODE_NONE){
             fprintf(stderr, "Error code 0x%x was returned during streaming. Aborting.\n", return_code);
             goto close_file;
         }
diff --git a/host/lib/usrp/e300/e300_sensor_manager.hpp b/host/lib/usrp/e300/e300_sensor_manager.hpp
index bfaf8e90c..1252e07b9 100644
--- a/host/lib/usrp/e300/e300_sensor_manager.hpp
+++ b/host/lib/usrp/e300/e300_sensor_manager.hpp
@@ -1,5 +1,5 @@
 //
-// Copyright 2014 Ettus Research LLC
+// Copyright 2014-2015 Ettus Research LLC
 //
 // This program is free software: you can redistribute it and/or modify
 // it under the terms of the GNU General Public License as published by
@@ -46,6 +46,8 @@ class e300_sensor_manager : boost::noncopyable
 public:
     typedef boost::shared_ptr<e300_sensor_manager> sptr;
 
+    virtual ~e300_sensor_manager() {};
+
     virtual uhd::sensor_value_t get_sensor(const std::string &key) = 0;
     virtual std::vector<std::string> get_sensors(void) = 0;