diff options
| -rw-r--r-- | host/docs/build.rst | 34 | ||||
| -rw-r--r-- | host/docs/dboards.rst | 48 | ||||
| -rw-r--r-- | host/docs/general.rst | 14 | ||||
| -rw-r--r-- | host/docs/gpsdo.rst | 10 | ||||
| -rw-r--r-- | host/docs/identification.rst | 6 | ||||
| -rw-r--r-- | host/docs/index.rst | 6 | ||||
| -rw-r--r-- | host/docs/stream.rst | 14 | ||||
| -rw-r--r-- | host/docs/sync.rst | 2 | ||||
| -rw-r--r-- | host/docs/transport.rst | 14 | ||||
| -rw-r--r-- | host/docs/usrp1.rst | 14 | ||||
| -rw-r--r-- | host/docs/usrp2.rst | 50 | ||||
| -rw-r--r-- | host/docs/usrp_b1xx.rst | 30 | ||||
| -rw-r--r-- | host/docs/usrp_e1xx.rst | 49 |
13 files changed, 145 insertions, 146 deletions
diff --git a/host/docs/build.rst b/host/docs/build.rst index d33bea363..0a18e9e9a 100644 --- a/host/docs/build.rst +++ b/host/docs/build.rst @@ -28,8 +28,8 @@ follow the auxiliary download URL for the Windows installer (below). Git ^^^^^^^^^^^^^^^^ Required to check out the repository. -On Windows, install Cygwin with Git support to checkout the repository, -or install msysGit from http://code.google.com/p/msysgit/downloads/list +On Windows, install Cygwin with Git support to checkout the repository +or install msysGit from http://code.google.com/p/msysgit/downloads/list. ^^^^^^^^^^^^^^^^ C++ Compiler @@ -84,7 +84,7 @@ Cheetah * **Download URL (Windows installer):** http://feisley.com/python/cheetah/ **Alternative method:** -Install setuptools, and use the easy_install command to install Cheetah. +Install **setuptools**, and use the **easy_install** command to install Cheetah. http://pypi.python.org/pypi/setuptools ^^^^^^^^^^^^^^^^ @@ -102,7 +102,7 @@ Docutils * **Download URL:** http://docutils.sourceforge.net/ **Alternate method:** -Install setuptools, and use the easy_install command to install Docutils. +Install **setuptools**, and use the **easy_install** command to install Docutils. http://pypi.python.org/pypi/setuptools ------------------------------------------------------------------------ @@ -122,8 +122,8 @@ Generate Makefiles with CMake Additionally, configuration variables can be passed into CMake via the command line. The following common-use configuration variables are listed below: -* For a custom install prefix: -DCMAKE_INSTALL_PREFIX=<install-path> -* To install libs into lib64: cmake -DLIB_SUFFIX=64 +* For a custom install prefix: **-DCMAKE_INSTALL_PREFIX=<install-path>** +* To install libs into lib64: **cmake -DLIB_SUFFIX=64** Example usage: :: @@ -142,8 +142,8 @@ Build and install ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Setup the library path (Linux) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Make sure that libuhd.so is in your LD_LIBRARY_PATH, -or add it to /etc/ld.so.conf and make sure to run: +Make sure that **libuhd.so** is in your **LD_LIBRARY_PATH**, +or add it to **/etc/ld.so.conf** and make sure to run: :: sudo ldconfig @@ -151,7 +151,7 @@ or add it to /etc/ld.so.conf and make sure to run: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Setup the library path (Mac OS X) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Make sure that libuhd.dylib is in your DYLD_LIBRARY_PATH. +Make sure that **libuhd.dylib** is in your **DYLD_LIBRARY_PATH**. ------------------------------------------------------------------------ Build Instructions (Windows) @@ -161,8 +161,8 @@ Build Instructions (Windows) Generate the project with CMake ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Open the CMake GUI. -* Set the path to the source code: <uhd-repo-path>/host -* Set the path to the build directory: <uhd-repo-path>/host/build +* Set the path to the source code: **<uhd-repo-path>/host**. +* Set the path to the build directory: **<uhd-repo-path>/host/build**. * Make sure that the paths do not contain spaces. * Click "Configure" and select "Microsoft Visual Studio 10". * Set the build variables and click "Configure" again. @@ -171,14 +171,14 @@ Generate the project with CMake ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LibUSB CMake notes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -On Windows, CMake does not have the advantage of pkg-config, +On Windows, CMake does not have the advantage of **pkg-config**, so we must manually tell CMake how to locate the LibUSB header and lib. * From the CMake GUI, select "Advanced View". -* Set LIBUSB_INCLUDE_DIRS to the directory with "libusb.h". -* Set LIBUSB_LIBRARIES to the full path for "libusb-1.0.lib". +* Set **LIBUSB_INCLUDE_DIRS** to the directory with **libusb.h**. +* Set **LIBUSB_LIBRARIES** to the full path for **libusb-1.0.lib**. - * Recommend the static libusb-1.0.lib to simplify runtime dependencies. + * Recommend the static **libusb-1.0.lib** to simplify runtime dependencies. * Check the box to enable USB support, click "Configure" and "Generate". @@ -206,10 +206,10 @@ Open the Visual Studio Command Prompt Shorcut: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Setup the PATH environment variable ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -* Add the UHD bin path to %PATH% (usually c:\\program files\\uhd\\bin) +* Add the UHD bin path to **%PATH%** (usually **C:\\Program Files\\UHD\\bin**) **Note:** -The interface for editing environment variable paths in Windows is very poor. +The default interface for editing environment variable paths in Windows is very poor. We recommend using "Rapid Environment Editor" (http://www.rapidee.com) over the default editor. ------------------------------------------------------------------------ diff --git a/host/docs/dboards.rst b/host/docs/dboards.rst index f434bf0c2..29812592f 100644 --- a/host/docs/dboards.rst +++ b/host/docs/dboards.rst @@ -28,13 +28,13 @@ greater than the Nyquist rate of the ADC. BasicRX Bandwidth (Hz): -* For Real-Mode (A or B frontend): 250M -* For Complex (AB or BA frontend): 500M +* **For Real-Mode (A or B frontend)**: 250M +* **For Complex (AB or BA frontend)**: 500M LFRX Bandwidth (Hz): -* For Real-Mode (A or B frontend): 33M -* For Complex (AB or BA frontend): 66M +* **For Real-Mode (A or B frontend)**: 33M +* **For Complex (AB or BA frontend)**: 66M ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Basic TX and LFTX @@ -52,13 +52,13 @@ greater than the Nyquist rate of the DAC. BasicTX Bandwidth (Hz): 250M -* For Real-Mode (A or B frontend): 250M -* For Complex (AB or BA frontend): 500M +* **For Real-Mode (A or B frontend**): 250M +* **For Complex (AB or BA frontend)**: 500M LFTX Bandwidth (Hz): 33M -* For Real-Mode (A or B frontend): 33M -* For Complex (AB or BA frontend): 66M +* **For Real-Mode (A or B frontend)**: 33M +* **For Complex (AB or BA frontend)**: 66M ^^^^^^^^^^^^^^^^^^^^^^^^^^^ DBSRX @@ -185,7 +185,7 @@ WBX Series ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The WBX Series boards have 2 quadrature frontends, one transmit, one receive. Transmit and Receive default to direct conversion but -can be used in low IF mode through lo_offset in uhd::tune_request_t +can be used in low IF mode through lo_offset in **uhd::tune_request_t**. The WBX Series boards have independent receive and transmit LO's and synthesizers allowing full-duplex operation on different transmit and receive frequencies. @@ -218,7 +218,7 @@ SBX Series ^^^^^^^^^^^^^^^^^^^^^^^^^^^ The SBX Series boards have 2 quadrature frontends, one transmit, one receive. Transmit and Receive default to direct conversion but -can be used in low IF mode through lo_offset in uhd::tune_request_t +can be used in low IF mode through lo_offset in **uhd::tune_request_t**. The SBX Series boards have independent receive and transmit LO's and synthesizers allowing full-duplex operation on different transmit and receive frequencies. @@ -319,13 +319,13 @@ over the standard daughterboard clock lines. **Step 1: Move the clock configuration resistor** -Remove R193 (which is 10 ohms, 0603 size), and put it on R194, which is empty. +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, +**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. +If you lose **R193**, you can use anything from 0 to 10 ohms there. **Step 2: Burn a new daughterboard id into the EEPROM** @@ -335,8 +335,8 @@ 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 is on your machine) +* **<slot>** is the name of the daughterboard slot (optional if the USRP has only one slot) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ RFX - Mod @@ -347,12 +347,12 @@ Please follow the modification procedures below: **Step 1: Disable the daughterboard clocks** -Move R64 to R84, Move R142 to R153 +Move **R64** to **R84**. Move **R142** to **R153**. **Step 2: Connect the motherboard blocks** -Move R35 to R36, Move R117 to R115 -These are all 0-ohm, so if you lose one, just short across the appropriate pads +Move **R35** to **R36**. Move **R117** to **R115**. +These are all 0-ohm, so if you lose one, just short across the appropriate pads. **Step 3: Burn the appropriate daughterboard ID into the EEPROM** @@ -363,19 +363,19 @@ With the daughterboard plugged-in, run the following commands: ./usrp_burn_db_eeprom --id=<rx_id> --unit=RX --args=<args> --slot=<slot> ./usrp_burn_db_eeprom --id=<tx_id> --unit=TX --args=<args> --slot=<slot> -* <rx_id> choose the appropriate RX ID for your daughterboard +* **<rx_id>** choose the appropriate RX ID for your daughterboard * **RFX400:** 0x0024 * **RFX900:** 0x0025 * **RFX1800:** 0x0034 * **RFX1200:** 0x0026 * **RFX2400:** 0x0027 -* <tx_id> choose the appropriate TX ID for your daughterboard +* **<tx_id>** choose the appropriate TX ID for your daughterboard * **RFX400:** 0x0028 * **RFX900:** 0x0029 * **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 is on your machine) +* **<slot>** is the name of the daughterboard slot (optional if the USRP has only one slot) diff --git a/host/docs/general.rst b/host/docs/general.rst index ebba7b532..fc7caff3c 100644 --- a/host/docs/general.rst +++ b/host/docs/general.rst @@ -50,7 +50,7 @@ After tuning, the RF front-end will need time to settle into a usable state. Typically, this means that the local oscillators must be given time to lock before streaming begins. Lock time is not consistent; it varies depending upon the device and requested settings. After tuning and before streaming, the user -should wait for the "lo_locked" sensor to become true, or sleep for +should wait for the **lo_locked** sensor to become true or sleep for a conservative amount of time (perhaps a second). Pseudo-code for dealing with settling time after tuning on receive: @@ -184,12 +184,12 @@ This error is harmless; it simply means that the thread will have a normal sched **Linux Notes:** Non-privileged users need special permission to change the scheduling priority. -Add the following line to */etc/security/limits.conf*: +Add the following line to **/etc/security/limits.conf**: :: @<my_group> - rtprio 99 -Replace <my_group> with a group to which your user belongs. +Replace **<my_group>** with a group to which your user belongs. Settings will not take effect until the user is in a different login session. ------------------------------------------------------------------------ @@ -201,9 +201,9 @@ Support for dynamically loadable modules ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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). +* 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 @@ -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 UHD: :: diff --git a/host/docs/gpsdo.rst b/host/docs/gpsdo.rst index 2f3655eff..f5e6f5e57 100644 --- a/host/docs/gpsdo.rst +++ b/host/docs/gpsdo.rst @@ -11,11 +11,11 @@ to the Jackson Labs Firefly-1A device unless noted otherwise. ------------------------------------------------------------------------ Specifications ------------------------------------------------------------------------ -* Receiver type: 50 channel with WAAS, EGNOS, MSAS -* 10MHz ADEV: 1e-11 over >24h -* 1PPS RMS jitter: <50ns 1-sigma -* Holdover: <11us over 3h -* Phase noise: +* **Receiver type**: 50 channel with WAAS, EGNOS, MSAS +* **10MHz ADEV**: 1e-11 over >24h +* **1PPS RMS jitter**: <50ns 1-sigma +* **Holdover**: <11us over 3h +* **Phase noise**: * **1Hz:** -80dBc/Hz * **10Hz:** -110dBc/Hz diff --git a/host/docs/identification.rst b/host/docs/identification.rst index 4e653ad06..a5e60e7f9 100644 --- a/host/docs/identification.rst +++ b/host/docs/identification.rst @@ -55,14 +55,14 @@ Device address arguments can be supplied to narrow the scope of the search. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Device discovery through the API ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The device::find() API call searches for devices and returns a list of discovered devices. +The **device::find()** API call searches for devices and returns a list of discovered devices. :: uhd::device_addr_t hint; //an empty hint discovers all devices uhd::device_addrs_t dev_addrs = uhd::device::find(hint); -The hint argument can be populated to narrow the scope of the search. +The **hint** argument can be populated to narrow the scope of the search. :: @@ -114,7 +114,7 @@ Run the following commands: Discovery via name ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The keyword "name" can be used to narrow the scope of the search. +The keyword **name** can be used to narrow the scope of the search. Example with the find devices utility: :: diff --git a/host/docs/index.rst b/host/docs/index.rst index 8ad1dcb65..8649e7ce3 100644 --- a/host/docs/index.rst +++ b/host/docs/index.rst @@ -2,8 +2,8 @@ UHD - USRP Hardware Driver ======================================================================== -The UHD is the "Universal Software Radio Peripheral" hardware driver. -The goal of the UHD is to provide a host driver and API for current and future Ettus Research products. +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. Users will be able to use the UHD driver standalone or with third-party applications. ------------------------------------------------------------------------ @@ -11,7 +11,7 @@ Contents ------------------------------------------------------------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Building and Installing the UHD +Building and Installing UHD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * `Build Guide <./build.html>`_ * `Installation Guide (Linux) <http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux>`_ diff --git a/host/docs/stream.rst b/host/docs/stream.rst index 054ec37dd..13523c077 100644 --- a/host/docs/stream.rst +++ b/host/docs/stream.rst @@ -9,7 +9,7 @@ Introduction to Streaming ------------------------------------------------------------------------ The concept of streaming refers to the transportation of samples between host and device. A stream is an object that facilitates streaming between host application and device. -A RX stream allows the user to receive samples from the device. +An RX stream allows the user to receive samples from the device. A TX stream allows the user to transmit samples to the device. ------------------------------------------------------------------------ @@ -22,9 +22,9 @@ Sample decoration is exposed to the user in the form of RX and TX metadata struc The length of an IF data packet can be limited by several factors: -* MTU of the link layer - network card, network switch -* Buffering on the host - frame size in a ring buffer -* Buffering on the device - size of BRAM FIFOs +* **MTU of the link layer:** network card, network switch +* **Buffering on the host:** frame size in a ring buffer +* **Buffering on the device:** size of BRAM FIFOs ------------------------------------------------------------------------ Data Types @@ -38,15 +38,15 @@ There are two important data types to consider when streaming: The host/CPU data type ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The host data type refers to the format of samples used in the host for baseband processing. -Typically, the data type is complex baseband such as normalized complex-float32 or complex-int16. +Typically, the data type is complex baseband such as normalized **complex-float32** or **complex-int16**. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The link-layer data type ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The link-layer or "over-the-wire" data type refers to the format of the samples sent through the link. -Typically, this data type is complex-int16. +Typically, this data type is **complex-int16*. However, to increase throughput over the link-layer, -at the expense of precision, complex-int8 may be used. +at the expense of precision, **complex-int8** may be used. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Conversion diff --git a/host/docs/sync.rst b/host/docs/sync.rst index 4c0756555..4cf52e38d 100644 --- a/host/docs/sync.rst +++ b/host/docs/sync.rst @@ -52,7 +52,7 @@ MIMO cable reference signals ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. +Users of the MIMO cable may use Method 1 (explained below) to synchronize multiple pairs of devices. :: diff --git a/host/docs/transport.rst b/host/docs/transport.rst index 111c46c68..b136f3e87 100644 --- a/host/docs/transport.rst +++ b/host/docs/transport.rst @@ -92,7 +92,7 @@ Also, consult: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Linux specific notes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -On linux, the maximum buffer sizes are capped by the sysctl values +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: :: @@ -100,7 +100,7 @@ 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* +Set the values permanently by editing **/etc/sysctl.conf**. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Windows specific notes @@ -114,8 +114,8 @@ FastSendDatagramThreshold registry key to change documented here: ------------------------------------------------------------------------ USB Transport (LibUSB) ------------------------------------------------------------------------ -The USB transport is implemented with libusb. -Libusb provides an asynchronous API for USB bulk transfers. +The USB transport is implemented with LibUSB. +LibUSB provides an asynchronous API for USB bulk transfers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Transport parameters @@ -145,9 +145,9 @@ Install USB driver (Windows) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A driver package must be installed to use a USB-based product with UHD: -* Download the driver from the UHD wiki page. -* Unzip the file into a known location. We will refer to this as the <directory>. +* 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. * 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. +* 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 b698da96e..6242ccb6a 100644 --- a/host/docs/usrp1.rst +++ b/host/docs/usrp1.rst @@ -5,7 +5,7 @@ UHD - USRP1 Application Notes .. contents:: Table of Contents ------------------------------------------------------------------------ -Specify a non-standard image +Specify a Non-standard Image ------------------------------------------------------------------------ The standard USRP1 images installer comes with two FPGA images: * **usrp1_fpga.rbf:** 2 DDCs + 2 DUCs @@ -31,7 +31,7 @@ Example device address string representations to specify non-standard firmware a fpga=usrp1_fpga_4rx.rbf, fw=usrp1_fw_custom.ihx ------------------------------------------------------------------------ -Missing and emulated features +Missing and Emulated Features ------------------------------------------------------------------------ The USRP1 FPGA does not have the necessary space to support the advanced streaming capabilities that are possible with the newer USRP devices. @@ -62,17 +62,17 @@ List of missing features * Start of burst flags for transmit/receive ------------------------------------------------------------------------ -Hardware setup notes +Hardware Setup Notes ------------------------------------------------------------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ External clock modification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The USRP 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 - * Remove 0.01uF 0603 capacitor C924 + * Solder SMA (**LTI-SASF54GT**) connector to **J2001**. + * Move 0 ohm 0603 resistor **R2029** to **R2030**. + * Move 0.01uF 0603 capacitor **C925** to **C926**. + * Remove 0.01uF 0603 capacitor **C924**. The new external clock needs to be a square wave between +7dBm and +15dBm diff --git a/host/docs/usrp2.rst b/host/docs/usrp2.rst index 452d4f9af..8a2782982 100644 --- a/host/docs/usrp2.rst +++ b/host/docs/usrp2.rst @@ -5,11 +5,11 @@ UHD - USRP2 and N Series Application Notes .. contents:: Table of Contents ------------------------------------------------------------------------ -Load the images onto the SD card (USRP2 only) +Load the Images onto the SD card (USRP2 only) ------------------------------------------------------------------------ **Warning!** -Use the usrp2_card_burner.py with caution. If you specify the wrong device node, -you could overwrite your hard drive. Make sure that --dev= specifies the SD card. +Use **usrp2_card_burner.py** with caution. If you specify the wrong device node, +you could overwrite your hard drive. Make sure that **--dev=** specifies the SD card. **Warning!** It is possible to use 3rd party SD cards with the USRP2. @@ -33,7 +33,7 @@ Use the card burner tool (UNIX) sudo ./usrp2_card_burner.py --dev=/dev/sd<XXX> --fpga=<path_to_fpga_image> sudo ./usrp2_card_burner.py --dev=/dev/sd<XXX> --fw=<path_to_firmware_image> -Use the *--list* option to get a list of possible raw devices. +Use the **--list** option to get a list of possible raw devices. The list result will filter out disk partitions and devices too large to be the sd card. The list option has been implemented on Linux, Mac OS X, and Windows. @@ -45,7 +45,7 @@ Use the card burner tool (Windows) <path_to_python.exe> <install-path>/share/uhd/utils/usrp2_card_burner_gui.py ------------------------------------------------------------------------ -Load the images onto the on-board flash (USRP-N Series only) +Load the Images onto the On-board Flash (USRP-N Series only) ------------------------------------------------------------------------ The USRP-N Series can be reprogrammed over the network to update or change the firmware and FPGA images. @@ -91,7 +91,7 @@ Continue to hold-down the button until the front-panel LEDs blink and remain sol When in safe-mode, the USRP-N device will always have the IP address **192.168.10.2**. ------------------------------------------------------------------------ -Setup networking +Setup Networking ------------------------------------------------------------------------ The USRP2 only supports Gigabit Ethernet and will not work with a 10/100 Mbps interface. @@ -102,7 +102,7 @@ to a USRP2 through a Gigabit Ethernet switch. Setup the host interface ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The USRP2 communicates at the IP/UDP layer over the gigabit ethernet. -The default IP address of the USRP2 is **192.168.10.2** +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 of **255.255.255.0** is recommended. @@ -113,15 +113,15 @@ On a Linux system, you can set a static IP address very easily by using the sudo ifconfig <interface> 192.168.10.1 -Note that <interface> is usually something like 'eth0'. You can discover the -names of the network interfaces in your computer by running 'ifconfig' without +Note that **<interface>** is usually something like **eth0**. You can discover the +names of the network interfaces in your computer by running **ifconfig** without any parameters: :: ifconfig -a **Note:** -When using the UHD, if an IP address for the USRP2 is not specified, +When using UHD, 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. @@ -168,7 +168,7 @@ Run the following commands: **Method 2 (Linux Only):** This method assumes that you do not know the IP address of your USRP2. -It uses raw ethernet packets to bypass the IP/UDP layer to communicate with the USRP2. +It uses raw Ethernet packets to bypass the IP/UDP layer to communicate with the USRP2. Run the following commands: :: @@ -176,7 +176,7 @@ Run the following commands: sudo ./usrp2_recovery.py --ifc=eth0 --new-ip=192.168.10.3 ------------------------------------------------------------------------ -Communication problems +Communication Problems ------------------------------------------------------------------------ When setting up a development machine for the first time, you may have various difficulties communicating with the USRP device. @@ -187,7 +187,7 @@ 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 +example, if your network interface is set to **192.168.20.1**, and the USRP 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. @@ -206,7 +206,7 @@ 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 the case, we recommend that you disable the firewall -or create a rule to allow all incoming packets with UDP source port 49152. +or create a rule to allow all incoming packets with UDP source port **49152**. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ping the device @@ -226,8 +226,8 @@ Read the serial port to get debug verbose output from the embedded microcontroll The microcontroller prints useful information about IP addresses, MAC addresses, control packets, fast-path settings, and bootloading. Use a standard USB to 3.3v-level serial converter at 230400 baud. -Connect GND to the converter ground, and connect TXD to the converter receive. -The RXD pin can be left unconnected as this is only a one-way communication. +Connect **GND** to the converter ground, and connect **TXD** to the converter receive. +The **RXD** pin can be left unconnected as this is only a one-way communication. * **USRP2:** Serial port located on the rear edge * **N210:** Serial port located on the left side @@ -238,7 +238,7 @@ Monitor the host network traffic Use Wireshark to monitor packets sent to and received from the device. ------------------------------------------------------------------------ -Addressing the device +Addressing the Device ------------------------------------------------------------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -248,7 +248,7 @@ In a single-device configuration, the USRP device must have a unique IPv4 address on the host computer. The USRP can be identified through its IPv4 address, resolvable hostname, or by other means. See the application notes on `device identification <./identification.html>`_. -Use this addressing scheme with the *single_usrp* interface. +Use this addressing scheme with the **single_usrp** interface. Example device address string representation for a USRP2 with IPv4 address **192.168.10.2**: @@ -263,7 +263,7 @@ In a multi-device configuration, each USRP device must have a unique IPv4 address on the host computer. The device address parameter keys must be suffixed with the device index. Each parameter key should be of the format <key><index>. -Use this addressing scheme with the *multi_usrp* interface. +Use this addressing scheme with the **multi_usrp** interface. * The order in which devices are indexed corresponds to the indexing of the transmit and receive channels. * The key indexing provides the same granularity of device identification as in the single device case. @@ -316,7 +316,7 @@ the following clock configuration must be set on the slave device: usrp->set_clock_config(clock_config, slave_index); ------------------------------------------------------------------------ -Hardware setup notes +Hardware Setup Notes ------------------------------------------------------------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -353,7 +353,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 is on your machine) :: @@ -386,13 +386,13 @@ Multiple RX channels There are two complete DDC chains in the FPGA. In the single channel case, only one chain is ever used. To receive from both channels, -the user must set the RX subdevice specification. +the user must set the **RX** subdevice specification. This hardware has only one daughterboard slot, -which has been aptly named slot "A". +which has been aptly named slot **A**. In the following example, a TVRX2 is installed. -Channel 0 is sourced from subdevice RX1, -channel 1 is sourced from subdevice RX2: +Channel 0 is sourced from subdevice **RX1**, +and channel 1 is sourced from subdevice **RX2**: :: usrp->set_rx_subdev_spec("A:RX1 A:RX2"); diff --git a/host/docs/usrp_b1xx.rst b/host/docs/usrp_b1xx.rst index 564fb89be..b38936021 100644 --- a/host/docs/usrp_b1xx.rst +++ b/host/docs/usrp_b1xx.rst @@ -5,10 +5,10 @@ UHD - USRP-B1XX Series Application Notes .. contents:: Table of Contents ------------------------------------------------------------------------ -Specify a non-standard image +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. +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: @@ -21,37 +21,37 @@ Example device address string representations to specify non-standard images: fw=usrp_b100_fw_firmware.ihx ------------------------------------------------------------------------ -Changing the master clock rate +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 +* **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) +* **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. +**Note:** See instructions below to communicate the desired clock rate into 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) +* **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, +To communicate the desired clock rate into UHD, specify the a special device address argument, -where the key is "master_clock_rate" and the value is a rate in Hz. +where the key is **master_clock_rate** and the value is a rate in Hz. Example: :: @@ -84,4 +84,4 @@ Available Sensors The following sensors are available; they can be queried through the API. -* ref_locked - clock reference locked (internal/external) +* **ref_locked:** clock reference locked (internal/external) diff --git a/host/docs/usrp_e1xx.rst b/host/docs/usrp_e1xx.rst index ef1e22b3a..31a47347f 100644 --- a/host/docs/usrp_e1xx.rst +++ b/host/docs/usrp_e1xx.rst @@ -5,11 +5,11 @@ UHD - USRP-E1XX Series Application Notes .. contents:: Table of Contents ------------------------------------------------------------------------ -Specify a non-standard image +Specify a Non-standard Image ------------------------------------------------------------------------ UHD 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. +**--fpga=** device address parameter. Example device address string representations to specify non-standard FPGA image: @@ -19,15 +19,15 @@ image: fpga=usrp_e100_custom.bin ------------------------------------------------------------------------ -Changing the master clock rate +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 +* **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 @@ -35,23 +35,22 @@ Set 61.44MHz - uses external VCXO To use the 61.44MHz clock rate with the USRP-Embedded, two jumpers must be moved 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) +* **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. +**Note:** See instructions below to communicate the desired clock rate 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) +* **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, +To communicate the desired clock rate into UHD, specify the a special device address argument, -where the key is "master_clock_rate" and the value is a rate in Hz. +where the key is **master_clock_rate** and the value is a rate in Hz. Example: :: @@ -66,15 +65,15 @@ Clock Synchronization Ref Clock - 10MHz ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The E1xx has a 10MHz TCXO which can be used to discipline the flexible clocking -by selecting REF_INT for the clock_config_t. +by selecting **REF_INT** for the **clock_config_t**. Alternately, an external 10MHz reference clock can be supplied by soldering a connector. -* Connector J10 (REF_IN) needs MCX connector WM5541-ND or similar -* Square wave will offer the best phase noise performance, but sinusoid is acceptable -* Power level: 0 to 15dBm -* Select REF_SMA in clock_config_t +* Connector **J10** (REF_IN) needs MCX connector **WM5541-ND** or similar. +* Square wave will offer the best phase noise performance, but sinusoid is acceptable. +* **Power level:** 0 to 15dBm +* Select **REF_SMA** in **clock_config_t**. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -83,13 +82,13 @@ PPS - Pulse Per Second An exteral PPS signal for timestamp synchronization can be supplied by soldering a connector. -* Connector J13 (PPS) needs MCX connector WM5541-ND or similar -* Requires a square wave signal -* Amplitude: 3.3 to 5Vpp +* Connector **J13** (PPS) needs MCX connector **WM5541-ND** or similar. +* Requires a square wave signal. +* **Amplitude:** 3.3 to 5Vpp 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 is on your machine). :: @@ -106,7 +105,7 @@ UHD will always try to detect an installed GPSDO at runtime. There is not a special EEPROM value to burn for GPSDO detection. ------------------------------------------------------------------------ -Hardware setup notes +Hardware Setup Notes ------------------------------------------------------------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -132,5 +131,5 @@ Available Sensors The following sensors are available; they can be queried through the API. -* ref_locked - clock reference locked (internal/external) +* **ref_locked:** clock reference locked (internal/external) * other sensors are added when the GPSDO is enabled |