diff options
| author | Martin Braun <martin.braun@ettus.com> | 2014-03-23 15:11:26 +0100 |
|---|---|---|
| committer | Martin Braun <martin.braun@ettus.com> | 2014-04-09 17:25:09 +0200 |
| commit | a74919c2a89a6b1ae40b526c4ceadf1108bfd186 (patch) | |
| tree | 79cb43c5d7ed3caa1fe8b695001267f0cc8286bf /host/docs | |
| parent | 47bf17b50a305228cfd07ff6fbaff3ac4a30e811 (diff) | |
| download | uhd-a74919c2a89a6b1ae40b526c4ceadf1108bfd186.tar.gz uhd-a74919c2a89a6b1ae40b526c4ceadf1108bfd186.tar.bz2 uhd-a74919c2a89a6b1ae40b526c4ceadf1108bfd186.zip | |
docs: Moved manual to Doxygen
Diffstat (limited to 'host/docs')
46 files changed, 3858 insertions, 3990 deletions
diff --git a/host/docs/CMakeLists.txt b/host/docs/CMakeLists.txt index 1ee0f1ade..015fa9dbb 100644 --- a/host/docs/CMakeLists.txt +++ b/host/docs/CMakeLists.txt @@ -18,89 +18,26 @@ ######################################################################## # List of manual sources ######################################################################## -SET(manual_sources - index.rst - identification.rst - build.rst - calibration.rst - coding.rst - dboards.rst - gpio_api.rst - gpsdo.rst - gpsdo_b2x0.rst - gpsdo_x3x0.rst - general.rst - images.rst - stream.rst - sync.rst - transport.rst - usrp1.rst - usrp2.rst - usrp_b100.rst - usrp_b200.rst - usrp_e1x0.rst - usrp_x3x0.rst - usrp_x3x0_config.rst -) ######################################################################## # Setup Manual ######################################################################## MESSAGE(STATUS "") -FIND_PACKAGE(Docutils) - -LIBUHD_REGISTER_COMPONENT("Manual" ENABLE_MANUAL ON "DOCUTILS_FOUND" OFF) - -IF(UHDHOST_PKG) - SET(PKG_DOC_DIR share/doc/uhd-host) -ENDIF(UHDHOST_PKG) +FIND_PACKAGE(Doxygen) +LIBUHD_REGISTER_COMPONENT("Manual" ENABLE_MANUAL ON "DOXYGEN_FOUND" OFF) +# TODO conditionally add the manual to Doxygen, now it just adds dependencies IF(ENABLE_MANUAL) - #setup rst2html options - SET(stylesheet ${CMAKE_CURRENT_SOURCE_DIR}/style.css) - SET(rst2html_options - --stylesheet=${stylesheet} - --no-toc-backlinks --date --time - ) - - #create generation rule for each source - FOREACH(rstfile ${manual_sources}) - #set input and output file names - SET(rstfile ${CMAKE_CURRENT_SOURCE_DIR}/${rstfile}) - GET_FILENAME_COMPONENT(rstfile_we ${rstfile} NAME_WE) - SET(htmlfile ${CMAKE_CURRENT_BINARY_DIR}/${rstfile_we}.html) - - #make the html file depend on the rst file - ADD_CUSTOM_COMMAND( - OUTPUT ${htmlfile} DEPENDS ${rstfile} ${stylesheet} - COMMAND ${RST2HTML_EXECUTABLE} ${rstfile} ${htmlfile} ${rst2html_options} - COMMENT "Generating ${htmlfile}" - ) - - #make the manual target depend on the html file - LIST(APPEND manual_html_files ${htmlfile}) - UHD_INSTALL(FILES ${htmlfile} DESTINATION ${PKG_DOC_DIR}/manual/html COMPONENT manual) - ENDFOREACH(rstfile ${manual_sources}) - - #make the html manual a build-time dependency - ADD_CUSTOM_TARGET(manual_html ALL DEPENDS ${manual_html_files}) - UHD_INSTALL(FILES ${manual_sources} DESTINATION ${PKG_DOC_DIR}/manual/rst COMPONENT manual) - - #resources for html manual - ADD_CUSTOM_COMMAND( - TARGET manual_html POST_BUILD - COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/res ${CMAKE_CURRENT_BINARY_DIR}/res - ) - UHD_INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/res DESTINATION ${PKG_DOC_DIR}/manual/html COMPONENT manual) - + FILE(GLOB manual_sources "*.dox") +ELSE(ENABLE_MANUAL) + SET(manual_source "") ENDIF(ENABLE_MANUAL) + ######################################################################## # Setup Doxygen ######################################################################## MESSAGE(STATUS "") -FIND_PACKAGE(Doxygen) - LIBUHD_REGISTER_COMPONENT("Doxygen" ENABLE_DOXYGEN ON "DOXYGEN_FOUND" OFF) IF(LIBUHDDEV_PKG) @@ -118,7 +55,7 @@ IF(ENABLE_DOXYGEN) #make doxygen directory depend on the header files FILE(GLOB_RECURSE header_files ${CMAKE_SOURCE_DIR}/include/*.hpp) ADD_CUSTOM_COMMAND( - OUTPUT ${CMAKE_CURRENT_BINARY_DIR_DOXYGEN} DEPENDS ${header_files} + OUTPUT ${CMAKE_CURRENT_BINARY_DIR_DOXYGEN} DEPENDS ${header_files} ${manual_source} COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile COMMENT "Generating documentation with doxygen" ) diff --git a/host/docs/Doxyfile.in b/host/docs/Doxyfile.in index 7395516b5..432e542aa 100644 --- a/host/docs/Doxyfile.in +++ b/host/docs/Doxyfile.in @@ -1,14 +1,16 @@ -# Doxyfile 1.6.1 +# Doxyfile 1.8.4 # This file describes the settings to be used by the documentation system -# doxygen (www.doxygen.org) for a project +# doxygen (www.doxygen.org) for a project. # -# All text after a hash (#) is considered a comment and will be ignored +# All text after a double hash (##) is considered a comment and is placed +# in front of the TAG it is preceding . +# All text after a hash (#) is considered a comment and will be ignored. # The format is: # TAG = value [value, ...] # For lists items can also be appended using: # TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" ") +# Values that contain spaces should be placed between quotes (" "). #--------------------------------------------------------------------------- # Project related configuration options @@ -22,16 +24,30 @@ DOXYFILE_ENCODING = UTF-8 -# The PROJECT_NAME tag is a single word (or a sequence of words surrounded -# by quotes) that should identify the project. +# The PROJECT_NAME tag is a single word (or sequence of words) that should +# identify the project. Note that if you do not use Doxywizard you need +# to put quotes around the project name if it contains spaces. -PROJECT_NAME = @CPACK_PACKAGE_NAME@ +PROJECT_NAME = "USRP Hardware Driver and USRP Manual" # The PROJECT_NUMBER tag can be used to enter a project or revision number. # This could be handy for archiving the generated documentation or # if some version control system is used. -PROJECT_NUMBER = @CPACK_PACKAGE_VERSION@ +PROJECT_NUMBER = "Version: @CPACK_PACKAGE_VERSION@" + +# Using the PROJECT_BRIEF tag one can provide an optional one line description +# for a project that appears at the top of each page and should give viewer +# a quick idea about the purpose of the project. Keep the description short. + +PROJECT_BRIEF = "UHD and USRP Manual" + +# With the PROJECT_LOGO tag one can specify an logo or icon that is +# included in the documentation. The maximum height of the logo should not +# exceed 55 pixels and the maximum width should not exceed 200 pixels. +# Doxygen will copy the logo to the output directory. + +PROJECT_LOGO = @CMAKE_SOURCE_DIR@/docs/Ettus_Logo.png # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) # base path where the generated documentation will be put. @@ -56,9 +72,9 @@ CREATE_SUBDIRS = NO # Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, # Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German, # Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English -# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian, -# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrilic, Slovak, -# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese. +# messages), Korean, Korean-en, Latvian, Lithuanian, Norwegian, Macedonian, +# Persian, Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, +# Slovak, Slovene, Spanish, Swedish, Ukrainian, and Vietnamese. OUTPUT_LANGUAGE = English @@ -112,7 +128,9 @@ FULL_PATH_NAMES = YES # only done if one of the specified strings matches the left-hand part of # the path. The tag can be used to show relative paths in the file list. # If left blank the directory from which doxygen is run is used as the -# path to strip. +# path to strip. Note that you specify absolute paths here, but also +# relative paths, which will be relative from the directory where doxygen is +# started. STRIP_FROM_PATH = @CMAKE_SOURCE_DIR@ @@ -126,7 +144,7 @@ STRIP_FROM_PATH = @CMAKE_SOURCE_DIR@ STRIP_FROM_INC_PATH = # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful is your file systems +# (but less readable) file names. This can be useful if your file system # doesn't support long names like on DOS, Mac, or CD-ROM. SHORT_NAMES = NO @@ -181,6 +199,13 @@ TAB_SIZE = 8 ALIASES = +# This tag can be used to specify a number of word-keyword mappings (TCL only). +# A mapping has the form "name=value". For example adding +# "class=itcl::class" will allow you to use the command class in the +# itcl::class meaning. + +TCL_SUBST = + # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C # sources only. Doxygen will then generate output that is more tailored for C. # For instance, some of the names that are used will be different. The list @@ -207,22 +232,40 @@ OPTIMIZE_FOR_FORTRAN = NO OPTIMIZE_OUTPUT_VHDL = NO -# Doxygen selects the parser to use depending on the extension of the files it parses. -# With this tag you can assign which parser to use for a given extension. -# Doxygen has a built-in mapping, but you can override or extend it using this tag. -# The format is ext=language, where ext is a file extension, and language is one of -# the parsers supported by doxygen: IDL, Java, Javascript, C#, C, C++, D, PHP, -# Objective-C, Python, Fortran, VHDL, C, C++. For instance to make doxygen treat -# .inc files as Fortran files (default is PHP), and .f files as C (default is Fortran), -# use: inc=Fortran f=C. Note that for custom extensions you also need to set FILE_PATTERNS otherwise the files are not read by doxygen. +# Doxygen selects the parser to use depending on the extension of the files it +# parses. With this tag you can assign which parser to use for a given +# extension. Doxygen has a built-in mapping, but you can override or extend it +# using this tag. The format is ext=language, where ext is a file extension, +# and language is one of the parsers supported by doxygen: IDL, Java, +# Javascript, CSharp, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, +# C++. For instance to make doxygen treat .inc files as Fortran files (default +# is PHP), and .f files as C (default is Fortran), use: inc=Fortran f=C. Note +# that for custom extensions you also need to set FILE_PATTERNS otherwise the +# files are not read by doxygen. EXTENSION_MAPPING = +# If MARKDOWN_SUPPORT is enabled (the default) then doxygen pre-processes all +# comments according to the Markdown format, which allows for more readable +# documentation. See http://daringfireball.net/projects/markdown/ for details. +# The output of markdown processing is further processed by doxygen, so you +# can mix doxygen, HTML, and XML commands with Markdown formatting. +# Disable only in case of backward compatibilities issues. + +MARKDOWN_SUPPORT = YES + +# When enabled doxygen tries to link words that correspond to documented +# classes, or namespaces to their corresponding documentation. Such a link can +# be prevented in individual cases by by putting a % sign in front of the word +# or globally by setting AUTOLINK_SUPPORT to NO. + +AUTOLINK_SUPPORT = YES + # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want # to include (a tag file for) the STL sources as input, then you should # set this tag to YES in order to let doxygen match functions declarations and # definitions whose arguments contain STL classes (e.g. func(std::string); v.s. -# func(std::string) {}). This also make the inheritance and collaboration +# func(std::string) {}). This also makes the inheritance and collaboration # diagrams that involve STL classes more complete and accurate. BUILTIN_STL_SUPPORT = YES @@ -238,10 +281,10 @@ CPP_CLI_SUPPORT = NO SIP_SUPPORT = NO -# For Microsoft's IDL there are propget and propput attributes to indicate getter -# and setter methods for a property. Setting this option to YES (the default) -# will make doxygen to replace the get and set methods by a property in the -# documentation. This will only work if the methods are indeed getting or +# For Microsoft's IDL there are propget and propput attributes to indicate +# getter and setter methods for a property. Setting this option to YES (the +# default) will make doxygen replace the get and set methods by a property in +# the documentation. This will only work if the methods are indeed getting or # setting a simple type. If this is not the case, or you want to show the # methods anyway, you should set this option to NO. @@ -262,6 +305,22 @@ DISTRIBUTE_GROUP_DOC = NO SUBGROUPING = YES +# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and +# unions are shown inside the group in which they are included (e.g. using +# @ingroup) instead of on a separate page (for HTML and Man pages) or +# section (for LaTeX and RTF). + +INLINE_GROUPED_CLASSES = NO + +# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and +# unions with only public data fields or simple typedef fields will be shown +# inline in the documentation of the scope in which they are defined (i.e. file, +# namespace, or group documentation), provided this scope is documented. If set +# to NO (the default), structs, classes, and unions are shown on a separate +# page (for HTML and Man pages) or section (for LaTeX and RTF). + +INLINE_SIMPLE_STRUCTS = NO + # When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum # is documented as struct, union, or enum with the name of the typedef. So # typedef struct TypeS {} TypeT, will appear in the documentation as a struct @@ -272,21 +331,16 @@ SUBGROUPING = YES TYPEDEF_HIDES_STRUCT = NO -# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to -# determine which symbols to keep in memory and which to flush to disk. -# When the cache is full, less often used symbols will be written to disk. -# For small to medium size projects (<1000 input files) the default value is -# probably good enough. For larger projects a too small cache size can cause -# doxygen to be busy swapping symbols to and from disk most of the time -# causing a significant performance penality. -# If the system has enough physical memory increasing the cache will improve the -# performance by keeping more symbols in memory. Note that the value works on -# a logarithmic scale so increasing the size by one will rougly double the -# memory usage. The cache size is given by this formula: -# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0, -# corresponding to a cache size of 2^16 = 65536 symbols - -SYMBOL_CACHE_SIZE = 0 +# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This +# cache is used to resolve symbols given their name and scope. Since this can +# be an expensive process and often the same symbol appear multiple times in +# the code, doxygen keeps a cache of pre-resolved symbols. If the cache is too +# small doxygen will become slower. If the cache is too large, memory is wasted. +# The cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid +# range is 0..9, the default is 0, corresponding to a cache size of 2^16 = 65536 +# symbols. + +LOOKUP_CACHE_SIZE = 0 #--------------------------------------------------------------------------- # Build related configuration options @@ -295,7 +349,7 @@ SYMBOL_CACHE_SIZE = 0 # If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in # documentation are documented, even if no documentation was available. # Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES +# the EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES EXTRACT_ALL = YES @@ -304,6 +358,11 @@ EXTRACT_ALL = YES EXTRACT_PRIVATE = NO +# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal +# scope will be included in the documentation. + +EXTRACT_PACKAGE = NO + # If the EXTRACT_STATIC tag is set to YES all static members of a file # will be included in the documentation. @@ -326,7 +385,7 @@ EXTRACT_LOCAL_METHODS = NO # extracted and appear in the documentation as a namespace called # 'anonymous_namespace{file}', where file will be replaced with the base # name of the file that contains the anonymous namespace. By default -# anonymous namespace are hidden. +# anonymous namespaces are hidden. EXTRACT_ANON_NSPACES = NO @@ -386,6 +445,12 @@ HIDE_SCOPE_NAMES = NO SHOW_INCLUDE_FILES = YES +# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen +# will list include files with double quotes in the documentation +# rather than with sharp brackets. + +FORCE_LOCAL_INCLUDES = NO + # If the INLINE_INFO tag is set to YES (the default) then a tag [inline] # is inserted in the documentation for inline members. @@ -405,7 +470,13 @@ SORT_MEMBER_DOCS = YES SORT_BRIEF_DOCS = NO -# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the (brief and detailed) documentation of class members so that constructors and destructors are listed first. If set to NO (the default) the constructors will appear in the respective orders defined by SORT_MEMBER_DOCS and SORT_BRIEF_DOCS. This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO. +# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen +# will sort the (brief and detailed) documentation of class members so that +# constructors and destructors are listed first. If set to NO (the default) +# the constructors will appear in the respective orders defined by +# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS. +# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO +# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO. SORT_MEMBERS_CTORS_1ST = NO @@ -425,6 +496,15 @@ SORT_GROUP_NAMES = NO SORT_BY_SCOPE_NAME = NO +# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to +# do proper type resolution of all parameters of a function it will reject a +# match between the prototype and the implementation of a member function even +# if there is only one candidate or it is obvious which candidate to choose +# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen +# will still accept a match between prototype and implementation in such cases. + +STRICT_PROTO_MATCHING = NO + # The GENERATE_TODOLIST tag can be used to enable (YES) or # disable (NO) the todo list. This list is created by putting \todo # commands in the documentation. @@ -450,15 +530,16 @@ GENERATE_BUGLIST = YES GENERATE_DEPRECATEDLIST= YES # The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. +# documentation sections, marked by \if section-label ... \endif +# and \cond section-label ... \endcond blocks. ENABLED_SECTIONS = # The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or define consists of for it to appear in +# the initial value of a variable or macro consists of for it to appear in # the documentation. If the initializer consists of more lines than specified # here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and defines in the +# The appearance of the initializer of individual variables and macros in the # documentation can be controlled using \showinitializer or \hideinitializer # command in the documentation regardless of this setting. @@ -470,12 +551,6 @@ MAX_INITIALIZER_LINES = 30 SHOW_USED_FILES = YES -# If the sources in your project are distributed over multiple directories -# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy -# in the documentation. The default is NO. - -SHOW_DIRECTORIES = NO - # Set the SHOW_FILES tag to NO to disable the generation of the Files page. # This will remove the Files entry from the Quick Index and from the # Folder Tree View (if specified). The default is YES. @@ -499,15 +574,26 @@ SHOW_NAMESPACES = YES FILE_VERSION_FILTER = -# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed by -# doxygen. The layout file controls the global structure of the generated output files -# in an output format independent way. The create the layout file that represents -# doxygen's defaults, run doxygen with the -l option. You can optionally specify a -# file name after the option, if omitted DoxygenLayout.xml will be used as the name -# of the layout file. +# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed +# by doxygen. The layout file controls the global structure of the generated +# output files in an output format independent way. To create the layout file +# that represents doxygen's defaults, run doxygen with the -l option. +# You can optionally specify a file name after the option, if omitted +# DoxygenLayout.xml will be used as the name of the layout file. LAYOUT_FILE = +# The CITE_BIB_FILES tag can be used to specify one or more bib files +# containing the references data. This must be a list of .bib files. The +# .bib extension is automatically appended if omitted. Using this command +# requires the bibtex tool to be installed. See also +# http://en.wikipedia.org/wiki/BibTeX for more info. For LaTeX the style +# of the bibliography can be controlled using LATEX_BIB_STYLE. To use this +# feature you need bibtex and perl available in the search path. Do not use +# file names with spaces, bibtex cannot handle them. + +CITE_BIB_FILES = + #--------------------------------------------------------------------------- # configuration options related to warning and progress messages #--------------------------------------------------------------------------- @@ -536,7 +622,7 @@ WARN_IF_UNDOCUMENTED = YES WARN_IF_DOC_ERROR = YES -# This WARN_NO_PARAMDOC option can be abled to get warnings for +# The WARN_NO_PARAMDOC option can be enabled to get warnings for # functions that are documented, but have no documentation for their parameters # or return value. If set to NO (the default) doxygen will only warn about # wrong or incomplete parameter documentation, but not about the absence of @@ -568,8 +654,8 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = @CMAKE_SOURCE_DIR@/include - +INPUT = @CMAKE_SOURCE_DIR@/include \ + @CMAKE_SOURCE_DIR@/docs # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is # also the default input encoding. Doxygen uses libiconv (or the iconv built @@ -582,10 +668,11 @@ INPUT_ENCODING = UTF-8 # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp # and *.h) to filter out the source-files in the directories. If left # blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx -# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90 +# *.c *.cc *.cxx *.cpp *.c++ *.d *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh +# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py +# *.f90 *.f *.for *.vhd *.vhdl -FILE_PATTERNS = *.hpp +FILE_PATTERNS = *.hpp *.dox *.h # The RECURSIVE tag can be used to turn specify whether or not subdirectories # should be searched for input files as well. Possible values are YES and NO. @@ -593,14 +680,16 @@ FILE_PATTERNS = *.hpp RECURSIVE = YES -# The EXCLUDE tag can be used to specify files and/or directories that should +# The EXCLUDE tag can be used to specify files and/or directories that should be # excluded from the INPUT source files. This way you can easily exclude a # subdirectory from a directory tree whose root is specified with the INPUT tag. +# Note that relative paths are relative to the directory from which doxygen is +# run. EXCLUDE = -# The EXCLUDE_SYMLINKS tag can be used select whether or not files or -# directories that are symbolic links (a Unix filesystem feature) are excluded +# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or +# directories that are symbolic links (a Unix file system feature) are excluded # from the input. EXCLUDE_SYMLINKS = NO @@ -645,7 +734,7 @@ EXAMPLE_RECURSIVE = NO # directories that contain image that are included in the documentation (see # the \image command). -IMAGE_PATH = +IMAGE_PATH = @CMAKE_SOURCE_DIR@/docs/res # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program @@ -653,8 +742,10 @@ IMAGE_PATH = # is the value of the INPUT_FILTER tag, and <input-file> is the name of an # input file. Doxygen will then use the output that the filter program writes # to standard output. -# If FILTER_PATTERNS is specified, this tag will be -# ignored. +# If FILTER_PATTERNS is specified, this tag will be ignored. +# Note that the filter must not add or remove lines; it is applied before the +# code is scanned, but not when the output code is generated. If lines are added +# or removed, the anchors will not be placed correctly. INPUT_FILTER = @@ -664,8 +755,8 @@ INPUT_FILTER = # filter if there is a match. # The filters are a list of the form: # pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further -# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER -# is applied to all files. +# info on how filters are used. If FILTER_PATTERNS is empty or if +# non of the patterns match the file name, INPUT_FILTER is applied. FILTER_PATTERNS = @@ -675,6 +766,21 @@ FILTER_PATTERNS = FILTER_SOURCE_FILES = NO +# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file +# pattern. A pattern will override the setting for FILTER_PATTERN (if any) +# and it is also possible to disable source filtering for a specific pattern +# using *.ext= (so without naming a filter). This option only has effect when +# FILTER_SOURCE_FILES is enabled. + +FILTER_SOURCE_PATTERNS = + +# If the USE_MD_FILE_AS_MAINPAGE tag refers to the name of a markdown file that +# is part of the input, its contents will be placed on the main page +# (index.html). This can be useful if you have a project on for instance GitHub +# and want reuse the introduction page also for the doxygen output. + +USE_MDFILE_AS_MAINPAGE = + #--------------------------------------------------------------------------- # configuration options related to source browsing #--------------------------------------------------------------------------- @@ -693,7 +799,7 @@ INLINE_SOURCES = NO # Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct # doxygen to hide any special comment blocks from generated source code -# fragments. Normal C and C++ comments will always remain visible. +# fragments. Normal C, C++ and Fortran comments will always remain visible. STRIP_CODE_COMMENTS = YES @@ -777,7 +883,14 @@ HTML_FILE_EXTENSION = .html # The HTML_HEADER tag can be used to specify a personal HTML header for # each generated HTML page. If it is left blank doxygen will generate a -# standard header. +# standard header. Note that when using a custom header you are responsible +# for the proper inclusion of any scripts and style sheets that doxygen +# needs, which is dependent on the configuration options used. +# It is advised to generate a default header using "doxygen -w html +# header.html footer.html stylesheet.css YourConfigFile" and then modify +# that header. Note that the header is subject to change so you typically +# have to redo this when upgrading to a newer version of doxygen or when +# changing the value of configuration settings such as GENERATE_TREEVIEW! HTML_HEADER = @@ -789,27 +902,80 @@ HTML_FOOTER = # The HTML_STYLESHEET tag can be used to specify a user-defined cascading # style sheet that is used by each HTML page. It can be used to -# fine-tune the look of the HTML output. If the tag is left blank doxygen -# will generate a default style sheet. Note that doxygen will try to copy -# the style sheet file to the HTML output directory, so don't put your own -# stylesheet in the HTML output directory as well, or it will be erased! +# fine-tune the look of the HTML output. If left blank doxygen will +# generate a default style sheet. Note that it is recommended to use +# HTML_EXTRA_STYLESHEET instead of this one, as it is more robust and this +# tag will in the future become obsolete. HTML_STYLESHEET = -# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, -# files or namespaces will be aligned in HTML using tables. If set to -# NO a bullet list will be used. +# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional +# user-defined cascading style sheet that is included after the standard +# style sheets created by doxygen. Using this option one can overrule +# certain style aspects. This is preferred over using HTML_STYLESHEET +# since it does not replace the standard style sheet and is therefor more +# robust against future updates. Doxygen will copy the style sheet file to +# the output directory. + +HTML_EXTRA_STYLESHEET = + +# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or +# other source files which should be copied to the HTML output directory. Note +# that these files will be copied to the base HTML output directory. Use the +# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these +# files. In the HTML_STYLESHEET file, use the file name only. Also note that +# the files will be copied as-is; there are no commands or markers available. + +HTML_EXTRA_FILES = + +# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. +# Doxygen will adjust the colors in the style sheet and background images +# according to this color. Hue is specified as an angle on a colorwheel, +# see http://en.wikipedia.org/wiki/Hue for more information. +# For instance the value 0 represents red, 60 is yellow, 120 is green, +# 180 is cyan, 240 is blue, 300 purple, and 360 is red again. +# The allowed range is 0 to 359. + +HTML_COLORSTYLE_HUE = 92 + +# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of +# the colors in the HTML output. For a value of 0 the output will use +# grayscales only. A value of 255 will produce the most vivid colors. + +HTML_COLORSTYLE_SAT = 31 + +# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to +# the luminance component of the colors in the HTML output. Values below +# 100 gradually make the output lighter, whereas values above 100 make +# the output darker. The value divided by 100 is the actual gamma applied, +# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2, +# and 100 does not change the gamma. -HTML_ALIGN_MEMBERS = YES +HTML_COLORSTYLE_GAMMA = 65 + +# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML +# page will contain the date and time when the page was generated. Setting +# this to NO can help when comparing the output of multiple runs. + +HTML_TIMESTAMP = YES # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML # documentation will contain sections that can be hidden and shown after the -# page has loaded. For this to work a browser that supports -# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox -# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari). +# page has loaded. HTML_DYNAMIC_SECTIONS = NO +# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of +# entries shown in the various tree structured indices initially; the user +# can expand and collapse entries dynamically later on. Doxygen will expand +# the tree to such a level that at most the specified number of entries are +# visible (unless a fully collapsed tree already exceeds this amount). +# So setting the number of entries 1 will produce a full collapsed tree by +# default. 0 is a special value representing an infinite number of entries +# and will result in a full expanded tree by default. + +HTML_INDEX_NUM_ENTRIES = 100 + # If the GENERATE_DOCSET tag is set to YES, additional index files # will be generated that can be used as input for Apple's Xcode 3 # integrated development environment, introduced with OSX 10.5 (Leopard). @@ -818,7 +984,8 @@ HTML_DYNAMIC_SECTIONS = NO # directory and running "make install" will install the docset in # ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find # it at startup. -# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html for more information. +# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html +# for more information. GENERATE_DOCSET = NO @@ -836,6 +1003,16 @@ DOCSET_FEEDNAME = "Doxygen generated docs" DOCSET_BUNDLE_ID = org.doxygen.Project +# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely +# identify the documentation publisher. This should be a reverse domain-name +# style string, e.g. com.mycompany.MyDocSet.documentation. + +DOCSET_PUBLISHER_ID = org.doxygen.Publisher + +# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher. + +DOCSET_PUBLISHER_NAME = Publisher + # If the GENERATE_HTMLHELP tag is set to YES, additional index files # will be generated that can be used as input for tools like the # Microsoft HTML help workshop to generate a compiled HTML help file (.chm) @@ -880,10 +1057,10 @@ BINARY_TOC = NO TOC_EXPAND = NO -# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and QHP_VIRTUAL_FOLDER -# are set, an additional index file will be generated that can be used as input for -# Qt's qhelpgenerator to generate a Qt Compressed Help (.qch) of the generated -# HTML documentation. +# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and +# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated +# that can be used as input for Qt's qhelpgenerator to generate a +# Qt Compressed Help (.qch) of the generated HTML documentation. GENERATE_QHP = NO @@ -905,20 +1082,24 @@ QHP_NAMESPACE = QHP_VIRTUAL_FOLDER = doc -# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to add. -# For more information please see +# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to +# add. For more information please see # http://doc.trolltech.com/qthelpproject.html#custom-filters QHP_CUST_FILTER_NAME = -# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the custom filter to add.For more information please see -# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">Qt Help Project / Custom Filters</a>. +# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the +# custom filter to add. For more information please see +# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters"> +# Qt Help Project / Custom Filters</a>. QHP_CUST_FILTER_ATTRS = -# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this project's +# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this +# project's # filter section matches. -# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">Qt Help Project / Filter Attributes</a>. +# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes"> +# Qt Help Project / Filter Attributes</a>. QHP_SECT_FILTER_ATTRS = @@ -929,16 +1110,30 @@ QHP_SECT_FILTER_ATTRS = QHG_LOCATION = -# The DISABLE_INDEX tag can be used to turn on/off the condensed index at -# top of each HTML page. The value NO (the default) enables the index and -# the value YES disables it. +# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files +# will be generated, which together with the HTML files, form an Eclipse help +# plugin. To install this plugin and make it available under the help contents +# menu in Eclipse, the contents of the directory containing the HTML and XML +# files needs to be copied into the plugins directory of eclipse. The name of +# the directory within the plugins directory should be the same as +# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before +# the help appears. -DISABLE_INDEX = NO +GENERATE_ECLIPSEHELP = NO -# This tag can be used to set the number of enum values (range [1..20]) -# that doxygen will group on one line in the generated HTML documentation. +# A unique identifier for the eclipse help plugin. When installing the plugin +# the directory name containing the HTML and XML files should also have +# this name. -ENUM_VALUES_PER_LINE = 4 +ECLIPSE_DOC_ID = org.doxygen.Project + +# The DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) +# at top of each HTML page. The value NO (the default) enables the index and +# the value YES disables it. Since the tabs have the same information as the +# navigation tree you can set this option to NO if you already set +# GENERATE_TREEVIEW to YES. + +DISABLE_INDEX = YES # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index # structure should be generated to display hierarchical information. @@ -947,13 +1142,17 @@ ENUM_VALUES_PER_LINE = 4 # is generated for HTML Help). For this to work a browser that supports # JavaScript, DHTML, CSS and frames is required (i.e. any modern browser). # Windows users are probably better off using the HTML help feature. +# Since the tree basically has the same information as the tab index you +# could consider to set DISABLE_INDEX to NO when enabling this option. -GENERATE_TREEVIEW = NO +GENERATE_TREEVIEW = YES -# By enabling USE_INLINE_TREES, doxygen will generate the Groups, Directories, -# and Class Hierarchy pages using a tree view instead of an ordered list. +# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values +# (range [0,1..20]) that doxygen will group on one line in the generated HTML +# documentation. Note that a value of 0 will completely suppress the enum +# values from appearing in the overview section. -USE_INLINE_TREES = NO +ENUM_VALUES_PER_LINE = 4 # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be # used to set the initial width (in pixels) of the frame in which the tree @@ -961,6 +1160,11 @@ USE_INLINE_TREES = NO TREEVIEW_WIDTH = 250 +# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open +# links to external symbols imported via tag files in a separate window. + +EXT_LINKS_IN_WINDOW = NO + # Use this tag to change the font size of Latex formulas included # as images in the HTML documentation. The default is 10. Note that # when you change the font size after a successful doxygen run you need @@ -969,13 +1173,112 @@ TREEVIEW_WIDTH = 250 FORMULA_FONTSIZE = 10 -# When the SEARCHENGINE tag is enable doxygen will generate a search box for the HTML output. The underlying search engine uses javascript -# and DHTML and should work on any modern browser. Note that when using HTML help (GENERATE_HTMLHELP) or Qt help (GENERATE_QHP) -# there is already a search function so this one should typically -# be disabled. +# Use the FORMULA_TRANPARENT tag to determine whether or not the images +# generated for formulas are transparent PNGs. Transparent PNGs are +# not supported properly for IE 6.0, but are supported on all modern browsers. +# Note that when changing this option you need to delete any form_*.png files +# in the HTML output before the changes have effect. + +FORMULA_TRANSPARENT = YES + +# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax +# (see http://www.mathjax.org) which uses client side Javascript for the +# rendering instead of using prerendered bitmaps. Use this if you do not +# have LaTeX installed or if you want to formulas look prettier in the HTML +# output. When enabled you may also need to install MathJax separately and +# configure the path to it using the MATHJAX_RELPATH option. + +USE_MATHJAX = NO + +# When MathJax is enabled you can set the default output format to be used for +# the MathJax output. Supported types are HTML-CSS, NativeMML (i.e. MathML) and +# SVG. The default value is HTML-CSS, which is slower, but has the best +# compatibility. + +MATHJAX_FORMAT = HTML-CSS + +# When MathJax is enabled you need to specify the location relative to the +# HTML output directory using the MATHJAX_RELPATH option. The destination +# directory should contain the MathJax.js script. For instance, if the mathjax +# directory is located at the same level as the HTML output directory, then +# MATHJAX_RELPATH should be ../mathjax. The default value points to +# the MathJax Content Delivery Network so you can quickly see the result without +# installing MathJax. +# However, it is strongly recommended to install a local +# copy of MathJax from http://www.mathjax.org before deployment. + +MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest + +# The MATHJAX_EXTENSIONS tag can be used to specify one or MathJax extension +# names that should be enabled during MathJax rendering. + +MATHJAX_EXTENSIONS = + +# The MATHJAX_CODEFILE tag can be used to specify a file with javascript +# pieces of code that will be used on startup of the MathJax code. + +MATHJAX_CODEFILE = + +# When the SEARCHENGINE tag is enabled doxygen will generate a search box +# for the HTML output. The underlying search engine uses javascript +# and DHTML and should work on any modern browser. Note that when using +# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets +# (GENERATE_DOCSET) there is already a search function so this one should +# typically be disabled. For large projects the javascript based search engine +# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution. SEARCHENGINE = YES +# When the SERVER_BASED_SEARCH tag is enabled the search engine will be +# implemented using a web server instead of a web client using Javascript. +# There are two flavours of web server based search depending on the +# EXTERNAL_SEARCH setting. When disabled, doxygen will generate a PHP script for +# searching and an index file used by the script. When EXTERNAL_SEARCH is +# enabled the indexing and searching needs to be provided by external tools. +# See the manual for details. + +SERVER_BASED_SEARCH = NO + +# When EXTERNAL_SEARCH is enabled doxygen will no longer generate the PHP +# script for searching. Instead the search results are written to an XML file +# which needs to be processed by an external indexer. Doxygen will invoke an +# external search engine pointed to by the SEARCHENGINE_URL option to obtain +# the search results. Doxygen ships with an example indexer (doxyindexer) and +# search engine (doxysearch.cgi) which are based on the open source search +# engine library Xapian. See the manual for configuration details. + +EXTERNAL_SEARCH = NO + +# The SEARCHENGINE_URL should point to a search engine hosted by a web server +# which will returned the search results when EXTERNAL_SEARCH is enabled. +# Doxygen ships with an example search engine (doxysearch) which is based on +# the open source search engine library Xapian. See the manual for configuration +# details. + +SEARCHENGINE_URL = + +# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed +# search data is written to a file for indexing by an external tool. With the +# SEARCHDATA_FILE tag the name of this file can be specified. + +SEARCHDATA_FILE = searchdata.xml + +# When SERVER_BASED_SEARCH AND EXTERNAL_SEARCH are both enabled the +# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is +# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple +# projects and redirect the results back to the right project. + +EXTERNAL_SEARCH_ID = + +# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen +# projects other than the one defined by this configuration file, but that are +# all added to the same external search index. Each project needs to have a +# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id +# of to a relative location where the documentation can be found. +# The format is: EXTRA_SEARCH_MAPPINGS = id1=loc1 id2=loc2 ... + +EXTRA_SEARCH_MAPPINGS = + #--------------------------------------------------------------------------- # configuration options related to the LaTeX output #--------------------------------------------------------------------------- @@ -993,6 +1296,9 @@ LATEX_OUTPUT = latex # The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be # invoked. If left blank `latex' will be used as the default command name. +# Note that when enabling USE_PDFLATEX this option is only used for +# generating bitmaps for formulas in the HTML output, but not in the +# Makefile that is written to the output directory. LATEX_CMD_NAME = latex @@ -1009,8 +1315,8 @@ MAKEINDEX_CMD_NAME = makeindex COMPACT_LATEX = NO # The PAPER_TYPE tag can be used to set the paper type that is used -# by the printer. Possible values are: a4, a4wide, letter, legal and -# executive. If left blank a4wide will be used. +# by the printer. Possible values are: a4, letter, legal and +# executive. If left blank a4 will be used. PAPER_TYPE = a4wide @@ -1026,6 +1332,20 @@ EXTRA_PACKAGES = LATEX_HEADER = +# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for +# the generated latex document. The footer should contain everything after +# the last chapter. If it is left blank doxygen will generate a +# standard footer. Notice: only use this tag if you know what you are doing! + +LATEX_FOOTER = + +# The LATEX_EXTRA_FILES tag can be used to specify one or more extra images +# or other source files which should be copied to the LaTeX output directory. +# Note that the files will be copied as-is; there are no commands or markers +# available. + +LATEX_EXTRA_FILES = + # If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated # is prepared for conversion to pdf (using ps2pdf). The pdf file will # contain links (just like the HTML output) instead of page references @@ -1052,10 +1372,19 @@ LATEX_BATCHMODE = NO LATEX_HIDE_INDICES = NO -# If LATEX_SOURCE_CODE is set to YES then doxygen will include source code with syntax highlighting in the LaTeX output. Note that which sources are shown also depends on other settings such as SOURCE_BROWSER. +# If LATEX_SOURCE_CODE is set to YES then doxygen will include +# source code with syntax highlighting in the LaTeX output. +# Note that which sources are shown also depends on other settings +# such as SOURCE_BROWSER. LATEX_SOURCE_CODE = NO +# The LATEX_BIB_STYLE tag can be used to specify the style to use for the +# bibliography, e.g. plainnat, or ieeetr. The default style is "plain". See +# http://en.wikipedia.org/wiki/BibTeX for more info. + +LATEX_BIB_STYLE = plain + #--------------------------------------------------------------------------- # configuration options related to the RTF output #--------------------------------------------------------------------------- @@ -1087,7 +1416,7 @@ COMPACT_RTF = NO RTF_HYPERLINKS = NO -# Load stylesheet definitions from file. Syntax is similar to doxygen's +# Load style sheet definitions from file. Syntax is similar to doxygen's # config file, i.e. a series of assignments. You only have to provide # replacements, missing definitions are set to their default value. @@ -1162,6 +1491,21 @@ XML_DTD = XML_PROGRAMLISTING = YES #--------------------------------------------------------------------------- +# configuration options related to the DOCBOOK output +#--------------------------------------------------------------------------- + +# If the GENERATE_DOCBOOK tag is set to YES Doxygen will generate DOCBOOK files +# that can be used to generate PDF. + +GENERATE_DOCBOOK = NO + +# The DOCBOOK_OUTPUT tag is used to specify where the DOCBOOK pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be put in +# front of it. If left blank docbook will be used as the default path. + +DOCBOOK_OUTPUT = docbook + +#--------------------------------------------------------------------------- # configuration options for the AutoGen Definitions output #--------------------------------------------------------------------------- @@ -1232,7 +1576,7 @@ MACRO_EXPANSION = YES EXPAND_ONLY_PREDEF = NO # If the SEARCH_INCLUDES tag is set to YES (the default) the includes files -# in the INCLUDE_PATH (see below) will be search if a #include is found. +# pointed to by INCLUDE_PATH will be searched when a #include is found. SEARCH_INCLUDES = YES @@ -1262,15 +1606,15 @@ PREDEFINED = # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then # this tag can be used to specify a list of macro names that should be expanded. # The macro definition that is found in the sources will be used. -# Use the PREDEFINED tag if you want to use a different macro definition. +# Use the PREDEFINED tag if you want to use a different macro definition that +# overrules the definition found in the source code. EXPAND_AS_DEFINED = # If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then -# doxygen's preprocessor will remove all function-like macros that are alone -# on a line, have an all uppercase name, and do not end with a semicolon. Such -# function macros are typically used for boiler-plate code, and will confuse -# the parser if not removed. +# doxygen's preprocessor will remove all references to function-like macros +# that are alone on a line, have an all uppercase name, and do not end with a +# semicolon, because these will confuse the parser if not removed. SKIP_FUNCTION_MACROS = YES @@ -1278,22 +1622,18 @@ SKIP_FUNCTION_MACROS = YES # Configuration::additions related to external references #--------------------------------------------------------------------------- -# The TAGFILES option can be used to specify one or more tagfiles. -# Optionally an initial location of the external documentation -# can be added for each tagfile. The format of a tag file without -# this location is as follows: +# The TAGFILES option can be used to specify one or more tagfiles. For each +# tag file the location of the external documentation should be added. The +# format of a tag file without this location is as follows: # # TAGFILES = file1 file2 ... # Adding location for the tag files is done as follows: # # TAGFILES = file1=loc1 "file2 = loc2" ... -# where "loc1" and "loc2" can be relative or absolute paths or -# URLs. If a location is present for each tag, the installdox tool -# does not have to be run to correct the links. -# Note that each tag file must have a unique name -# (where the name does NOT include the path) -# If a tag file is not located in the directory in which doxygen -# is run, you must also specify the path to the tagfile here. +# where "loc1" and "loc2" can be relative or absolute paths +# or URLs. Note that each tag file must have a unique name (where the name does +# NOT include the path). If a tag file is not located in the directory in which +# doxygen is run, you must also specify the path to the tagfile here. TAGFILES = @@ -1314,6 +1654,12 @@ ALLEXTERNALS = NO EXTERNAL_GROUPS = YES +# If the EXTERNAL_PAGES tag is set to YES all external pages will be listed +# in the related pages index. If set to NO, only the current project's +# pages will be listed. + +EXTERNAL_PAGES = YES + # The PERL_PATH should be the absolute path and name of the perl script # interpreter (i.e. the result of `which perl'). @@ -1326,9 +1672,8 @@ PERL_PATH = /usr/bin/perl # If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will # generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base # or super classes. Setting the tag to NO turns the diagrams off. Note that -# this option is superseded by the HAVE_DOT option below. This is only a -# fallback. It is recommended to install and use dot, since it yields more -# powerful graphs. +# this option also works with HAVE_DOT disabled, but it is recommended to +# install and use dot, since it yields more powerful graphs. CLASS_DIAGRAMS = YES @@ -1354,33 +1699,38 @@ HIDE_UNDOC_RELATIONS = YES HAVE_DOT = NO -# By default doxygen will write a font called FreeSans.ttf to the output -# directory and reference it in all dot files that doxygen generates. This -# font does not include all possible unicode characters however, so when you need -# these (or just want a differently looking font) you can specify the font name -# using DOT_FONTNAME. You need need to make sure dot is able to find the font, -# which can be done by putting it in a standard location or by setting the -# DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory -# containing the font. +# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is +# allowed to run in parallel. When set to 0 (the default) doxygen will +# base this on the number of processors available in the system. You can set it +# explicitly to a value larger than 0 to get control over the balance +# between CPU load and processing speed. + +DOT_NUM_THREADS = 0 + +# By default doxygen will use the Helvetica font for all dot files that +# doxygen generates. When you want a differently looking font you can specify +# the font name using DOT_FONTNAME. You need to make sure dot is able to find +# the font, which can be done by putting it in a standard location or by setting +# the DOTFONTPATH environment variable or by setting DOT_FONTPATH to the +# directory containing the font. -DOT_FONTNAME = FreeSans +DOT_FONTNAME = # The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs. # The default size is 10pt. DOT_FONTSIZE = 10 -# By default doxygen will tell dot to use the output directory to look for the -# FreeSans.ttf font (which doxygen will put there itself). If you specify a -# different font using DOT_FONTNAME you can set the path where dot -# can find it using this tag. +# By default doxygen will tell dot to use the Helvetica font. +# If you specify a different font using DOT_FONTNAME you can use DOT_FONTPATH to +# set the path where dot can find it. DOT_FONTPATH = # If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen # will generate a graph for each documented class showing the direct and # indirect inheritance relations. Setting this tag to YES will force the -# the CLASS_DIAGRAMS tag to NO. +# CLASS_DIAGRAMS tag to NO. CLASS_GRAPH = YES @@ -1402,6 +1752,15 @@ GROUP_GRAPHS = YES UML_LOOK = NO +# If the UML_LOOK tag is enabled, the fields and methods are shown inside +# the class node. If there are many fields or methods and many nodes the +# graph may become too big to be useful. The UML_LIMIT_NUM_FIELDS +# threshold limits the number of items for each type to make the size more +# manageable. Set this to 0 for no limit. Note that the threshold may be +# exceeded by 50% before the limit is enforced. + +UML_LIMIT_NUM_FIELDS = 10 + # If set to YES, the inheritance and collaboration graphs will show the # relations between templates and their instances. @@ -1438,11 +1797,11 @@ CALL_GRAPH = NO CALLER_GRAPH = NO # If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen -# will graphical hierarchy of all classes instead of a textual one. +# will generate a graphical hierarchy of all classes instead of a textual one. GRAPHICAL_HIERARCHY = YES -# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES +# If the DIRECTORY_GRAPH and HAVE_DOT tags are set to YES # then doxygen will show the dependencies a directory has on other directories # in a graphical way. The dependency relations are determined by the #include # relations between the files in the directories. @@ -1450,11 +1809,22 @@ GRAPHICAL_HIERARCHY = YES DIRECTORY_GRAPH = YES # The DOT_IMAGE_FORMAT tag can be used to set the image format of the images -# generated by dot. Possible values are png, jpg, or gif -# If left blank png will be used. +# generated by dot. Possible values are svg, png, jpg, or gif. +# If left blank png will be used. If you choose svg you need to set +# HTML_FILE_EXTENSION to xhtml in order to make the SVG files +# visible in IE 9+ (other browsers do not have this requirement). DOT_IMAGE_FORMAT = png +# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to +# enable generation of interactive SVG images that allow zooming and panning. +# Note that this requires a modern browser other than Internet Explorer. +# Tested and working are Firefox, Chrome, Safari, and Opera. For IE 9+ you +# need to set HTML_FILE_EXTENSION to xhtml in order to make the SVG files +# visible. Older versions of IE do not have SVG support. + +INTERACTIVE_SVG = NO + # The tag DOT_PATH can be used to specify the path where the dot tool can be # found. If left blank, it is assumed the dot tool can be found in the path. @@ -1466,6 +1836,12 @@ DOT_PATH = DOTFILE_DIRS = +# The MSCFILE_DIRS tag can be used to specify one or more directories that +# contain msc files that are included in the documentation (see the +# \mscfile command). + +MSCFILE_DIRS = + # The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of # nodes that will be shown in the graph. If the number of nodes in a graph # becomes larger than this value, doxygen will truncate the graph, which is diff --git a/host/docs/Ettus_Logo.png b/host/docs/Ettus_Logo.png Binary files differnew file mode 100644 index 000000000..89587ab9a --- /dev/null +++ b/host/docs/Ettus_Logo.png diff --git a/host/docs/build.dox b/host/docs/build.dox new file mode 100644 index 000000000..1584a7b58 --- /dev/null +++ b/host/docs/build.dox @@ -0,0 +1,186 @@ +/*! \page page_build_guide Building and Installing UHD + +\tableofcontents + +\section build_dependencies Build Dependencies + +<b>Linux Notes:</b> +This is dependent on the distribution you are using, but most, if not all, of +the dependencies should be available in the package repositories for your +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. +Other dependencies can be downloaded as DMG installers from the web +or installed via MacPorts. +See the UHD OS X page for more information: http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_OS_X + +<b>Windows Notes:</b> +The dependencies can be acquired through installable EXE files. +Usually, the Windows installer can be found on the project's website. +Some projects do not host Windows installers, and if this is the case, +follow the auxiliary download URL for the Windows installer (below). + +\section git 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. + +\section cpp_compiler C++ Compiler + +The following compilers are known to work: + +- GCC +- Clang +- MSVC + +### CMake + +- **Purpose:** generates project build files +- **Minimum Version:** 2.6 +- **Usage:** build time (required) +- **Download URL:** http://www.cmake.org/cmake/resources/software.html + +### Boost + +- **Purpose:** C++ library +- **Minimum Version:** 1.36 (Linux), 1.40 (Windows) +- **Usage:** build time + runtime (required) +- **Download URL:** http://www.boost.org/users/download/ +- **Download URL (Windows installer):** http://www.boostpro.com/download + +### LibUSB + +- **Purpose:** USB-based hardware support +- **Minimum Version:** 1.0 +- **Usage:** build time + runtime (optional) +- **Download URL:** http://sourceforge.net/projects/libusb/files/libusb-1.0/ +- **Download URL (Windows):** https://github.com/libusbx/libusbx + +### Python + +- **Purpose:** used by Cheetah and utility scripts +- **Minimum Version:** 2.6 +- **Usage:** build time + runtime utility scripts (required) +- **Download URL:** http://www.python.org/download/ + +### Cheetah + +- **Purpose:** source code generation +- **Minimum Version:** 2.0 +- **Usage:** build time (required) +- **Download URL:** http://www.cheetahtemplate.org/download.html +- **Download URL (Windows installer):** http://feisley.com/python/cheetah/ + +**Alternative method:** +Install **setuptools**, and use the **easy_install** command to install Cheetah. +http://pypi.python.org/pypi/setuptools + +### Doxygen + +- **Purpose:** generates HTML API documentation +- **Usage:** build time (optional) +- **Download URL:** http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc + +**Alternate method:** +Install **setuptools**, and use the **easy_install** command to install Docutils. +http://pypi.python.org/pypi/setuptools + +\section build_instructions_unix Build Instructions (Unix) + +\subsection generate_unix Generate Makefiles with CMake + + cd <uhd-repo-path>/host + mkdir build + cd build + 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` + +Example usage: + + cmake -DCMAKE_INSTALL_PREFIX=/opt/uhd ../ + +\subsection build_install_unix Build and install + + make + make test + sudo make install + +\subsection libpath_linux 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: + + sudo ldconfig + +\section build_instructions_windows Build Instructions (Windows) + +\subsection cmake_win 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`. +- 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. +- Click "Generate", and a project file will be created in the build directory. + +\subsection libusb_notes LibUSB notes + +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`. +- Recommend the static `libusb-1.0.lib` to simplify runtime dependencies. +- Check the box to enable USB support, click "Configure" and "Generate". + +<b>Note:</b> On Windows, LibUSBx is required to use most USB3 controllers. + +\subsection build_in_msvc Build the project in MSVC +- Open the generated project file in MSVC. +- Change the build type from "Debug" to "Release". +- Select the "Build All" target, right-click, and choose "Build". +- Select the install target, right-click, and choose "Build". + +<b>Note:</b> +You may not have permission to build the install target. +You need to be an administrator or to run MSVC as administrator. + +\section build_msvc_cmd_line Build the project in MSVC (command line) +Open the Visual Studio Command Prompt Shorcut: + + cd <uhd-repo-path>\host\build + DevEnv uhd.sln /build Release /project ALL_BUILD + DevEnv uhd.sln /build Release /project INSTALL + +\subsection path_env Setup the PATH environment variable +* Add the UHD bin path to `%PATH%` (usually `C:\\Program Files\\UHD\\bin`) + +<b>Note:</b> +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. + +\section post_install_tasks Post-Install Tasks + +For USB-based devices, +see the `USB Transport Application Notes <./transport.html#usb-transport-libusb>`_ +for platform-specific post-installation tasks. + +\section post_install_tasks_macosx Post-Install Tasks (Mac OS X) + +Make sure that the value of `CMAKE_INSTALL_PREFIX` is at or near the +front of the shell `PATH` environment variable. Do \b NOT set +`DYLD_LIBRARY_PATH` or any related DYLD environment variable +permanently; these work differently than under Linux and should be +used for testing / temporary purposes only. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/build.rst b/host/docs/build.rst deleted file mode 100644 index f53a56d9b..000000000 --- a/host/docs/build.rst +++ /dev/null @@ -1,228 +0,0 @@ -======================================================================== -UHD Software - Build Guide -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Build Dependencies ------------------------------------------------------------------------- - -**Linux Notes:** -This is dependent on the distribution you are using, but most, if not all, of -the dependencies should be available in the package repositories for your -package manager. - -**Mac OS X Notes:** -Install the Xcode app to get the build tools (GCC and Make). -Use MacPorts to get the Boost and Cheetah dependencies. -Other dependencies can be downloaded as DMG installers from the web -or installed via MacPorts. -See the UHD OS X page for more information: http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_OS_X - -**Windows Notes:** -The dependencies can be acquired through installable EXE files. -Usually, the Windows installer can be found on the project's website. -Some projects do not host Windows installers, and if this is the case, -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. - -^^^^^^^^^^^^^^^^ -C++ Compiler -^^^^^^^^^^^^^^^^ -The following compilers are known to work: - -* GCC -* Clang -* MSVC - -^^^^^^^^^^^^^^^^ -CMake -^^^^^^^^^^^^^^^^ -* **Purpose:** generates project build files -* **Minimum Version:** 2.6 -* **Usage:** build time (required) -* **Download URL:** http://www.cmake.org/cmake/resources/software.html - -^^^^^^^^^^^^^^^^ -Boost -^^^^^^^^^^^^^^^^ -* **Purpose:** C++ library -* **Minimum Version:** 1.36 (Linux), 1.40 (Windows) -* **Usage:** build time + runtime (required) -* **Download URL:** http://www.boost.org/users/download/ -* **Download URL (Windows installer):** http://www.boostpro.com/download - -^^^^^^^^^^^^^^^^ -LibUSB -^^^^^^^^^^^^^^^^ -* **Purpose:** USB-based hardware support -* **Minimum Version:** 1.0 -* **Usage:** build time + runtime (optional) -* **Download URL:** http://sourceforge.net/projects/libusb/files/libusb-1.0/ -* **Download URL (Windows):** https://github.com/libusbx/libusbx - -^^^^^^^^^^^^^^^^ -Python -^^^^^^^^^^^^^^^^ -* **Purpose:** used by Cheetah and utility scripts -* **Minimum Version:** 2.6 -* **Usage:** build time + runtime utility scripts (required) -* **Download URL:** http://www.python.org/download/ - -^^^^^^^^^^^^^^^^ -Cheetah -^^^^^^^^^^^^^^^^ -* **Purpose:** source code generation -* **Minimum Version:** 2.0 -* **Usage:** build time (required) -* **Download URL:** http://www.cheetahtemplate.org/download.html -* **Download URL (Windows installer):** http://feisley.com/python/cheetah/ - -**Alternative method:** -Install **setuptools**, and use the **easy_install** command to install Cheetah. -http://pypi.python.org/pypi/setuptools - -^^^^^^^^^^^^^^^^ -Doxygen -^^^^^^^^^^^^^^^^ -* **Purpose:** generates HTML API documentation -* **Usage:** build time (optional) -* **Download URL:** http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc - -^^^^^^^^^^^^^^^^ -Docutils -^^^^^^^^^^^^^^^^ -* **Purpose:** generates HTML user manual -* **Usage:** build time (optional) -* **Download URL:** http://docutils.sourceforge.net/ - -**Alternate method:** -Install **setuptools**, and use the **easy_install** command to install Docutils. -http://pypi.python.org/pypi/setuptools - ------------------------------------------------------------------------- -Build Instructions (Unix) ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Generate Makefiles with CMake -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - cd <uhd-repo-path>/host - mkdir build - cd build - 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** - -Example usage: -:: - - cmake -DCMAKE_INSTALL_PREFIX=/opt/uhd ../ - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Build and install -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - make - make test - sudo make 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: -:: - - sudo ldconfig - ------------------------------------------------------------------------- -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**. -* 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. -* Click "Generate", and a project file will be created in the build directory. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -LibUSB notes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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**. - - * Recommend the static **libusb-1.0.lib** to simplify runtime dependencies. - -* Check the box to enable USB support, click "Configure" and "Generate". - -**Note:** On Windows, LibUSBx is required to use most USB3 controllers. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Build the project in MSVC -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -* Open the generated project file in MSVC. -* Change the build type from "Debug" to "Release". -* Select the "Build All" target, right-click, and choose "Build". -* Select the install target, right-click, and choose "Build". - -**Note:** You may not have permission to build the install target. -You need to be an administrator or to run MSVC as administrator. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Build the project in MSVC (command line) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Open the Visual Studio Command Prompt Shorcut: -:: - - cd <uhd-repo-path>\host\build - DevEnv uhd.sln /build Release /project ALL_BUILD - DevEnv uhd.sln /build Release /project INSTALL - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Setup the PATH environment variable -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -* Add the UHD bin path to **%PATH%** (usually **C:\\Program Files\\UHD\\bin**) - -**Note:** -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. - ------------------------------------------------------------------------- -Post-Install Tasks ------------------------------------------------------------------------- -For USB-based devices, -see the `USB Transport Application Notes <./transport.html#usb-transport-libusb>`_ -for platform-specific post-installation tasks. - ------------------------------------------------------------------------- -Post-Install Tasks (Mac OS X) ------------------------------------------------------------------------- -Make sure that the value of **CMAKE_INSTALL_PREFIX** is at or near the -front of the shell **PATH** environment variable. Do **NOT** set -DYLD_LIBRARY_PATH or any related DYLD environment variable -permanently; these work differently than under Linux and should be -used for testing / temporary purposes only. diff --git a/host/docs/calibration.dox b/host/docs/calibration.dox new file mode 100644 index 000000000..494cfca49 --- /dev/null +++ b/host/docs/calibration.dox @@ -0,0 +1,70 @@ +/*! \page page_calibration Calibration Application Notes + +\tableofcontents + +\section calibration_self Self-Calibration + +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 software will +automatically apply corrections at runtime when the user re-tunes the +daughterboard LO. Calibration results are specific to an individual RF +board. + +<b>Note:</b> 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 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 +- **uhd_cal_tx_iq_balance:** - mimimizes TX IQ imbalance vs. LO + frequency + +The following RF frontends are supported by the self-calibration +utilities: + +- RFX Series transceiver boards +- WBX Series transceiver boards +- SBX Series transceiver boards +- CBX Series transceiver boards + +\subsection calibration_self_utils Calibration Utilities + +UHD software installs the calibration utilities into +`<install-path>/bin`. **Disconnect** any external hardware from the +RF antenna ports, and run the following from the command line. Each +utility will take several minutes to complete. : + + uhd_cal_rx_iq_balance --verbose --args=<optional device args> + uhd_cal_tx_iq_balance --verbose --args=<optional device args> + uhd_cal_tx_dc_offset --verbose --args=<optional device args> + +See the output given by --help for more advanced options, such as: +manually choosing the frequency range and step size for the sweeps. + +<b>Note:</b> Your daughterboard needs a serial number to run a calibration +utility. Some older daughterboards may not have a serial number. If this +is the case, run the following command to burn a serial number into the +daughterboard's EEPROM: : + + <install dir>/lib/uhd/utils/usrp_burn_db_eeprom --ser=<desired serial> --args=<optional device args> + +\subsection calibration_ Calibration Data + +Calibration files are stored in the user's home/application directory. +They can easily be moved from machine to another by copying the "cal" +directory. Re-running a calibration utility will replace the existing +calibration file. The old calibration file will be renamed so it may be +recovered by the user. + +- **Linux:** `${HOME}/.uhd/cal/` +- **Windows:** `%APPDATA%\.uhd\cal\` + +*/ +// vim:ft=doxygen: diff --git a/host/docs/calibration.rst b/host/docs/calibration.rst deleted file mode 100644 index 23bef01b7..000000000 --- a/host/docs/calibration.rst +++ /dev/null @@ -1,70 +0,0 @@ -======================================================================== -UHD - Calibration Application Notes -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Self-Calibration ------------------------------------------------------------------------- -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 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:** -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 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 - * **uhd_cal_tx_iq_balance:** - mimimizes TX IQ imbalance vs. LO frequency - -The following RF frontends are supported by the self-calibration utilities: - - * RFX Series transceiver boards - * WBX Series transceiver boards - * SBX Series transceiver boards - * CBX Series transceiver boards - -******************************************** -Calibration Utilities -******************************************** -UHD software installs the calibration utilities into **<install-path>/bin**. -**Disconnect** any external hardware from the RF antenna ports, -and run the following from the command line. -Each utility will take several minutes to complete. -:: - - uhd_cal_rx_iq_balance --verbose --args=<optional device args> - uhd_cal_tx_iq_balance --verbose --args=<optional device args> - uhd_cal_tx_dc_offset --verbose --args=<optional device args> - -See the output given by --help for more advanced options, such as: -manually choosing the frequency range and step size for the sweeps. - -**Note:** -Your daughterboard needs a serial number to run a calibration utility. Some older daughterboards -may not have a serial number. If this is the case, run the following command to burn a serial number -into the daughterboard's EEPROM: -:: - - <install dir>/lib/uhd/utils/usrp_burn_db_eeprom --ser=<desired serial> --args=<optional device args> - -******************************************** -Calibration Data -******************************************** -Calibration files are stored in the user's home/application directory. -They can easily be moved from machine to another by copying the "cal" directory. -Re-running a calibration utility will replace the existing calibration file. -The old calibration file will be renamed so it may be recovered by the user. - - * **Linux:** ${HOME}/.uhd/cal/ - * **Windows:** %APPDATA%\\.uhd\\cal\\ - diff --git a/host/docs/coding.dox b/host/docs/coding.dox new file mode 100644 index 000000000..b50e55e24 --- /dev/null +++ b/host/docs/coding.dox @@ -0,0 +1,30 @@ +/*! \page page_coding Coding to the API + +\tableofcontents + +\section coding_api Various API interfaces + +\subsection coding_api_hilevel High-Level: The Multi-USRP + +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 for uhd::usrp::multi_usrp. + +\subsection coding_api_lowlevel Low-Level: The device API + +A device is an abstraction for hardware that is connected to the host +system. 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. +- Create a device object for a particular device identified by + address. +- Register a device driver into the discovery and factory sub-system. +- Streaming samples with metadata into and out of the device. +- Set and get properties on the device object. + +See the documentation for uhd::device. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/coding.rst b/host/docs/coding.rst deleted file mode 100644 index 432307cca..000000000 --- a/host/docs/coding.rst +++ /dev/null @@ -1,30 +0,0 @@ -======================================================================== -UHD - Coding to the API -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -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 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. -* Create a device object for a particular device identified by address. -* Register a device driver into the discovery and factory sub-system. -* Streaming samples with metadata into and out of the device. -* Set and get properties on the device object. - -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 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.dox b/host/docs/dboards.dox new file mode 100644 index 000000000..b25656b5b --- /dev/null +++ b/host/docs/dboards.dox @@ -0,0 +1,405 @@ +/*! \page page_dboards Daughterboard Application Notes + +\tableofcontents + +\section dboards Daughterboard Properties + + +The following contains interesting notes about each daughterboard. +Eventually, this page will be expanded to list out the full properties +of each board as well. + +\subsection dboards_basicrx Basic RX and LFRX + +The Basic RX and LFRX boards have 4 frontends: + +- **Frontend A:** real signal on antenna RXA +- **Frontend B:** real signal on antenna RXB +- **Frontend AB:** quadrature frontend using both antennas (IQ) +- **Frontend BA:** quadrature frontend using both antennas (QI) + +The boards have no tunable elements or programmable gains. Through the +magic of aliasing, you can down-convert signals greater than the Nyquist +rate of the ADC. + +BasicRX Bandwidth: + +- **For Real-Mode (A or B frontend)**: 250 MHz +- **For Complex (AB or BA frontend)**: 500 MHz + +LFRX Bandwidth: + +- **For Real-Mode (A or B frontend)**: 33 MHz +- **For Complex (AB or BA frontend)**: 66 MHz + +\subsection dboards_basictx Basic TX and LFTX + +The Basic TX and LFTX boards have 4 frontends: + +- **Frontend A:** real signal on antenna TXA +- **Frontend B:** real signal on antenna TXB +- **Frontend AB:** quadrature frontend using both antennas (IQ) +- **Frontend BA:** quadrature frontend using both antennas (QI) + +The boards have no tunable elements or programmable gains. Through the +magic of aliasing, you can up-convert signals greater than the Nyquist +rate of the DAC. + +BasicTX Bandwidth: + +- **For Real-Mode (A or B frontend**): 250 MHz +- **For Complex (AB or BA frontend)**: 500 MHz + +LFTX Bandwidth: + +- **For Real-Mode (A or B frontend)**: 33 MHz +- **For Complex (AB or BA frontend)**: 66 MHz + +\subsection dboards_dbsrx DBSRX + +The DBSRX board has 1 quadrature frontend. It defaults to direct +conversion but can use a low IF through lo_offset in uhd::tune_request_t. + +Receive Antennas: **J3** + +- **Frontend 0:** Complex baseband signal from antenna J3 + +The board has no user selectable antenna setting. + +Receive Gains: + +- **GC1**, Range: 0-56dB +- **GC2**, Range: 0-24dB + +Bandwidth: 8 MHz - 66 MHz + +Sensors: + +- **lo_locked**: boolean for LO lock state + +\subsection dboards_dbsrx2 DBSRX2 + +The DBSRX2 board has 1 quadrature frontend. It defaults to direct +conversion, but can use a low IF through lo_offset in uhd::tune_request_t. + +Receive Antennas: **J3** + +- **Frontend 0:** Complex baseband signal from antenna J3 + +The board has no user-selectable antenna setting. + +Receive Gains: + +- **GC1**, Range: 0-73dB +- **BBG**, Range: 0-15dB + +Bandwidth (Hz): 8 MHz -80 MHz + +Sensors: + +- **lo_locked**: boolean for LO lock state + +\subsection dboards_rfx RFX Series + +The RFX Series boards have 2 quadrature frontends: Transmit and Receive. +Transmit defaults to low IF, and Receive defaults to direct conversion. +The IF can be adjusted through lo_offset in uhd::tune_request_t. + +The RFX Series boards have independent receive and transmit LO's and +synthesizers allowing full-duplex operation on different transmit and +receive frequencies. + +Transmit Antennas: **TX/RX** + +Receive Antennas: **TX/RX** or **RX2** + +- **Frontend 0:** Complex baseband signal for selected antenna + +The user may set the receive antenna to be TX/RX or RX2. However, when +using an RFX board in full-duplex mode, the receive antenna will always +be set to RX2, regardless of the settings. + +Receive Gains: **PGA0**, Range: 0-70dB (except RFX400 range is 0-45dB) + +Bandwidth: + +- **RX**: 40 MHz +- **TX**: 40 MHz + +Sensors: + +- **lo_locked**: boolean for LO lock state + +\subsection dboards_xcvr XCVR 2450 + +The XCVR2450 has 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. + +The XCVR2450 has a non-contiguous tuning range consisting of a high band +(4.9-6.0 GHz) and a low band (2.4-2.5 GHz). + +Transmit Antennas: **J1** or **J2** + +Receive Antennas: **J1** or **J2** + +- **Frontend 0:** Complex baseband signal for selected antenna + +The XCVR2450 uses a common LO for both receive and transmit. Even though +the API allows the RX and TX LOs to be individually set, a change of one +LO setting will be reflected in the other LO setting. + +The XCVR2450 does not support full-duplex mode, attempting to operate in +full-duplex will result in transmit-only operation. + +Transmit Gains: + +- **VGA**, Range: 0-30dB +- **BB**, Range: 0-5dB + +Receive Gains: + +- **LNA**, Range: 0-30.5dB +- **VGA**, Range: 0-62dB + +Bandwidths: + +- **RX**: 15 MHz, 19 MHz, 28 MHz, 36 MHz; (each +-0, 5, or 10%) +- **TX**: 24 MHz, 36 MHz, 48 MHz + +Sensors: + +- **lo_locked**: boolean for LO lock state +- **rssi**: float for rssi in dBm + +\subsection dboards_wbx WBX Series + +Features: + +- 2 quadrature frontends (1 transmit, 1 receive) + - Defaults to direct conversion + - Can be used in low IF mode through lo_offset with uhd::tune_request_t +- Independent recieve and transmit LO's and synthesizers + - Allows for full-duplex operation on different transmit and receive frequencies + - Can be set to use Integer-N tuning for better spur performance + with uhd::tune_request_t + +Transmit Antennas: **TX/RX** + +Receive Antennas: **TX/RX** or **RX2** + +- **Frontend 0:** Complex baseband signal for selected antenna + +- **Note:** The user may set the receive antenna to be TX/RX or RX2. + However, when using a WBX board in full-duplex mode, the receive + antenna will always be set to RX2, regardless of the settings. + +Transmit Gains: **PGA0**, Range: 0-25dB + +Receive Gains: **PGA0**, Range: 0-31.5dB + +Bandwidths: + +- **WBX**: 40 MHz, RX & TX +- **WBX-120**: 120 MHz, RX & TX + +Sensors: + +- **lo_locked**: boolean for LO lock state + +\subsection dboards_sbx SBX Series + +Features: + +- 2 quadrature frontends (1 transmit, 1 receive) + - Defaults to direct conversion + - Can be used in low IF mode through lo_offset with uhd::tune_request_t +- Independent recieve and transmit LO's and synthesizers + - Allows for full-duplex operation on different transmit and + receive frequencies + - Can be set to use Integer-N tuning for better spur performance with uhd::tune_request_t + +Transmit Antennas: **TX/RX** + +Receive Antennas: **TX/RX** or **RX2** + +- **Frontend 0:** Complex baseband signal for selected antenna + +- **Note:** The user may set the receive antenna to be TX/RX or RX2. + However, when using an SBX board in full-duplex mode, the receive + antenna will always be set to RX2, regardless of the settings. + +Transmit Gains: **PGA0**, Range: 0-31.5dB + +Receive Gains: **PGA0**, Range: 0-31.5dB + +Bandwidths: + +- **SBX**: 40 MHz, RX & TX +- **SBX-120**: 120 MHz, RX & TX + +Sensors: + +- **lo_locked**: boolean for LO lock state + +LEDs: + +- All LEDs flash when daughterboard control is initialized +- **TX LD**: Transmit Synthesizer Lock Detect +- **TX/RX**: Receiver on TX/RX antenna port (No TX) +- **RX LD**: Receive Synthesizer Lock Detect +- **RX1/RX2**: Receiver on RX2 antenna port + +\subsection dboards_cbx CBX Series + +Features: +- 2 quadrature frontends (1 transmit, 1 receive) + - Defaults to direct conversion + - Can be used in low IF mode through lo_offset with uhd::tune_request_t +- Independent recieve and transmit LO's and synthesizers + - Allows for full-duplex operation on different transmit and + receive frequencies + - Can be set to use Integer-N tuning for better spur performance with uhd::tune_request_t + +Transmit Antennas: **TX/RX** + +Receive Antennas: **TX/RX** or **RX2** + +- **Frontend 0:** Complex baseband signal for selected antenna + +- **Note:** The user may set the receive antenna to be TX/RX or RX2. + However, when using a CBX board in full-duplex mode, the receive + antenna will always be set to RX2, regardless of the settings. + +Transmit Gains: **PGA0**, Range: 0-31.5dB + +Receive Gains: **PGA0**, Range: 0-31.5dB + +Bandwidths: + +- **CBX**: 40 MHz, RX & TX +- **CBX-120**: 120 MHz, RX & TX + +Sensors: + +- **lo_locked**: boolean for LO lock state + +LEDs: + +- All LEDs flash when daughterboard control is initialized +- **TX LD**: Transmit Synthesizer Lock Detect +- **TX/RX**: Receiver on TX/RX antenna port (No TX) +- **RX LD**: Receive Synthesizer Lock Detect +- **RX1/RX2**: Receiver on RX2 antenna port + +\subsection dboards_tvrx TVRX + +The TVRX board has 1 real-mode frontend. It is operated at a low IF. + +Receive Antennas: RX + +- **Frontend 0:** real-mode baseband signal from antenna RX + +Receive Gains: + +- **RF**, Range: -13.3-50.3dB (frequency-dependent) +- **IF**, Range: -1.5-32.5dB + +Bandwidth: 6 MHz + +\subsection dboards_tvrx2 TVRX2 + +The TVRX2 board has 2 real-mode frontends. It is operated at a low IF. + +Receive Frontends: + +- **Frontend RX1:** real-mode baseband from antenna J100 +- **Frontend RX2:** real-mode baseband from antenna J140 + +Note: The TVRX2 has always-on AGC; the software controllable gain is the +final gain stage which controls the AGC set-point for output to ADC. + +Receive Gains: + +- **IF**, Range: 0.0-30.0dB + +Bandwidth: 1.7 MHz, 6 MHz, 7 MHz, 8 MHz, 10 MHz + +Sensors: + +- **lo_locked**: boolean for LO lock state +- **rssi**: float for measured RSSI in dBm +- **temperature**: float for measured temperature in degC + +\subsection dboards_dbsrxmod DBSRX - Modifying for other boards that USRP1 + +Due to different clocking capabilities, the DBSRX will require +modifications to operate on a non-USRP1 motherboard. On a USRP1 +motherboard, a divided clock is provided from an FPGA pin because the +standard daughterboard clock lines cannot provided a divided clock. +However, on other USRP motherboards, the divided clock is provided over +the standard daughterboard clock lines. + +\subsubsection dboards_dbsrxmod_1 Step 1: Move the clock configuration resistor + +Remove **R193** (which is 10 Ohms, 0603 size), and put it on **R194**, +which is empty. This is made somewhat more complicated by the fact that +the silkscreen is not clear in that area. **R193** is on the back, +immediately below the large beige connector, **J2**. **R194** is just +below, and to the left of **R193**. The silkscreen for **R193** is ok, +but for **R194**, it is upside down, and partially cut off. If you lose +**R193**, you can use anything from 0 to 10 Ohms there. + +\subsubsection dboards_dbsrxmod_1 Step 2: Burn a new daughterboard id into the EEPROM + +With the daughterboard plugged-in, run the following commands: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_db_eeprom --id=0x000d --unit=RX --args=<args> --slot=<slot> + +- **\<args\>** are device address arguments (optional if only one USRP + device is on your machine) +- **\<slot\>** is the name of the daughterboard slot (optional if the + USRP device has only one slot) + +\subsection dboards_rfxmod RFX - Modify to use motherboard oscillator + +Older RFX boards require modifications to use the motherboard +oscillator. 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** + +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. + +- Step 3: Burn the appropriate daughterboard ID into the EEPROM + +With the daughterboard plugged in, run the following commands: : + + cd <install-path>/lib/uhd/utils + ./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 + - **RFX400:** 0x0024 + - **RFX900:** 0x0025 + - **RFX1800:** 0x0034 + - **RFX1200:** 0x0026 + - **RFX2400:** 0x0027 +- `<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 device is on your machine) +- `<slot>` is the name of the daughterboard slot (optional if the USRP device has only one slot) + + +*/ +// vim:ft=doxygen: diff --git a/host/docs/dboards.rst b/host/docs/dboards.rst deleted file mode 100644 index d6cbc6151..000000000 --- a/host/docs/dboards.rst +++ /dev/null @@ -1,425 +0,0 @@ -======================================================================== -UHD Daughterboard Application Notes -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Daughterboard Properties ------------------------------------------------------------------------- - -The following contains interesting notes about each daughterboard. -Eventually, this page will be expanded to list out the full -properties of each board as well. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Basic RX and LFRX -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The Basic RX and LFRX boards have 4 frontends: - -* **Frontend A:** real signal on antenna RXA -* **Frontend B:** real signal on antenna RXB -* **Frontend AB:** quadrature frontend using both antennas (IQ) -* **Frontend BA:** quadrature frontend using both antennas (QI) - -The boards have no tunable elements or programmable gains. -Through the magic of aliasing, you can down-convert signals -greater than the Nyquist rate of the ADC. - -BasicRX Bandwidth: - -* **For Real-Mode (A or B frontend)**: 250 MHz -* **For Complex (AB or BA frontend)**: 500 MHz - -LFRX Bandwidth: - -* **For Real-Mode (A or B frontend)**: 33 MHz -* **For Complex (AB or BA frontend)**: 66 MHz - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Basic TX and LFTX -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The Basic TX and LFTX boards have 4 frontends: - -* **Frontend A:** real signal on antenna TXA -* **Frontend B:** real signal on antenna TXB -* **Frontend AB:** quadrature frontend using both antennas (IQ) -* **Frontend BA:** quadrature frontend using both antennas (QI) - -The boards have no tunable elements or programmable gains. -Through the magic of aliasing, you can up-convert signals -greater than the Nyquist rate of the DAC. - -BasicTX Bandwidth (Hz): - -* **For Real-Mode (A or B frontend**): 250 MHz -* **For Complex (AB or BA frontend)**: 500 MHz - -LFTX Bandwidth (Hz): - -* **For Real-Mode (A or B frontend)**: 33 MHz -* **For Complex (AB or BA frontend)**: 66 MHz - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -DBSRX -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The DBSRX board has 1 quadrature frontend. -It defaults to direct conversion but can use a low IF through lo_offset in **uhd::tune_request_t**. - -Receive Antennas: **J3** - -* **Frontend 0:** Complex baseband signal from antenna J3 - -The board has no user selectable antenna setting. - -Receive Gains: - -* **GC1**, Range: 0-56dB -* **GC2**, Range: 0-24dB - -Bandwidth: 8 MHz - 66 MHz - -Sensors: - -* **lo_locked**: boolean for LO lock state - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -DBSRX2 -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The DBSRX2 board has 1 quadrature frontend. -It defaults to direct conversion, but can use a low IF through lo_offset in **uhd::tune_request_t**. - -Receive Antennas: **J3** - -* **Frontend 0:** Complex baseband signal from antenna J3 - -The board has no user-selectable antenna setting. - -Receive Gains: - -* **GC1**, Range: 0-73dB -* **BBG**, Range: 0-15dB - -Bandwidth (Hz): 8 MHz -80 MHz - -Sensors: - -* **lo_locked**: boolean for LO lock state - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -RFX Series -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The RFX Series boards have 2 quadrature frontends: Transmit and Receive. -Transmit defaults to low IF, and Receive defaults to direct conversion. -The IF can be adjusted through lo_offset in **uhd::tune_request_t**. - -The RFX Series boards have independent receive and transmit LO's and synthesizers -allowing full-duplex operation on different transmit and receive frequencies. - -Transmit Antennas: **TX/RX** - -Receive Antennas: **TX/RX** or **RX2** - -* **Frontend 0:** Complex baseband signal for selected antenna - -The user may set the receive antenna to be TX/RX or RX2. -However, when using an RFX board in full-duplex mode, -the receive antenna will always be set to RX2, regardless of the settings. - -Receive Gains: **PGA0**, Range: 0-70dB (except RFX400 range is 0-45dB) - -Bandwidth: - -* **RX**: 40 MHz -* **TX**: 40 MHz - -Sensors: - -* **lo_locked**: boolean for LO lock state - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -XCVR 2450 -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The XCVR2450 has 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. - -The XCVR2450 has a non-contiguous tuning range consisting of a -high band (4.9-6.0 GHz) and a low band (2.4-2.5 GHz). - -Transmit Antennas: **J1** or **J2** - -Receive Antennas: **J1** or **J2** - -* **Frontend 0:** Complex baseband signal for selected antenna - -The XCVR2450 uses a common LO for both receive and transmit. -Even though the API allows the RX and TX LOs to be individually set, -a change of one LO setting will be reflected in the other LO setting. - -The XCVR2450 does not support full-duplex mode, attempting to operate -in full-duplex will result in transmit-only operation. - -Transmit Gains: - -* **VGA**, Range: 0-30dB -* **BB**, Range: 0-5dB - -Receive Gains: - -* **LNA**, Range: 0-30.5dB -* **VGA**, Range: 0-62dB - -Bandwidths: - -* **RX**: 15 MHz, 19 MHz, 28 MHz, 36 MHz; (each +-0, 5, or 10%) -* **TX**: 24 MHz, 36 MHz, 48 MHz - -Sensors: - -* **lo_locked**: boolean for LO lock state -* **rssi**: float for rssi in dBm - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -WBX Series -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Features: - -* 2 quadrature frontends (1 transmit, 1 receive) - - * Defaults to direct conversion - * Can be used in low IF mode through lo_offset with **uhd::tune_request_t** - -* Independent recieve and transmit LO's and synthesizers - - * Allows for full-duplex operation on different transmit and receive frequencies - * Can be set to use Integer-N tuning for better spur performance with **uhd::tune_request_t** - -Transmit Antennas: **TX/RX** - -Receive Antennas: **TX/RX** or **RX2** - -* **Frontend 0:** Complex baseband signal for selected antenna - -* **Note:** The user may set the receive antenna to be TX/RX or RX2. However, when using a WBX board in full-duplex mode, the receive antenna will always be set to RX2, regardless of the settings. - -Transmit Gains: **PGA0**, Range: 0-25dB - -Receive Gains: **PGA0**, Range: 0-31.5dB - -Bandwidths: - -* **WBX**: 40 MHz, RX & TX -* **WBX-120**: 120 MHz, RX & TX - -Sensors: - -* **lo_locked**: boolean for LO lock state - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -SBX Series -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Features: - -* 2 quadrature frontends (1 transmit, 1 receive) - - * Defaults to direct conversion - * Can be used in low IF mode through lo_offset with **uhd::tune_request_t** - -* Independent recieve and transmit LO's and synthesizers - - * Allows for full-duplex operation on different transmit and receive frequencies - * Can be set to use Integer-N tuning for better spur performance with **uhd::tune_request_t** - -Transmit Antennas: **TX/RX** - -Receive Antennas: **TX/RX** or **RX2** - -* **Frontend 0:** Complex baseband signal for selected antenna - -* **Note:** The user may set the receive antenna to be TX/RX or RX2. However, when using an SBX board in full-duplex mode, the receive antenna will always be set to RX2, regardless of the settings. - -Transmit Gains: **PGA0**, Range: 0-31.5dB - -Receive Gains: **PGA0**, Range: 0-31.5dB - -Bandwidths: - -* **SBX**: 40 MHz, RX & TX -* **SBX-120**: 120 MHz, RX & TX - -Sensors: - -* **lo_locked**: boolean for LO lock state - -LEDs: - -* All LEDs flash when daughterboard control is initialized -* **TX LD**: Transmit Synthesizer Lock Detect -* **TX/RX**: Receiver on TX/RX antenna port (No TX) -* **RX LD**: Receive Synthesizer Lock Detect -* **RX1/RX2**: Receiver on RX2 antenna port - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -CBX Series -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Features: - -* 2 quadrature frontends (1 transmit, 1 receive) - - * Defaults to direct conversion - * Can be used in low IF mode through lo_offset with **uhd::tune_request_t** - -* Independent recieve and transmit LO's and synthesizers - - * Allows for full-duplex operation on different transmit and receive frequencies - * Can be set to use Integer-N tuning for better spur performance with **uhd::tune_request_t** - -Transmit Antennas: **TX/RX** - -Receive Antennas: **TX/RX** or **RX2** - -* **Frontend 0:** Complex baseband signal for selected antenna - -* **Note:** The user may set the receive antenna to be TX/RX or RX2. However, when using a CBX board in full-duplex mode, the receive antenna will always be set to RX2, regardless of the settings. - -Transmit Gains: **PGA0**, Range: 0-31.5dB - -Receive Gains: **PGA0**, Range: 0-31.5dB - -Bandwidths: - -* **CBX**: 40 MHz, RX & TX -* **CBX-120**: 120 MHz, RX & TX - -Sensors: - -* **lo_locked**: boolean for LO lock state - -LEDs: - -* All LEDs flash when daughterboard control is initialized -* **TX LD**: Transmit Synthesizer Lock Detect -* **TX/RX**: Receiver on TX/RX antenna port (No TX) -* **RX LD**: Receive Synthesizer Lock Detect -* **RX1/RX2**: Receiver on RX2 antenna port - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -TVRX -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The TVRX board has 1 real-mode frontend. -It is operated at a low IF. - -Receive Antennas: RX - -* **Frontend 0:** real-mode baseband signal from antenna RX - -Receive Gains: - -* **RF**, Range: -13.3-50.3dB (frequency-dependent) -* **IF**, Range: -1.5-32.5dB - -Bandwidth: 6 MHz - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -TVRX2 -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The TVRX2 board has 2 real-mode frontends. -It is operated at a low IF. - -Receive Frontends: - -* **Frontend RX1:** real-mode baseband from antenna J100 -* **Frontend RX2:** real-mode baseband from antenna J140 - -Note: The TVRX2 has always-on AGC; the software controllable gain is the -final gain stage which controls the AGC set-point for output to ADC. - -Receive Gains: - -* **IF**, Range: 0.0-30.0dB - -Bandwidth: 1.7 MHz, 6 MHz, 7 MHz, 8 MHz, 10 MHz - -Sensors: - -* **lo_locked**: boolean for LO lock state -* **rssi**: float for measured RSSI in dBm -* **temperature**: float for measured temperature in degC - -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -DBSRX - Mod -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Due to different clocking capabilities, -the DBSRX will require modifications to operate on a non-USRP1 motherboard. -On a USRP1 motherboard, a divided clock is provided from an FPGA pin -because the standard daughterboard clock lines cannot provided a divided clock. -However, on other USRP motherboards, the divided clock is provided -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. -This is made somewhat more complicated by the fact that the silkscreen is not clear in that area. -**R193** is on the back, immediately below the large beige connector, **J2**. -**R194** is just below, and to the left of **R193**. -The silkscreen for **R193** is ok, but for **R194**, -it is upside down, and partially cut off. -If you lose **R193**, you can use anything from 0 to 10 Ohms there. - -**Step 2: Burn a new daughterboard id into the EEPROM** - -With the daughterboard plugged-in, run the following commands: -:: - - cd <install-path>/lib/uhd/utils - ./usrp_burn_db_eeprom --id=0x000d --unit=RX --args=<args> --slot=<slot> - -* **<args>** are device address arguments (optional if only one USRP 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 software will print a warning about the modification. -Please follow the modification procedures below: - -**Step 1: Disable the daughterboard clocks** - -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. - -**Step 3: Burn the appropriate daughterboard ID into the EEPROM** - -With the daughterboard plugged-in, run the following commands: -:: - - cd <install-path>/lib/uhd/utils - ./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 - - * **RFX400:** 0x0024 - * **RFX900:** 0x0025 - * **RFX1800:** 0x0034 - * **RFX1200:** 0x0026 - * **RFX2400:** 0x0027 -* **<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 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.dox b/host/docs/general.dox new file mode 100644 index 000000000..14f017d04 --- /dev/null +++ b/host/docs/general.dox @@ -0,0 +1,220 @@ +/*! \page page_general General Application Notes + +\tableofcontents + +\section general_tuning Tuning Notes + +\subsection general_tuning_process Two-stage tuning process + +A USRP device has two stages of tuning: + +- RF front-end: translates bewteen RF and IF +- DSP: translates between IF and baseband + +In a typical use-case, the user specifies an overall center frequency +for the signal chain. The RF front-end will be tuned as close as +possible to the center frequency, and the DSP will account for the error +in tuning between target 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 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 the UHD software handle the +rest. + +The **tune_request_t** object can also be used with certain +daughterboards to use Integer-N tuning instead of the default fractional +tuning, allowing for better spur performance. The daughterboards that +support this functionality are: + +- WBX (all revisions) +- WBX-120 +- SBX (all revisions) +- SBX-120 +- CBX +- CBX-120 + +\subsubsection general_tuning_rxchain Tuning the receive chain: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +//tuning to a desired center frequency +usrp->set_rx_freq(target_frequency_in_hz); + +--OR-- + +//advanced tuning with tune_request_t uhd::tune_request_t +tune_req(target_frequency_in_hz, desired_lo_offset); +tune_req.args = uhd::device_addr_t("mode_n=integer"); //to use Int-N tuning +//fill in any additional/optional tune request fields... +usrp->set_rx_freq(tune_req); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +More information can be found in uhd::tune_request_t. + +\subsection general_tuning_rfsettling RF front-end settling time + +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 a conservative amount of time (perhaps a +second). + +\subsubsection general_tuning_waitcode Pseudo-code for dealing with settling time after tuning on receive: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + usrp->set_rx_freq(...); + sleep(1); + usrp->issue_stream_command(...); + + --OR-- + + usrp->set_rx_freq(...); + while (not usrp->get_rx_sensor("lo_locked").to_bool()){ + //sleep for a short time in milliseconds + } + usrp->issue_stream_command(...); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\section general_subdev Specifying the Subdevice to Use + +A subdevice specification string for USRP family devices is composed of: + + <motherboard slot name>:<daughterboard frontend name> + +Ex: The subdev spec markup string to select a WBX on slot B. + + B:0 + +Ex: The subdev spec markup string to select a BasicRX on slot B. + + B:AB + + -- OR -- + + B:A + + -- OR -- + + B:B + +\subsection general_subdev_slotnames USRP Family Motherboard Slot Names + +All USRP family motherboards have a first slot named **A:**. The USRP1 and the X3x0 +have two daughterboard subdevice slots, known as **A:** and **B:**. + +\subsection general_subdev_dbnames Daughterboard Frontend Names + +Daughterboard frontend names can be used to specify which signal path is +used from a daughterboard. Most daughterboards have only one frontend **:0**. +A few daughterboards (Basic, LF and TVRX2) have multiple +frontend names available. The frontend names are documented in \ref page_dboards. + +\section general_ounotes Overflow/Underflow Notes + +<b>Note:</b> The following overflow/underflow notes do not apply to USRP1, +which does not support the advanced features available in newer +products. + +\subsection general_ounotes_overflow 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 software detects the overflow, it prints an "O" or "D" to stdout, +and pushes an inline message packet into the receive stream. + +<b>Network-based devices</b>: The host does not back-pressure the receive +stream. When the kernel's socket buffer becomes full, it will drop +subsequent packets. UHD software detects the overflow as a discontinuity +in the packet's sequence numbers, and pushes an inline message packet +into the receive stream. In this case the character "D" is printed to +stdout as an indication. + +<b>Other devices</b>: The host back-pressures the receive stream. +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. In this case the character +"O" is printed to stdout as an indication. If the device was in +continuous streaming mode, the UHD software will automatically restart +streaming when the buffer has space again. + +\subsection general_ounotes_underrun Underrun notes + +When transmitting, the device consumes samples at a constant rate. +Underflow occurs when the host does not produce data fast enough. When +UHD software detects the underflow, it prints a "U" to stdout, and +pushes a message packet into the async message stream. + +<b>Note:</b> "O" and "U" message are generally harmless, and just mean the host machine can't keep up with the requested rates. + +\section general_threading Threading Notes + +\subsection general_threading_safety Thread safety notes + +For the most part, UHD software is thread-safe. Please observe the +following limitations: + +<b>Fast-path thread requirements:</b> There are three fast-path methods for +a device: `send()`, `recv()`, and `recv_async_msg()`. All three +methods are thread-safe and can be called from different thread +contexts. For performance, the user should call each method from a +separate thread context. These methods can also be used in a +non-blocking fashion by using a timeout of zero. + +<b>Slow-path thread requirements:</b> It is safe to change multiple +settings simultaneously. However, this could leave the settings for a +device in an uncertain state. This is because changing one setting could +have an impact on how a call affects other settings. Example: setting +the channel mapping affects how the antennas are set. It is recommended +to use at most one thread context for manipulating device settings. + +\subsection general_threading_prio Thread priority scheduling + +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. + +<b>Linux Notes:</b> + +Non-privileged users need special permission to change the scheduling +priority. Add the following line to `/etc/security/limits.conf`: + + @GROUP - rtprio 99 + +Replace `GROUP` with a group to which your user belongs. +Settings will not take effect until the user is in a different login +session. + +\section general_misc Miscellaneous Notes + +\subsection general_misc_dynamic 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). + +\subsection general_misc_prints 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 +the UHD library: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +#include <uhd/utils/msg.hpp> + +void my_handler(uhd::msg::type_t type, const std::string &msg){ +//handle the message... +} + +uhd::msg::register_handler(&my_handler); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*/ +// vim:ft=doxygen: diff --git a/host/docs/general.rst b/host/docs/general.rst deleted file mode 100644 index 930c18188..000000000 --- a/host/docs/general.rst +++ /dev/null @@ -1,242 +0,0 @@ -=============================== -UHD - General Application Notes -=============================== - -.. contents:: Table of Contents - ------------- -Tuning Notes ------------- - -^^^^^^^^^^^^^^^^^^^^^^^^ -Two-stage tuning process -^^^^^^^^^^^^^^^^^^^^^^^^ -A USRP device has two stages of tuning: - -* RF front-end: translates bewteen RF and IF -* DSP: translates between IF and baseband - -In a typical use-case, the user specifies an overall center frequency for the -signal chain. The RF front-end will be tuned as close as possible to the center -frequency, and the DSP will account for the error in tuning between target -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 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 the UHD -software handle the rest. - -The **tune_request_t** object can also be used with certain daughterboards to use -Integer-N tuning instead of the default fractional tuning, allowing for better spur -performance. The daughterboards that support this functionality are: - -* WBX (all revisions) -* WBX-120 -* SBX (all revisions) -* SBX-120 -* CBX -* CBX-120 - -Tuning the receive chain: -::::::::::::::::::::::::: - - //tuning to a desired center frequency - usrp->set_rx_freq(target_frequency_in_hz); - - --OR-- - - //advanced tuning with tune_request_t - uhd::tune_request_t tune_req(target_frequency_in_hz, desired_lo_offset); - tune_req.args = uhd::device_addr_t("mode_n=integer"); //to use Int-N tuning - //fill in any additional/optional tune request fields... - usrp->set_rx_freq(tune_req); - -More information can be found in `tune_request.hpp <./../../doxygen/html/structuhd_1_1tune__request__t.html>`_. - -^^^^^^^^^^^^^^^^^^^^^^^^^^ -RF front-end settling time -^^^^^^^^^^^^^^^^^^^^^^^^^^ -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 -a conservative amount of time (perhaps a second). - -Pseudo-code for dealing with settling time after tuning on receive: -::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: - -:: - - usrp->set_rx_freq(...); - sleep(1); - usrp->issue_stream_command(...); - - --OR-- - - usrp->set_rx_freq(...); - while (not usrp->get_rx_sensor("lo_locked").to_bool()){ - //sleep for a short time in milliseconds - } - usrp->issue_stream_command(...); - - -------------------------------- -Specifying the Subdevice to Use -------------------------------- -A subdevice specification string for USRP family devices is composed of: - -:: - - <motherboard slot name>:<daughterboard frontend name> - -Ex: The subdev spec markup string to select a WBX on slot B. - -:: - - B:0 - -Ex: The subdev spec markup string to select a BasicRX on slot B. - -:: - - B:AB - - -- OR -- - - B:A - - -- OR -- - - B:B - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -USRP Family Motherboard Slot Names -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -All USRP family motherboards have a first slot named **A:**. The USRP1 has -two daughterboard subdevice slots, known as **A:** and **B:**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Daughterboard Frontend Names -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Daughterboard frontend names can be used to specify which signal path is used -from a daughterboard. Most daughterboards have only one frontend **:0**. A few -daughterboards (Basic, LF and TVRX2) have multiple frontend names available. -The frontend names are documented in the -`Daughterboard Application Notes <./dboards.html>`_ - ------------------------- -Overflow/Underflow Notes ------------------------- -**Note:** The following overflow/underflow notes do not apply to USRP1, -which does not support the advanced features available in newer products. - -^^^^^^^^^^^^^^ -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 software detects the overflow, it prints an "O" or "D" 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 software detects the overflow as a discontinuity in the packet's sequence numbers, -and pushes an inline message packet into the receive stream. -In this case the character "D" is printed to stdout as an indication. - -**Other devices**: -The host back-pressures the receive stream. -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. -In this case the character "O" is printed to stdout as an indication. -If the device was in continuous streaming mode, -the UHD software will automatically restart streaming when the buffer has -space again. - -^^^^^^^^^^^^^^^ -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 software detects the underflow, it prints a "U" to stdout, -and pushes a message packet into the async message stream. - ---------------- -Threading Notes ---------------- - -^^^^^^^^^^^^^^^^^^^ -Thread safety notes -^^^^^^^^^^^^^^^^^^^ -For the most part, UHD software is thread-safe. -Please observe the following limitations: - -**Fast-path thread requirements:** -There are three fast-path methods for a device: **send()**, **recv()**, and **recv_async_msg()**. -All three methods are thread-safe and can be called from different thread contexts. -For performance, the user should call each method from a separate thread context. -These methods can also be used in a non-blocking fashion by using a timeout of zero. - -**Slow-path thread requirements:** -It is safe to change multiple settings simultaneously. However, -this could leave the settings for a device in an uncertain state. -This is because changing one setting could have an impact on how a call affects other settings. -Example: setting the channel mapping affects how the antennas are set. -It is recommended to use at most one thread context for manipulating device settings. - -^^^^^^^^^^^^^^^^^^^^^^^^^^ -Thread priority scheduling -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -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:** - -Non-privileged users need special permission to change the scheduling priority. -Add the following line to **/etc/security/limits.conf**: -:::::::::::::::::::::::::::::::::::::::::::::::::::::::: - - @<my_group> - rtprio 99 - -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. - -------------------- -Miscellaneous Notes -------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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). - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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 the UHD library: - -:: - - #include <uhd/utils/msg.hpp> - - void my_handler(uhd::msg::type_t type, const std::string &msg){ - //handle the message... - } - - uhd::msg::register_handler(&my_handler); diff --git a/host/docs/gpio_api.dox b/host/docs/gpio_api.dox new file mode 100644 index 000000000..17a2411fc --- /dev/null +++ b/host/docs/gpio_api.dox @@ -0,0 +1,119 @@ +/*! \page page_gpio_api X3x0 GPIO API + +\tableofcontents + +\section xgpio_fpanel The X3x0 Front Panel GPIO + +The X3x0 is the first USRP device to offer an auxiliary GPIO connection +on the motherboard itself (independent of the daughterboards). These +GPIO pins are controlled directly by the FPGA, where they are controlled +by an ATR (Automatic Transmit / Receive). This allows them to be toggled +simultaneously with other radio-level changes (e.g., enabling or +disabling a TX or RX mixer). + +\subsection xgpio_fpanel_gpio Front Panel GPIO + +\subsubsection xgpio_fpanel_conn Connector + +\image html x3x0_gpio_conn.png "X3x0 GPIO Connectors" + +\subsubsection xgpio_fpanel_pins Pin Mapping + +- Pin 1: +3.3V +- Pin 2: Data[0] +- Pin 3: Data[1] +- Pin 4: Data[2] +- Pin 5: Data[3] +- Pin 6: Data[4] +- Pin 7: Data[5] +- Pin 8: Data[6] +- Pin 9: Data[7] +- Pin 10: Data[8] +- Pin 11: Data[9] +- Pin 12: Data[10] +- Pin 13: Data[11] +- Pin 14: 0V +- Pin 15: 0V + +\subsection xgpio_fpanel_atr Explaining ATR + +ATR works by defining the value of the GPIO pins for certain states of +the radio. This is the "automatic" part of it. For example, you can tell +UHD that when the radio is transmitting and receiving (full duplex), +GPIO6 should be high, but when it is only transmitting, GPI06 should be +low. This state machine is set up using a series of GPIO attributes, +with paired values and a mask, which you will want to define for the +GPIO pins you intend to use. To set up the ATR, you use uhd::usrp::multi_usrp::set_gpio_attr(). + +- **CTRL**: Is this pin controlled by ATR (automatic), or by manual + control only? +- **DDR**: "Data Direction Register" - defines whether or not a GPIO + is an output or an input. +- **OUT**: Manually set the value of a pin (only to be used in non-ATR + mode). +- **ATR_0X**: The status of the pins when the radio is **idle**. +- **ATR_RX**: The status of the pins when the radio is only + **receiving**. +- **ATR_TX**: The status of the pins when the radio is only + **transmitting**. +- **ATR_XX**: The status of the pins when the radio is in + **full-duplex** mode. + +The counterpart to setting the ATR (the "getter"), is called +uhd::usrp::multi_usrp::get_gpio_attr(). +t has the exact same attributes as above, and has +one more: + +- **READBACK**: Readback the GPIOs marked as inputs. + +\subsection xgpio_fpanel_xample An Example + +The front panel X3x0 GPIO bank is enumerated in the motherboard property +tree (`*<mb_path>/gpio/FP0/*`), and so is easily accessible through +the standard uhd::usrp::multi_usrp UHD interface. + +You can discover this using the uhd::usrp::multi_usrp::get_gpio_banks() function. +This will tell you that there is a GPIO bank on your +X3x0 called "FP0". This is the bank we want to set-up. + +Let's say we want to use GPIO6 for an external amp. We want it to be +automatically controlled by ATR as an output, and we want it to be high +when we are transmitting, and low in all other cases. We are also using +GPIO4, which we want to control manually, as an output. We can set this +up with the following code: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + // set up our masks, defining the pin numbers + #define AMP_GPIO_MASK (1 << 6) + #define MAN_GPIO_MASK (1 << 4) + + #define ATR_MASKS (AMP_GPIO_MASK | MAN_GPIO_MASK) + + // set up our values for ATR control: 1 for ATR, 0 for manual + #define ATR_CONTROL (AMP_GPIO_MASK & ~MAN_GPIO_MASK) + + // set up the GPIO directions: 1 for output, 0 for input + #define GPIO_DDR (AMP_GPIO_MASK & ~MAN_GPIO_MASK) + + // assume an existing USRP device handle, called "usrp_x300" + + // now, let's do the basic ATR setup + usrp_x300->set_gpio_attr("FP0", "CTRL", ATR_CONTROL, ATR_MASKS); + usrp_x300->set_gpio_attr("FP0", "DDR", GPIO_DDR, ATR_MASKS); + + // let's manually set GPIO4 high + usrp_x300->set_gpio_attr("FP0", "OUT", 1, MAN_GPIO_MASK); + + // finally, let's set up GPIO6 as we described above + usrp_x300->set_gpio_attr("FP0", "ATR_0X", 0, AMP_GPIO_MASK); + usrp_x300->set_gpio_attr("FP0", "ATR_RX", 0, AMP_GPIO_MASK); + usrp_x300->set_gpio_attr("FP0", "ATR_TX", 0, AMP_GPIO_MASK); + usrp_x300->set_gpio_attr("FP0", "ATR_XX", 0, AMP_GPIO_MASK); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +After the above code is run, the ATR in the FPGA will automatically +control GPIO6, as we have described, based on the radio state, and we +have direct manual control over GPIO4. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/gpio_api.rst b/host/docs/gpio_api.rst deleted file mode 100644 index 9fd86d081..000000000 --- a/host/docs/gpio_api.rst +++ /dev/null @@ -1,129 +0,0 @@ -======================================================================== -UHD - X3x0 GPIO API -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -The X3x0 Front Panel GPIO ------------------------------------------------------------------------- -The X3x0 is the first USRP device to offer an auxiliary GPIO connection on the -motherboard itself (independent of the daughterboards). These GPIO pins are -controlled directly by the FPGA, where they are controlled by an ATR (Automatic -Transmit / Receive). This allows them to be toggled simultaneously with other -radio-level changes (e.g., enabling or disabling a TX or RX mixer). - - -^^^^^^^^^^^^^^^^ -Front Panel GPIO -^^^^^^^^^^^^^^^^ - -Connector -::::::::: - -.. image:: ./res/x3x0_gpio_conn.png - :scale: 75% - :align: left - -Pin Mapping -::::::::::: - -* Pin 1: +3.3V -* Pin 2: Data[0] -* Pin 3: Data[1] -* Pin 4: Data[2] -* Pin 5: Data[3] -* Pin 6: Data[4] -* Pin 7: Data[5] -* Pin 8: Data[6] -* Pin 9: Data[7] -* Pin 10: Data[8] -* Pin 11: Data[9] -* Pin 12: Data[10] -* Pin 13: Data[11] -* Pin 14: 0V -* Pin 15: 0V - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Explaining ATR -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ATR works by defining the value of the GPIO pins for certain states of the -radio. This is the "automatic" part of it. For example, you can tell UHD that -when the radio is transmitting and receiving (full duplex), GPIO6 should be -high, but when it is only transmitting, GPI06 should be low. This state machine -is set up using a series of GPIO attributes, with paired values and a mask, -which you will want to define for the GPIO pins you intend to use. To set up -the ATR, you use the **multi_usrp** function *set_gpio_attr*. - -* **CTRL**: Is this pin controlled by ATR (automatic), or by manual control - only? -* **DDR**: "Data Direction Register" - defines whether or not a GPIO is an - output or an input. -* **OUT**: Manually set the value of a pin (only to be used in non-ATR mode). -* **ATR_0X**: The status of the pins when the radio is **idle**. -* **ATR_RX**: The status of the pins when the radio is only **receiving**. -* **ATR_TX**: The status of the pins when the radio is only **transmitting**. -* **ATR_XX**: The status of the pins when the radio is in **full-duplex** mode. - -The counterpart to setting the ATR (the "getter"), is called *get_gpio_attr*. -It has the exact same attributes as above, and has one more: - -* **READBACK**: Readback the GPIOs marked as inputs. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -An Example -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The front panel X3x0 GPIO bank is enumerated in the motherboard property tree -("*<mb_path>/gpio/FP0/*"), and so is easily accessible through the standard -**multi_usrp** UHD interface. - -You can discover this using the *get_gpio_banks* function in **multi_usrp**. -This will tell you that there is a GPIO bank on your X3x0 called "FP0". This is -the bank we want to set-up. - -Let's say we want to use GPIO6 for an external amp. We want it to be -automatically controlled by ATR as an output, and we want it to be high when we -are transmitting, and low in all other cases. We are also using GPIO4, which -we want to control manually, as an output. We can set this up with the following -code: - -:: - - // set up our masks, defining the pin numbers - #define AMP_GPIO_MASK (1 << 6) - #define MAN_GPIO_MASK (1 << 4) - - #define ATR_MASKS (AMP_GPIO_MASK | MAN_GPIO_MASK) - - // set up our values for ATR control: 1 for ATR, 0 for manual - #define ATR_CONTROL (AMP_GPIO_MASK & ~MAN_GPIO_MASK) - - // set up the GPIO directions: 1 for output, 0 for input - #define GPIO_DDR (AMP_GPIO_MASK & ~MAN_GPIO_MASK) - - // assume an existing USRP device handle, called "usrp_x300" - - // now, let's do the basic ATR setup - usrp_x300->set_gpio_attr("FP0", "CTRL", ATR_CONTROL, ATR_MASKS); - usrp_x300->set_gpio_attr("FP0", "DDR", GPIO_DDR, ATR_MASKS); - - // let's manually set GPIO4 high - usrp_x300->set_gpio_attr("FP0", "OUT", 1, MAN_GPIO_MASK); - - // finally, let's set up GPIO6 as we described above - usrp_x300->set_gpio_attr("FP0", "ATR_0X", 0, AMP_GPIO_MASK); - usrp_x300->set_gpio_attr("FP0", "ATR_RX", 0, AMP_GPIO_MASK); - usrp_x300->set_gpio_attr("FP0", "ATR_TX", 0, AMP_GPIO_MASK); - usrp_x300->set_gpio_attr("FP0", "ATR_XX", 0, AMP_GPIO_MASK); - -After the above code is run, the ATR in the FPGA will automatically control -GPIO6, as we have described, based on the radio state, and we have direct -manual control over GPIO4. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Further Information -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -For more information, see the Doxygen API documentation: - -* `multi_usrp API <./../../doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html>`_ diff --git a/host/docs/gpsdo.dox b/host/docs/gpsdo.dox new file mode 100644 index 000000000..a67004acc --- /dev/null +++ b/host/docs/gpsdo.dox @@ -0,0 +1,81 @@ +/*! \page page_gpsdo Internal GPSDO Application Notes (USRP-N2x0/E1X0 Models) + +\tableofcontents + +This application note describes the use of integrated GPS-disciplined +oscillators (GPSDOs) for the USRP N-Series and E1xx. For information +regarding the GPSDO that is compatible with the USRP X-Series, please +see: \ref page_gpsdo_x3x0 + + +\section gpsdo_specs 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**: + - **1Hz:** -80 dBc/Hz + - **10Hz:** -110 dBc/Hz + - **100Hz:** -135 dBc/Hz + - **1kHz:** -145 dBc/Hz + - **10kHz:** \< -145 dBc/Hz + +<b>Antenna Types:</b> + +The GPSDO is capable of supplying a 3V for active GPS antennas or +supporting passive antennas. + +\section gpsdo_install Installation Instructions + +Instructions for mounting the GPSDO kit onto your USRP device can be +found here: http://www.ettus.com/content/files/gpsdo-kit_2.pdf + +\subsection gspdo_install_post Post-installation Task (N-Series only) + +<b>Note:</b> The following instructions are only necessary for UHD 3.4.\* +and below. + +This is necessary if you require absolute GPS time in your application +or need to communicate with the GPSDO to obtain location, satellite +info, etc. If you only require 10 MHz and PPS signals for reference or +MIMO use (see \ref page_sync), it is not necessary to perform this step. + +To configure the USRP to communicate with the GPSDO, use the +`usrp_burn_mb_eeprom` utility: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --key=gpsdo --val=internal + + -- restore original setting -- + ./usrp_burn_mb_eeprom --args=<optional device args> --key=gpsdo --val=none + +\section gpsdo_use Using the GPSDO in Your Application + +By default, if a GPSDO is detected at startup, the USRP will be +configured to use it as a frequency and time reference. The internal +VITA timestamp will be initialized to the GPS time, and the internal +oscillator will be phase-locked to the 10 MHz GPSDO reference. If the +GPSDO is not locked to satellites, the VITA time will not be +initialized. + +GPS data is obtained through the **mboard_sensors** interface. To +retrieve the current GPS time, use the **gps_time** sensor: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + usrp->get_mboard_sensor("gps_time"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The returned value will be the current epoch time, in seconds since +January 1, 1970. This value is readily converted into human-readable +format using the **time.h** library in C, **boost::posix_time** in C++, +etc. + +Other information can be fetched as well. You can query the lock status +with the **gps_locked** sensor, as well as obtain raw NMEA sentences +using the **gps_gprmc**, and **gps_gpgga** sensors. Location +information can be parsed out of the **gps_gpgga** sensor by using **gpsd** +or another NMEA parser. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/gpsdo.rst b/host/docs/gpsdo.rst deleted file mode 100644 index 8ffff8672..000000000 --- a/host/docs/gpsdo.rst +++ /dev/null @@ -1,87 +0,0 @@ -======================================================================== -UHD - Internal GPSDO Application Notes (USRP-N2x0/E1X0 Models) -======================================================================== - -.. contents:: Table of Contents - -This application note describes the use of integrated GPS-disciplined oscillators (GPSDOs) for -the USRP N-Series and E1xx. For information regarding the GPSDO that is compatible with -the USRP X-Series, please see: - -`USRP-X3x0 Internal GPSDO Device Manual <./gpsdo_x3x0.html>`_ - -======= - ------------------------------------------------------------------------- -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**: - - * **1Hz:** -80 dBc/Hz - * **10Hz:** -110 dBc/Hz - * **100Hz:** -135 dBc/Hz - * **1kHz:** -145 dBc/Hz - * **10kHz:** <-145 dBc/Hz - -**Antenna Types:** - -The GPSDO is capable of supplying a 3V for active GPS antennas or supporting passive antennas. - ------------------------------------------------------------------------- -Installation Instructions ------------------------------------------------------------------------- -Instructions for mounting the GPSDO kit onto your USRP device can be found here: -`http://www.ettus.com/content/files/gpsdo-kit_2.pdf <http://www.ettus.com/content/files/gpsdo-kit_2.pdf>`_ - -******************************************** -Post-installation Task (N-Series only) -******************************************** - -**Note:** The following instructions are only necessary for UHD 3.4.* and below. - -This is necessary if you require absolute GPS time in your application -or need to communicate with the GPSDO to obtain location, satellite info, etc. -If you only require 10 MHz and PPS signals for reference or MIMO use -(see the `Synchronization Application Notes <./sync.html>`_), -it is not necessary to perform this step. - -To configure the USRP to communicate with the GPSDO, use the -**usrp_burn_mb_eeprom** utility: - -:: - - cd <install-path>/lib/uhd/utils - ./usrp_burn_mb_eeprom --args=<optional device args> --key=gpsdo --val=internal - - -- restore original setting -- - ./usrp_burn_mb_eeprom --args=<optional device args> --key=gpsdo --val=none - ------------------------------------------------------------------------- -Using the GPSDO in Your Application ------------------------------------------------------------------------- -By default, if a GPSDO is detected at startup, the USRP will be configured -to use it as a frequency and time reference. The internal VITA timestamp -will be initialized to the GPS time, and the internal oscillator will be -phase-locked to the 10 MHz GPSDO reference. If the GPSDO is not locked to -satellites, the VITA time will not be initialized. - -GPS data is obtained through the **mboard_sensors** interface. To retrieve -the current GPS time, use the **gps_time** sensor: - -:: - - usrp->get_mboard_sensor("gps_time"); - -The returned value will be the current epoch time, in seconds since -January 1, 1970. This value is readily converted into human-readable -format using the **time.h** library in C, **boost::posix_time** in C++, etc. - -Other information can be fetched as well. You can query the lock status -with the **gps_locked** sensor, as well as obtain raw NMEA sentences using -the **gps_gprmc**, and **gps_gpgga** sensors. Location -information can be parsed out of the **gps_gpgga** sensor by using **gpsd** or -another NMEA parser. diff --git a/host/docs/gpsdo_b2x0.dox b/host/docs/gpsdo_b2x0.dox new file mode 100644 index 000000000..a54665427 --- /dev/null +++ b/host/docs/gpsdo_b2x0.dox @@ -0,0 +1,73 @@ +/*! \page page_gpsdo_b2x0 Internal GPSDO Application Notes (USRP-B2x0 Models) + +\tableofcontents + +This application note describes the use of integrated GPS-disciplined +oscillators with Ettus Research USRP devices. + +\section gpsdob_specs Specifications + +- **Receiver type**: 50 channel with WAAS, EGNOS, MSAS +- **10MHz ADEV**: 5e-11 over \>24h +- **1PPS RMS jitter**: \<50ns 1-sigma +- **Holdover**: \<20us over 3h + +<b>Phase noise</b>: + + Offset | Phase Noise Power +---------|------------------- + 1Hz | -65dBc/Hz + 10Hz | > -102dBc/Hz + 100Hz | -132dBc/Hz + 1kHz | -148dBc/Hz + 10kHz | -152dBc/Hz + 100kHz | \< -155dBc/Hz + +<b>Antenna Types:</b> + +The GPSDO is capable of supplying a 3V for active GPS antennas or +supporting passive antennas. + +\section gpsdob_install Installation Instructions + +To install the GPSDO, you must insert it into the slot on the board near +the 10 MHz Reference SMA. Keep in mind that the two sides of the GPSDO +have a different number of pins. When inserting the GPSDO, make sure to +press down firmly and evenly. When turning on the USRP B2X0 device, a +green LED should illuminate on the GPSDO. This signifies that the unit +has successfully been placed. + +<b>NOTE: The pins on the GPSDO are very fragile. Be sure to press down +evenly, or the pins may bend or break. Once the GPSDO is in place, we +very highly discourage further removal, as this also risks damaging the +pins.</b> + +\section gpsdob_using Using the GPSDO in Your Application + +By default, if a GPSDO is detected at startup, the USRP will be +configured to use it as a frequency and time reference. The internal +VITA timestamp will be initialized to the GPS time, and the internal +oscillator will be phase-locked to the 10MHz GPSDO reference. If the +GPSDO is not locked to satellites, the VITA time will not be +initialized. + +GPS data is obtained through the **mboard_sensors** interface. To +retrieve the current GPS time, use the **gps_time** sensor: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +usrp->get_mboard_sensor("gps_time"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The returned value will be the current epoch time, in seconds since +January 1, 1970. This value is readily converted into human-readable +format using the **time.h** library in C, **boost::posix_time** in C++, +etc. + +Other information can be fetched as well. You can query the lock status +with the **gps_locked** sensor, as well as obtain raw NMEA sentences +using the **gps_gprmc**, and **gps_gpgga** sensors. Location +information can be parsed out of the **gps_gpgga** sensor by using **gpsd** +or another NMEA parser. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/gpsdo_b2x0.rst b/host/docs/gpsdo_b2x0.rst deleted file mode 100644 index a0815d23a..000000000 --- a/host/docs/gpsdo_b2x0.rst +++ /dev/null @@ -1,79 +0,0 @@ -======================================================================== -UHD - Internal GPSDO Application Notes (USRP-B2x0 Models) -======================================================================== - -.. contents:: Table of Contents - -This application note describes the use of integrated GPS-disciplined -oscillators with Ettus Research USRP devices. - ------------------------------------------------------------------------- -Specifications ------------------------------------------------------------------------- -* **Receiver type**: 50 channel with WAAS, EGNOS, MSAS -* **10MHz ADEV**: 5e-11 over >24h -* **1PPS RMS jitter**: <50ns 1-sigma -* **Holdover**: <20us over 3h - -**Phase noise**: - -+------------+-------------+ -| | TCXO | -+============+=============+ -| **1Hz** | -65dBc/Hz | -+------------+-------------+ -| **10Hz** | -102dBc/Hz | -+------------+-------------+ -| **100Hz** | -132dBc/Hz | -+------------+-------------+ -| **1kHz** | -148dBc/Hz | -+------------+-------------+ -| **10kHz** | -152dBc/Hz | -+------------+-------------+ -| **100kHz** | <-155dBc/Hz | -+------------+-------------+ - -**Antenna Types:** - -The GPSDO is capable of supplying a 3V for active GPS antennas or supporting passive antennas. - ------------------------------------------------------------------------- -Installation Instructions ------------------------------------------------------------------------- -To install the GPSDO, you must insert it into the slot on the board -near the 10 MHz Reference SMA. Keep in mind that the two sides of the -GPSDO have a different number of pins. When inserting the GPSDO, make -sure to press down firmly and evenly. When turning on the USRP B2X0 device, -a green LED should illuminate on the GPSDO. This signifies that the unit -has successfully been placed. - -**NOTE: The pins on the GPSDO are very fragile. Be sure to press down -evenly, or the pins may bend or break. Once the GPSDO is in place, -we very highly discourage further removal, as this also risks damaging -the pins.** - ------------------------------------------------------------------------- -Using the GPSDO in Your Application ------------------------------------------------------------------------- -By default, if a GPSDO is detected at startup, the USRP will be configured -to use it as a frequency and time reference. The internal VITA timestamp -will be initialized to the GPS time, and the internal oscillator will be -phase-locked to the 10MHz GPSDO reference. If the GPSDO is not locked to -satellites, the VITA time will not be initialized. - -GPS data is obtained through the **mboard_sensors** interface. To retrieve -the current GPS time, use the **gps_time** sensor: - -:: - - usrp->get_mboard_sensor("gps_time"); - -The returned value will be the current epoch time, in seconds since -January 1, 1970. This value is readily converted into human-readable -format using the **time.h** library in C, **boost::posix_time** in C++, etc. - -Other information can be fetched as well. You can query the lock status -with the **gps_locked** sensor, as well as obtain raw NMEA sentences using -the **gps_gprmc**, and **gps_gpgga** sensors. Location -information can be parsed out of the **gps_gpgga** sensor by using **gpsd** or -another NMEA parser. diff --git a/host/docs/gpsdo_x3x0.dox b/host/docs/gpsdo_x3x0.dox new file mode 100644 index 000000000..24997d50b --- /dev/null +++ b/host/docs/gpsdo_x3x0.dox @@ -0,0 +1,76 @@ +/*! \page page_gpsdo_x3x0 Internal GPSDO Application Notes (USRP-X3x0 Models) + +\tableofcontents + +This application note describes the use of the board-mounted GPS +Disciplined OCXO, as used with the USRP X300/X310. For information +regarding the GPSDO that is compatible with the USRP N2xx or E1xx, +please see \ref page_gpsdo. + +\section gpsdox_specs Specifications + +- **Receiver type**: 50 channel with WAAS, EGNOS, MSAS +- **10 MHz ADEV**: 5e-11 over \>24h +- **1PPS RMS jitter**: \<50ns 1-sigma +- **Holdover**: \<20us over 3h + +<b>Phase noise</b>: + + Offset | OCXO Phase noise power +---------|---------------------------- +1Hz |-75dBc/Hz +10Hz |-110dBc/Hz +100Hz |-132dBc/Hz +1kHz |-142dBc/Hz +10kHz |-145dBc/Hz +100kHz |-150dBc/Hz + +<b>Antenna Types:</b> + +The GPSDO is capable of supplying a 3V for active GPS antennas or +supporting passive antennas. + +\section gpsdox_install Installation Instructions + +To install the GPSDO, you must insert it into the slot on the board near +the 10 MHz Reference SMA. Keep in mind that the two sides of the GPSDO +have a different number of pins. When inserting the GPSDO, make sure to +press down firmly and evenly. When turning on the USRP X3x0 device, a +green LED should illuminate on the GPSDO. This signifies that the unit +has successfully been placed. + +<b>NOTE: The pins on the GPSDO are very fragile. Be sure to press down +evenly, or the pins may bend or break. Once the GPSDO is in place, we +very highly discourage further removal, as this also risks damaging the +pins.</b> + +\section gpsdox_using Using the GPSDO in Your Application + +By default, if a GPSDO is detected at startup, the USRP will be +configured to use it as a frequency and time reference. The internal +VITA timestamp will be initialized to the GPS time, and the internal +oscillator will be phase-locked to the 10MHz GPSDO reference. If the +GPSDO is not locked to satellites, the VITA time will not be +initialized. + +GPS data is obtained through the **mboard_sensors** interface. To +retrieve the current GPS time, use the **gps_time** sensor: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + usrp->get_mboard_sensor("gps_time"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The returned value will be the current epoch time, in seconds since +January 1, 1970. This value is readily converted into human-readable +format using the **time.h** library in C, **boost::posix_time** in C++, +etc. + +Other information can be fetched as well. You can query the lock status +with the **gps_locked** sensor, as well as obtain raw NMEA sentences +using the **gps_gprmc**, and **gps_gpgga** sensors. Location +information can be parsed out of the **gps_gpgga** sensor by using **gpsd** +or another NMEA parser. + + +*/ +// vim:ft=doxygen: diff --git a/host/docs/gpsdo_x3x0.rst b/host/docs/gpsdo_x3x0.rst deleted file mode 100644 index 0d4d31f3b..000000000 --- a/host/docs/gpsdo_x3x0.rst +++ /dev/null @@ -1,82 +0,0 @@ -======================================================================== -UHD - Internal GPSDO Application Notes (USRP-X3x0 Models) -======================================================================== - -.. contents:: Table of Contents - -This application note describes the use of the board-mounted GPS Disciplined OCXO, -as used with the USRP X300/X310. For information regarding the GPSDO that is -compatible with the USRP N2xx or E1xx, please see: - -`USRP-N2x0/E1x0 Internal GPSDO Device Manual <./gpsdo.html>`_ - ------------------------------------------------------------------------- -Specifications ------------------------------------------------------------------------- -* **Receiver type**: 50 channel with WAAS, EGNOS, MSAS -* **10 MHz ADEV**: 5e-11 over >24h -* **1PPS RMS jitter**: <50ns 1-sigma -* **Holdover**: <20us over 3h - -**Phase noise**: - -+------------+------------+ -| | OCXO | -+============+============+ -| **1Hz** | -75dBc/Hz | -+------------+------------+ -| **10Hz** | -110dBc/Hz | -+------------+------------+ -| **100Hz** | -132dBc/Hz | -+------------+------------+ -| **1kHz** | -142dBc/Hz | -+------------+------------+ -| **10kHz** | -145dBc/Hz | -+------------+------------+ -| **100kHz** | -150dBc/Hz | -+------------+------------+ - -**Antenna Types:** - -The GPSDO is capable of supplying a 3V for active GPS antennas or supporting passive antennas. - ------------------------------------------------------------------------- -Installation Instructions ------------------------------------------------------------------------- -To install the GPSDO, you must insert it into the slot on the board -near the 10 MHz Reference SMA. Keep in mind that the two sides of the -GPSDO have a different number of pins. When inserting the GPSDO, make -sure to press down firmly and evenly. When turning on the USRP B2X0 device, -a green LED should illuminate on the GPSDO. This signifies that the unit -has successfully been placed. - -**NOTE: The pins on the GPSDO are very fragile. Be sure to press down -evenly, or the pins may bend or break. Once the GPSDO is in place, -we very highly discourage further removal, as this also risks damaging -the pins.** - ------------------------------------------------------------------------- -Using the GPSDO in Your Application ------------------------------------------------------------------------- -By default, if a GPSDO is detected at startup, the USRP will be configured -to use it as a frequency and time reference. The internal VITA timestamp -will be initialized to the GPS time, and the internal oscillator will be -phase-locked to the 10MHz GPSDO reference. If the GPSDO is not locked to -satellites, the VITA time will not be initialized. - -GPS data is obtained through the **mboard_sensors** interface. To retrieve -the current GPS time, use the **gps_time** sensor: - -:: - - usrp->get_mboard_sensor("gps_time"); - -The returned value will be the current epoch time, in seconds since -January 1, 1970. This value is readily converted into human-readable -format using the **time.h** library in C, **boost::posix_time** in C++, etc. - -Other information can be fetched as well. You can query the lock status -with the **gps_locked** sensor, as well as obtain raw NMEA sentences using -the **gps_gprmc**, and **gps_gpgga** sensors. Location -information can be parsed out of the **gps_gpgga** sensor by using **gpsd** or -another NMEA parser. diff --git a/host/docs/identification.dox b/host/docs/identification.dox new file mode 100644 index 000000000..35b62d53e --- /dev/null +++ b/host/docs/identification.dox @@ -0,0 +1,112 @@ +/*! \page page_identification Device Identification Notes + +\tableofcontents + +\section id_identifying 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. Most UHD utility applications and examples have an `--args` +parameter that takes a device address, which is expressed as a delimited +string. + +See device_addr.hpp for reference. + +\subsection id_identifying_common Common device identifiers + +Every device has several ways of identifying it on the host system: + +Identifier | Key | Notes | Example +-----------|----------|-----------------------------------------------------------|--------------------------------- +Serial | serial | globally unique identifier | 12345678 +Address | addr | unique identifier on a network | 192.168.10.2 +Resource | resource | unique identifier for USRP RIO devices (over PCI Express) | RIO0 +Name | name | optional user-set identifier | my_usrp1 (User-defined value) +Type | type | hardware series identifier | usrp1, usrp2, b200, x300, ... + +\subsection id_identifying_cmdline Device discovery via command line + +Devices attached to your system can be discovered using the +`uhd_find_devices` program. This program scans your system for +supported devices and prints out an enumerated list of discovered +devices and their addresses. The list of discovered devices can be +narrowed down by specifying device address args. + + uhd_find_devices + +Device address arguments can be supplied to narrow the scope of the +search. + + uhd_find_devices --args="type=usrp1" + + -- OR -- + + uhd_find_devices --args="serial=12345678" + +\subsection id_identifying_api Device discovery through the API + +The device::find() API call searches for devices and returns a list +of discovered devices. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + 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. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + uhd::device_addr_t hint; + hint["type"] = "usrp1"; + uhd::device_addrs_t dev_addrs = uhd::device::find(hint); + + -- OR -- + + uhd::device_addr_t hint; + hint["serial"] = "12345678"; + uhd::device_addrs_t dev_addrs = uhd::device::find(hint); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\subsection id_identifying_props Device properties + +Properties of devices attached to your system can be probed with the +`uhd_usrp_probe` program. This program constructs an instance of the +device and prints out its properties, such as detected daughterboards, +frequency range, gain ranges, etc... + +<b>Usage:</b> + + uhd_usrp_probe --args <device-specific-address-args> + +\section id_naming Naming a USRP Device + +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: + +- is composed of ASCII characters +- is 0-20 characters +- is not required to be unique + +\subsection id_naming_set Set a custom name + +Run the following commands: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --key=name --val=lab1_xcvr + +\subsection id_naming_discovery Discovery via name + +The keyword `name` can be used to narrow the scope of the search. +Example with the find devices utility: + + uhd_find_devices --args="name=lab1_xcvr" + + -- OR -- + + uhd_find_devices --args="type=usrp1, name=lab1_xcvr" + +*/ +// vim:ft=doxygen: diff --git a/host/docs/identification.rst b/host/docs/identification.rst deleted file mode 100644 index cbae25082..000000000 --- a/host/docs/identification.rst +++ /dev/null @@ -1,130 +0,0 @@ -================================= -UHD - Device Identification Notes -================================= - -.. contents:: Table of Contents - ------------------------- -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. -Most UHD utility applications and examples have an **--args** parameter that takes a device address, which is expressed as a delimited string. - -See the documentation in **types/device_addr.hpp** for reference. - -^^^^^^^^^^^^^^^^^^^^^^^^^ -Common device identifiers -^^^^^^^^^^^^^^^^^^^^^^^^^ -Every device has several ways of identifying it on the host system: - -+------------+----------+-----------------------------------------------------------+------------------------------- -| Identifier | Key | Notes | Example -+============+==========+===========================================================+=============================== -| Serial | serial | globally unique identifier | 12345678 -+------------+----------+-----------------------------------------------------------+---------------------------- -| Address | addr | unique identifier on a network | 192.168.10.2 -+------------+----------+-----------------------------------------------------------+------------------------------- -| Resource | resource | unique identifier for USRP RIO devices (over PCI Express) | RIO0 -+------------+----------+-----------------------------------------------------------+------------------------------- -| Name | name | optional user-set identifier | my_usrp1 (User-defined value) -+------------+----------+-----------------------------------------------------------+---------------------------- -| Type | type | hardware series identifier | usrp1, usrp2, -+------------+----------+-----------------------------------------------------------+---------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Device discovery via command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Devices attached to your system can be discovered using the **uhd_find_devices** program. -This program scans your system for supported devices and prints -out an enumerated list of discovered devices and their addresses. -The list of discovered devices can be narrowed down by specifying device address args. - -:: - - uhd_find_devices - -Device address arguments can be supplied to narrow the scope of the search. - -:: - - uhd_find_devices --args="type=usrp1" - - -- OR -- - - uhd_find_devices --args="serial=12345678" - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Device discovery through the API -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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. - -:: - - uhd::device_addr_t hint; - hint["type"] = "usrp1"; - uhd::device_addrs_t dev_addrs = uhd::device::find(hint); - - -- OR -- - - uhd::device_addr_t hint; - hint["serial"] = "12345678"; - uhd::device_addrs_t dev_addrs = uhd::device::find(hint); - -^^^^^^^^^^^^^^^^^ -Device properties -^^^^^^^^^^^^^^^^^ -Properties of devices attached to your system can be probed with the **uhd_usrp_probe** program. -This program constructs an instance of the device and prints out its properties, -such as detected daughterboards, frequency range, gain ranges, etc... - -**Usage:** - -:: - - uhd_usrp_probe --args <device-specific-address-args> - --------------------- -Naming a USRP Device --------------------- -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: - -* is composed of ASCII characters -* is 0-20 characters -* is not required to be unique - -^^^^^^^^^^^^^^^^^ -Set a custom name -^^^^^^^^^^^^^^^^^ - -Run the following commands: - -:: - - cd <install-path>/lib/uhd/utils - ./usrp_burn_mb_eeprom --args=<optional device args> --key=name --val=lab1_xcvr - -^^^^^^^^^^^^^^^^^^ -Discovery via name -^^^^^^^^^^^^^^^^^^ - -The keyword **name** can be used to narrow the scope of the search. -Example with the find devices utility: - -:: - - uhd_find_devices --args="name=lab1_xcvr" - - -- OR -- - - uhd_find_devices --args="type=usrp1, name=lab1_xcvr" diff --git a/host/docs/images.dox b/host/docs/images.dox new file mode 100644 index 000000000..02454c674 --- /dev/null +++ b/host/docs/images.dox @@ -0,0 +1,114 @@ +/*! \page page_images Firmware and FPGA Image Application Notes + +\tableofcontents + +\section images_overview Images Overview + +Every USRP device must be loaded with special firmware and FPGA images. +The methods of loading images into the device vary among devices: + +- **USRP1:** The host code will automatically load the firmware and + FPGA at runtime. +- **USRP2:** The user must manually write the images onto the USRP2 SD + card. +- **USRP-N Series:** The user programs an image into on-board storage, + which then is automatically loaded at runtime. +- **USRP-E Series:** The host code will automatically load the FPGA at + runtime. +- **USRP-B Series:** The host code will automatically load the FPGA at + runtime. +- **USRP-X Series:** The user programs an image into on-board storage, + which then is automatically loaded at runtime. + +\section images_prebuild Pre-built Images + +Pre-built images are available for download. + +- <a href="http://files.ettus.com/binaries/master_images/">Master Branch images</a> +- <a href="http://files.ettus.com/binaries/maint_images/">Maint Branch images</a> + +The pre-built images come in two forms: + +- bundled with UHD software in a platform-specific installer +- stand-alone platform-independent archive files + +\subsection images_prebuilt_downloader UHD Images Downloader + +The UHD images downloader downloads UHD images compatible with the host +code and places them in the default images directory. + +By default, it can be found at: `<install-path>/lib/uhd/utils/uhd_images_downloader.py` + +By default, it installs images to: `<install-path>/share/uhd/images` + +\subsection images_prebuilt_installers Platform installers + +The UNIX-based installers will install the images into `/usr/share/uhd/images`. + +The Windows installers will install the images into `C:/Program Files/UHD/share/uhd/images`. + +\subsection images_prebuilt_archive Archive install + +When installing images from an archive, there are two options: + +<b>Option 1:</b> + +Unpack the archive into the UHD installation prefix. 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. + +<b>Option 2:</b> + +Unpack the archive anywhere and set the `UHD_IMAGES_PATH` +environment variable. `UHD_IMAGES_PATH` may contain a list of +directories to search for image files. + +\section images_building Building Images + +The UHD source repository comes with the source code necessary to build +both firmware and FPGA images for all supported devices. + +The build commands for a particular image can be found in +`<uhd-repo-path>/images/Makefile`. + +\subsection images_building_xilinx Xilinx FPGA builds + +USRP Xilinx FPGA images are built with two different versions of ISE, +depending on the device. + +The build requires that you have a UNIX-like environment with `Make`. +Make sure that `xtclsh` from the Xilinx ISE bin directory is in your `$PATH`. + +- Xilinx ISE 14.4: USRP X3x0 Series + +See `<uhd-repo-path>/fpga/usrp3/top/`. + +- Xilinx ISSE 12.2: USRP N2x0, USRP B2x0, USRP B1x0, USRP E1x0, USRP2 + +See `<uhd-repo-path>/fpga/usrp2/top/`. + +\subsection images_building_zpu ZPU firmware builds + +The ZPU GCC compiler is required to build the ZPU firmware images. The +build requires that you have a UNIX-like environment with `CMake` and +`Make`. Make sure that `zpu-elf-gcc` is in your `$PATH`. + +See `<uhd-repo-path>/firmware/zpu`. + +\subsection images_building_altera Altera FPGA builds + +Quartus is required to build the Altera FPGA image for the USRP1. +Pre-built images can also be found in `<uhd-repo-path>/fpga/usrp1/rbf`. + +See `<uhd-repo-path>/fpga/usrp1/toplevel/`. + +\subsection images_building_fx2 FX2 firmware builds + +The SDCC compiler is required to build the FX2 firmware images. The +build requires that you have a UNIX-like environment with `CMake` and `Make`. + +See `<uhd-repo-path>/firmware/fx2`. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/images.rst b/host/docs/images.rst deleted file mode 100644 index 37fbabf4b..000000000 --- a/host/docs/images.rst +++ /dev/null @@ -1,126 +0,0 @@ -======================================================================== -UHD - Firmware and FPGA Image Application Notes -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Images Overview ------------------------------------------------------------------------- -Every USRP device must be loaded with special firmware and FPGA images. -The methods of loading images into the device vary among devices: - -* **USRP1:** The host code will automatically load the firmware and FPGA at runtime. -* **USRP2:** The user must manually write the images onto the USRP2 SD card. -* **USRP-N Series:** The user programs an image into on-board storage, which - then is automatically loaded at runtime. -* **USRP-E Series:** The host code will automatically load the FPGA at runtime. -* **USRP-B Series:** The host code will automatically load the FPGA at runtime. -* **USRP-X Series:** The user programs an image into on-board storage, which - then is automatically loaded at runtime. - ------------------------------------------------------------------------- -Pre-built Images ------------------------------------------------------------------------- - -Pre-built images are available for download. - -* `Master Branch images <http://files.ettus.com/binaries/master_images/>`_ -* `Maint Branch images <http://files.ettus.com/binaries/maint_images/>`_ - -The pre-built images come in two forms: - -* bundled with UHD software in a platform-specific installer -* stand-alone platform-independent archive files - -^^^^^^^^^^^^^^^^^^^^^^ -UHD Images Downloader -^^^^^^^^^^^^^^^^^^^^^^ - -The UHD images downloader downloads UHD images compatible with the host code -and places them in the default images directory. - -By default, it can be found at: **<install-path>/lib/uhd/utils/uhd_images_downloader.py** - -By default, it installs images to: **<install-path>/share/uhd/images** - -^^^^^^^^^^^^^^^^^^^^^^ -Platform installers -^^^^^^^^^^^^^^^^^^^^^^ -The UNIX-based installers will install the images into **/usr/share/uhd/images**. - -The Windows installers will install the images into **C:/Program Files/UHD/share/uhd/images**. - -^^^^^^^^^^^^^^^^^^^^^^ -Archive install -^^^^^^^^^^^^^^^^^^^^^^ -When installing images from an archive, there are two options: - -**Option 1:** - -Unpack the archive into the UHD installation prefix. -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:** - -Unpack the archive anywhere and set the **UHD_IMAGES_PATH** environment variable. -**UHD_IMAGES_PATH** may contain a list of directories to search for image files. - ------------------------------------------------------------------------- -Building Images ------------------------------------------------------------------------- - -The UHD source repository comes with the source code necessary to build -both firmware and FPGA images for all supported devices. - -The build commands for a particular image can be found in **<uhd-repo-path>/images/Makefile**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Xilinx FPGA builds -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -USRP Xilinx FPGA images are built with two different versions of ISE, depending -on the device. - -The build requires that you have a UNIX-like environment with **Make**. -Make sure that **xtclsh** from the Xilinx ISE bin directory is in your **$PATH**. - - -**Xilinx ISE 14.4** -* USRP X3x0 Series - -See **<uhd-repo-path>/fpga/usrp3/top/**. - -**Xilinx ISE 12.2** -* USRP N2x0 -* USRP B2x0 -* USRP B1x0 -* USRP E1x0 -* USRP2 - -See **<uhd-repo-path>/fpga/usrp2/top/**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -ZPU firmware builds -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The ZPU GCC compiler is required to build the ZPU firmware images. -The build requires that you have a UNIX-like environment with **CMake** and **Make**. -Make sure that **zpu-elf-gcc** is in your **$PATH**. - -See **<uhd-repo-path>/firmware/zpu**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Altera FPGA builds -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Quartus is required to build the Altera FPGA image for the USRP1. -Pre-built images can also be found in **<uhd-repo-path>/fpga/usrp1/rbf**. - -See **<uhd-repo-path>/fpga/usrp1/toplevel/***. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -FX2 firmware builds -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The SDCC compiler is required to build the FX2 firmware images. -The build requires that you have a UNIX-like environment with **CMake** and **Make**. - -See **<uhd-repo-path>/firmware/fx2**. diff --git a/host/docs/index.rst b/host/docs/index.rst deleted file mode 100644 index ffad1488d..000000000 --- a/host/docs/index.rst +++ /dev/null @@ -1,68 +0,0 @@ -======================================================================== -UHD - USRP Hardware Driver -======================================================================== - -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 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>`_ - -^^^^^^^^^^^^^^^^^^^^^ -General UHD Manuals -^^^^^^^^^^^^^^^^^^^^^ -* `General Application Notes <./general.html>`_ -* `Device Identification Notes <./identification.html>`_ -* `Firmware and FPGA Image Notes <./images.html>`_ -* `Daughterboard Application Notes <./dboards.html>`_ -* `Transport Application Notes <./transport.html>`_ -* `Synchronization Application Notes <./sync.html>`_ -* `Calibration Application Notes <./calibration.html>`_ - -^^^^^^^^^^^^^^^^^^^^^ -USRP N-Series Devices -^^^^^^^^^^^^^^^^^^^^^ -* `USRP-N2x0 Series Device Manual <./usrp2.html>`_ -* `USRP-N2x0 Internal GPSDO Device Manual <./gpsdo.html>`_ - -^^^^^^^^^^^^^^^^^^^^^ -USRP B-Series Devices -^^^^^^^^^^^^^^^^^^^^^ -* `USRP-B100 Series Device Manual <./usrp_b100.html>`_ -* `USRP-B2x0 Series Device Manual <./usrp_b200.html>`_ -* `USRP1 Device Manual <./usrp1.html>`_ - -^^^^^^^^^^^^^^^^^^^^^ -USRP E-Series Devices -^^^^^^^^^^^^^^^^^^^^^ -* `USRP-E1x0 Series Device Manual <./usrp_e1x0.html>`_ -* `USRP-E1x0 Internal GPSDO Device Manual <./gpsdo.html>`_ - -^^^^^^^^^^^^^^^^^^^^^ -USRP X-Series Devices -^^^^^^^^^^^^^^^^^^^^^ -* `USRP-X3x0 Series Device Manual <./usrp_x3x0.html>`_ -* `USRP-X3x0 Internal GPSDO Device Manual <./gpsdo_x3x0.html>`_ -* `USRP-X3x0 Front Panel GPIO API <./gpio_api.html>`_ -* `USRP-X3x0 System Configuration <./usrp_x3x0_config.html>`_ - -^^^^^^^^^^^^^^^^^^^^^ -USRP Legacy Series -^^^^^^^^^^^^^^^^^^^^^ -* `USRP2 Device Manual <./usrp2.html>`_ - -^^^^^^^^^^^^^^^^^^^^^ -API Documentation -^^^^^^^^^^^^^^^^^^^^^ -* `Doxygen <./../../doxygen/html/index.html>`_ -* `Using the API <./coding.html>`_ -* `Device Streaming <./stream.html>`_ diff --git a/host/docs/mainpage.dox b/host/docs/mainpage.dox new file mode 100644 index 000000000..535a00e22 --- /dev/null +++ b/host/docs/mainpage.dox @@ -0,0 +1,59 @@ +/*! \mainpage Table Of Contents + +\tableofcontents + +Welcome to the manual pages for the Universal Software Radio Peripherals (USRP) and their driver suite, the USRP Hardware Driver (UHD). Here, you will find information on how to use the USRPs and how to use the API to connect to them through your own software. + +# Building and Installing UHD + +\li \subpage page_build_guide +\li <a href="http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux">Installation Guide (Linux)</a> +\li <a href="http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Windows">Installation Guide (Windows)</a> + +# General UHD Manuals + +\li \subpage page_general +\li \subpage page_identification +\li \subpage page_images +\li \subpage page_dboards +\li \subpage page_transport +\li \subpage page_sync +\li \subpage page_calibration + +# Device Specific Manuals + +## USRP N-Series Devices + +\li \subpage page_usrp2 +\li \subpage page_gpsdo + +## USRP B-Series Devices + +\li \subpage page_usrp_b100 +\li \subpage page_usrp_b200 +\li \subpage page_gpsdo_b2x0 +\li \subpage page_usrp1 + +## USRP E-Series Devices + +\li \subpage page_usrp_e1x0 +\li \subpage page_gpsdo + +## USRP X-Series Devices + +\li \subpage page_usrp_x3x0 +\li \subpage page_gpsdo_x3x0 +\li \subpage page_gpio_api +\li \subpage page_usrp_x3x0_config + +## USRP Legacy Series + +\li \subpage page_usrp2 + +# API Documentation + +\li \subpage page_coding +\li \subpage page_stream + +*/ +// vim:ft=doxygen: diff --git a/host/docs/stream.dox b/host/docs/stream.dox new file mode 100644 index 000000000..0c015c5bd --- /dev/null +++ b/host/docs/stream.dox @@ -0,0 +1,56 @@ +/*! \page page_stream Device streaming + +\tableofcontents + +\section stream_intro 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. An RX stream allows the user to +receive samples from the device. A TX stream allows the user to transmit +samples to the device. + +\section stream_lle Link Layer Encapsulation + +The VITA49 standard provides encapsulation for sample data across a link +layer. On all second generation hardware (and later), samples are +encapsulated into VRT IF data packets. These packets also provide sample +decoration such as stream time and burst flags. Sample decoration is +exposed to the user in the form of RX and TX metadata structs. + +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 + +\section stream_datatypes Data Types + +There are two important data types to consider when streaming: + +- The data type of the samples used on the host for processing +- The data type of the samples sent through the link-layer + +\subsection stream_datatypes_cpu 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**. + +\subsection stream_datatypes_otw 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**. +However, to increase throughput over the link-layer, +at the expense of precision, **complex-int8** may be used. + +\subsection stream_datatypes_conv Conversion + +The user may request arbitrary combinations of host and link data types; +however, not all combinations are supported. The user may register +custom data type formats and conversion routines. See +convert.hpp for further documentation. + +TODO: provide example of convert API +*/ +// vim:ft=doxygen: diff --git a/host/docs/stream.rst b/host/docs/stream.rst deleted file mode 100644 index 337d7ca40..000000000 --- a/host/docs/stream.rst +++ /dev/null @@ -1,59 +0,0 @@ -======================================================================== -UHD - Device streaming -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -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. -An RX stream allows the user to receive samples from the device. -A TX stream allows the user to transmit samples to the device. - ------------------------------------------------------------------------- -Link Layer Encapsulation ------------------------------------------------------------------------- -The VITA49 standard provides encapsulation for sample data across a link layer. -On all second generation hardware (and later), samples are encapsulated into VRT IF data packets. -These packets also provide sample decoration such as stream time and burst flags. -Sample decoration is exposed to the user in the form of RX and TX metadata structs. - -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 - ------------------------------------------------------------------------- -Data Types ------------------------------------------------------------------------- -There are two important data types to consider when streaming: - -* The data type of the samples used on the host for processing -* The data type of the samples sent through the link-layer - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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**. -However, to increase throughput over the link-layer, -at the expense of precision, **complex-int8** may be used. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Conversion -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The user may request arbitrary combinations of host and link data types; -however, not all combinations are supported. -The user may register custom data type formats and conversion routines. -See **uhd/convert.hpp** for further documentation. - -TODO: provide example of convert API diff --git a/host/docs/sync.dox b/host/docs/sync.dox new file mode 100644 index 000000000..f41d3a78c --- /dev/null +++ b/host/docs/sync.dox @@ -0,0 +1,197 @@ +/*! \page page_sync Synchronization Application Notes + +\tableofcontents + +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. + +<b>Note:</b> The following synchronization notes do not apply to USRP1, +which does not support the advanced features available in newer +products. + +\section sync_commonref Common Reference Signals + +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. +- A MIMO cable transmits an encoded time message from one device to + another. + +\subsection sync_commonref_pps PPS and 10 MHz reference signals + +Connect the front panel SMA connectors to the reference sources. +Typically, these signals are provided by an external GPSDO. However, +some USRP models can provide these signals from an optional internal +GPSDO. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +usrp->set_clock_source("external"); +usrp->set_time_source("external"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +<b>Note:</b> Sometimes the delay on the PPS signal will cause it to arrive +inside the timing margin the FPGA sampling clock, causing PPS edges to +be separated by less or more than 100 million cycles of the FPGA clock. +If this is the case, you can change the edge reference of the PPS signal +with this parameter: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +usrp->set_time_source("_external_"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +<b>Note2:</b> For users generating their own signals for the external SMA +connectors, the PPS should be clocked from the 10MHz reference. See the +application notes for your device for specific signal requirements. + +\subsection sync_commonref_mimo 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 (explained below) to +synchronize multiple pairs of devices. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + usrp->set_clock_source("mimo"); + usrp->set_time_source("mimo"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\section sync_time Synchronizing the Device Time + +The purpose of the PPS signal is to synchronously latch a time into the +device. You can use the `set_time_next_pps(...)` function to either +initialize the sample time to 0 or an absolute time, such as GPS time or +UTC time. For the purposes of synchronizing devices, it doesn't matter +what time you initialize to when using `set_time_next_pps(...)`. + +\subsection sync_time_reg Method 1 - poll the USRP time registers + +One way to initialize the PPS edge is to poll the "last PPS" time from +the USRP device. When the last PPS time increments, the user can +determine that a PPS has occurred: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + const uhd::time_spec_t last_pps_time = usrp->get_time_last_pps(); + while (last_pps_time == usrp->get_time_last_pps()){ + //sleep 100 milliseconds (give or take) + } + usrp->set_time_next_pps(uhd::time_spec_t(0.0)); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\subsection sync_time_gpsdo Method 2 - query the GPSDO for seconds + +Most GPSDOs can be configured to output a NMEA string over the serial +port once every PPS. The user can wait for this string to determine the +PPS edge, and the user can also parse this string to determine GPS time: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + //call user's function to wait for NMEA message... + usrp->set_time_next_pps(uhd::time_spec_t(0.0)); + + -- OR -- + + //call user's function to wait for NMEA message... + //call user's function to parse the NMEA message... + usrp->set_time_next_pps(uhd::time_spec_t(gps_time+1)); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\subsection sync_time_internalgps Method 3 - internal GPSDO + +USRP devices with internal GPSDOs properly configured will automatically +configure themselves to set the VITA time to current UTC time. See \ref page_gpsdo +for more details. + +\subsection sync_time_mimocable Method 4 - 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 device sends an encoded time message over +the MIMO cable. The slave device will automatically synchronize to the +time on the master device. See \ref usrp2_mimocable for more detail. + +\section sync_phase Synchronizing Channel Phase + +\subsection sync_phase_cordics Align CORDICs in the DSP + +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 synchronized via the 10 MHz and PPS inputs, the streaming +will start at exactly the same time on both devices. The CORDICs are +reset at each start-of-burst command, so users should ensure that every +start-of-burst also has a time spec set. + +For receive, a burst is started when the user issues a stream command. +This stream command should have a time spec set: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); + stream_cmd.num_samps = samps_to_recv; + stream_cmd.stream_now = false; + stream_cmd.time_spec = time_to_recv; + usrp->issue_stream_cmd(stream_cmd); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For transmit, a burst is started when the user calls send(). The +metadata should have a time spec set: : + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + uhd::tx_metadata_t md; + md.start_of_burst = true; + md.end_of_burst = false; + md.has_time_spec = true; + md.time_spec = time_to_send; + + //send a single packet + size_t num_tx_samps = tx_streamer->send(buffs, samps_to_send, md); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\subsection sync_phase_lo Align LOs in the front-end (SBX, WBX, CBX) + +Using timed commands, multiple frontends can be tuned at a specific +time. This timed-tuning ensures that the phase offsets between VCO/PLL +chains will remain constant after each re-tune. See notes below: + +- There is a random phase offset between any two frontends +- This phase offset is different for different LO frequencies +- This phase offset remains constant after retuning + - Due to a divider, WBX phase offset will be randomly +/- 180 deg after re-tune +- This phase offset will drift over time due to thermal and other characteristics +- Periodic calibration will be necessary for phase-coherent applications + +Code snippet example, tuning with timed commands: : + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + //we will tune the frontends in 100ms from now + uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1); + + //sets command time on all devices + //the next commands are all timed + usrp->set_command_time(cmd_time); + + //tune channel 0 and channel 1 + usrp->set_rx_freq(1.03e9, 0); // Channel 0 + usrp->set_rx_freq(1.03e9, 1); // Channel 1 + + //end timed commands + usrp->clear_command_time(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\subsection sync_phase_lootherfe Align LOs in the front-end (others) + +After tuning the RF front-ends, each local oscillator may have a random +phase offset due to the dividers in the VCO/PLL chains. This offset will +remain constant after the device has been initialized, and will remain +constant until the device is closed or re-tuned. This phase offset is +typically removed by the user in MIMO applications, using a training +sequence to estimate the offset. It will be necessary to re-align the +LOs after each tune command. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/sync.rst b/host/docs/sync.rst deleted file mode 100644 index 21be60a20..000000000 --- a/host/docs/sync.rst +++ /dev/null @@ -1,197 +0,0 @@ -======================================================================== -UHD - Synchronization Application Notes -======================================================================== - -.. contents:: Table of Contents - -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. - ------------------------------------------------------------------------- -Common Reference Signals ------------------------------------------------------------------------- -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. -* A MIMO cable transmits an encoded time message from one device to another. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -PPS and 10 MHz reference signals -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Connect the front panel SMA connectors to the reference sources. -Typically, these signals are provided by an external GPSDO. -However, some USRP models can provide these signals from an optional internal GPSDO. - -:: - - usrp->set_clock_source("external"); - usrp->set_time_source("external"); - -**Note:** -Sometimes the delay on the PPS signal will cause it to arrive inside the timing -margin the FPGA sampling clock, causing PPS edges to be separated by less or -more than 100 million cycles of the FPGA clock. If this is the case, -you can change the edge reference of the PPS signal with this parameter: - -:: - - usrp->set_time_source("_external_"); - -**Note2:** -For users generating their own signals for the external SMA connectors, -the PPS should be clocked from the 10MHz reference. -See the application notes for your device for specific signal requirements. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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 (explained below) to synchronize multiple pairs of devices. - -:: - - usrp->set_clock_source("mimo"); - usrp->set_time_source("mimo"); - ------------------------------------------------------------------------- -Synchronizing the Device Time ------------------------------------------------------------------------- -The purpose of the PPS signal is to synchronously latch a time into the device. -You can use the **set_time_next_pps(...)** function to either initialize the sample time to 0 -or an absolute time, such as GPS time or UTC time. -For the purposes of synchronizing devices, -it doesn't matter what time you initialize to when using **set_time_next_pps(...)**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Method 1 - poll the USRP time registers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -One way to initialize the PPS edge is to poll the "last PPS" time from the USRP device. -When the last PPS time increments, the user can determine that a PPS has occurred: - -:: - - const uhd::time_spec_t last_pps_time = usrp->get_time_last_pps(); - while (last_pps_time == usrp->get_time_last_pps()){ - //sleep 100 milliseconds (give or take) - } - usrp->set_time_next_pps(uhd::time_spec_t(0.0)); - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Method 2 - query the GPSDO for seconds -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Most GPSDOs can be configured to output a NMEA string over the serial port once every PPS. -The user can wait for this string to determine the PPS edge, -and the user can also parse this string to determine GPS time: - -:: - - //call user's function to wait for NMEA message... - usrp->set_time_next_pps(uhd::time_spec_t(0.0)); - - -- OR -- - - //call user's function to wait for NMEA message... - //call user's function to parse the NMEA message... - usrp->set_time_next_pps(uhd::time_spec_t(gps_time+1)); - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Method 3 - internal GPSDO -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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 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 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. - ------------------------------------------------------------------------- -Synchronizing Channel Phase ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Align CORDICs in the DSP -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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 -synchronized via the 10MHz and PPS inputs, the streaming will start at exactly -the same time on both devices. The CORDICs are reset at each start-of-burst -command, so users should ensure that every start-of-burst also has a time spec set. - -For receive, a burst is started when the user issues a stream command. This stream command should have a time spec set: -:: - - uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); - stream_cmd.num_samps = samps_to_recv; - stream_cmd.stream_now = false; - stream_cmd.time_spec = time_to_recv; - usrp->issue_stream_cmd(stream_cmd); - -For transmit, a burst is started when the user calls send(). The metadata should have a time spec set: -:: - - uhd::tx_metadata_t md; - md.start_of_burst = true; - md.end_of_burst = false; - md.has_time_spec = true; - md.time_spec = time_to_send; - - //send a single packet - size_t num_tx_samps = tx_streamer->send(buffs, samps_to_send, md); - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Align LOs in the front-end (SBX, WBX, CBX) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Using timed commands, multiple frontends can be tuned at a specific time. -This timed-tuning ensures that the phase offsets between VCO/PLL chains -will remain constant after each re-tune. See notes below: - -* There is a random phase offset between any two frontends -* This phase offset is different for different LO frequencies -* This phase offset remains constant after retuning - - * Due to a divider, WBX phase offset will be randomly +/- 180 deg after re-tune - -* This phase offset will drift over time due to thermal and other characteristics -* Periodic calibration will be necessary for phase-coherent applications - -Code snippet example, tuning with timed commands: -:: - - //we will tune the frontends in 100ms from now - uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1); - - //sets command time on all devices - //the next commands are all timed - usrp->set_command_time(cmd_time); - - //tune channel 0 and channel 1 - usrp->set_rx_freq(1.03e9, 0/*ch0*/); - usrp->set_rx_freq(1.03e9, 1/*ch1*/); - - //end timed commands - usrp->clear_command_time(); - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Align LOs in the front-end (others) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -After tuning the RF front-ends, -each local oscillator may have a random phase offset due to the dividers -in the VCO/PLL chains. This offset will remain constant after the device -has been initialized, and will remain constant until the device is closed -or re-tuned. This phase offset is typically removed by the user in MIMO -applications, using a training sequence to estimate the offset. It will -be necessary to re-align the LOs after each tune command. diff --git a/host/docs/transport.dox b/host/docs/transport.dox new file mode 100644 index 000000000..a00a7aa5f --- /dev/null +++ b/host/docs/transport.dox @@ -0,0 +1,160 @@ +/*! \page page_transport Transport Application Notes + +\tableofcontents + +\section transport_intro Introduction + +A transport is the layer between the packet interface and a device IO +interface. The advanced user can pass optional parameters into the +underlying transport layer through the device address. 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 software: + +\section transport_udp UDP Transport (Sockets) + +The UDP transport is implemented with user-space sockets. This means +standard Berkeley sockets API using send()/recv(). + +\subsection transport_udp_params Transport parameters + +The following parameters can be used to alter the transport's default +behavior: + +- `recv_frame_size:` The size of a single receive buffer in bytes +- `num_recv_frames:` The number of receive buffers to allocate +- `send_frame_size:` The size of a single send buffer in bytes +- `num_send_frames:` The number of send buffers to allocate + +<b>Notes:</b> +- `num_recv_frames` does not affect performance. +- `num_send_frames` does not affect performance. +- `recv_frame_size` and `send_frame_size` can be used + to increase or decrease the maximum number of samples per packet. The + frame sizes default to an MTU of 1472 bytes per IP/UDP packet and may be + increased if permitted by your network hardware. + +\subsection transport_udp_flow Flow control parameters + +The host-based flow control expects periodic update packets from the +device. These update packets inform the host of the last packet consumed +by the device, which allows the host to determine throttling conditions +for the transmission of packets. The following mechanisms affect the +transmission of periodic update packets: + +- `ups_per_fifo:` The number of update packets for each FIFO's + worth of bytes sent into the device +- `ups_per_sec:` The number of update packets per second (defaults + to 20 updates per second) + +\subsection transport_udp_sockbufs Resize socket buffers + +It may be useful to increase the size of the socket buffers to move the +burden of buffering samples into the kernel or to buffer incoming +samples faster than they can be processed. However, if your application +cannot process samples fast enough, no amount of buffering can save you. +The following parameters can be used to alter socket's buffer sizes: + +- `recv_buff_size:` The desired size of the receive buffer in + bytes +- `send_buff_size:` The desired size of the send buffer in bytes + +<b>Note:</b> Large send buffers tend to decrease transmit performance. + +\subsection transport_udp_latency Latency Optimization + +Latency is a measurement of the time it takes a sample to travel between +the host and device. Most computer hardware and software is bandwidth +optimized, which may negatively affect latency. If your application has +strict latency requirements, please consider the following notes: + +<b>Note1:</b> The time taken by the device to populate a packet is +proportional to the sample rate. Therefore, to improve receive latency, +configure the transport for a smaller frame size. + +<b>Note2:</b> For overall latency improvements, look for "Interrupt +Coalescing" settings for your OS and ethernet chipset. It seems the +Intel ethernet chipsets offer fine-grained control in Linux. Also, +consult: + +- <http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/interrupt_coal.htm> + +\subsection transport_udp_linux Linux specific notes + +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: : + + 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`. + +\subsection transport_udp_windows Windows specific notes + +**UDP send fast-path:** It is important to change the default UDP +behavior such that 1500 byte packets still travel through the fast path +of the sockets stack. This can be adjusted with the +FastSendDatagramThreshold registry key: + +- FastSendDatagramThreshold registry key documented here: + + - <http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx#appendix_e> + +- Double click and run + `<install-path>/share/uhd/FastSendDatagramThreshold.reg` +- A system reboot is recommended after the registry key change. + +<b>Power profile:</b> The Windows power profile can seriously impact +instantaneous bandwidth. Application can take time to ramp-up to full +performance capability. It is recommended that users set the power +profile to "high performance". + +\section transport_usb USB Transport (LibUSB) + +The USB transport is implemented with LibUSB. LibUSB provides an +asynchronous API for USB bulk transfers. + +\subsection transport_usb_params Transport parameters + +The following parameters can be used to alter the transport's default +behavior: + +- `recv_frame_size:` The size of a single receive transfers in + bytes +- `num_recv_frames:` The number of simultaneous receive transfers +- `send_frame_size:` The size of a single send transfers in bytes +- `num_send_frames:` The number of simultaneous send transfers + +\subsection transport_usb_udev Setup Udev for USB (Linux) + +On Linux, Udev handles USB plug and unplug events. The following +commands install a Udev rule so that non-root users may access the +device: + + cd <install-path>/lib/uhd/utils + sudo cp uhd-usrp.rules /etc/udev/rules.d/ + sudo udevadm control --reload-rules + sudo udevadm trigger + +\subsection transport_usb_installwin Install USB driver (Windows) + +A driver package must be installed to use a USB-based product with UHD +software: + +- Download the driver from the UHD wiki page + <a href="http://files.ettus.com/binaries/misc/erllc_uhd_winusb_driver.zip">here</a>. +- Unzip the file into a known location. We will refer to this as the `<directory>`. +- 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. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/transport.rst b/host/docs/transport.rst deleted file mode 100644 index 88f787893..000000000 --- a/host/docs/transport.rst +++ /dev/null @@ -1,165 +0,0 @@ -======================================================================== -UHD - Transport Application Notes -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Introduction ------------------------------------------------------------------------- -A transport is the layer between the packet interface and a device IO -interface. The advanced user can pass optional parameters into the underlying -transport layer through the device address. 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 -software: - ------------------------------------------------------------------------- -UDP Transport (Sockets) ------------------------------------------------------------------------- -The UDP transport is implemented with user-space sockets. -This means standard Berkeley sockets API using send()/recv(). - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Transport parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The following parameters can be used to alter the transport's default behavior: - -* **recv_frame_size:** The size of a single receive buffer in bytes -* **num_recv_frames:** The number of receive buffers to allocate -* **send_frame_size:** The size of a single send buffer in bytes -* **num_send_frames:** The number of send buffers to allocate - -**Note1:** -**num_recv_frames** does not affect performance. - -**Note2:** -**num_send_frames** does not affect performance. - -**Note3:** -**recv_frame_size** and **send_frame_size** can be used to -increase or decrease the maximum number of samples per packet. -The frame sizes default to an MTU of 1472 bytes per IP/UDP packet -and may be increased if permitted by your network hardware. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Flow control parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The host-based flow control expects periodic update packets from the device. -These update packets inform the host of the last packet consumed by the device, -which allows the host to determine throttling conditions for the transmission of packets. -The following mechanisms affect the transmission of periodic update packets: - -* **ups_per_fifo:** The number of update packets for each FIFO's worth of bytes sent into the device -* **ups_per_sec:** The number of update packets per second (defaults to 20 updates per second) - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Resize socket buffers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -It may be useful to increase the size of the socket buffers to -move the burden of buffering samples into the kernel or to -buffer incoming samples faster than they can be processed. -However, if your application cannot process samples fast enough, -no amount of buffering can save you. -The following parameters can be used to alter socket's buffer sizes: - -* **recv_buff_size:** The desired size of the receive buffer in bytes -* **send_buff_size:** The desired size of the send buffer in bytes - -**Note:** Large send buffers tend to decrease transmit performance. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Latency Optimization -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Latency is a measurement of the time it takes a sample to travel between the host and device. -Most computer hardware and software is bandwidth optimized, which may negatively affect latency. -If your application has strict latency requirements, please consider the following notes: - -**Note1:** -The time taken by the device to populate a packet is proportional to the sample rate. -Therefore, to improve receive latency, configure the transport for a smaller frame size. - -**Note2:** -For overall latency improvements, -look for "Interrupt Coalescing" settings for your OS and ethernet chipset. -It seems the Intel ethernet chipsets offer fine-grained control in Linux. -Also, consult: - -* http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/interrupt_coal.htm - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Linux specific notes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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: -:: - - 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**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Windows specific notes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -**UDP send fast-path:** -It is important to change the default UDP behavior such that -1500 byte packets still travel through the fast path of the sockets stack. -This can be adjusted with the FastSendDatagramThreshold registry key: - -* FastSendDatagramThreshold registry key documented here: - - * http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx#appendix_e - -* Double click and run <install-path>/share/uhd/FastSendDatagramThreshold.reg -* A system reboot is recommended after the registry key change. - -**Power profile:** -The Windows power profile can seriously impact instantaneous bandwidth. -Application can take time to ramp-up to full performance capability. -It is recommended that users set the power profile to "high performance". - ------------------------------------------------------------------------- -USB Transport (LibUSB) ------------------------------------------------------------------------- -The USB transport is implemented with LibUSB. -LibUSB provides an asynchronous API for USB bulk transfers. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Transport parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The following parameters can be used to alter the transport's default behavior: - -* **recv_frame_size:** The size of a single receive transfers in bytes -* **num_recv_frames:** The number of simultaneous receive transfers -* **send_frame_size:** The size of a single send transfers in bytes -* **num_send_frames:** The number of simultaneous send transfers - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Setup Udev for USB (Linux) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -On Linux, Udev handles USB plug and unplug events. -The following commands install a Udev rule -so that non-root users may access the device: - -:: - - cd <install-path>/lib/uhd/utils - sudo cp uhd-usrp.rules /etc/udev/rules.d/ - sudo udevadm control --reload-rules - sudo udevadm trigger - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Install USB driver (Windows) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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 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.dox b/host/docs/usrp1.dox new file mode 100644 index 000000000..a6b2d3741 --- /dev/null +++ b/host/docs/usrp1.dox @@ -0,0 +1,95 @@ +/*! \page page_usrp1 USRP1 Device Manual + +\tableofcontents + +\section usrp1_features Comparative features list + +- Hardware Capabilities: + - 2 transceiver card slots + - 64 MHz fixed clock rate +- FPGA Capabilities: + - 2 RX DDC chains in FPGA + - 2 TX DUC chains in FPGA (no TX CORDIC -\> uses DAC) + - sc16 sample modes - RX & TX + - Up to 8 MHz of RF BW with 16-bit samples + - sc8 sample mode - RX only + - Up to 16 MHz of RF BW with 8-bit samples + +\section usrp1_imgs Specify a Non-standard Image + +The standard USRP1 images installer comes with two FPGA images: +- **usrp1_fpga.rbf:** 2 DDCs + 2 DUCs +- **usrp1_fpga_4rx.rbf:** 4 DDCs + 0 DUCs + +By default, the USRP1 uses the FPGA image with 2 DDCs and 2 DUCs. +However, a device address parameter can be used to override the FPGA +image selection to use an alternate or a custom FPGA image. See the +images application notes for installing custom images. + +Example device address string representations to specify non-standard +firmware and/or FPGA images: + + fpga=usrp1_fpga_4rx.rbf + + -- OR -- + + fw=usrp1_fw_custom.ihx + + -- OR -- + + fpga=usrp1_fpga_4rx.rbf, fw=usrp1_fw_custom.ihx + +\section usrp1_emul 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. +Some of these features are emulated in software to support the API. + +\subsection usrp1_emul_list List of emulated features + +- Setting the current device time +- Getting the current device time +- Transmitting at a specific time +- Transmitting a specific number of samples +- Receiving at a specific time +- Receiving a specific number of samples +- End of burst flags for transmit/receive +- Notification on late stream command +- Notification on late transmit packet +- Notification on underflow or overflow +- Notification on broken chain error + +<b>Note:</b> These emulated features rely on the host system's clock for +timed operations and therefore may not have sufficient precision for the +application. + +\subsection usrp1_emul_listmissing List of missing features + +- Start of burst flags for transmit/receive + +\section usrp1_hw Hardware Setup Notes + +\subsection usrp1_hw_extclk External clock modification + +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**. + - Remove 0.01uF 0603 capacitor **C924**. + +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 software can initialize with the correct clock rate. +Run the following commands to record the setting into the EEPROM: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --key=mcr --val=<rate> + +The user may override the clock rate specified in the EEPROM by using a +device address: Example: + + uhd_usrp_probe --args="mcr=52e6" + +*/ +// vim:ft=doxygen: diff --git a/host/docs/usrp1.rst b/host/docs/usrp1.rst deleted file mode 100644 index be74fe00a..000000000 --- a/host/docs/usrp1.rst +++ /dev/null @@ -1,111 +0,0 @@ -======================================================================== -UHD - USRP1 Device Manual -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Comparative features list ------------------------------------------------------------------------- - -**Hardware Capabilities:** - * 2 transceiver card slots - * 64 MHz fixed clock rate - -**FPGA Capabilities:** - * 2 RX DDC chains in FPGA - * 2 TX DUC chains in FPGA (no TX CORDIC -> uses DAC) - * sc16 sample modes - RX & TX - - - Up to 8 MHz of RF BW with 16-bit samples - - * sc8 sample mode - RX only - - - Up to 16 MHz of RF BW with 8-bit samples - ------------------------------------------------------------------------- -Specify a Non-standard Image ------------------------------------------------------------------------- -The standard USRP1 images installer comes with two FPGA images: - * **usrp1_fpga.rbf:** 2 DDCs + 2 DUCs - * **usrp1_fpga_4rx.rbf:** 4 DDCs + 0 DUCs - -By default, the USRP1 uses the FPGA image with 2 DDCs and 2 DUCs. -However, a device address parameter can be used to override -the FPGA image selection to use an alternate or a custom FPGA image. -See the images application notes for installing custom images. - -Example device address string representations to specify non-standard firmware and/or FPGA images: - -:: - - fpga=usrp1_fpga_4rx.rbf - - -- OR -- - - fw=usrp1_fw_custom.ihx - - -- OR -- - - fpga=usrp1_fpga_4rx.rbf, fw=usrp1_fw_custom.ihx - ------------------------------------------------------------------------- -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. -Some of these features are emulated in software to support the API. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -List of emulated features -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -* Setting the current device time -* Getting the current device time -* Transmitting at a specific time -* Transmitting a specific number of samples -* Receiving at a specific time -* Receiving a specific number of samples -* End of burst flags for transmit/receive -* Notification on late stream command -* Notification on late transmit packet -* Notification on underflow or overflow -* Notification on broken chain error - -**Note:** -These emulated features rely on the host system's clock for timed operations -and therefore may not have sufficient precision for the application. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -List of missing features -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -* Start of burst flags for transmit/receive - ------------------------------------------------------------------------- -Hardware Setup Notes ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -External clock modification -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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**. - * Remove 0.01uF 0603 capacitor **C924**. - -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 software can initialize with the correct clock rate. -Run the following commands to record the setting into the EEPROM: -:: - - cd <install-path>/lib/uhd/utils - ./usrp_burn_mb_eeprom --args=<optional device args> --key=mcr --val=<rate> - -The user may override the clock rate specified in the EEPROM by using a device address: -Example: -:: - - uhd_usrp_probe --args="mcr=52e6" diff --git a/host/docs/usrp2.dox b/host/docs/usrp2.dox new file mode 100644 index 000000000..d2e9baccc --- /dev/null +++ b/host/docs/usrp2.dox @@ -0,0 +1,425 @@ +/*! \page page_usrp2 USRP2 and N2x0 Series Device Manual + +\tableofcontents + +\section usrp2_features Comparative features list + +- Hardware Capabilities: + - 1 transceiver card slot + - External PPS reference input + - External 10 MHz reference input + - MIMO cable shared reference + - Fixed 100 MHz clock rate + - Internal GPSDO option (N2x0 only) +- FPGA Capabilities: + - 2 RX DDC chains in FPGA + - 1 TX DUC chain in FPGA + - Timed commands in FPGA (N2x0 only) + - Timed sampling in FPGA + - 16-bit and 8-bit sample modes (sc8 and sc16) + - Up to 25 MHz of RF BW with 16-bit samples + - Up to 50 MHz of RF BW with 8-bit samples + +\section usrp2_load Load the Images onto the SD card (USRP2 only) + +<b>Warning!</b> Use `usrp2_card_burner` with caution. If you specify +the wrong device node, you could overwrite your hard drive. Make sure +that `--dev=` specifies the SD card. + +<b>Warning!</b> It is possible to use 3rd party SD cards with the USRP2. +However, certain types of SD cards will not interface with the CPLD: + +- Cards can be SDHC, which is not a supported interface. +- Cards can have unexpected timing characteristics. + +For these reasons, we recommend that you use the SD card that was +supplied with the USRP2. + +\subsection usrp2_load_cardburner Use the card burner tool (UNIX) + + sudo <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py + + -- OR -- + + cd <install-path>/lib/uhd/utils + 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. 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. + +\subsection usrp2_load_cardburnerwin Use the card burner tool (Windows) + + <path_to_python.exe> <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py + +\section usrp2_loadflash 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. When updating images, always burn +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 + +Use default images: + + usrp_n2xx_simple_net_burner --addr=<IP address> + +Use custom-built images: + + usrp_n2xx_simple_net_burner --addr=<IP address> --fw=<firmware path> --fpga=<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 +images. Fortunately, the USRP-N Series can be booted into a safe +(read-only) image. Once booted into the safe image, the user can once +again load images onto the device. + +The safe-mode button is a pushbutton switch (S2) located inside the +enclosure. To boot into the safe image, hold-down the safe-mode button +while power-cycling the device. Continue to hold-down the button until +the front-panel LEDs blink and remain solid. + +When in safe-mode, the USRP-N device will always have the IP address **192.168.10.2**. + +\section usrp2_network Setup Networking + +The USRP2 only supports Gigabit Ethernet and will not work with a 10/100 +Mbps interface. However, a 10/100 Mbps interface can be connected +indirectly to a USRP2 through a Gigabit Ethernet switch. + +\subsection usrp2_network_setuphost 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**. 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. + +On a Linux system, you can set a static IP address very easily by using +the 'ifconfig' command: + + 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 any parameters: + + ifconfig -a + +<b>Note:</b> 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. + +\subsection usrp2_network_multidev Multiple devices per host + +For maximum throughput, one Ethernet interface per USRP2 is recommended, +although multiple devices may be connected via a Gigabit Ethernet +switch. In any case, each Ethernet interface should have its own subnet, +and the corresponding USRP2 device should be assigned an address in that +subnet. Example: + +- Configuration for USRP2 device 0: + - Ethernet interface IPv4 address: **192.168.10.1** + - Ethernet interface subnet mask: **255.255.255.0** + - USRP2 device IPv4 address: **192.168.10.2** + +- Configuration for USRP2 device 1: + - Ethernet interface IPv4 address: **192.168.20.1** + - Ethernet interface subnet mask: **255.255.255.0** + - USRP2 device IPv4 address: **192.168.20.2** + +\subsection usrp2_network_changeip Change the USRP2's IP address + +You may need to change the USRP2's IP address for several reasons: +- to satisfy your particular network configuration +- to use multiple USRP2s on the same host computer +- to set a known IP address into USRP2 (in case you forgot) + +#### Method 1 + +To change the USRP2's IP address, you must know the +current address of the USRP2, and the network must be setup properly as +described above. Run the following commands: : + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr --val=192.168.10.3 + +#### 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. Run the following commands: + + cd <install-path>/lib/uhd/utils + sudo ./usrp2_recovery.py --ifc=eth0 --new-ip=192.168.10.3 + +\section usrp2_commprob Communication Problems + +When setting up a development machine for the first time, you may have +various difficulties communicating with the USRP device. The following +tips are designed to help narrow down and diagnose the problem. + +\subsection usrp2_commprob_ctrlresponse 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 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 device. Instructions for setting your +IP address are in the previous section of this documentation. + +\subsection usrp2_commprob_firewall Firewall issues + +When the IP address is not specified, the device discovery broadcasts +UDP packets from each ethernet interface. Many firewalls will block the +replies to these broadcast packets. 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**. + +\subsection usrp2_commprob_ping Ping the device + +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. + + ping 192.168.10.2 + +\subsection usrp2_commprob_uart Monitor the serial output + +Read the serial port to get debug verbose output from the embedded +microcontroller. 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. + +- **USRP2:** Serial port located on the rear edge +- **N210:** Serial port located on the left side + +\subsection usrp2_commprob_wireshark Monitor the host network traffic + +Use Wireshark to monitor packets sent to and received from the device. + +\section usrp2_addr Addressing the Device + +\subsection usrp2_addr_single Single device configuration + +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 \ref page_identification. +Please note that this addressing scheme should also be used with the **multi_usrp** +interface. + +Example device address string representation for a USRP2 with IPv4 +address **192.168.10.2**: + + addr=192.168.10.2 + +\subsection usrp2_ Multiple device configuration + +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 uhd::usrp::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. + +Example device address string representation for 2 USRP2s with IPv4 +addresses **192.168.10.2** and **192.168.20.2**: + + addr0=192.168.10.2, addr1=192.168.20.2 + +\section usrp2_mimocable Using the MIMO Cable + +The MIMO cable allows two USRP devices to share reference clocks, time +synchronization, and the Ethernet interface. One of the devices will +sync its clock and time references to the MIMO cable. This device will +be referred to as the slave, and the other device, the master. + +- The slave device acquires the clock and time references from the + master device. +- The master and slave may be used individually or in a multi-device + configuration. +- External clocking is optional and should only be supplied to the + master device. + +\subsection usrp2_mimocable_shared Shared Ethernet mode + +In shared Ethernet mode, only one device in the configuration can be +attached to the Ethernet. + +- Clock reference, time reference, and data are communicated over the + MIMO cable. +- Master and slave must have different IPv4 addresses in the same + subnet. + +\subsection usrp2_mimocable_dual Dual Ethernet mode + +In dual Ethernet mode, both devices in the configuration must be +attached to the Ethernet. + +- Only clock reference and time reference are communicated over the + MIMO cable. +- The master and slave must have different IPv4 addresses in different + subnets. + +\subsection usrp2_mimocable_cfgslave Configuring the slave + +In order for the slave to synchronize to the master over MIMO cable, the +following clock configuration must be set on the slave device: : + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + usrp->set_time_source("mimo", slave_index); + usrp->set_clock_source("mimo", slave_index); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +\section usrp2_altstream Alternative stream destination + +It is possible to program the USRP device to send RX packets to an +alternative IP/UDP destination. + +\subsection usrp2_altstream_subnet Set the subnet and gateway + +To use an alternative streaming destination, the device needs to be able +to determine if the destination address is within its subnet, and ARP +appropriately. Therefore, the user should ensure that subnet and gateway +addresses have been programmed into the device's EEPROM. + +Run the following commands: + + cd <install-path>/lib/uhd/utils + ./usrp_burn_mb_eeprom --args=<optional device args> --key=subnet --val=255.255.255.0 + ./usrp_burn_mb_eeprom --args=<optional device args> --key=gateway --val=192.168.10.1 + +\subsection usrp2_altstream_rxstream Create a receive streamer + +Set the stream args "addr" and "port" values to the alternative +destination. Packets will be sent to this destination when the user +issues a stream command. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + //create a receive streamer, host type does not matter + uhd::stream_args_t stream_args("fc32"); + + //resolvable address and port for a remote udp socket + stream_args.args["addr"] = "192.168.10.42"; + stream_args.args["port"] = "12345"; + + //create the streamer + uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args); + + //issue stream command + uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); + stream_cmd.num_samps = total_num_samps; + stream_cmd.stream_now = true; + usrp->issue_stream_cmd(stream_cmd); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +<b>Note:</b> Calling `recv()` on this streamer object should yield a timeout. + +\section usrp2_hw Hardware Setup Notes + +\subsection usrp2_hw_leds Front panel LEDs + +The LEDs on the front panel can be useful in debugging hardware and +software issues. The LEDs reveal the following about the state of the +device: + +- **LED A:** transmitting +- **LED B:** MIMO cable link +- **LED C:** receiving +- **LED D:** firmware loaded +- **LED E:** reference lock +- **LED F:** CPLD loaded + +\subsection usrp2_hw_refclk Ref Clock - 10 MHz + +Using an external 10 MHz reference clock, a square wave will offer the +best phase noise performance, but a sinusoid is acceptable. The +reference clock requires the following power level: + +- **USRP2** 5 to 15 dBm +- **N2XX** 0 to 15 dBm + +\subsection usrp2_hw_pps PPS - Pulse Per Second + +Using a PPS signal for timestamp synchronization requires a square wave +signal with the following amplitude: + +- **USRP2** 5Vpp +- **N2XX** 3.3 to 5Vpp + +Test the PPS input with the following app: + +- `<args>` are device address arguments (optional if only one USRP + device is on your machine) + + cd <install-path>/lib/uhd/examples + ./test_pps_input --args=\<args\> + +\subsection usrp2_hw_gpsdo Internal GPSDO + +Please see \ref page_gpsdo for information on configuring and using the internal GPSDO. + +\section usrp2_misc Miscellaneous + +\subsection usrp2_misc_sensors Available Sensors + +The following sensors are available for the USRP2/N-Series motherboards; +they can be queried through the API. + +- **mimo_locked** - clock reference locked over the MIMO cable +- **ref_locked** - clock reference locked (internal/external) +- other sensors are added when the GPSDO is enabled + +\subsection usrp2_misc_multirx 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. This hardware has only +one daughterboard slot, which has been aptly named slot **A**. + +In the following example, a TVRX2 is installed. Channel 0 is sourced +from subdevice **RX1**, and channel 1 is sourced from subdevice **RX2** +(**RX1** and **RX2** are the antenna ports on the TVRX2 daughterboard): + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + usrp->set_rx_subdev_spec("A:RX1 A:RX2"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*/ +// vim:ft=doxygen: diff --git a/host/docs/usrp2.rst b/host/docs/usrp2.rst deleted file mode 100644 index 361d98f01..000000000 --- a/host/docs/usrp2.rst +++ /dev/null @@ -1,475 +0,0 @@ -======================================================================== -UHD - USRP2 and N2x0 Series Device Manual -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Comparative features list ------------------------------------------------------------------------- - -**Hardware Capabilities:** - * 1 transceiver card slot - * External PPS reference input - * External 10 MHz reference input - * MIMO cable shared reference - * Fixed 100 MHz clock rate - * Internal GPSDO option (N2x0 only) - -**FPGA Capabilities:** - * 2 RX DDC chains in FPGA - * 1 TX DUC chain in FPGA - * Timed commands in FPGA (N2x0 only) - * Timed sampling in FPGA - * 16-bit and 8-bit sample modes (sc8 and sc16) - - * Up to 25 MHz of RF BW with 16-bit samples - * Up to 50 MHz of RF BW with 8-bit samples - ------------------------------------------------------------------------- -Load the Images onto the SD card (USRP2 only) ------------------------------------------------------------------------- -**Warning!** -Use **usrp2_card_burner** 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. -However, certain types of SD cards will not interface with the CPLD: - -* Cards can be SDHC, which is not a supported interface. -* Cards can have unexpected timing characteristics. - -For these reasons, we recommend that you use the SD card that was supplied with the USRP2. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use the card burner tool (UNIX) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - sudo <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py - - -- OR -- - - cd <install-path>/lib/uhd/utils - 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. -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. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use the card burner tool (Windows) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - <path_to_python.exe> <install-path>/lib/uhd/utils/usrp2_card_burner_gui.py - ------------------------------------------------------------------------- -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. -When updating images, always burn 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. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use the net burner tool -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - Use default images: - usrp_n2xx_simple_net_burner --addr=<IP address> - - Use custom-built images: - usrp_n2xx_simple_net_burner --addr=<IP address> --fw=<firmware path> --fpga=<FPGA path> - -**Note:** -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. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use the graphical net burner tool (Linux) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use the graphical net burner tool (Windows) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: - - <path_to_python.exe> <install-path>/lib/uhd/utils/usrp_n2xx_net_burner_gui.py - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Device recovery and bricking -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Its possible to put the device into an unusable state by loading bad images. -Fortunately, the USRP-N Series can be booted into a safe (read-only) image. -Once booted into the safe image, the user can once again load images onto the device. - -The safe-mode button is a pushbutton switch (S2) located inside the enclosure. -To boot into the safe image, hold-down the safe-mode button while power-cycling the device. -Continue to hold-down the button until the front-panel LEDs blink and remain solid. - -When in safe-mode, the USRP-N device will always have the IP address **192.168.10.2**. - ------------------------------------------------------------------------- -Setup Networking ------------------------------------------------------------------------- -The USRP2 only supports Gigabit Ethernet -and will not work with a 10/100 Mbps interface. -However, a 10/100 Mbps interface can be connected indirectly -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**. -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. - -On a Linux system, you can set a static IP address very easily by using the -'ifconfig' command: -:: - - 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 -any parameters: -:: - - ifconfig -a - -**Note:** -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. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Multiple devices per host -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -For maximum throughput, one Ethernet interface per USRP2 is recommended, -although multiple devices may be connected via a Gigabit Ethernet switch. -In any case, each Ethernet interface should have its own subnet, -and the corresponding USRP2 device should be assigned an address in that subnet. -Example: - -**Configuration for USRP2 device 0:** - -* Ethernet interface IPv4 address: **192.168.10.1** -* Ethernet interface subnet mask: **255.255.255.0** -* USRP2 device IPv4 address: **192.168.10.2** - -**Configuration for USRP2 device 1:** - -* Ethernet interface IPv4 address: **192.168.20.1** -* Ethernet interface subnet mask: **255.255.255.0** -* USRP2 device IPv4 address: **192.168.20.2** - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Change the USRP2's IP address -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -You may need to change the USRP2's IP address for several reasons: - -* to satisfy your particular network configuration -* to use multiple USRP2s on the same host computer -* to set a known IP address into USRP2 (in case you forgot) - -**Method 1:** -To change the USRP2's IP address, -you must know the current address of the USRP2, -and the network must be setup properly as described above. -Run the following commands: -:: - - cd <install-path>/lib/uhd/utils - ./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr --val=192.168.10.3 - -**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. -Run the following commands: -:: - - cd <install-path>/lib/uhd/utils - sudo ./usrp2_recovery.py --ifc=eth0 --new-ip=192.168.10.3 - ------------------------------------------------------------------------- -Communication Problems ------------------------------------------------------------------------- -When setting up a development machine for the first time, -you may have various difficulties communicating with the USRP device. -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 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 device. Instructions for setting your IP address are in the -previous section of this documentation. - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Firewall issues -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -When the IP address is not specified, -the device discovery broadcasts UDP packets from each ethernet interface. -Many firewalls will block the replies to these broadcast packets. -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**. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Ping the device -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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. - -:: - - ping 192.168.10.2 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Monitor the serial output -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Read the serial port to get debug verbose output from the embedded microcontroller. -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. - -* **USRP2:** Serial port located on the rear edge -* **N210:** Serial port located on the left side - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Monitor the host network traffic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use Wireshark to monitor packets sent to and received from the device. - ------------------------------------------------------------------------- -Addressing the Device ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Single device configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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>`_. Please note that this -addressing scheme should also be used with the **multi_usrp** interface. - -Example device address string representation for a USRP2 with IPv4 address **192.168.10.2**: - -:: - - addr=192.168.10.2 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Multiple device configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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. - -* 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. - -Example device address string representation for 2 USRP2s with IPv4 addresses **192.168.10.2** and **192.168.20.2**: -:: - - addr0=192.168.10.2, addr1=192.168.20.2 - ------------------------------------------------------------------------- -Using the MIMO Cable ------------------------------------------------------------------------- -The MIMO cable allows two USRP devices to share reference clocks, -time synchronization, and the Ethernet interface. -One of the devices will sync its clock and time references to the MIMO cable. -This device will be referred to as the slave, and the other device, the master. - -* The slave device acquires the clock and time references from the master device. -* The master and slave may be used individually or in a multi-device configuration. -* External clocking is optional and should only be supplied to the master device. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Shared Ethernet mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -In shared Ethernet mode, -only one device in the configuration can be attached to the Ethernet. - -* Clock reference, time reference, and data are communicated over the MIMO cable. -* Master and slave must have different IPv4 addresses in the same subnet. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Dual Ethernet mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -In dual Ethernet mode, -both devices in the configuration must be attached to the Ethernet. - -* Only clock reference and time reference are communicated over the MIMO cable. -* The master and slave must have different IPv4 addresses in different subnets. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Configuring the slave -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -In order for the slave to synchronize to the master over MIMO cable, -the following clock configuration must be set on the slave device: -:: - - usrp->set_time_source("mimo", slave_index); - usrp->set_clock_source("mimo", slave_index); - - ------------------------------------------------------------------------- -Alternative stream destination ------------------------------------------------------------------------- -It is possible to program the USRP device to send RX packets to an alternative IP/UDP destination. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Set the subnet and gateway -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -To use an alternative streaming destination, -the device needs to be able to determine if the destination address -is within its subnet, and ARP appropriately. -Therefore, the user should ensure that subnet and gateway addresses -have been programmed into the device's EEPROM. - -Run the following commands: -:: - - cd <install-path>/lib/uhd/utils - ./usrp_burn_mb_eeprom --args=<optional device args> --key=subnet --val=255.255.255.0 - ./usrp_burn_mb_eeprom --args=<optional device args> --key=gateway --val=192.168.10.1 - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Create a receive streamer -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Set the stream args "addr" and "port" values to the alternative destination. -Packets will be sent to this destination when the user issues a stream command. - -:: - - //create a receive streamer, host type does not matter - uhd::stream_args_t stream_args("fc32"); - - //resolvable address and port for a remote udp socket - stream_args.args["addr"] = "192.168.10.42"; - stream_args.args["port"] = "12345"; - - //create the streamer - uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args); - - //issue stream command - uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE); - stream_cmd.num_samps = total_num_samps; - stream_cmd.stream_now = true; - usrp->issue_stream_cmd(stream_cmd); - -**Note:** -Calling recv() on this streamer object should yield a timeout. - ------------------------------------------------------------------------- -Hardware Setup Notes ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Front panel LEDs -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The LEDs on the front panel can be useful in debugging hardware and software issues. -The LEDs reveal the following about the state of the device: - -* **LED A:** transmitting -* **LED B:** MIMO cable link -* **LED C:** receiving -* **LED D:** firmware loaded -* **LED E:** reference lock -* **LED F:** CPLD loaded - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Ref Clock - 10 MHz -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Using an external 10 MHz reference clock, a square wave will offer the best phase -noise performance, but a sinusoid is acceptable. The reference clock requires the following power level: - -* **USRP2** 5 to 15 dBm -* **N2XX** 0 to 15 dBm - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -PPS - Pulse Per Second -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Using a PPS signal for timestamp synchronization requires a square wave signal with the following amplitude: - -* **USRP2** 5Vpp -* **N2XX** 3.3 to 5Vpp - -Test the PPS input with the following app: - -* **<args>** are device address arguments (optional if only one USRP device is on your machine) - -:: - - cd <install-path>/lib/uhd/examples - ./test_pps_input --args=<args> - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Internal GPSDO -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Please see the `Internal GPSDO Application Notes <./gpsdo.html>`_ -for information on configuring and using the internal GPSDO. - ------------------------------------------------------------------------- -Miscellaneous ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Available Sensors -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The following sensors are available for the USRP2/N-Series motherboards; -they can be queried through the API. - -* **mimo_locked** - clock reference locked over the MIMO cable -* **ref_locked** - clock reference locked (internal/external) -* other sensors are added when the GPSDO is enabled - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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. -This hardware has only one daughterboard slot, -which has been aptly named slot **A**. - -In the following example, a TVRX2 is installed. -Channel 0 is sourced from subdevice **RX1**, -and channel 1 is sourced from subdevice **RX2** (**RX1** and **RX2** -are the antenna ports on the TVRX2 daughterboard): - -:: - - usrp->set_rx_subdev_spec("A:RX1 A:RX2"); diff --git a/host/docs/usrp_b100.dox b/host/docs/usrp_b100.dox new file mode 100644 index 000000000..c61d17f02 --- /dev/null +++ b/host/docs/usrp_b100.dox @@ -0,0 +1,96 @@ +/*! \page page_usrp_b100 USRP-B100 Series Device Manual + +\tableofcontents + +\section b100_features Comparative features list + +- Hardware Capabilities: + - 1 transceiver card slot + - External PPS reference input + - External 10 MHz reference input + - Configurable clock rate (defaults 64 MHz) +- FPGA Capabilities: + - 1 RX DDC chain in FPGA + - 1 TX DUC chain in FPGA + - Timed commands in FPGA + - Timed sampling in FPGA + - sc8 and sc16 sample modes + - Up to 8 MHz of RF BW with 16-bit samples + - Up to 16 MHz of RF BW with 8-bit samples + +\section b100_imgs Specify a Non-standard Image + +UHD software will automatically select the USRP B100 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: + + fpga=usrp_b100_fpga_2rx.bin + + -- OR -- + + fw=usrp_b100_fw.ihx + +\section b100_mcr Changing the Master Clock Rate + +The master clock rate of the B100 feeds both the FPGA DSP and the codec +chip. Hundreds of rates between 32 MHz and 64 MHz are available. A few +notable rates are: + +- **64 MHz:** maximum rate of the codec chip +- **61.44 MHz:** good for UMTS/WCDMA applications +- **52 MHz:** good for GSM applications + +\subsection b100_mcr_vcxo Set 61.44 MHz - uses external VCXO + +To use the 61.44 MHz clock rate, the USRP embedded will require one +jumper to be moved, 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 + +<b>Note:</b> See instructions below to communicate the desired clock rate +into UHD software. + +\subsection b100_mcr_vco Set other rates - uses internal VCO + +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 software, specify the +special device address argument, where the key is +**master_clock_rate** and the value is a rate in Hz. Example: : + + uhd_usrp_probe --args="master_clock_rate=52e6" + +\section b100_hw Hardware setup notes + +\subsection b100_hw_leds Front panel LEDs + +The LEDs on the front panel can be useful in debugging hardware and +software issues. The LEDs reveal the following about the state of the +device: + +- **LED A:** transmitting +- **LED B:** FPGA loaded +- **LED C:** receiving +- **LED D:** FPGA loaded +- **LED E:** reference lock +- **LED F:** board power + +\section b100_misc Miscellaneous + +\subsection b100_misc_sensors Available Sensors + +The following sensors are available; they can be queried through the +API. + +- **ref_locked:** clock reference locked (internal/external) + +*/ +// vim:ft=doxygen: diff --git a/host/docs/usrp_b100.rst b/host/docs/usrp_b100.rst deleted file mode 100644 index 223ad5a90..000000000 --- a/host/docs/usrp_b100.rst +++ /dev/null @@ -1,107 +0,0 @@ -======================================================================== -UHD - USRP-B100 Series Device Manual -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Comparative features list ------------------------------------------------------------------------- - -**Hardware Capabilities:** - * 1 transceiver card slot - * External PPS reference input - * External 10 MHz reference input - * Configurable clock rate (defaults 64 MHz) - -**FPGA Capabilities:** - * 1 RX DDC chain in FPGA - * 1 TX DUC chain in FPGA - * Timed commands in FPGA - * Timed sampling in FPGA - * sc8 and sc16 sample modes - - * Up to 8 MHz of RF BW with 16-bit samples - * Up to 16 MHz of RF BW with 8-bit samples - ------------------------------------------------------------------------- -Specify a Non-standard Image ------------------------------------------------------------------------- -UHD software will automatically select the USRP B100 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: - -:: - - fpga=usrp_b100_fpga_2rx.bin - - -- OR -- - - fw=usrp_b100_fw.ihx - ------------------------------------------------------------------------- -Changing the Master Clock Rate ------------------------------------------------------------------------- -The master clock rate of the B100 feeds both the FPGA DSP and the codec chip. -Hundreds of rates between 32 MHz and 64 MHz are available. -A few notable rates are: - -* **64 MHz:** maximum rate of the codec chip -* **61.44 MHz:** good for UMTS/WCDMA applications -* **52 MHz:** good for GSM applications - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Set 61.44 MHz - uses external VCXO -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -To use the 61.44 MHz clock rate, the USRP embedded will require one jumper to be moved, -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 software. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Set other rates - uses internal VCO -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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 software, -specify the special device address argument, -where the key is **master_clock_rate** and the value is a rate in Hz. -Example: -:: - - uhd_usrp_probe --args="master_clock_rate=52e6" - ------------------------------------------------------------------------- -Hardware setup notes ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Front panel LEDs -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The LEDs on the front panel can be useful in debugging hardware and software issues. -The LEDs reveal the following about the state of the device: - -* **LED A:** transmitting -* **LED B:** FPGA loaded -* **LED C:** receiving -* **LED D:** FPGA loaded -* **LED E:** reference lock -* **LED F:** board power - ------------------------------------------------------------------------- -Miscellaneous ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Available Sensors -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The following sensors are available; -they can be queried through the API. - -* **ref_locked:** clock reference locked (internal/external) diff --git a/host/docs/usrp_b200.dox b/host/docs/usrp_b200.dox new file mode 100644 index 000000000..77b20ed01 --- /dev/null +++ b/host/docs/usrp_b200.dox @@ -0,0 +1,69 @@ +/*! \page page_usrp_b200 USRP-B2x0 Series Device Manual + +\tableofcontents + +\section b200_features Comparative features list - B200 + +- Hardware Capabilities: + - Integrated RF frontend (70 MHz - 6 GHz) + - External PPS reference input + - External 10 MHz reference input + - Configurable clock rate + - Internal GPSDO option + - B210 Only: + - MICTOR Debug Connector + - JTAG Connector +- FPGA Capabilities: + - Timed commands in FPGA + - Timed sampling in FPGA + +\section b200_imgs Specify a Non-standard Image + +UHD software will automatically select the USRP B2X0 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: + + fpga=usrp_b200_fpga.bin + + -- OR -- + + fw=usrp_b200_fw.hex + +\section b200_mcr Changing the Master Clock Rate + +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. + +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: : + + uhd_usrp_probe --args="master_clock_rate=52e6" + +\section b200_fe RF Frontend Notes + +The B200 features an integrated RF frontend. + +\subsection b200_fe_tuning Frontend tuning + +The RF frontend has individually tunable receive and transmit chains. On +the B200, there is one transmit and one receive RF frontend. On the +B210, both transmit and receive can be used in a MIMO configuration. For +the MIMO case, both receive frontends share the RX LO, and both transmit +frontends share the TX LO. Each LO is tunable between 50 MHz and 6 GHz. + +\subsection b200_fe_gain Frontend gain + +All frontends have individual analog gain controls. The receive +frontends have 73 dB of available gain; and the transmit frontends have +89.5 dB of available gain. Gain settings are application specific, but +it is recommended that users consider using at least half of the +available gain to get reasonable dynamic range. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/usrp_b200.rst b/host/docs/usrp_b200.rst deleted file mode 100644 index b282ec424..000000000 --- a/host/docs/usrp_b200.rst +++ /dev/null @@ -1,78 +0,0 @@ -======================================================================== -UHD - USRP-B2x0 Series Device Manual -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Comparative features list - B200 ------------------------------------------------------------------------- - -**Hardware Capabilities:** - * Integrated RF frontend (70 MHz - 6 GHz) - * External PPS reference input - * External 10 MHz reference input - * Configurable clock rate - * Internal GPSDO option - * B210 Only: - - * MICTOR Debug Connector - * JTAG Connector - -**FPGA Capabilities:** - * Timed commands in FPGA - * Timed sampling in FPGA - ------------------------------------------------------------------------- -Specify a Non-standard Image ------------------------------------------------------------------------- -UHD software will automatically select the USRP B2X0 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: - -:: - - fpga=usrp_b200_fpga.bin - - -- OR -- - - fw=usrp_b200_fw.hex - ------------------------------------------------------------------------- -Changing the Master Clock Rate ------------------------------------------------------------------------- -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. - -The user can set the master clock rate through the usrp API call set_master_clock_rate(), -or the clock rate can be set through the device arguments, which many applications take: -:: - - uhd_usrp_probe --args="master_clock_rate=52e6" - ------------------------------------------------------------------------- -RF Frontend Notes ------------------------------------------------------------------------- -The B200 features and integrated RF frontend. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Frontend tuning -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The RF frontend has individually tunable receive and transmit chains. -On the B200, there is one transmit and one receive RF frontend. -On the B210, both transmit and receive can be used in a MIMO configuration. -For the MIMO case, both receive frontends share the RX LO, -and both transmit frontends share the TX LO. -Each LO is tunable between 50 MHz and 6 GHz. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Frontend gain -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -All frontends have individual analog gain controls. -The receive frontends have 73 dB of available gain; -and the transmit frontends have 89.5 dB of available gain. -Gain settings are application specific, -but it is recommended that users consider using at least -half of the available gain to get reasonable dynamic range. diff --git a/host/docs/usrp_e1x0.dox b/host/docs/usrp_e1x0.dox new file mode 100644 index 000000000..c73e6ed42 --- /dev/null +++ b/host/docs/usrp_e1x0.dox @@ -0,0 +1,136 @@ +/*! \page page_usrp_e1x0 USRP-E1x0 Series Device Manual + +\tableofcontents + +\section e1x0_features Comparative features list + +- Hardware Capabilities: + - 1 transceiver card slot + - Internal PPS reference input + - Internal 10 MHz reference input + - Configurable clock rate (defaults to 64 MHz) + - Internal GPSDO option +- FPGA Capabilities: + - 2 RX DDC chains in FPGA + - 1 TX DUC chain in FPGA + - Timed commands in FPGA + - Timed sampling in FPGA + - sc8 and sc16 sample modes + - Up to 8 MHz of RF BW with 16-bit samples + - Up to 16 MHz of RF BW with 8-bit samples + +\section e1x0_imgs Specify a Non-standard Image + +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. + +Example device address string representations to specify non-standard +FPGA image: + + fpga=usrp_e100_custom.bin + +\section e1x0_mcr 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 32 MHz and 64 MHz are +available. A few notable rates are: + +- **64 MHz:** maximum rate of the codec chip +- **61.44 MHz:** good for UMTS/WCDMA applications +- **52 MHz:** good for GSM applications + +\subsection e1x0_mcr_extvcxo Set 61.44MHz - uses external VCXO + +To use the 61.44 MHz 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). + +**Note:** See instructions below to communicate the desired clock rate +to UHD software. + +\subsection e1x0_intvco 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). + +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: + + uhd_usrp_probe --args="master_clock_rate=52e6" + +\section e1x0_clksync Clock Synchronization + +\subsection e1x0_clksync_ref Ref Clock - 10MHz + +The E1xx has a 10MHz TCXO which can be used to discipline the flexible +clocking by selecting `REF_INT` for the uhd::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 uhd::clock_config_t. + +\subsection e1x0_clksync_pps PPS - Pulse Per Second + +An external 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 5 Vpp + +Test the PPS input with the following app (`<args>` are device +address arguments, optional if only one USRP device is on your machine): + + cd <install-path>/lib/uhd/examples + ./test_pps_input --args=<args> + +\subsection e1x0_clksync_gpsdo Internal GPSDO + +Please see the \ref page_gpsdo for +information on configuring and using the internal GPSDO. + +UHD software will always try to detect an installed GPSDO at runtime. It +is not necessary to burn a special EEPROM value for GPSDO detection. + +\section e1x0_hw Hardware Setup Notes + +\subsection e1x0_hw_leds Front panel LEDs + +The LEDs on the front panel can be useful in debugging hardware and +software issues. The LEDs reveal the following about the state of the +device: + +- **LED A:** transmitting +- **LED B:** PPS signal +- **LED C:** receiving +- **LED D:** FPGA loaded +- **LED E:** reference lock +- **LED F:** board power + +\section e1x0_misc Miscellaneous + +\subsection e1x0_misc_sensors Available Sensors + +The following sensors are available; they can be queried through the +API. + +- **ref_locked:** clock reference locked (internal/external) +- other sensors are added when the GPSDO is enabled + +*/ +// vim:ft=doxygen: diff --git a/host/docs/usrp_e1x0.rst b/host/docs/usrp_e1x0.rst deleted file mode 100644 index ea2d05a3c..000000000 --- a/host/docs/usrp_e1x0.rst +++ /dev/null @@ -1,156 +0,0 @@ -======================================================================== -UHD - USRP-E1x0 Series Device Manual -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Comparative features list ------------------------------------------------------------------------- - -**Hardware Capabilities:** - * 1 transceiver card slot - * Internal PPS reference input - * Internal 10 MHz reference input - * Configurable clock rate (defaults to 64 MHz) - * Internal GPSDO option - -**FPGA Capabilities:** - * 2 RX DDC chains in FPGA - * 1 TX DUC chain in FPGA - * Timed commands in FPGA - * Timed sampling in FPGA - * sc8 and sc16 sample modes - - * Up to 8 MHz of RF BW with 16-bit samples - * Up to 16 MHz of RF BW with 8-bit samples - ------------------------------------------------------------------------- -Specify a Non-standard Image ------------------------------------------------------------------------- -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. - -Example device address string representations to specify non-standard FPGA -image: - -:: - - fpga=usrp_e100_custom.bin - ------------------------------------------------------------------------- -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 32 MHz and 64 MHz are available. A few notable -rates are: - -* **64 MHz:** maximum rate of the codec chip -* **61.44 MHz:** good for UMTS/WCDMA applications -* **52 MHz:** good for GSM applications - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Set 61.44MHz - uses external VCXO -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -To use the 61.44 MHz 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). - -**Note:** See instructions below to communicate the desired clock rate to UHD software. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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). - -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: -:: - - uhd_usrp_probe --args="master_clock_rate=52e6" - ------------------------------------------------------------------------- -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**. - -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**. - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -PPS - Pulse Per Second -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -An external 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 5 Vpp - -Test the PPS input with the following app (**<args>** are device address -arguments, optional if only one USRP device is on your machine): - -:: - - cd <install-path>/lib/uhd/examples - ./test_pps_input --args=<args> - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Internal GPSDO -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Please see the `Internal GPSDO Application Notes <./gpsdo.html>`_ -for information on configuring and using the internal GPSDO. - -UHD software will always try to detect an installed GPSDO at runtime. -It is not necessary to burn a special EEPROM value for GPSDO detection. - ------------------------------------------------------------------------- -Hardware Setup Notes ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Front panel LEDs -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The LEDs on the front panel can be useful in debugging hardware and software -issues. The LEDs reveal the following about the state of the device: - -* **LED A:** transmitting -* **LED B:** PPS signal -* **LED C:** receiving -* **LED D:** FPGA loaded -* **LED E:** reference lock -* **LED F:** board power - ------------------------------------------------------------------------- -Miscellaneous ------------------------------------------------------------------------- - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Available Sensors -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The following sensors are available; -they can be queried through the API. - -* **ref_locked:** clock reference locked (internal/external) -* other sensors are added when the GPSDO is enabled diff --git a/host/docs/usrp_x3x0.rst b/host/docs/usrp_x3x0.dox index ee6960298..d97923345 100644 --- a/host/docs/usrp_x3x0.rst +++ b/host/docs/usrp_x3x0.dox @@ -1,46 +1,37 @@ -=============================== -UHD - X3x0 Series Device Manual -=============================== - -.. contents:: Table of Contents - -------------------------- -Comparative features list -------------------------- - -**Hardware Capabilities:** - * 2 transceiver card slots (can do 2x2 MIMO out of the box) - * Dual SFP+ Transceivers (can be used with 1 GigE, 10 GigE) - * PCI Express over cable (MXI) gen1 x4 - * External PPS input & output - * External 10 MHz input & output - * Expandable via 2nd SFP+ interface - * Supported master clock rates: 200 MHz, 184.32 MHz - * External GPIO Connector with UHD API control - * External USB Connection for built-in JTAG debugger - * Internal GPSDO option - * Kintex-7 FPGA (X310: XC7K410T, X300: XC7K325T) - -**FPGA Capabilities:** - * 2 RX DDC chains in FPGA - * 2 TX DUC chain in FPGA - * Timed commands in FPGA - * Timed sampling in FPGA - * 16-bit and 8-bit sample modes (sc8 and sc16) - * Up to 120 MHz of RF bandwidth with 16-bit samples - ---------------- -Getting started ---------------- +/*! \page page_usrp_x3x0 X3x0 Series Device Manual + +\tableofcontents + +\section x3x0_feature_list Comparative features list + +- Hardware Capabilities: + - 2 transceiver card slots (can do 2x2 MIMO out of the box) + - Dual SFP+ Transceivers (can be used with 1 GigE, 10 GigE) + - PCI Express over cable (MXI) gen1 x4 + - External PPS input & output + - External 10 MHz input & output + - Expandable via 2nd SFP+ interface + - Supported master clock rates: 200 MHz, 184.32 MHz + - External GPIO Connector with UHD API control + - External USB Connection for built-in JTAG debugger + - Internal GPSDO option + - Kintex-7 FPGA (X310: XC7K410T, X300: XC7K325T) +- FPGA Capabilities: + - 2 RX DDC chains in FPGA + - 2 TX DUC chain in FPGA + - Timed commands in FPGA + - Timed sampling in FPGA + - 16-bit and 8-bit sample modes (sc8 and sc16) + - Up to 120 MHz of RF bandwidth with 16-bit samples + +\section x3x0_getting_started Getting started This will run you through the first steps relevant to get your USRP X300/X310 up and running. Here, we assume you will connect your USRP using Gigabit Ethernet (1GigE), as this interface is readily available in most computers. For 10 Gigabit Ethernet (10GigE) or PCI Express (PCIe), see the corresponding sections in this manual page. -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Assembling the X300/X310 kit -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_getting_started_assembling Assembling the X300/X310 kit Before you can start using your USRP, you might have to assemble the hardware, if this has not yet happened. Make sure you are grounded (e.g. by touching a radiator) @@ -54,122 +45,109 @@ in order not to damage sensitive electronics through static discharge! confusion, make sure the internal connections match the labels on the front panel (i.e. TX/RX is connected to TX/RX). 4. If you have purchased an internal GPSDO, follow the instructions on - `the internal GPSDO manual page <./gpsdo_x3x0.html>`_ to insert the GPSDO. Note that you + \ref page_gpsdo_x3x0 to insert the GPSDO. Note that you will need an external GPS antenna connected to the rear GPS ANT connector in order to make use of GPS, although your USRP will still be usable without. 5. Connect the 1 GigE SFP+ transceiver into the Ethernet port 0 and connect the X300/X310 with your computer. 6. Connect the power supply and switch on the USRP. -^^^^^^^^^^^^^^^^^^^^ -Network Connectivity -^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_getting_started_connectivity Network Connectivity The next step is to make sure your computer can talk to the USRP. An otherwise unconfigured USRP device will have the IP address 192.168.10.2 when using 1GigE. It is recommended to directly connect your USRP to the computer at first, and to set the IP address on your machine to 192.168.10.1. -See the `system configuration manual <./usrp_x3x0_config.html>`_ on details how to change your machine's IP address. +See \ref x3x0_setup_network_host_interface on details how to change your machine's IP address. -**Note**: If you are running an automatic IP configuration service such as Network Manager, make +<b>Note</b>: If you are running an automatic IP configuration service such as Network Manager, make sure it is either deactivated or configured to not change the network device! This can, in extreme cases, lead to you bricking the USRP! -If your network configuration is correct, running ``uhd_find_devices`` will find your USRP -and print some information about it. You will also be able to ping the USRP by running:: +If your network configuration is correct, running `uhd_find_devices` will find your USRP +and print some information about it. You will also be able to ping the USRP by running: ping 192.168.10.2 -on the command line. At this point, you should also run:: +on the command line. At this point, you should also run: uhd_usrp_probe --args addr=192.168.10.2 to make sure all of your components (daughterboards, GPSDO) are correctly detected and usable. -^^^^^^^^^^^^^^^^^^^^^ -Updating the firmware -^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_getting_started_fw_update Updating the firmware -If the output from ``uhd_find_devices`` and ``uhd_usrp_probe`` didn't show any warnings, you +If the output from `uhd_find_devices` and `uhd_usrp_probe` didn't show any warnings, you can skip this step. However, if there were warnings regarding version incompatibility, you will have to upate the FPGA image before you can start using your USRP. -1. Download the current UHD images. You can use the ``uhd_images_downloader`` script provided - with UHD (see also `FPGA Image Flavors`_). -2. Use the ``usrp_x3xx_fpga_burner`` utility to update the FPGA image. On the command line, run:: +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: usrp_x3xx_fpga_burner --addr=192.168.10.2 --type=HGS # Since we are using 1GigE, type is HGS - If you have installed the images to a non-standard location, you might need to run (change the filename according to your device):: + 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 The process of updating the firmware will take several minutes. Make sure the process of flashing the image does not get interrupted. -See `Load the Images onto the On-board Flash`_ for more details. +See \ref x3x0_flash for more details. -When your firmware is up to date, power-cycle the device and re-run ``uhd_usrp_probe``. There should +When your firmware is up to date, power-cycle the device and re-run `uhd_usrp_probe`. There should be no more warnings at this point, and all components should be correctly detected. Your USRP is now ready for development! --------------- -Hardware Setup --------------- +\section x3x0_hw Hardware Setup -^^^^^^^^^^^^^^^^^^^^^^^^^ -Gigabit Ethernet (1 GigE) -^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_hw_1gige Gigabit Ethernet (1 GigE) -Installing the USRP X300/X310 -::::::::::::::::::::::::::::: -* Prior to installing the module, the host PC can remain powered on. -* Plug a 1 Gigabit SFP Transceiver into Ethernet Port 0 on the USRP X300/X310 device. -* Use the Ethernet cable to connect the SFP+ transciever on the device to the host computer. For maximum throughput, Ettus Research recommends that you connect each device to its own dedicated Gigabit Ethernet interface on the host computer. -* Connect the AC/DC power supply to the device and plug the supply into a wall outlet. -* The OS will automatically recognize the device (e.g. when running uhd_find_devices). +- Prior to installing the module, the host PC can remain powered on. +- Plug a 1 Gigabit SFP Transceiver into Ethernet Port 0 on the USRP X300/X310 device. +- Use the Ethernet cable to connect the SFP+ transciever on the device to the host computer. For maximum throughput, Ettus Research recommends that you connect each device to its own dedicated Gigabit Ethernet interface on the host computer. +- Connect the AC/DC power supply to the device and plug the supply into a wall outlet. +- The OS will automatically recognize the device (e.g. when running `uhd_find_devices`). -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Ten Gigabit Ethernet (10 GigE) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_hw_10gige Ten Gigabit Ethernet (10 GigE) + +### Installing the Host Ethernet Interface -Installing the Host Ethernet Interface -:::::::::::::::::::::::::::::::::::::: Ettus Research recommends the Intel Ethernet Converged Network Adapter X520-DA2 interface for communication with the USRP X300/X310 device. Installation instructions for this interface are available on the official Intel website. -Installing the USRP X300/X310 -::::::::::::::::::::::::::::: -* Prior to installing the module, the host PC can remain powered on. -* Use a 10 Gigabit SFP+ cable to connect Ethernet Port 1 on the USRP X300/X310 device to the host computer. For maximum throughput, Ettus Research recommends that you connect the device to its own dedicated Ten Gigabit, Ettus Research recommended Ethernet interface on the host computer. -* Connect the AC/DC power supply to the device and plug the supply into a wall outlet. -* The OS will automatically recognize the device (e.g. when running uhd_find_devices). +### Installing the USRP X300/X310 + +- Prior to installing the module, the host PC can remain powered on. +- Use a 10 Gigabit SFP+ cable to connect Ethernet Port 1 on the USRP X300/X310 device to the host computer. For maximum throughput, Ettus Research recommends that you connect the device to its own dedicated Ten Gigabit, Ettus Research recommended Ethernet interface on the host computer. +- Connect the AC/DC power supply to the device and plug the supply into a wall outlet. +- The OS will automatically recognize the device (e.g. when running `uhd_find_devices`). + +The LEDs on the front panel can be useful in debugging hardware and software issues (see \ref x3x0_hw_fpanel) -The LEDs on the front panel can be useful in debugging hardware and software issues (see Section "Front Panel") +\subsection x3x0_hw_pcie PCI Express (Desktop) -^^^^^^^^^^^^^^^^^^^^^ -PCI Express (Desktop) -^^^^^^^^^^^^^^^^^^^^^ -*Important Note: The USRP X-Series provides PCIe connectivity over MXI cable. -We will use the 'MXI' nomenclature for the rest of this manual.* +<b>Important Note: The USRP X-Series provides PCIe connectivity over MXI cable. +We will use the 'MXI' nomenclature for the rest of this manual.</b> -Installing the PCI Express Interface Kit -:::::::::::::::::::::::::::::::::::::::: -Follow the instructions listed in the `Set Up Your MXI-Express x4 System <http://www.ni.com/pdf/manuals/371976c.pdf>`_ +### Installing the PCI Express Interface Kit + +Follow the instructions listed in the <a href="http://www.ni.com/pdf/manuals/371976c.pdf">Set Up Your MXI-Express x4 System</a> document to setup the NI PCIe-8371 module. -Installing the USRP X300/X310 -::::::::::::::::::::::::::::: -* Prior to installing the module, make sure that the PC is powered off. -* Using a MXI-Express Cable connect the USRP X300/X310 to the NI PCIe-8371. -* Connect the AC/DC power supply to the device and plug the supply into a wall outlet. -* Power on the USRP X300/X310 device using the power switch located in the bottom-right corner of the front panel. -* Power on the PC (The OS automatically recognizes the new device) +### Installing the USRP X300/X310 + +- Prior to installing the module, make sure that the PC is powered off. +- Using a MXI-Express Cable connect the USRP X300/X310 to the NI PCIe-8371. +- Connect the AC/DC power supply to the device and plug the supply into a wall outlet. +- Power on the USRP X300/X310 device using the power switch located in the bottom-right corner of the front panel. +- Power on the PC (The OS automatically recognizes the new device) -NOTE: The USRP device is not hot-pluggable over PCI Express. Any connection changes with only be detected by your +<b>Note:</b> The USRP device is not hot-pluggable over PCI Express. Any connection changes with only be detected by your computer after a successful reboot. -Troubleshooting -::::::::::::::: +### Troubleshooting + Two possible failure modes are your computer not booting when connected to your USRP device through MXI-Express, and Windows not properly discovering your devices (for example, there is a yellow exclamation point on a PCI to PCI @@ -177,70 +155,63 @@ bridge in Windows Device Manager, despite drivers for all devices being installed). These situations often are due to programming errors in PCI Express device configuration of the BIOS. To use this software, you need a MXI-Express device that supports Mode 1 operation. -Refer to `NI MXI-Express BIOS Compatibility Software Readme <http://download.ni.com/support/softlib//PXI/MXIe%20Compatibility%20Software/1.5.0/readme.html#SupportedHardware>`_ +Refer to <a href="http://download.ni.com/support/softlib//PXI/MXIe%20Compatibility%20Software/1.5.0/readme.html#SupportedHardware">NI MXI-Express BIOS Compatibility Software Readme</a> for more information. -The BIOS Compatibility Software can be downloaded for Windows from the `MXI-Express BIOS Compatibility Software <http://www.ni.com/download/mxi-express-bios-compatibility-software-1.5/3764/en/>`_ page +The BIOS Compatibility Software can be downloaded for Windows from the <a href="http://www.ni.com/download/mxi-express-bios-compatibility-software-1.5/3764/en/"> MXI-Express BIOS Compatibility Software page</a>. + +\subsection x3x0_hw_pcie_laptop PCI Express (Laptop) -^^^^^^^^^^^^^^^^^^^^ -PCI Express (Laptop) -^^^^^^^^^^^^^^^^^^^^ -*Important Note: The USRP X-Series provides PCIe connectivity over MXI cable. -We will use the 'MXI' nomenclature for the rest of this manual.* +<b>Important Note: The USRP X-Series provides PCIe connectivity over MXI cable +We will use the 'MXI' nomenclature for the rest of this manual.</b> -Installing the PCI Express Card -::::::::::::::::::::::::::::::: -Follow the instructions listed in the “Installing an NI ExpressCard-8360 Host Card” section of the -`Set Up Your MXI-Express x1 System <http://www.ni.com/pdf/manuals/373259d.pdf#page=10>`_ +### Installing the PCI Express Card + +Follow the instructions listed in the “Installing an NI ExpressCard-8360 Host Card” section of the +<a href="http://www.ni.com/pdf/manuals/373259d.pdf#page=10">Set Up Your MXI-Express x1 System</a> document to setup the NI ExpressCard-8360B module. -Installing the USRP X300/X310 -::::::::::::::::::::::::::::: +### Installing the USRP X300/X310 + Because a laptop computer is not grounded, follow this procedure to safely connect a laptop computer to your USRP device. -* Connect the AC/DC power supply to the device and plug the supply into a wall outlet. Ensure that the USRP device is powered off. -* Touch the NI ExpressCard-8360B and a metal part of the USRP device simultaneously. Do not install the NI ExpressCard-8360B into the laptop computer yet. -* Connect the cable to the NI ExpressCard-8360B and USRP. -* Plug the NI ExpressCard-8360B into an available ExpressCard slot. If your laptop computer is already running (or hibernating, suspended, etc) when you install an NI ExpressCard-8360B, you must reboot to detect the USRP. Otherwise, the USRP is detected when you start your computer. +- Connect the AC/DC power supply to the device and plug the supply into a wall outlet. Ensure that the USRP device is powered off. +- Touch the NI ExpressCard-8360B and a metal part of the USRP device simultaneously. Do not install the NI ExpressCard-8360B into the laptop computer yet. +- Connect the cable to the NI ExpressCard-8360B and USRP. +- Plug the NI ExpressCard-8360B into an available ExpressCard slot. If your laptop computer is already running (or hibernating, suspended, etc.) when you install an NI ExpressCard-8360B, you must reboot to detect the USRP. Otherwise, the USRP is detected when you start your computer. -NOTE: The USRP device is not hot-pluggable over PCI Express. Any connection changes will only be detected by your computer after a successful reboot. +\b Note: The USRP device is not hot-pluggable over PCI Express. Any connection changes will only be detected by your computer after a successful reboot. + +\section x3x0_jtag On-Board JTAG Programmer --------------------------------- -On-Board JTAG Programmer --------------------------------- The USRP X3x0 includes an on-board JTAG programmer, built into the motherboard. To connect to this JTAG device, simply connect your computer to the USB JTAG port on the front of the X3x0 device. You may now use the JTAG programmer in the same way you would use any other, including: -* `Xilinx Programming Tools (ISE, iMPACT) <http://www.xilinx.com/support/download/index.htm>`_ -* `Xilinx Chipscope <http://www.xilinx.com/tools/cspro.htm>`_ -* `Digilent ADEPT <https://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,828&Prod=ADEPT2>`_ +- <a href="http://www.xilinx.com/support/download/index.htm">Xilinx Programming Tools (ISE, iMPACT)</a> +- <a href="http://www.xilinx.com/tools/cspro.htm">Xilinx Chipscope</a> +- <a href="https://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,828&Prod=ADEPT2">Digilent ADEPT</a> In order to use the JTAG programmer with the Xilinx tools, the Digilent drivers and plugin have to be installed first. Although recent versions of ISE ship with the driver, it has to still be manually installed. -Note: Sometimes the ISE shipped versions are newer than the ones available via Digilent's website. It is therefore advisable to +\b Note: Sometimes the ISE shipped versions are newer than the ones available via Digilent's website. It is therefore advisable to use the ISE provided plugin and drivers. -To install first locate your ISE installation path (default is /opt/Xilinx/<Version>). - -**LINUX** -:: +To install first locate your ISE installation path on a Linux system (default is `/opt/Xilinx/<Version>`): sudo <ise install path>/ISE_DS/common/bin/lin64/digilent/install_digilent.sh Afterwards either reboot or force udev to reload its rules by: -:: sudo udevadm control --reload The USRP-X series device should now be usable with all the tools mentioned above. --------------------------------- -Load FPGA Images onto the Device --------------------------------- +\section x3x0_load_fpga_imgs Load FPGA Images onto the Device + The USRP-X Series device ships with a bitstream pre-programmed in the flash, which is automatically loaded onto the FPGA during device power-up. However, a new FPGA image can be configured over the PCI Express interface or the @@ -251,93 +222,74 @@ Please note that this process is *different* than replacing the FPGA image stored in the flash, which will then be automatically loaded the next time the device is reset. -^^^^^^^^^^^^^^^^^^ -FPGA Image Flavors -^^^^^^^^^^^^^^^^^^ +\subsection x3x0_load_fpga_imgs_fpga_flavours FPGA Image Flavors + The USRP-X Series devices contains two SFP+ ports for the two Ethernet channels. Because the SFP+ ports support both 1 Gigabit (SFP) and 10 Gigabit (SFP+) transceivers, several FPGA images are shipped with UHD to determine the behavior of the above interfaces. -+---------------------+------------------------+------------------------+ | FPGA Image Flavor | SFP+ Port 0 Interface | SFP+ Port 1 Interface | -+=====================+========================+========================+ +|---------------------|------------------------|------------------------| | HGS (Default) | 1 Gigabit Ethernet | 10 Gigabit Ethernet | -+---------------------+------------------------+------------------------+ | XGS | 10 Gigabit Ethernet | 10 Gigabit Ethernet | -+---------------------+------------------------+------------------------+ FPGA images are shipped in 2 formats: -* **LVBITX**: LabVIEW FPGA configuration bitstream format (for use over PCI Express and Ethernet) -* **BIT**: Xilinx configuration bitstream format (for use over Ethernet and JTAG) +- **LVBITX**: LabVIEW FPGA configuration bitstream format (for use over PCI Express and Ethernet) +- **BIT**: Xilinx configuration bitstream format (for use over Ethernet and JTAG) -To get the latest images, simply use the uhd_images_downloader script: - -**UNIX:** - -:: +To get the latest images, simply use the uhd_images_downloader script. On Unix systems, use this command: sudo uhd_images_downloader -**Windows:** - -:: +On Windows, use: <path_to_python.exe> <install-path>/bin/uhd_images_downloader.py -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use PCI Express to load FPGA images -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_load_fpga_imgs_pcie Use PCI Express to load FPGA images + UHD requires a valid LabVIEW FPGA configuration bitstream file (LVBITX) to use the USRP-X Series -device over the PCI Express bus. LabVIEW FPGA is **NOT** required to use UHD with a USRP-X Series device. +device over the PCI Express bus. LabVIEW FPGA is \b not required to use UHD with a USRP-X Series device. Because FPGA configuration is a part of normal operation over PCI Express, there is no setup required before running UHD. -The **fpga** tag can be set in the optional device args passed to indicate the FPGA image flavor to UHD. +The \e fpga tag can be set in the optional device args passed to indicate the FPGA image flavor to UHD. If the above tag is specified, UHD will attempt to load the FPGA image with the requested flavor from the UHD images directory. If the tag is not specified, UHD will automatically detect the flavor of the image and attempt to load the corresponding configuration bitstream onto the device. Note that if UHD detects that the requested image is already loaded onto the FPGA then it will not reload it. -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use JTAG to load FPGA images -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The USRP-X Series device features an on-board USB-JTAG programmer that can be accessed on the front-panel -of the device. The iMPACT tool in the `Xilinx Programming Tools <http://www.xilinx.com/support/download/index.htm>`_ package can be used to load an image over -the JTAG interface. This can be useful for unbricking devices. +\subsection x3x0_load_fpga_imgs_jtag Use JTAG to load FPGA images -If you have iMPACT installed, you can use the impact_jtag_programmer.sh tool to install images. Make sure your X3x0 is powered on and connected to your computer using the front panel USB JTAG connector (USB 2.0 is fine for this). Then run the tool: +The USRP-X Series device features an on-board USB-JTAG programmer that can be accessed on the front-panel +of the device. The iMPACT tool in the <a href="http://www.xilinx.com/support/download/index.htm">Xilinx Programming Tools (ISE, iMPACT)</a> package can be used to load an image over the JTAG interface. This can be useful for unbricking devices. -:: +If you have iMPACT installed, you can use the `impact_jtag_programmer.sh` tool to install images. Make sure your X3x0 is powered on and connected to your computer using the front panel USB JTAG connector (USB 2.0 is fine for this). Then run the tool: <path_to_uhd_tools>/impact_jtag_programmer.sh --fpga-path=<fpga_image_path> ---------------------------------------- -Load the Images onto the On-board Flash ---------------------------------------- +\section x3x0_flash Load the Images onto the On-board Flash + To change the FPGA image stored in the on-board flash, the USRP-X Series device can be reprogrammed over the network or PCI Express. Once you have programmed an image into the flash, that image will be automatically loaded on the FPGA during the device boot-up sequence. -**Note:** +\b Note: Different hardware revisions require different FPGA images. Determine the revision number from the sticker on the rear of the device. If you are manually specifying an FPGA path, the utility will not try to detect your device information, and you will need to use this number to select which image to burn. -**Note:** +\b Note: The burner 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. -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use the burner tool over Ethernet -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: +\subsection x3x0_flash_burner_tool Use the burner tool over Ethernet Automatic FPGA path, detect image type: usrp_x3xx_fpga_burner --addr=<IP address> @@ -348,10 +300,7 @@ Use the burner tool over Ethernet Manual FPGA path: usrp_x3xx_fpga_burner --addr=<IP address> --fpga-path=<path to FPGA image> -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use the burner tool over PCI Express -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -:: +\subsection x3x0_flash_burner_tool_pcie Use the burner tool over PCI Express Automatic FPGA path, detect image type: usrp_x3xx_fpga_burner --resource=<NI-RIO resource> @@ -362,163 +311,134 @@ Use the burner tool over PCI Express Manual FPGA path: usrp_x3xx_fpga_burner --resource=<NI-RIO resource> --fpga-path=<path to FPGA image> -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Device recovery and bricking -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_flash_bricking Device recovery and bricking It is possible to put the device into an unusable state by loading bad images ("bricking"). Fortunately, the USRP-X Series device can be loaded with a good image temporarily using the USB-JTAG interface. Once booted into the safe image, the user can once again load images onto the device over Ethernet or PCI Express. ----------------- -Setup Networking ----------------- +\section x3x0_setup_network Setup Networking The USRP-X Series only supports Gigabit and Ten Gigabit Ethernet and will not work with a 10/100 Mbps interface. -**Please note that 10 Gigabit Ethernet defines the protocol, not necessary the +<b>Please note that 10 Gigabit Ethernet defines the protocol, not necessary the medium. For example, you may use 10GigE over optical with optical SFP+ -transceiver modules.** +transceiver modules.</b> + +\subsection x3x0_setup_network_host_interface Setup the host interface -^^^^^^^^^^^^^^^^^^^^^^^^ -Setup the host interface -^^^^^^^^^^^^^^^^^^^^^^^^ The USRP-X Series communicates at the IP/UDP layer over the Gigabit and Ten Gigabit Ethernet. The default IP address for the USRP X300/X310 device depends on the Ethernet Port and interface used. You must configure the host Ethernet interface with a static IP address on the same subnet as the connected device to enable communication, as shown in the following table: -+---------------+-------------------------+----------------+----------------+---------------+---------------+ -| Ethernet | USRP | Default USRP | Host Static | Host Static | Address | -| Interface | Ethernet Port | IP Address | IP Address | Subnet Mask | EEPROM key | -+===============+=========================+================+================+===============+===============+ -| Gigabit | Port 0 (HGS Image) | 192.168.10.2 | 192.168.10.1 | 255.255.255.0 | ``ip-addr0`` | -+---------------+-------------------------+----------------+----------------+---------------+---------------+ -| Ten Gigabit | Port 0 (XGS Image) | 192.168.30.2 | 192.168.30.1 | 255.255.255.0 | ``ip-addr2`` | -+---------------+-------------------------+----------------+----------------+---------------+---------------+ -| Ten Gigabit | Port 1 (HGS/XGS Image) | 192.168.40.2 | 192.168.40.1 | 255.255.255.0 | ``ip-addr3`` | -+---------------+-------------------------+----------------+----------------+---------------+---------------+ - -As you can see, the X300/X310 actually stores different IP addresses, which all address the device differently: Each combination of Ethernet port and interface type (i.e., Gigabit or Ten Gigabit) has its own IP address. As an example, when addressing the device through 1 Gigabit Ethernet on its first port (Port 0), the relevant IP address is the one stored in the EEPROM with key ``ip-addr0``, or 192.168.10.2 by default. - -See the `system configuration manual <./usrp_x3x0_config.html>`_ on details -how to change your machine's IP address and MTU size to work well with the X300. - -^^^^^^^^^^^^^^^^^^^^^^^^^ -Multiple devices per host -^^^^^^^^^^^^^^^^^^^^^^^^^ + Ethernet Interface | USRP Ethernet Port | Default USRP IP Address | Host Static IP Address | Host Static Subnet Mask | Address EEPROM key +---------------------|-------------------------|--------------------------|-------------------------|-------------------------|------------------- + Gigabit | Port 0 (HGS Image) | 192.168.10.2 | 192.168.10.1 | 255.255.255.0 | `ip-addr0` + Ten Gigabit | Port 0 (XGS Image) | 192.168.30.2 | 192.168.30.1 | 255.255.255.0 | `ip-addr2` + Ten Gigabit | Port 1 (HGS/XGS Image) | 192.168.40.2 | 192.168.40.1 | 255.255.255.0 | `ip-addr3` + +As you can see, the X300/X310 actually stores different IP addresses, which all address the device differently: Each combination of Ethernet port and interface type (i.e., Gigabit or Ten Gigabit) has its own IP address. As an example, when addressing the device through 1 Gigabit Ethernet on its first port (Port 0), the relevant IP address is the one stored in the EEPROM with key `ip-addr0`, or 192.168.10.2 by default. + +See \ref x3x0cfg_hostpc_netcfg_ip on details how to change your machine's IP address and MTU size to work well with the X300. + +\subsection x3x0_setup_network_multidevs Multiple devices per host + For maximum throughput, one Ethernet interface per USRP is recommended, although multiple devices may be connected via an Ethernet switch. In any case, each Ethernet interface should have its own subnet, and the corresponding USRP device should be assigned an address in that subnet. Example: -**Configuration for USRP-X Series device 0:** +### Configuration for USRP-X Series device 0: -* Ethernet interface IPv4 address: **192.168.10.1** -* Ethernet interface subnet mask: **255.255.255.0** -* USRP-X Series device IPv4 address: **192.168.10.2** +- Ethernet interface IPv4 address: `192.168.10.1` +- Ethernet interface subnet mask: `255.255.255.0` +- USRP-X Series device IPv4 address: `192.168.10.2` -**Configuration for USRP-X Series device 1:** +### Configuration for USRP-X Series device 1: -* Ethernet interface IPv4 address: **192.168.110.1** -* Ethernet interface subnet mask: **255.255.255.0** -* USRP-X Series device IPv4 address: **192.168.110.2** +- Ethernet interface IPv4 address: `192.168.110.1` +- Ethernet interface subnet mask: `255.255.255.0` +- USRP-X Series device IPv4 address: `192.168.110.2` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Change the USRP's IP address -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -You may need to change the USRP's IP address for several reasons: +\subsection x3x0_setup_change_ip Change the USRP's IP address -* to satisfy your particular network configuration -* to use multiple USRP-X Series devices on the same host computer -* to set a known IP address into USRP (in case you forgot) +You may need to change the USRP's IP address for several reasons: +- to satisfy your particular network configuration +- to use multiple USRP-X Series devices on the same host computer +- to set a known IP address into USRP (in case you forgot) To change the USRP's IP address, you must know the current address of the USRP, and the network must be setup properly as described above. -You must also know which IP address of the X300 you want to change, as identified by their address EEPROM key (e.g. ``ip-addr0``, see the table above). +You must also know which IP address of the X300 you want to change, as identified by their address EEPROM key (e.g. `ip-addr0`, see the table above). Run the following commands: -**UNIX:** - -:: +\b UNIX: cd <install-path>/lib/uhd/utils ./usrp_burn_mb_eeprom --args=<optional device args> --key=ip-addr0 --val=192.168.10.3 -**Windows:** - -:: +\b Windows: cd <install-path>\lib\uhd\utils usrp_burn_mb_eeprom.exe --args=<optional device args> --key=ip-addr0 --val=192.168.10.3 ---------------------- -Addressing the Device ---------------------- +You must power-cycle the device before you can use this new address. + +\section x3x0_addressing Addressing the Device + +\subsection x3x0_addressing_singledev Single device configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Single device configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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, NI-RIO resource name or by other means. -See the application notes on `device identification <./identification.html>`_. -Use this addressing scheme with the **multi_usrp** interface (not a typo!). - -Example device address string representation for a USRP-X Series device with IPv4 address **192.168.10.2**: +See the application notes on \ref page_identification. +Use this addressing scheme with the uhd::usrp::multi_usrp interface (not a typo!). -:: +Example device address string representation for a USRP-X Series device with IPv4 address 192.168.10.2: addr=192.168.10.2 -Example device address string representation for a USRP-X Series device with RIO resource name **RIO0** over PCI Express: - -:: +Example device address string representation for a USRP-X Series device with RIO resource name `RIO0` over PCI Express: resource=RIO0 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Multiple device configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_addressing_multidevcfg Multiple device configuration + 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. +Each parameter key should be of the format \<key\>\<index\>. +Use this addressing scheme with the uhd::usrp::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. +- 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. Example device address string representation for 2 USRPs with IPv4 addresses **192.168.10.2** and **192.168.20.2**: -:: - addr0=192.168.10.2, addr1=192.168.20.2 ----------------------- -Communication Problems ----------------------- +\section x3x0_comm_problems Communication Problems + When setting up a development machine for the first time, you may have various difficulties communicating with the USRP device. The following tips are designed to help narrow down and diagnose the problem. -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -RuntimeError: no control response -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_comm_problems_runtimeerr 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 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 +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 device. Instructions for setting your IP address are in the previous section of this documentation. -^^^^^^^^^^^^^^^ -Firewall issues -^^^^^^^^^^^^^^^ +\subsection x3x0_comm_problems_firewall Firewall issues + When the IP address is not specified, the device discovery broadcasts UDP packets from each Ethernet interface. Many firewalls will block the replies to these broadcast packets. @@ -528,52 +448,40 @@ 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**. -^^^^^^^^^^^^^^^ -Ping the device -^^^^^^^^^^^^^^^ +\subsection x3x0_comm_problems_ping Ping the device The USRP device will reply to ICMP echo requests ("ping"). A successful ping response means that the device has booted properly and that it is using the expected IP address. -:: - ping 192.168.10.2 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -USRP device not enumerated (Linux) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_comm_problems_not_enumerated USRP device not enumerated (Linux) + UHD requires the RIO device manager service to be running in order to communicate with an X-Series USRP over PCIe. This service is installed as a part of the USRP RIO (or NI-USRP) installer. On Linux, the service is not started at system boot time, and is left to the user to control. To start it, run the following command: -:: - sudo niusrprio_pcie start If the device still does not enumerate after starting the device manager, make sure that the host computer has successfully detected it. You can do so by running the following command: -:: - lspci -k -d 1093:c4c4 A device similar to the following should be detected: -:: - $ lspci -k -d 1093:c4c4 04:00.0 Signal processing controller: National Instruments ... Subsystem: National Instruments Device 76ca Kernel driver in use: niusrpriok_shipped -* A USRP X300 should appear with 'Subsystem: National Instruments Device 7736' -* A USRP X310 should appear with 'Subsystem: National Instruments Device 76ca' +- A USRP X300 should appear with 'Subsystem: National Instruments Device 7736' +- A USRP X310 should appear with 'Subsystem: National Instruments Device 76ca' + +\subsection x3x0_comm_problems_not_enumerated_win USRP device not enumerated (Windows) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -USRP device not enumerated (Windows) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ UHD requires the RIO device manager service to be running in order to communicate with an X-Series USRP over PCIe. This service is installed as a part of the USRP RIO (or NI-USRP) installer. On Windows, it can be found in @@ -584,142 +492,105 @@ status of **niusrpriorpc** is "Running". If the device still does not enumerate after starting the device manager, make sure that the host computer has successfully detected it. You can do so by checking if your device shows up in the Windows Device Manager. -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Monitor the host network traffic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_comm_problems_monitor Monitor the host network traffic Use Wireshark to monitor packets sent to and received from the device. -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Observe Ethernet port LEDs -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_comm_problems_leds Observe Ethernet port LEDs When there is network traffic arriving at the Ethernet port, LEDs will light up. You can use this to make sure the network connection is correctly set up, e.g. by pinging the USRP and making sure the LEDs start to blink. --------------- -Hardware Notes --------------- - -^^^^^^^^^^^ -Front Panel -^^^^^^^^^^^ - -.. image:: ./res/x3x0_fp_overlay.png - :scale: 80% - :align: left - -* **JTAG**: USB connector for the on-board USB-JTAG programmer -* **RF A Group** - - * **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on daughterboard A - * **RX2 LED**: Indicates that data is streaming on the RX2 channel on daughterboard A - -* **REF**: Indicates that the external Reference Clock is locked -* **PPS**: Indicates a valid PPS signal by pulsing once per second -* **AUX I/O**: Front panel GPIO connector. -* **GPS**: Indicates that GPS reference is locked -* **LINK**: Indicates that the host computer is communicating with the device (Activity) - -* **RF B Group** - - * **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on daughterboard B - * **RX2 LED**: Indicates that data is streaming on the RX2 channel on daughterboard B - -* **PWR**: Power switch - -^^^^^^^^^^ -Rear Panel -^^^^^^^^^^ - -.. image:: ./res/x3x0_rp_overlay.png - :scale: 80% - :align: left - - -* **PWR**: Connector for the USRP-X Series power supply -* **1G/10G ETH**: SFP+ ports for Ethernet interfaces -* **REF OUT**: Output port for the exported reference clock -* **REF IN**: Reference clock input -* **PCIe x4**: Connector for Cabled PCI Express link -* **PPS/TRIG OUT**: Output port for the PPS signal -* **PPS/TRIG IN**: Input port for the PPS signal -* **GPS**: Connection for the GPS antenna - -^^^^^^^^^^^^^^^^^^ -Ref Clock - 10 MHz -^^^^^^^^^^^^^^^^^^ +\section x3x0_hw Hardware Notes + +\subsection x3x0_hw_fpanel Front Panel + +\image html x3x0_fp_overlay.png "X3x0" + +- **JTAG**: USB connector for the on-board USB-JTAG programmer +- **RF A Group** + + **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on daughterboard A + + **RX2 LED**: Indicates that data is streaming on the RX2 channel on daughterboard A +- **REF**: Indicates that the external Reference Clock is locked +- **PPS**: Indicates a valid PPS signal by pulsing once per second +- **AUX I/O**: Front panel GPIO connector. +- **GPS**: Indicates that GPS reference is locked +- **LINK**: Indicates that the host computer is communicating with the device (Activity) + +- **RF B Group** + + **TX/RX LED**: Indicates that data is streaming on the TX/RX channel on daughterboard B + + **RX2 LED**: Indicates that data is streaming on the RX2 channel on daughterboard B +- **PWR**: Power switch + +\subsection x3x0_hw_rear_panel Rear Panel + +\image html x3x0_rp_overlay.png "X3x0 Rear Panel" + +- **PWR**: Connector for the USRP-X Series power supply +- **1G/10G ETH**: SFP+ ports for Ethernet interfaces +- **REF OUT**: Output port for the exported reference clock +- **REF IN**: Reference clock input +- **PCIe x4**: Connector for Cabled PCI Express link +- **PPS/TRIG OUT**: Output port for the PPS signal +- **PPS/TRIG IN**: Input port for the PPS signal +- **GPS**: Connection for the GPS antenna + +\subsection x3x0_hw_x3x0_hw_ref10M Ref Clock - 10 MHz + Using an external 10 MHz reference clock, a square wave will offer the best phase noise performance, but a sinusoid is acceptable. The power level of the reference clock cannot exceed +15 dBm. -^^^^^^^^^^^^^^^^^^^^^^ -PPS - Pulse Per Second -^^^^^^^^^^^^^^^^^^^^^^ +\subsection x3x0_hw_pps PPS - Pulse Per Second Using a PPS signal for timestamp synchronization requires a square wave signal with the following a 5Vpp amplitude. To test the PPS input, you can use the following tool from the UHD examples: -* **<args>** are device address arguments (optional if only one USRP device is on your machine) - -:: +- `<args>` are device address arguments (optional if only one USRP device is on your machine) cd <install-path>/lib/uhd/examples - ./test_pps_input --args=<args> - -^^^^^^^^^^^^^^ -Internal GPSDO -^^^^^^^^^^^^^^ -Please see the `Internal GPSDO Application Notes <./gpsdo_x3x0.html>`_ -for information on configuring and using the internal GPSDO. - -^^^^^^^^^^^^^^^^ -Front Panel GPIO -^^^^^^^^^^^^^^^^ - -Connector -::::::::: - -.. image:: ./res/x3x0_gpio_conn.png - :scale: 75% - :align: left - -Pin Mapping -::::::::::: - -* Pin 1: +3.3V -* Pin 2: Data[0] -* Pin 3: Data[1] -* Pin 4: Data[2] -* Pin 5: Data[3] -* Pin 6: Data[4] -* Pin 7: Data[5] -* Pin 8: Data[6] -* Pin 9: Data[7] -* Pin 10: Data[8] -* Pin 11: Data[9] -* Pin 12: Data[10] -* Pin 13: Data[11] -* Pin 14: 0V -* Pin 15: 0V - - -Please see the `GPIO API Notes <./gpio_api.html>`_ for information on configuring and using the GPIO bus. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Debugging custom FPGA designs with Xilinx Chipscope -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ./test_pps_input --args=\<args\> + +\subsection x3x0_hw_gpsdo Internal GPSDO + +Please see \ref page_gpsdo_x3x0 for information on configuring and using the internal GPSDO. + +\subsection x3x0_hw_gpio Front Panel GPIO + +### Connector + +\image html x3x0_gpio_conn.png "X3x0 GPIO Connector" + +### Pin Mapping + +- Pin 1: +3.3V +- Pin 2: Data[0] +- Pin 3: Data[1] +- Pin 4: Data[2] +- Pin 5: Data[3] +- Pin 6: Data[4] +- Pin 7: Data[5] +- Pin 8: Data[6] +- Pin 9: Data[7] +- Pin 10: Data[8] +- Pin 11: Data[9] +- Pin 12: Data[10] +- Pin 13: Data[11] +- Pin 14: 0V +- Pin 15: 0V + + +Please see the \ref page_gpio_api for information on configuring and using the GPIO bus. + +\subsection x3x0_hw_chipscope Debugging custom FPGA designs with Xilinx Chipscope Xilinx chipscope allows for debugging custom FPGA designs similar to a logic analyzer. USRP-X series devices can be used with Xilinx chipscope using the onboard USB JTAG connector. Further information on how to use Chipscope can be found in the Xilinx Chipscope Pro Software and Cores User Guide (UG029). -------------- -Miscellaneous -------------- +\section x3x0_misc Miscellaneous + +\subsection x3x0_misc_multirx Multiple RX channels -^^^^^^^^^^^^^^^^^^^^ -Multiple RX channels -^^^^^^^^^^^^^^^^^^^^ There are two complete DDC and DUC DSP 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** or **TX** subdevice specification. @@ -728,16 +599,17 @@ In the following example, a TVRX2 is installed. Channel 0 is sourced from subdevice **RX1**, and channel 1 is sourced from subdevice **RX2** (**RX1** and **RX2** are antenna connectors on the TVRX2 daughterboard). -:: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +usrp->set_rx_subdev_spec("A:RX1 A:RX2"); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - usrp->set_rx_subdev_spec("A:RX1 A:RX2"); +\subsection x3x0_misc_sensors Available Sensors - -^^^^^^^^^^^^^^^^^ -Available Sensors -^^^^^^^^^^^^^^^^^ The following sensors are available for the USRP-X Series motherboards; they can be queried through the API. -* **ref_locked** - clock reference locked (internal/external) -* Other sensors are added when the GPSDO is enabled +- **ref_locked** - clock reference locked (internal/external) +- Other sensors are added when the GPSDO is enabled + +*/ +// vim:ft=doxygen: diff --git a/host/docs/usrp_x3x0_config.dox b/host/docs/usrp_x3x0_config.dox new file mode 100644 index 000000000..209d22210 --- /dev/null +++ b/host/docs/usrp_x3x0_config.dox @@ -0,0 +1,267 @@ +/*! \page page_usrp_x3x0_config System Configuration for USRP X3x0 Series + +\tableofcontents + +\section x3x0cfg_hostpc Configuring your Host PC + +The USRP X3x0 is capable of delivering very fast sample rates to the +host PC, and even high-powered desktops can have trouble keeping up at +the higher rates. You can improve the performance of your host by +configuring a number of settings that affect the performance of your +computer. + +These are: + +- Kernel Version +- Network Configuration +- Power Management Configuration +- Real-Time & Priority Scheduling +- Building with ORC & Volk + +These items are covered in more detail, below. + +\subsection x3x0cfg_hostpc_kernel Kernel Version + +Performance issues may be encountered with Linux kernels earlier than +3.11. Ettus Research strongly recommends using kernel version 3.11 or +higher for high sample rates. + +\subsection x3x0cfg_hostpc_netcfg Network Configuration + +When using Ethernet interfaces to communicate with the device, it is +necessary to configure a number of facets regarding your network +connection. + +\subsubsection x3x0cfg_hostpc_netcfg_nwmgr Configuring NetworkManager + +Fedora and Ubuntu both use NetworkManager to manage network connections. +Unfortunately, NetworkManager often tries to take control of a +connection and will disconnect the interface. + +You should open your NetworkManager configuration and tell it to ignore +the network interface you are using. **This is not the same as simply +setting a static IP address.** You *must* tell NetworkManager to ignore +the interface. + +\subsubsection x3x0cfg_hostpc_netcfg_sockbuff Configuring the Socket Buffers + +It is necessary to increase the maximum size of the socket buffers to +avoid potential overflows and underruns at high sample rates. Add the +following entries into /etc/sysctl.conf (root privileges required): + + net.core.rmem_max=33554432 + net.core.wmem_max=33554432 + +Either restart the system or issue the following commands: + + sudo sysctl -w net.core.rmem_max=33554432 + sudo sysctl -w net.core.wmem_max=33554432 + +\subsubsection x3x0cfg_hostpc_netcfg_mtu Configuring the MTU + +In order to achieve maximum performance, we recommend setting the MTU +size to 9000 for 10 GigE and 1500 for 1 GigE. It is possible to use +smaller MTUs, but this can affect performance. With some NICs, setting +the MTU too high can also cause issues. To set the MTU to 9000, you can +use the following command: + + sudo ifconfig <interface> mtu 9000 # For 10 GigE + sudo ifconfig <interface> mtu 1500 # For 1 GigE + +Using these MTUs will set the frame sizes for UHD communication to 8000 +and 1472, respectively. + +In some cases, specifying the frame size manually by adding the argument +`<send/recv>_frame_size=1472` can solve issues. Note that a frame +size of 1472 will limit the available sampling rate, although this is +not a problem on 1 GigE. + +\subsubsection x3x0cfg_hostpc_netcfg_firewall Configuring the Firewall + +Many Linux distributions come installed with a Firewall, by default. The +Firewall will often interfere with your ability to communicate with your +USRP. You should configure your firewall to "trust" the interface you +are using. Setting this properly depends on your OS and firewall +configuration method. + +\subsubsection x3x0cfg_hostpc_netcfg_if Interface Configuration File (Fedora) + +On Fedora systems, you can configure the network interface mostly from +one place (with the exception of the socket buffers). Each interface on +your system should have a file in: + + /etc/sysconfig/network-scripts/ + +As an example, if your 1GigE interface is "em1", your "ifcfg-em1" +configuration file should look something like this, when configured for +use with a USRP X3xx: + + TYPE="Ethernet" + BOOTPROTO="none" + IPADDR0="192.168.10.1" + DEFROUTE="yes" + IPV4_FAILURE_FATAL="no" + IPV6INIT="no" + IPV6_FAILURE_FATAL="no" + NAME="em1" + UUID="<specific to your device>" + ONBOOT="no" + HWADDR"<specific to your device>" + PEERDNS="yes" + PEERROUTES="yes" + ZONE="trusted" + MTU="9000" + NM_MANAGED="no" + +The above file was generated and modified on a Fedora 20 system. + +\subsection x3x0cfg_hostpc_pwr Power Management + +Power management on the host system attempts to save power by reducing +clock frequencies or even powering off devices while not in use. This +can lead to significant performance issues when trying to operate at +high sample rates. Ettus Research strongly recommends disabling all +power management. + +\subsubsection x3x0cfg_hostpc_pwr_cpugov Setting the CPU Governors + +In Linux, the CPU governors dictate the frequency at which the CPU +operates and attempt to reduce the CPU frequencies at certain times to +save power. When running at high sample rates, reduction of CPU +frequencies can cause significant performance issues. To prevent those +issues, set the governor to "performance". + +**Ubuntu:** 1. Install cpufrequtils: + + sudo apt-get install cpufrequtils + +2. Edit `/etc/init.d/cpufrequtils` and set `GOVERNOR="performance"` on the + appropriate line (run as root): + + sed s/^GOVERNOR=.*$/GOVERNOR=\"performance\"/g /etc/init.d/cpufrequtils > /etc/init.d/cpufrequtils + +3. Restart cpufrequtils: + + sudo /etc/init.d/cpufrequtils restart + +\b Fedora: + + sudo cpupower frequency-set -g performance + +\subsection x3x0cfg_hostpc_rtprio Real-Time & Priority Scheduling + +Enabling real-time and priority scheduling can improve the total +processing throughput of your application. Priority scheduling should be +enabled for UHD, and real-time scheduling can be enabled by your +application. + +\subsubsection x3x0cfg_hostpc_rtprio_thread Thread Priority Scheduling with UHD + +For information regarding how to enable priority scheduling for UHD on +your system, please see \ref page_general. + +\subsubsection x3x0cfg_hostpc_rtprio_app Real-Time Scheduling in your Application + +Please note that turning on real-time scheduling in your application +**may lock up your computer** if the processor cannot keep up with the +application. You should generally avoid using real-time scheduling +unless you need to. + +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 + +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 + +\subsubsection x3x0cfg_hostpc_volk_volk Compiling GNURadio with Volk + +If you are using GNURadio to build applications, you should compile +GNURadio with Volk. For instructions on how to do this, +<a href="http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk">refer to the GNURadio wiki</a>. + +\section x3x0cfg_hosthw Host PC Hardware Selection + +\subsection x3x0cfg_hosthw_mb Motherboard + +Testing has shown that some motherboards do not provide enough PCIe bus +bandwidth to support higher sample rates. Motherboards with PCIe 3.0 are +required and the PCIe architecture of the motherboard should be +carefully considered. Slots with dedicated PCIe lanes should be used for +PCIe or 10GbE cards that will be connected to the X3x0 device. + +\subsection x3x0cfg_hosthw_10gige 10GbE NIC + +Intel or Myricom 10GbE NICs are recommended. Mellanox, SolarFlare, and +Chelsio 10GbE NICs are not currently recommended. The Ethernet card +should be plugged into the slot that has the most direct connection with +the CPU (PCIe lanes are not shared with another slot). Refer to the +motherboard manual for more information on PCIe architecture. + +\section x3x0cfg_hosthw_troubleshooting Troubleshooting Performance Issues + +The output on the host console provides indicators of performance issues +in the form of single upper-case letters. The following table lists the +letters, their meanings, and possible causes: + + Indicator |Meaning | Possible Causes + -----------|----------------------|--------------------------------------------------------------------------------- + O |Overflow on RX |- Data is not being consumed by user's application fast enough. + | |- CPU governor or other power management not configured correctly. + D |Dropped packet on RX |- Network hardware failure. (Check host NIC, cable, switch, etc...) + | |- PCIe bus on host cannot sustain throughput. (Check ethtool -S \<interface\>). + | |- CPU governor or other power management not configured correctly. + | |- Frame size might not work with the current NIC's MTU. + U |Underflow on TX |- Samples are not being produced by user's application fast enough. + | |- CPU governor or other power management not configured correctly. + L |Late packet |- Samples are not being produced by user's application fast enough. + |(usually on MIMO TX) |- CPU governor or other power management not configured correctly. + | |- Incorrect/invalid time_spec provided. + S |Sequence error on TX |- Network hardware failure. (Check host NIC, cable, switch, etc...) + | |- Frame size might not work with the current NIC's MTU. + +\subsection x3x0cfg_hosthw_troubleshooting_eth Troubleshooting Ethernet Issues + +1. First, check `ifconfig <interface>` to see if there are any errors + reported on the interface. If there are errors, it is most likely a + network hardware problem. +2. Next, check the output of `ethtool -S <interface>`. The output is + driver-specific, but may give important clues as to what may be + happening. For example, a high value on rx_missed_errors for an + Intel NIC indicates that the bus (i.e. PCIe) is not keeping up. +3. Finally, Wireshark can be used to validate the traffic between the + host and device and make sure there is no unwanted traffic on the + interface. + +*/ +// vim:ft=doxygen: diff --git a/host/docs/usrp_x3x0_config.rst b/host/docs/usrp_x3x0_config.rst deleted file mode 100644 index 4be247b04..000000000 --- a/host/docs/usrp_x3x0_config.rst +++ /dev/null @@ -1,319 +0,0 @@ -======================================================================== -UHD - System Configuration for USRP X3x0 Series -======================================================================== - -.. contents:: Table of Contents - ------------------------------------------------------------------------- -Configuring your Host PC ------------------------------------------------------------------------- - -The USRP X3x0 is capable of delivering very fast sample rates to the host PC, -and even high-powered desktops can have trouble keeping up at the higher rates. -You can improve the performance of your host by configuring a number of -settings that affect the performance of your computer. - -These are: - - * Kernel Version - * Network Configuration - * Power Management Configuration - * Real-Time & Priority Scheduling - * Building with ORC & Volk - -These items are covered in more detail, below. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Kernel Version -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Performance issues may be encountered with Linux kernels earlier than 3.11. -Ettus Research strongly recommends using kernel version 3.11 or higher for high -sample rates. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Network Configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -When using Ethernet interfaces to communicate with the device, it is necessary -to configure a number of facets regarding your network connection. - -Configuring NetworkManager -------------------------------------- -Fedora and Ubuntu both use NetworkManager to manage network connections. -Unfortunately, NetworkManager often tries to take control of a connection and -will disconnect the interface. - -You should open your NetworkManager configuration and tell it to ignore the -network interface you are using. **This is not the same as simply setting -a static IP address.** You *must* tell NetworkManager to ignore the interface. - -Changing the host's IP address -------------------------------------- - -On a Linux system, you can add a static IP address very easily by using the -'ip' command: - -:: - - sudo ip addr add 192.168.10.1/24 dev <interface> - -Note that **<interface>** is usually something like **eth0**. You can discover the -names of the network interfaces in your computer by running: - -:: - - ip addr show - -Configuring the Socket Buffers -------------------------------------- -It is necessary to increase the maximum size of the socket buffers to avoid -potential overflows and underruns at high sample rates. Add the following -entries into /etc/sysctl.conf (root privileges required): - -:: - - net.core.rmem_max=33554432 - net.core.wmem_max=33554432 - -Either restart the system or issue the following commands: - -:: - - sudo sysctl -w net.core.rmem_max=33554432 - sudo sysctl -w net.core.wmem_max=33554432 - - -Configuring the MTU -------------------------------------- -In order to achieve maximum performance, we recommend setting the MTU size to -9000 for 10 GigE and 1500 for 1 GigE. It is possible to use smaller MTUs, but this -can affect performance. With some NICs, setting the MTU too high can also cause issues. -To set the MTU to 9000, you can use the following command: - -:: - - sudo ifconfig <interface> mtu 9000 # For 10 GigE - sudo ifconfig <interface> mtu 1500 # For 1 GigE - -Using these MTUs will set the frame sizes for UHD communication to 8000 and 1472, -respectively. - -In some cases, specifying the frame size manually by adding the argument -"<send/recv>_frame_size=1472" can solve issues. Note that a frame size of 1472 will limit -the available sampling rate, although this is not a problem on 1 GigE. - - -Configuring the Firewall -------------------------------------- -Many Linux distributions come installed with a Firewall, by default. The -Firewall will often interfere with your ability to communicate with your USRP. -You should configure your firewall to "trust" the interface you are using. -Setting this properly depends on your OS and firewall configuration method. - -When using UHD software, if an IP address for the USRP-X Series device is not specified, -the software will use UDP broadcast packets to locate the USRP-X Series device. -On some systems, the firewall will block UDP broadcast packets. -It is therefore recommended that you change or disable your firewall settings. - -Interface Configuration File (Fedora) -------------------------------------- -On Fedora systems, you can configure the network interface mostly from one -place (with the exception of the socket buffers). Each interface on your system -should have a file in: - -:: - - /etc/sysconfig/network-scripts/ - -As an example, if your 1GigE interface is "em1", your "ifcfg-em1" configuration -file should look something like this, when configured for use with a USRP X3xx: - -:: - - TYPE="Ethernet" - BOOTPROTO="none" - IPADDR0="192.168.10.1" - DEFROUTE="yes" - IPV4_FAILURE_FATAL="no" - IPV6INIT="no" - IPV6_FAILURE_FATAL="no" - NAME="em1" - UUID="<specific to your device>" - ONBOOT="no" - HWADDR"<specific to your device>" - PEERDNS="yes" - PEERROUTES="yes" - ZONE="trusted" - MTU="9000" - NM_MANAGED="no" - -The above file was generated and modified on a "Fedora 20" system. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Power Management -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Power management on the host system attempts to save power by reducing clock -frequencies or even powering off devices while not in use. This can lead to -significant performance issues when trying to operate at high sample rates. -Ettus Research strongly recommends disabling all power management. - - -Setting the CPU Governors -------------------------------------- -In Linux, the CPU governors dictate the frequency at which the CPU operates and -attempt to reduce the CPU frequencies at certain times to save power. When -running at high sample rates, reduction of CPU frequencies can cause -significant performance issues. To prevent those issues, set the governor to -"performance". - -**Ubuntu:** -1. Install cpufrequtils: - -:: - - sudo apt-get install cpufrequtils - -2. Edit /etc/init.d/cpufrequtils and set GOVERNOR="performance" on the appropriate line (run as root): - -:: - - sed s/^GOVERNOR=.*$/GOVERNOR=\"performance\"/g /etc/init.d/cpufrequtils > /etc/init.d/cpufrequtils - -3. Restart cpufrequtils: - -:: - - sudo /etc/init.d/cpufrequtils restart - -**Fedora:** - -:: - - sudo cpupower frequency-set -g performance - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Real-Time & Priority Scheduling -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Enabling real-time and priority scheduling can improve the total processing -throughput of your application. Priority scheduling should be enabled for UHD, -and real-time scheduling can be enabled by your application. - -Thread Priority Scheduling with UHD -------------------------------------- -For information regarding how to enable priority scheduling for UHD on your -system, please see the `General UHD Notes <./general.html#threading-notes>`_. - -Real-Time Scheduling in your Application ----------------------------------------- -Please note that turning on real-time scheduling in your application **may lock -up your computer** if the processor cannot keep up with the application. You -should generally avoid using real-time scheduling unless you need to. - -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. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Building with ORC & Volk -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -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. - -Compiling UHD with ORC -------------------------------------- -ORC, the `Oil Runtime Compiler <http://code.entropywave.com/orc/>`_, 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 - -Compiling GNURadio with Volk -------------------------------------- -If you are using GNURadio to build applications, you should compile GNURadio -with Volk. For instructions on how to do this, `refer to the GNURadio wiki -<http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk>`_. - - ------------------------------------------------------------------------- -Host PC Hardware Selection ------------------------------------------------------------------------- -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Motherboard -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Testing has shown that some motherboards do not provide enough PCIe bus -bandwidth to support higher sample rates. Motherboards with PCIe 3.0 are -required and the PCIe architecture of the motherboard should be carefully -considered. Slots with dedicated PCIe lanes should be used for PCIe or 10GbE -cards that will be connected to the X3x0 device. - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -10GbE NIC -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Intel or Myricom 10GbE NICs are recommended. Mellanox, SolarFlare, and Chelsio -10GbE NICs are not currently recommended. The Ethernet card should be plugged -into the slot that has the most direct connection with the CPU (PCIe lanes are -not shared with another slot). Refer to the motherboard manual for more -information on PCIe architecture. - ------------------------------------------------------------------------- -Troubleshooting Performance Issues ------------------------------------------------------------------------- -The output on the host console provides indicators of performance issues in the -form of single upper-case letters. The following table lists the letters, -their meanings, and possible causes: - -========= ====================== ==================================================================== -Indicator Meaning Possible Causes -========= ====================== ==================================================================== -O Overflow on RX - Data is not being consumed by user's application fast enough. - - CPU governor or other power management not configured correctly. -D Dropped packet on RX - Network hardware failure. (Check host NIC, cable, switch, etc...) - - PCIe bus on host cannot sustain throughput. (Check ethtool -S <interface>). - - CPU governor or other power management not configured correctly. - - Frame size might not work with the current NIC's MTU. -U Underflow on TX - Samples are not being produced by user's application fast enough. - - CPU governor or other power management not configured correctly. -L Late packet - Samples are not being produced by user's application fast enough. - (usually on MIMO TX) - CPU governor or other power management not configured correctly. - - Incorrect/invalid time_spec provided. -S Sequence error on TX - Network hardware failure. (Check host NIC, cable, switch, etc...) - - Frame size might not work with the current NIC's MTU. -========= ====================== ==================================================================== - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Troubleshooting Ethernet Issues -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -1. First, check 'ifconfig <interface>' to see if there are any errors reported - on the interface. If there are errors, it is most likely a network hardware - problem. -2. Next, check the output of 'ethtool -S <interface>'. The output is - driver-specific, but may give important clues as to what may be happening. - For example, a high value on rx_missed_errors for an Intel NIC indicates - that the bus (i.e. PCIe) is not keeping up. -3. Finally, Wireshark can be used to validate the traffic between the host and - device and make sure there is no unwanted traffic on the interface. - |
