diff options
Diffstat (limited to 'host/docs')
| -rw-r--r-- | host/docs/dboards.dox | 4 | ||||
| -rw-r--r-- | host/docs/uhd.dox | 1 | ||||
| -rw-r--r-- | host/docs/usrp_b200.dox | 31 | ||||
| -rw-r--r-- | host/docs/usrp_e3x0.dox | 6 | ||||
| -rw-r--r-- | host/docs/vrt_chdr.dox | 83 |
5 files changed, 119 insertions, 6 deletions
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/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/usrp_b200.dox b/host/docs/usrp_b200.dox index 6ee2f3445..9d3550b98 100644 --- a/host/docs/usrp_b200.dox +++ b/host/docs/usrp_b200.dox @@ -36,15 +36,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 8f94ea64d..b92d15363 100644 --- a/host/docs/usrp_e3x0.dox +++ b/host/docs/usrp_e3x0.dox @@ -131,7 +131,7 @@ which should return 'arm-oe-linux-gnueabi'. -# Setup your environment as described in \ref e3x0_sdk_usage -# Type the following in the build directory (assuming a build in host/build): - $ cmake -DCMAKE_TOOLCHAIN_FILE=<youruhdsrc>/host/cmake/Toolchains/oe-sdk_cross.cmake -DENABLE_E300=ON .. + $ cmake -DCMAKE_TOOLCHAIN_FILE=<youruhdsrc>/host/cmake/Toolchains/oe-sdk_cross.cmake -DENABLE_E300=On .. $ make \subsubsection e3x0_sdk_usage_gnuradio Building GNU Radio @@ -190,7 +190,7 @@ builds) $ bitbake gnuradio-dev-image \endcode -When this completes, the files needed to create the sd card are in +When this completes, the files needed to create the SD card are in `tmp-glibc/deploy/images/ettus-e300` -# Build the toolchain. @@ -487,7 +487,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/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: |