diff options
author | Nicholas Corgan <nick.corgan@ettus.com> | 2012-12-18 15:47:17 -0800 |
---|---|---|
committer | Nicholas Corgan <nick.corgan@ettus.com> | 2012-12-18 15:49:13 -0800 |
commit | 2acddaccbde707afe8c28f183bb4418947384786 (patch) | |
tree | 7d1390a5a72fec7793bec7c5a12b0b5873de4cbc /host | |
parent | 9761065040e56e43a05b69e5e41ca66e4175ee8d (diff) | |
download | uhd-2acddaccbde707afe8c28f183bb4418947384786.tar.gz uhd-2acddaccbde707afe8c28f183bb4418947384786.tar.bz2 uhd-2acddaccbde707afe8c28f183bb4418947384786.zip |
docs: UHD/USRP rephrasing
Diffstat (limited to 'host')
-rw-r--r-- | host/docs/build.rst | 2 | ||||
-rw-r--r-- | host/docs/calibration.rst | 8 | ||||
-rw-r--r-- | host/docs/coding.rst | 6 | ||||
-rw-r--r-- | host/docs/dboards.rst | 12 | ||||
-rw-r--r-- | host/docs/general.rst | 22 | ||||
-rw-r--r-- | host/docs/identification.rst | 8 | ||||
-rw-r--r-- | host/docs/images.rst | 4 | ||||
-rw-r--r-- | host/docs/index.rst | 10 | ||||
-rw-r--r-- | host/docs/sync.rst | 16 | ||||
-rw-r--r-- | host/docs/transport.rst | 6 | ||||
-rw-r--r-- | host/docs/usrp1.rst | 4 | ||||
-rw-r--r-- | host/docs/usrp2.rst | 14 | ||||
-rw-r--r-- | host/docs/usrp_b100.rst | 6 | ||||
-rw-r--r-- | host/docs/usrp_e1x0.rst | 10 |
14 files changed, 64 insertions, 64 deletions
diff --git a/host/docs/build.rst b/host/docs/build.rst index 0a18e9e9a..00f79aaaa 100644 --- a/host/docs/build.rst +++ b/host/docs/build.rst @@ -1,5 +1,5 @@ ======================================================================== -UHD - Build Guide +UHD Software - Build Guide ======================================================================== .. contents:: Table of Contents diff --git a/host/docs/calibration.rst b/host/docs/calibration.rst index 1945c4dd5..a24d7cbca 100644 --- a/host/docs/calibration.rst +++ b/host/docs/calibration.rst @@ -7,11 +7,11 @@ UHD - Calibration Application Notes ------------------------------------------------------------------------ Self-calibration ------------------------------------------------------------------------ -UHD comes with several self-calibration utilities for minimizing IQ imbalance and DC offset. +UHD software comes with several self-calibration utilities for minimizing IQ imbalance and DC offset. These utilities perform calibration sweeps using transmit leakage into the receive path (special equipment is not required). The results from a calibration are written to a CSV file in the user's home directory. -UHD will automatically apply corrections at runtime when the user re-tunes the daughterboard LO. +UHD software will automatically apply corrections at runtime when the user re-tunes the daughterboard LO. Calibration results are specific to an individual RF board. **Note:** @@ -19,7 +19,7 @@ When a calibration table is present, and the user wishes to override the calibration settings through the API: the user should re-apply the desired setting every time the LO is re-tuned. -UHD comes with the following calibration utilities: +UHD software comes with the following calibration utilities: * **uhd_cal_rx_iq_balance:** - mimimizes RX IQ imbalance vs. LO frequency * **uhd_cal_tx_dc_offset:** - mimimizes TX DC offset vs. LO frequency @@ -34,7 +34,7 @@ The following RF frontends are supported by the self-calibration utilities: ******************************************** Calibration Utilities ******************************************** -UHD installs the calibration utilities into **<install-path>/bin**. +UHD software installs the calibration utilities into **<install-path>/bin**. **Disconnect** any extrernal hardware from the RF antenna ports, and run the following from the command line. Each utility will take several minutes to complete. diff --git a/host/docs/coding.rst b/host/docs/coding.rst index ef8cb5fe2..432307cca 100644 --- a/host/docs/coding.rst +++ b/host/docs/coding.rst @@ -11,7 +11,7 @@ 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 +For a USRP device, this means that the motherboard and everything on it would be considered to be a "device". The device API provides ways to: * Discover devices that are physically connected to the host system. @@ -25,6 +25,6 @@ See the documentation in *device.hpp* for reference. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ High-Level: The Multi-USRP ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The Multi-USRP class provides a fat interface to a single USRP with -one or more channels, or multiple USRPs in a homogeneous setup. +The Multi-USRP class provides a fat interface to a single USRP device with +one or more channels, or multiple USRP devicess in a homogeneous setup. See the documentation in *usrp/multi_usrp.hpp* for reference. diff --git a/host/docs/dboards.rst b/host/docs/dboards.rst index 29812592f..3f4875c4c 100644 --- a/host/docs/dboards.rst +++ b/host/docs/dboards.rst @@ -1,5 +1,5 @@ ======================================================================== -UHD - Daughterboard Application Notes +UHD Daughterboard Application Notes ======================================================================== .. contents:: Table of Contents @@ -335,14 +335,14 @@ With the daughterboard plugged-in, run the following commands: cd <install-path>/share/uhd/utils ./usrp_burn_db_eeprom --id=0x000d --unit=RX --args=<args> --slot=<slot> -* **<args>** are device address arguments (optional if only one USRP is on your machine) -* **<slot>** is the name of the daughterboard slot (optional if the USRP has only one slot) +* **<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 USRP device has only one slot) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ RFX - Mod ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Older RFX boards require modifications to use the motherboard oscillator. -If this is the case, UHD will print a warning about the modification. +If this is the case, UHD software will print a warning about the modification. Please follow the modification procedures below: **Step 1: Disable the daughterboard clocks** @@ -377,5 +377,5 @@ With the daughterboard plugged-in, run the following commands: * **RFX1800:** 0x0035 * **RFX1200:** 0x002a * **RFX2400:** 0x002b -* **<args>** are device address arguments (optional if only one USRP is on your machine) -* **<slot>** is the name of the daughterboard slot (optional if the USRP has only one slot) +* **<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 USRP device has only one slot) diff --git a/host/docs/general.rst b/host/docs/general.rst index fc7caff3c..fc2735c46 100644 --- a/host/docs/general.rst +++ b/host/docs/general.rst @@ -23,10 +23,10 @@ frequency and actual frequency. The user may also explicitly control both stages of tuning through through the **tune_request_t** object, which allows for more advanced tuning. -In general, Using UHD's advanced tuning is highly recommended as it makes it +In general, Using UHD software's advanced tuning is highly recommended as it makes it easy to move the DC component out of your band-of-interest. This can be done by -passing your desired LO offset to the **tune_request_t** object, and letting UHD -handle the rest. +passing your desired LO offset to the **tune_request_t** object, and letting the UHD +software handle the rest. Tuning the receive chain: :: @@ -125,13 +125,13 @@ 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, +When UHD software 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, +UHD software detects the overflow as a discontinuity in the packet's sequence numbers, and pushes an inline message packet into the receive stream. **Other devices**: @@ -140,14 +140,14 @@ Therefore, overflows always occur in the device itself. When the device's internal buffers become full, streaming is shut off, and an inline message packet is sent to the host. If the device was in continuous streaming mode, -UHD will automatically restart streaming. +the UHD software 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 UHD detects underflow, it prints a "U" to stdout, +When UHD software detects the underflow, it prints a "U" to stdout, and pushes a message packet into the async message stream. ------------------------------------------------------------------------ @@ -157,7 +157,7 @@ Threading Notes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thread safety notes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -For the most part, UHD is thread-safe. +For the most part, UHD software is thread-safe. Please observe the following limitations: **Fast-path thread requirements:** @@ -177,8 +177,8 @@ It is recommended to use at most one thread context for manipulating device sett Thread priority scheduling ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -When UHD spawns a new thread it may try to boost the thread's scheduling priority. -When setting the priority fails, UHD prints out an error. +When UHD software spawns a new thread it may try to boost the thread's scheduling priority. +When setting the priority fails, the UHD software prints out an error. This error is harmless; it simply means that the thread will have a normal scheduling priority. **Linux Notes:** @@ -211,7 +211,7 @@ 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: +Make **register_handler** your first call into the UHD library: :: diff --git a/host/docs/identification.rst b/host/docs/identification.rst index a5e60e7f9..ba9b30898 100644 --- a/host/docs/identification.rst +++ b/host/docs/identification.rst @@ -5,7 +5,7 @@ UHD - Device Identification Notes .. contents:: Table of Contents ------------------------------------------------------------------------ -Identifying USRPs +Identifying USRP Devices ------------------------------------------------------------------------ Devices are addressed through key/value string pairs. These string pairs can be used to narrow down the search for a specific device or group of devices. @@ -89,10 +89,10 @@ such as detected daughterboards, frequency range, gain ranges, etc... uhd_usrp_probe --args <device-specific-address-args> ------------------------------------------------------------------------ -Naming a USRP +Naming a USRP Device ------------------------------------------------------------------------ -For convenience purposes, users may assign a custom name to their USRPs. -The USRP can then be identified via name, rather than a difficult to remember serial or address. +For convenience purposes, users may assign a custom name to their USRP device. +The USRP device can then be identified via name, rather than a difficult to remember serial or address. A name has the following properties: diff --git a/host/docs/images.rst b/host/docs/images.rst index dc9770460..95e2d96b0 100644 --- a/host/docs/images.rst +++ b/host/docs/images.rst @@ -29,7 +29,7 @@ See the UHD wiki for the download link. The pre-built images come in two forms: -* bundled with UHD in a platform-specific installer +* bundled with UHD software in a platform-specific installer * stand-alone platform-independent archive files ^^^^^^^^^^^^^^^^^^^^^^ @@ -59,7 +59,7 @@ When installing images from an archive, there are two options: **Option 1:** Unpack the archive into the UHD installation prefix. -UHD will always search **<install-path>/share/uhd/images** for image files. +UHD software will always search **<install-path>/share/uhd/images** for image files. Where **<install-path>** was set by the **CMAKE_INSTALL_PREFIX** at configure-time. **Option 2:** diff --git a/host/docs/index.rst b/host/docs/index.rst index 00b1c9618..5e3d08fb4 100644 --- a/host/docs/index.rst +++ b/host/docs/index.rst @@ -2,17 +2,17 @@ UHD - USRP Hardware Driver ======================================================================== -UHD is the "Universal Software Radio Peripheral" hardware driver. -The goal of UHD is to provide a host driver and API for current and future Ettus Research products. +UHD software is the "Universal Software Radio Peripheral" Hardware Driver software. +The goal of UHD software is to provide a host driver and API for current and future Ettus Research products. Users will be able to use the UHD driver standalone or with third-party applications. ------------------------------------------------------------------------ Contents ------------------------------------------------------------------------ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Building and Installing UHD -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Building and Installing UHD Software +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * `Build Guide <./build.html>`_ * `Installation Guide (Linux) <http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux>`_ * `Installation Guide (Windows) <http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Windows>`_ diff --git a/host/docs/sync.rst b/host/docs/sync.rst index 8622dc642..a1f6cb7df 100644 --- a/host/docs/sync.rst +++ b/host/docs/sync.rst @@ -4,9 +4,9 @@ UHD - Synchronization Application Notes .. contents:: Table of Contents -The following application notes explain how to synchronize multiple USRPs -with the goal of transmitting or receiving time-aligned samples for MIMO -or other applications requiring multiple USRPs operating synchronously. +The following application notes explain how to synchronize multiple USRP +devices with the goal of transmitting or receiving time-aligned samples for MIMO +or other applications requiring multiple USRP devices operating synchronously. **Note:** The following synchronization notes do not apply to USRP1, which does not support the advanced features available in newer products. @@ -14,7 +14,7 @@ which does not support the advanced features available in newer products. ------------------------------------------------------------------------ Common Reference Signals ------------------------------------------------------------------------ -USRPs take two reference signals in order to synchronize clocks and time: +USRP devices take two reference signals in order to synchronize clocks and time: * A 10MHz reference to provide a single frequency reference for both devices. * A pulse-per-second (PPS) to synchronize the sample time across devices. @@ -103,16 +103,16 @@ and the user can also parse this string to determine GPS time: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Method 3 - internal GPSDO ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -USRPs with internal GPSDOs properly configured will automatically +USRP devices with internal GPSDOs properly configured will automatically configure themselves to set the VITA time to current UTC time. See the `GPSDO Application Notes <./gpsdo.html>`_ for more details. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Method 4 - MIMO cable ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -A USRP can synchronize its time to another USRP via the MIMO cable. +A USRP device can synchronize its time to another USRP device via the MIMO cable. Unlike the other methods, this does not use a real "pulse per second". -Rather, the USRP sends an encoded time message over the MIMO cable. +Rather, the USRP device sends an encoded time message over the MIMO cable. The slave device will automatically synchronize to the time on the master device. See the `MIMO Cable Application Notes <./usrp2.html#using-the-mimo-cable>`_ for more detail. @@ -123,7 +123,7 @@ Synchronizing Channel Phase ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Align CORDICs in the DSP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -In order to achieve phase alignment between USRPs, the CORDICS in both +In order to achieve phase alignment between USRP devices, the CORDICS in both devices must be aligned with respect to each other. This is easily achieved by issuing stream commands with a time spec property, which instructs the streaming to begin at a specified time. Since the devices are already diff --git a/host/docs/transport.rst b/host/docs/transport.rst index 2e39e75d1..db89c8db9 100644 --- a/host/docs/transport.rst +++ b/host/docs/transport.rst @@ -14,7 +14,7 @@ These optional parameters control how the transport object allocates memory, resizes kernel buffers, spawns threads, etc. When not spcified, 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: +The transport parameters are defined below for the various transports in the UHD software: ------------------------------------------------------------------------ UDP Transport (Sockets) @@ -154,11 +154,11 @@ so that non-root users may access the device: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Install USB driver (Windows) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -A driver package must be installed to use a USB-based product with UHD: +A driver package must be installed to use a USB-based product with UHD software: * Download the driver from the UHD wiki page `here <http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip>`_. * Unzip the file into a known location. We will refer to this as the **<directory>**. -* Open the device manager and plug in the USRP. You will see an unrecognized USB device in the device manager. +* Open the device manager and plug in the USRP device. You will see an unrecognized USB device in the device manager. * Right click on the unrecognized USB device and select update/install driver software (may vary for your OS). * In the driver installation wizard, select "browse for driver", browse to the **<directory>**, and select the **.inf** file. * Continue through the installation wizard until the driver is installed. diff --git a/host/docs/usrp1.rst b/host/docs/usrp1.rst index c1fdec146..b6fd24b09 100644 --- a/host/docs/usrp1.rst +++ b/host/docs/usrp1.rst @@ -79,7 +79,7 @@ Hardware Setup Notes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ External clock modification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The USRP can be modified to accept an external clock reference instead of the 64MHz onboard reference. +The USRP device can be modified to accept an external clock reference instead of the 64MHz onboard reference. * Solder SMA (**LTI-SASF54GT**) connector to **J2001**. * Move 0 ohm 0603 resistor **R2029** to **R2030**. * Move 0.01uF 0603 capacitor **C925** to **C926**. @@ -89,7 +89,7 @@ The new external clock needs to be a square wave between +7dBm and +15dBm After the hardware modification, the user should burn the setting into the EEPROM, -so UHD can initialize with the correct clock rate. +so UHD software can initialize with the correct clock rate. Run the following commands to record the setting into the EEPROM: :: diff --git a/host/docs/usrp2.rst b/host/docs/usrp2.rst index e675e61ba..5f1e51ea9 100644 --- a/host/docs/usrp2.rst +++ b/host/docs/usrp2.rst @@ -148,7 +148,7 @@ any parameters: ifconfig -a **Note:** -When using UHD, if an IP address for the USRP2 is not specified, +When using UHD software, if an IP address for the USRP2 is not specified, the software will use UDP broadcast packets to locate the USRP2. On some systems, the firewall will block UDP broadcast packets. It is recommended that you change or disable your firewall settings. @@ -213,13 +213,13 @@ The following tips are designed to help narrow down and diagnose the problem. RuntimeError: no control response ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a common error that occurs when you have set the subnet of your network -interface to a different subnet than the network interface of the USRP. For -example, if your network interface is set to **192.168.20.1**, and the USRP is +interface to a different subnet than the network interface of the USRP device. For +example, if your network interface is set to **192.168.20.1**, and the USRP device is **192.168.10.2** (note the difference in the third numbers of the IP addresses), you will likely see a 'no control response' error message. Fixing this is simple - just set the your host PC's IP address to the same -subnet as that of your USRP. Instructions for setting your IP address are in the +subnet as that of your USRP device. Instructions for setting your IP address are in the previous section of this documentation. @@ -238,7 +238,7 @@ or create a rule to allow all incoming packets with UDP source port **49152**. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ping the device ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The USRP will reply to ICMP echo requests. +The USRP device will reply to ICMP echo requests. A successful ping response means that the device has booted properly and that it is using the expected IP address. @@ -346,7 +346,7 @@ the following clock configuration must be set on the slave device: ------------------------------------------------------------------------ Alternative stream destination ------------------------------------------------------------------------ -It is possible to program the USRP to send RX packets to an alternative IP/UDP destination. +It is possible to program the USRP device to send RX packets to an alternative IP/UDP destination. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Set the subnet and gateway @@ -429,7 +429,7 @@ Using a PPS signal for timestamp synchronization requires a square wave signal w Test the PPS input with the following app: -* **<args>** are device address arguments (optional if only one USRP is on your machine) +* **<args>** are device address arguments (optional if only one USRP device is on your machine) :: diff --git a/host/docs/usrp_b100.rst b/host/docs/usrp_b100.rst index cdb853b61..b5dc79b50 100644 --- a/host/docs/usrp_b100.rst +++ b/host/docs/usrp_b100.rst @@ -21,7 +21,7 @@ Comparative features list ------------------------------------------------------------------------ Specify a Non-standard Image ------------------------------------------------------------------------ -UHD will automatically select the USRP B-Series images from the installed images package. +UHD software 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: @@ -54,7 +54,7 @@ and X4 must be populated with a 61.44 MHz oscillator. * **J15** is a three pin header, move the jumper to (pin1, pin2) * **357LB3I061M4400** is the recommended oscillator for X4 -**Note:** See instructions below to communicate the desired clock rate into UHD. +**Note:** See instructions below to communicate the desired clock rate into UHD software. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Set other rates - uses internal VCO @@ -63,7 +63,7 @@ To use other clock rates, the jumper will need to be in the default position. * **J15** is a three pin header, move the jumper to (pin2, pin3) -To communicate the desired clock rate into UHD, +To communicate the desired clock rate into UHD software, specify the a special device address argument, where the key is **master_clock_rate** and the value is a rate in Hz. Example: diff --git a/host/docs/usrp_e1x0.rst b/host/docs/usrp_e1x0.rst index 189cbb86b..fc929e639 100644 --- a/host/docs/usrp_e1x0.rst +++ b/host/docs/usrp_e1x0.rst @@ -22,7 +22,7 @@ Comparative features list ------------------------------------------------------------------------ Specify a Non-standard Image ------------------------------------------------------------------------ -UHD will automatically select the USRP-Embedded FPGA image from the +UHD software will automatically select the USRP-Embedded FPGA image from the installed images package. The FPGA image selection can be overridden with the **--fpga=** device address parameter. @@ -53,7 +53,7 @@ on the device. * **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 UHD. +**Note:** See instructions below to communicate the desired clock rate to UHD software. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Set other rates - uses internal VCO @@ -63,7 +63,7 @@ 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 UHD, +To communicate the desired clock rate into UHD software, specify the a special device address argument, where the key is **master_clock_rate** and the value is a rate in Hz. Example: @@ -103,7 +103,7 @@ a connector. Test the PPS input with the following app: -* **<args** are device address arguments (optional if only one USRP is on your machine). +* **<args** are device address arguments (optional if only one USRP device is on your machine). :: @@ -116,7 +116,7 @@ Internal GPSDO Please see the `Internal GPSDO Application Notes <./gpsdo.html>`_ for information on configuring and using the internal GPSDO. -UHD will always try to detect an installed GPSDO at runtime. +UHD software will always try to detect an installed GPSDO at runtime. There is not a special EEPROM value to burn for GPSDO detection. ------------------------------------------------------------------------ |