diff options
Diffstat (limited to 'host/docs')
| -rw-r--r-- | host/docs/CMakeLists.txt | 3 | ||||
| -rw-r--r-- | host/docs/build.dox | 18 | ||||
| -rw-r--r-- | host/docs/dboards.dox | 4 | ||||
| -rw-r--r-- | host/docs/octoclock.dox | 31 | ||||
| -rw-r--r-- | host/docs/uhd.dox | 1 | ||||
| -rw-r--r-- | host/docs/uhd_image_loader.1 | 130 | ||||
| -rw-r--r-- | host/docs/usrp2.dox | 29 | ||||
| -rw-r--r-- | host/docs/usrp_b200.dox | 31 | ||||
| -rw-r--r-- | host/docs/usrp_e3x0.dox | 6 | ||||
| -rw-r--r-- | host/docs/usrp_x3x0.dox | 24 | ||||
| -rw-r--r-- | host/docs/usrp_x3x0_config.dox | 34 | ||||
| -rw-r--r-- | host/docs/vrt_chdr.dox | 83 |
12 files changed, 290 insertions, 104 deletions
diff --git a/host/docs/CMakeLists.txt b/host/docs/CMakeLists.txt index d0f060ceb..79488e373 100644 --- a/host/docs/CMakeLists.txt +++ b/host/docs/CMakeLists.txt @@ -1,5 +1,5 @@ # -# Copyright 2010-2013 Ettus Research LLC +# Copyright 2010-2013,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 @@ -120,6 +120,7 @@ SET(man_page_sources uhd_cal_tx_dc_offset.1 uhd_cal_tx_iq_balance.1 uhd_find_devices.1 + uhd_image_loader.1 uhd_images_downloader.1 uhd_usrp_probe.1 usrp_n2xx_simple_net_burner.1 diff --git a/host/docs/build.dox b/host/docs/build.dox index 1097ab5ab..f3fdf5aa6 100644 --- a/host/docs/build.dox +++ b/host/docs/build.dox @@ -11,7 +11,7 @@ package manager. <b>Mac OS X Notes:</b> Install the Xcode app to get the build tools (GCC and Make). -Use MacPorts to get the Boost and Cheetah dependencies. +Use MacPorts to get the Boost and Mako dependencies. Other dependencies can be downloaded as DMG installers from the web or installed via MacPorts. See the UHD OS X build instructions for more information: \ref build_instructions_osx @@ -57,22 +57,20 @@ Other compilers (or lower versions) may work, but are unsupported. ### Python -- **Purpose:** used by Cheetah and utility scripts +- **Purpose:** used by mako and utility scripts - **Minimum Version:** 2.6 - **Usage:** build time + runtime utility scripts (required) - **Download URL:** http://www.python.org/download/ -### Cheetah +### Mako - **Purpose:** source code generation -- **Minimum Version:** 2.0 +- **Minimum Version:** 0.5.0 - **Usage:** build time (required) -- **Download URL:** http://www.cheetahtemplate.org/download.html -- **Download URL (Windows installer):** http://feisley.com/python/cheetah/ +- **Download URL:** http://www.makotemplates.org/download.html **Alternative method:** -Install **setuptools**, and use the **easy_install** command to install Cheetah. -http://pypi.python.org/pypi/setuptools +You can use `pip` or `easy_install` to install Mako from PyPi. ### Doxygen @@ -96,7 +94,7 @@ or install msysGit from http://code.google.com/p/msysgit/downloads/list. You can install all the dependencies through the package manager: - sudo apt-get install libboost-all-dev libusb-1.0-0-dev python-cheetah doxygen python-docutils cmake + sudo apt-get install libboost-all-dev libusb-1.0-0-dev python-mako doxygen python-docutils cmake Your actual command may differ. @@ -104,7 +102,7 @@ Your actual command may differ. You can install all the dependencies through the package manager: - sudo yum -y install boost-devel libusb1-devel python-cheetah doxygen python-docutils cmake + sudo yum -y install boost-devel libusb1-devel python-mako doxygen python-docutils cmake Your actual command may differ. diff --git a/host/docs/dboards.dox b/host/docs/dboards.dox index 3d6866a42..812a3a09e 100644 --- a/host/docs/dboards.dox +++ b/host/docs/dboards.dox @@ -372,6 +372,10 @@ Sensors: - **rssi**: float for measured RSSI in dBm - **temperature**: float for measured temperature in degC +\subsection dboards_e300 E310 MIMO XCVR board + +Please refer to \ref e3x0_dboard_e310. + \subsection dboards_dbsrxmod DBSRX - Modifying for other boards that USRP1 Due to different clocking capabilities, the DBSRX will require diff --git a/host/docs/octoclock.dox b/host/docs/octoclock.dox index 7469e0719..362ee779f 100644 --- a/host/docs/octoclock.dox +++ b/host/docs/octoclock.dox @@ -7,41 +7,24 @@ - Hardware Capabilities: - Fully integrated timing source with 8-Way distribution (10 MHz and 1 PPS) - User selection between internal GPSDO (when present) or external 10 MHz/1 PPS source + - Ethernet bootloader for easy firmware upgrade - Source detection with automatic switch over in case of failure or disconnect - Streaming GPS time and NMEA strings over Ethernet (OctoClock-G only) \section octoclock_load Loading Firmware onto the Octoclock -\subsection bootloader OctoClock bootloader - -If you purchased your OctoClock device before Ethernet functionality was introduced, or if your unit's -bootloader has somehow become corrupted, you must burn the bootloader onto the device before you can load -the primary firmware. - -To load the bootloader onto the OctoClock, two things are needed: - -- AVR programmer -- AVRdude software - -Connect the AVR programmer to J108, as specified on the <a href="http://files.ettus.com/schematics/octoclock/octoclock.pdf"> -schematics</a>. Once you verify that the programmer is properly connected, run the following commands to burn the firmware: +First, the OctoClock's bootloader needs to be loaded onto the device. Connect the AVR programmer to J108, as +specified on the <a href="http://files.ettus.com/schematics/octoclock/octoclock.pdf">schematics</a>. Once you +verify that the programmer is properly connected, run the following commands to load the bootloader: cd <install path>/share/uhd/images - avrdude -p atmega128 -c <programmer name> -P usb -U efuse:w:0xFF:m -U hfuse:w:0x80:m -U lfuse:w:0xFF:m -U flash:w:octoclock_bootloader.hex:i + avrdude -p atmega128 -c <programmer name> -P usb -U efuse:w:0xFF:m -U hfuse:w:0x80:m -U lfuse:w:0xEF:m -U flash:w:octoclock_r4_fw.hex:i + +When the bootloader is loaded, it will have a default IP address of `192.168.10.3`. \b Note: On Linux, `sudo avrdude ...` might be necessary to gain access to the programmer. -Once the bootloader has been burned, power-cycle your OctoClock device and refer to the below instructions on burning the OctoClock's -primary firmware. - -\subsection application Primary Octoclock firmware - -To load firmware onto the OctoClock, you must use the `octoclock_firmware_burner` utility, specifying the IP -address of the OctoClock device, as follows: - - octoclock_firmware_burner --addr=192.168.10.3 - \section octoclock_network Setting Up Networking \subsection host_interface Setting up the host interface diff --git a/host/docs/uhd.dox b/host/docs/uhd.dox index 949c710b1..fcd0a25b0 100644 --- a/host/docs/uhd.dox +++ b/host/docs/uhd.dox @@ -12,6 +12,7 @@ Some additional pages on developing UHD are also available here: \li \subpage page_coding \li \subpage page_converters \li \subpage page_stream +\li \subpage page_rtp */ // vim:ft=doxygen: diff --git a/host/docs/uhd_image_loader.1 b/host/docs/uhd_image_loader.1 new file mode 100644 index 000000000..5d5c88ec5 --- /dev/null +++ b/host/docs/uhd_image_loader.1 @@ -0,0 +1,130 @@ +.TH "uhd_image_loader" 1 "3.9.0" UHD "User Commands" +.SH NAME +uhd_image_loader - UHD Image Loader + +.SH DESCRIPTION +Burn firmware and FPGA images onto connected Ettus Research devices. + +.SH SYNOPSIS +.B uhd_image_loader [OPTIONS] + +.SH OPTIONS +.IP "List options:" +--help +.IP "Device and loader arguments:" +--args="" +.IP "Custom firmware filepath:" +--fw-path="" +.IP "Custom FPGA filepath:" +--fpga-path="" +.IP "Don't burn firmware:" +--no-fw +.IP "Don't burn FPGA:" +--no-fpga + +.SH SPECIFYING A PARTICULAR DEVICE +.sp +Without any arguments given through the \fIargs=""\fR option, this utility will start a session +with the first Ettus Research device it sees. The arguments shown below will narrow down the +utility's search for a particular device: + +.SS All devices +.sp +The \fIname=\fR and \fIserial=\fR arguments can be used to specify any device except an +uninitialized USB device or an OctoClock bootloader. The \fItype=\fR argument can be used +to specify any device, as described below: + +"type=" argument + +Argument | Device + +type=usrp2 | USRP N200, USRP N210 + +type=b200 | USRP B200, USRP B210 + +type=e100 | USRP E100, USRP E110 + +type=e3x0 | USRP E310 + +type=octoclock | OctoClock + +.sp +NOTE: The USRP1, USRP2, and USRP B100 are not supported. + +.SS Network devices +.sp +By default, this utility will check all network interfaces for network-based devices, but a specific +IP address can be specified with the \fIaddr=\fR argument. + +.SS NI-RIO devices +.sp +An X-Series devices connected via PCIe can be specified by its NI-RIO resource through the \fIresource=\fR +argument, and the RPC port through which to communicate with it can be specified with the \fIrpc-port=\fR +argument. Using these options is not recommended, as their default values are almost always used. + +.SS OctoClock devices +An OctoClock's name and serial are only exposed when the firmware is loaded, so if the device only has a +bootloader, only the \fIaddr=\fR argument can be used to find it. + +.SH DEVICE-SPECIFIC LOADER OPTIONS +.sp +Certain devices have specific options for customizing their image loading process, and these can be passed +in through the \fI--args=""\fR option. These arguments are specified below: + +.SS USRP N200, USRP N210 +.sp +The \fIoverwrite-safe\fR option will overwrite the device's safe-mode firmware and FPGA images. This is +NOT RECOMMENDED, as these images serve as the backup if the device's primary images are corrupted. + +.sp +The \fIreset\fR option will automatically reset the device once the loading process finishes. When the +device resets, it will have its new images loaded. + +.SS USRP X300, USRP X310 (Ethernet only) +.sp +The \fIconfigure\fR option will automatically reset the device once the loading process finishes. When +the device resets, it will have its new FPGA image loaded. + +.sp +The \fIverify\fR option will tell the device to internally verify the integrity of the image as it loads. +This greatly increases the loading time. + +.SH EXAMPLES + +.SS Load only the default FPGA image onto a specific N2x0 device and reset +.sp +uhd_image_loader --args="type=usrp2,addr=192.168.10.2,reset" --no-fw +.ft + +.SS Load a custom FPGA image onto a specific X3x0 device +.sp +uhd_image_loader --args="type=x300,addr=192.168.40.2" --fpga-path="/home/user/my_x300_fpga_image.bit" +.ft + +.fi + +.SH SEE ALSO +UHD documentation: +.B http://files.ettus.com/manual/ +.LP +GR-UHD documentation: +.B http://gnuradio.org/doc/doxygen/page_uhd.html +.LP +Other UHD programs: +.sp +uhd_images_downloader(1) usrp2_card_burner(1) +.SH AUTHOR +This manual page was written by Nicholas Corgan +for the Debian project (but may be used by others). +.SH COPYRIGHT +Copyright (c) 2015 Ettus Research LLC +.LP +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 +the Free Software Foundation, either version 3 of the License, or +(at your option) any later version. +.LP +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. diff --git a/host/docs/usrp2.dox b/host/docs/usrp2.dox index 7b6cb9ed0..3f85e45b5 100644 --- a/host/docs/usrp2.dox +++ b/host/docs/usrp2.dox @@ -62,32 +62,21 @@ both the FPGA and firmware images before power cycling. This ensures that when the device reboots, it has a compatible set of images to boot into. -\subsection usrp2_loadflash_netburner Use the net burner tool +\subsection usrp2_loadflash_imageloader Use the image loader Use default images: - usrp_n2xx_simple_net_burner --addr=<IP address> + uhd_image_loader --args="type=usrp2,addr=<IP address>" Use custom-built images: - usrp_n2xx_simple_net_burner --addr=<IP address> --fw=<firmware path> --fpga=<FPGA path> + uhd_image_loader --args="type=usrp2,addr=<IP address>" --fw-path="<firmware path>" --fpga-path="<FPGA path>" <b>Note:</b> Different hardware revisions require different FPGA images. Determine the revision number from the sticker on the rear of the chassis. Use this number to select the correct FPGA image for your device. -For users who would prefer a graphical utility, a Python-based -alternative exists. - -\subsection usrp2_loadflash_gui Use the graphical net burner tool (Linux) - - <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py - -\subsection usrp2_loadflash_guiwin Use the graphical net burner tool (Windows) - - <path_to_python.exe> <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py - \subsection usrp2_loadflash_brick Device recovery and bricking Its possible to put the device into an unusable state by loading bad @@ -438,22 +427,20 @@ There is a sub-directory in the archive below the firmware/images called 'bit'. The USRP should now be able to communicate on the network (you'll see some LEDs light up and network link be established). The next step is to flash the device and program the serial number. Both these steps can be done with UHD (the JTAG step is complete). -To be sure, run `uhd_find_devices` and it should appear in the list - remember this IP address for the burner utility (should be 192.168.10.2 - make sure your network settings enable to you communicate with that subnet!). +To be sure, run `uhd_find_devices` and it should appear in the list - remember this IP address for the image loader utility (should be 192.168.10.2 - make sure your network settings enable to you communicate with that subnet!). -The first step is to flash the unit's safe-mode image, and then do a normal flash - both with the USRP N-series image burner utility. +The first step is to flash the unit's safe-mode image, and then do a normal flash - both with the UHD Image Loader utility. Make sure you have UHD installed, and the images from before, and follow the instructions in \ref usrp2_load. -You can combine the `--fw` and `--fpga` arguments into the single invocation of the burner. +You can combine the `--fw-path` and `--fpga-path` arguments into the single invocation of the image loader. You will probably use "usrp_n210_fw.bin" for the firmware and "usrp_n210_r4_fpga.bin" for the FPGA image parameters (use the full/relative file path if your current directory is not that of the images). - usrp_n2xx_net_burner.py --addr=192.168.10.2 --fw=usrp_n210_fw.bin --fpga=usrp_n210_r4_fpga.bin --overwrite-safe + uhd_image_loader --args="type=usrp2,addr=192.168.10.2,overwrite-safe" --fw-path=usrp_n210_fw.bin --fpga-path=usrp_n210_r4_fpga.bin -Use `--overwrite-safe` the first time, and then repeat without it for the second time. +Use the `overwrite-safe` option the first time, and then repeat without it for the second time. Don't forget to power-cycle the device after it has been flashed. -If you see a Python exception thrown (e.g. KeyError 65535) and something about if(check_rev)... use the --dont-check-rev option too (this is when the EEPROM has not yet been initialised, or has been blanked). - You can change the normal IP address by following the instructions in \ref usrp2_network_changeip. If you run `uhd_usrp_probe`, you can see the EEPROM keys at the top. Example: diff --git a/host/docs/usrp_b200.dox b/host/docs/usrp_b200.dox index bd79c4470..1da7f2aee 100644 --- a/host/docs/usrp_b200.dox +++ b/host/docs/usrp_b200.dox @@ -38,15 +38,40 @@ images: The master clock rate feeds the RF frontends and the DSP chains. Users may select non-default clock rates to acheive integer decimations or -interpolations in the DSP chains. The default master clock rate defaults -to 32 MHz, but can be set to any rate between 5 MHz and 61.44 MHz. +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. The user can set the master clock rate through the usrp API call uhd::usrp::multi_usrp::set_master_clock_rate(), or the clock rate can be set through the -device arguments, which many applications take: : +device arguments, which many applications take: uhd_usrp_probe --args="master_clock_rate=52e6" +The property to control the master clock rate is a double value, called `tick_rate`. + +\subsection b200_auto_mcr Automatic Clock Rate Setting + +The default clock rate setting is to automatically set a clock rate +depending on the requested sampling rate. The automatic clock rate selection +is disabled when either `master_clock_rate` is given in the device initialization +arguments, or when uhd::usrp::multi_usrp::set_master_clock_rate() is called. + +Note that the master clock rate must be an integer multiple of the sampling +rate. If a master clock rate is chosen for which this condition does not +hold, a warning will be displayed and a different sampling rate is used internally. + +Nevertheless, there are multiple valid values for the master clock rate +for most sampling rates. The auto clock rate selection attempts to use +the largest possible clock rate as to enable as many half-band filters +as possible. Expert users might have cases where a more fine-grained +control over the resampling stages is required, in which case manually +selecting a master clock rate might be more suitable than the automatic +rate. + +The property to dis- or enable the auto tick rate is a boolean value, +`auto_tick_rate`. + \section b200_fe RF Frontend Notes The B200 features an integrated RF frontend. diff --git a/host/docs/usrp_e3x0.dox b/host/docs/usrp_e3x0.dox index e23bbaeb5..f34aef229 100644 --- a/host/docs/usrp_e3x0.dox +++ b/host/docs/usrp_e3x0.dox @@ -188,9 +188,9 @@ builds) $ export MACHINE="ettus-e300" $ bitbake gnuradio-dev-image \endcode -When this completes, the files needed to create the sd card are in -`tmp-glibc/deploy/images/ettus-e300`. See \ref e3x0_upgrade_sd_card for instructions to write the image to your sd card. +When this completes, the files needed to create the SD card are in +`tmp-glibc/deploy/images/ettus-e300` -# Build the toolchain. \code{.sh} @@ -693,7 +693,7 @@ usrp->set_rx_subdev_spec("A:A A:B"); The following sensors are available for the USRP-E Series motherboards; they can be queried through the API. -- **fe_locked** - rx / tx frontend pll locked +- **fe_locked** - rx / tx frontend PLL locked - **temp** - processor temperature value - **gps_time** and **gps_locked** sensors are added when the GPS is found diff --git a/host/docs/usrp_x3x0.dox b/host/docs/usrp_x3x0.dox index d9657424e..bf2323b71 100644 --- a/host/docs/usrp_x3x0.dox +++ b/host/docs/usrp_x3x0.dox @@ -89,13 +89,13 @@ number, you will have to update the FPGA image before you can start using your U 1. Download the current UHD images. You can use the `uhd_images_downloader` script provided with UHD (see also \ref page_images). -2. Use the `usrp_x3xx_fpga_burner` utility to update the FPGA image. On the command line, run: +2. Use the `uhd_image_loader` utility to update the FPGA image. On the command line, run: - usrp_x3xx_fpga_burner --addr=192.168.10.2 --type=HGS + uhd_image_loader --args="type=x300,addr=192.168.10.2,fpga=HGS" If you have installed the images to a non-standard location, you might need to run (change the filename according to your device): - usrp_x3xx_fpga_burner --addr=192.168.10.2 --fpga-path <path_to_images>/usrp_x310_fpga_HGS.bit + uhd_image_loader --args="type=x300,addr=192.168.10.2" --fpga-path="<path_to_images>/usrp_x310_fpga_HGS.bit" The process of updating the FPGA image will take several minutes. Make sure the process of flashing the image does not get interrupted. @@ -303,31 +303,31 @@ detect your device information, and you will need to use this number to select which image to burn. \b Note: -The burner utility will default to using the appropriate BIT file if no custom +The image loader utility will default to using the appropriate BIT file if no custom FPGA image path is specified, but it is compatible with BIN, BIT, and LVBITX images. -\subsection x3x0_flash_burner_tool Use the burner tool over Ethernet +\subsection uhd_image_loader_tool Use the image loader over Ethernet Automatic FPGA path, detect image type: - usrp_x3xx_fpga_burner --addr=<IP address> + uhd_image_loader --args="type=x300,addr=<IP address>" Automatic FPGA path, select image type: - usrp_x3xx_fpga_burner --addr=<IP address> --type=<HGS or XGS> + uhd_image_loader --args="type=x300,addr=<IP address>,fpga=<HGS or XGS>" Manual FPGA path: - usrp_x3xx_fpga_burner --addr=<IP address> --fpga-path=<path to FPGA image> + uhd_image_loader --args="type=x300,addr=<IP address>" --fpga-path="<path to FPGA image>" -\subsection x3x0_flash_burner_tool_pcie Use the burner tool over PCI Express +\subsection uhd_image_loader_tool_pcie Use the image loader over PCI Express Automatic FPGA path, detect image type: - usrp_x3xx_fpga_burner --resource=<NI-RIO resource> + uhd_image_loader --args="type=x300,resource=<NI-RIO resource>" Automatic FPGA path, select image type: - usrp_x3xx_fpga_burner --resource=<NI-RIO resource> --type=<HGS or XGS> + uhd_image_loader --args="type=x300,resource=<NI-RIO resource>,fpga=<HGS or XGS>" Manual FPGA path: - usrp_x3xx_fpga_burner --resource=<NI-RIO resource> --fpga-path=<path to FPGA image> + uhd_image_loader --args="type=x300,resource=<NI-RIO resource>" --fpga-path="<path to FPGA image>" \subsection x3x0_flash_bricking Device recovery and bricking It is possible to put the device into an unusable state by loading bad images ("bricking"). diff --git a/host/docs/usrp_x3x0_config.dox b/host/docs/usrp_x3x0_config.dox index 2ee449cc2..ed80c31de 100644 --- a/host/docs/usrp_x3x0_config.dox +++ b/host/docs/usrp_x3x0_config.dox @@ -320,38 +320,12 @@ Real-time scheduling is enabled via different methods depending on your application and operating system. In GNU Radio Companion, it can be turned on in each individual flowgraph. -\subsection x3x0cfg_hostpc_volk Building with ORC & Volk +\subsection x3x0cfg_hostpc_volk SIMD Acceleration Especially when running high-performance applications, processing -performance can be dramatically improved by SIMD instructions. UHD uses -ORC to provide SIMD capability, and GNU Radio includes a SIMD library -called "Volk". These should both be used to guarantee optimum -performance. - -\subsubsection x3x0cfg_hostpc_volk_orc Compiling UHD with ORC - -ORC, the <a href="http://code.entropywave.com/orc/">Oil Runtime Compiler</a>, -is a third-party compiler that UHD uses to create efficient SIMD code for -your particular computer. ORC is generally easily installed from your -OS's package manager. - -On Fedora: - - $ sudo yum update; sudo yum install orc-compiler orc-devel - -On Ubuntu: - - $ sudo apt-get update; sudo apt-get install liborc-<version> liborc-<version>-dev - -After installing ORC, when building UHD from source, you should see -"ORC" as one of the configured UHD components. - - -- ###################################################### - -- # UHD enabled components - -- ###################################################### - -- * LibUHD - <cut for brevity> - -- * ORC +performance can be dramatically improved by SIMD instructions. +GNU Radio includes a SIMD library +called "Volk", which should be used to guarantee optimum performance. \subsubsection x3x0cfg_hostpc_volk_volk Compiling GNURadio with Volk diff --git a/host/docs/vrt_chdr.dox b/host/docs/vrt_chdr.dox new file mode 100644 index 000000000..8ab177b21 --- /dev/null +++ b/host/docs/vrt_chdr.dox @@ -0,0 +1,83 @@ +/*! \page page_rtp Radio Transport Protocols + +\tableofcontents + +Radio transport protocols are used to exchange samples (or other items) between host and devices. +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) +and CVITA (compressed VITA), also known as CHDR. Generation-3 devices and the B200 use CHDR, the rest +use VRT. + +\section rtp_vrt VRT + +VRT is an open protocol defined by the VITA-49 standard. It was designed for interoperability, +and to allow different device types to work with different software stacks. + +VRT is a very verbose standard, and only a subset is implemented in UHD/USRPs. +The full standard is available from the VITA website: http://www.vita.com . + + +\section rtp_chdr CVITA (CHDR) + +For the third generation of Ettus devices, a new type transport protocol was designed. +It reduces the complexity of the original standard and uses a fixed-length 64-Bit header +for everything except the timestamp. Because this is a "compressed" form of VITA, it +was dubbed "Compressed VITA" (CVITA). The compressed header is called CHDR, which is why +the protocol is often called CHDR itself (pronounced like the cheese "cheddar"). + +By compressing all information into a 64-bit line, the header can efficiently be parsed +in newer FPGAs, where the common streaming protocol is 64-Bit AXI. The first line in a +packet already provides all necessary information to proceed. + +Some CHDR-specific functions can be found in: uhd::transport::vrt::chdr. + +The form of a CVITA packet is the following: + +Address (Bytes) | Length (Bytes) | Payload +----------------|----------------|---------------------------- +0 | 8 | Compressed Header (CHDR) +8 | 8 | Fractional Time (Optional!) +8/16 | - | Data + +If there is no timestamp present, the data starts at address 8, otherwise, it starts at 16. + +The 64 Bits in the compressed header have the following meaning: + +Bits | Meaning +-------|-------------------------------------------------- +63:62 | Packet Type +61 | Has fractional time stamp (1: Yes) +60 | End-of-burst or error flag +59:48 | 12-bit sequence number +47:32 | Total packet length in Bytes +31:0 | Stream ID (SID) + + +The packet type is determined mainly by the first two bits, although +the EOB or error flag are also taken into consideration: + +Bit 63 | Bit 62 | Bit 60 | Packet Type +-------|--------|--------|-------------- +0 | 0 | 0 | Data +0 | 0 | 1 | Data (End-of-burst) +0 | 1 | 0 | Flow Control +1 | 0 | 0 | Command Packet +1 | 1 | 0 | Command Response +1 | 1 | 1 | Command Response (Error) + +\section vrt_tools Tools + +For CHDR, we provide a Wireshark dissector under tools/chdr_dissector. It can be used +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: +* 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 + +*/ +// vim:ft=doxygen: |