diff options
Diffstat (limited to 'host/docs')
| -rw-r--r-- | host/docs/CMakeLists.txt | 108 | ||||
| -rw-r--r-- | host/docs/Doxyfile.in | 1514 | ||||
| -rw-r--r-- | host/docs/build.rst | 220 | ||||
| -rw-r--r-- | host/docs/calibration.rst | 61 | ||||
| -rw-r--r-- | host/docs/coding.rst | 30 | ||||
| -rw-r--r-- | host/docs/dboards.rst | 381 | ||||
| -rw-r--r-- | host/docs/general.rst | 224 | ||||
| -rw-r--r-- | host/docs/gpsdo.rst | 80 | ||||
| -rw-r--r-- | host/docs/identification.rst | 125 | ||||
| -rw-r--r-- | host/docs/images.rst | 93 | ||||
| -rw-r--r-- | host/docs/index.rst | 41 | ||||
| -rw-r--r-- | host/docs/stream.rst | 59 | ||||
| -rw-r--r-- | host/docs/style.css | 102 | ||||
| -rw-r--r-- | host/docs/sync.rst | 164 | ||||
| -rw-r--r-- | host/docs/transport.rst | 153 | ||||
| -rw-r--r-- | host/docs/usrp1.rst | 92 | ||||
| -rw-r--r-- | host/docs/usrp2.rst | 398 | ||||
| -rw-r--r-- | host/docs/usrp_b1xx.rst | 87 | ||||
| -rw-r--r-- | host/docs/usrp_e1xx.rst | 136 |
19 files changed, 4068 insertions, 0 deletions
diff --git a/host/docs/CMakeLists.txt b/host/docs/CMakeLists.txt new file mode 100644 index 000000000..e393a79f0 --- /dev/null +++ b/host/docs/CMakeLists.txt @@ -0,0 +1,108 @@ +# +# Copyright 2010-2011 Ettus Research LLC +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. +# + +######################################################################## +# List of manual sources +######################################################################## +SET(manual_sources + index.rst + identification.rst + build.rst + calibration.rst + coding.rst + dboards.rst + gpsdo.rst + general.rst + images.rst + stream.rst + sync.rst + transport.rst + usrp1.rst + usrp2.rst + usrp_b1xx.rst + usrp_e1xx.rst +) + +######################################################################## +# Setup Manual +######################################################################## +MESSAGE(STATUS "") +FIND_PACKAGE(Docutils) + +LIBUHD_REGISTER_COMPONENT("Manual" ENABLE_MANUAL ON "DOCUTILS_FOUND" OFF) + +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}) + 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}) +ENDIF(ENABLE_MANUAL) + +INSTALL(FILES ${manual_sources} DESTINATION ${PKG_DOC_DIR}/manual/rst COMPONENT manual) + +######################################################################## +# Setup Doxygen +######################################################################## +MESSAGE(STATUS "") +FIND_PACKAGE(Doxygen) + +LIBUHD_REGISTER_COMPONENT("Doxygen" ENABLE_DOXYGEN ON "DOXYGEN_FOUND" OFF) + +IF(ENABLE_DOXYGEN) + #generate the doxygen configuration file + SET(CMAKE_CURRENT_BINARY_DIR_DOXYGEN ${CMAKE_CURRENT_BINARY_DIR}/doxygen) + CONFIGURE_FILE( + ${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in + ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile + @ONLY) + + #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} + COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile + COMMENT "Generating documentation with doxygen" + ) + + #make the doxygen generation a built-time dependency + ADD_CUSTOM_TARGET(doxygen_docs ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR_DOXYGEN}) + INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR_DOXYGEN} DESTINATION ${PKG_DOC_DIR} COMPONENT doxygen) +ENDIF(ENABLE_DOXYGEN) diff --git a/host/docs/Doxyfile.in b/host/docs/Doxyfile.in new file mode 100644 index 000000000..7395516b5 --- /dev/null +++ b/host/docs/Doxyfile.in @@ -0,0 +1,1514 @@ +# Doxyfile 1.6.1 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project +# +# 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 (" ") + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# This tag specifies the encoding used for all characters in the config file +# that follow. The default is UTF-8 which is also the encoding used for all +# text before the first occurrence of this tag. Doxygen uses libiconv (or the +# iconv built into libc) for the transcoding. See +# http://www.gnu.org/software/libiconv for the list of possible encodings. + +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. + +PROJECT_NAME = @CPACK_PACKAGE_NAME@ + +# 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@ + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) +# base path where the generated documentation will be put. +# If a relative path is entered, it will be relative to the location +# where doxygen was started. If left blank the current directory will be used. + +OUTPUT_DIRECTORY = @CMAKE_CURRENT_BINARY_DIR_DOXYGEN@ + +# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create +# 4096 sub-directories (in 2 levels) under the output directory of each output +# format and will distribute the generated files over these directories. +# Enabling this option can be useful when feeding doxygen a huge amount of +# source files, where putting all generated files in the same directory would +# otherwise cause performance problems for the file system. + +CREATE_SUBDIRS = NO + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# The default language is English, other supported languages are: +# 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. + +OUTPUT_LANGUAGE = English + +# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will +# include brief member descriptions after the members that are listed in +# the file and class documentation (similar to JavaDoc). +# Set to NO to disable this. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend +# the brief description of a member or function before the detailed description. +# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator +# that is used to form the text in various listings. Each string +# in this list, if found as the leading text of the brief description, will be +# stripped from the text and the result after processing the whole list, is +# used as the annotated text. Otherwise, the brief description is used as-is. +# If left blank, the following values are used ("$name" is automatically +# replaced with the name of the entity): "The $name class" "The $name widget" +# "The $name file" "is" "provides" "specifies" "contains" +# "represents" "a" "an" "the" + +ABBREVIATE_BRIEF = + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# Doxygen will generate a detailed section even if there is only a brief +# description. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all +# inherited members of a class in the documentation of that class as if those +# members were ordinary class members. Constructors, destructors and assignment +# operators of the base classes will not be shown. + +INLINE_INHERITED_MEMB = NO + +# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full +# path before files name in the file list and in the header files. If set +# to NO the shortest path that makes the file name unique will be used. + +FULL_PATH_NAMES = YES + +# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag +# can be used to strip a user-defined part of the path. Stripping is +# 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. + +STRIP_FROM_PATH = @CMAKE_SOURCE_DIR@ + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of +# the path mentioned in the documentation of a class, which tells +# the reader which header file to include in order to use a class. +# If left blank only the name of the header file containing the class +# definition is used. Otherwise one should specify the include paths that +# are normally passed to the compiler using the -I flag. + +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 +# doesn't support long names like on DOS, Mac, or CD-ROM. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen +# will interpret the first line (until the first dot) of a JavaDoc-style +# comment as the brief description. If set to NO, the JavaDoc +# comments will behave just like regular Qt-style comments +# (thus requiring an explicit @brief command for a brief description.) + +JAVADOC_AUTOBRIEF = NO + +# If the QT_AUTOBRIEF tag is set to YES then Doxygen will +# interpret the first line (until the first dot) of a Qt-style +# comment as the brief description. If set to NO, the comments +# will behave just like regular Qt-style comments (thus requiring +# an explicit \brief command for a brief description.) + +QT_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen +# treat a multi-line C++ special comment block (i.e. a block of //! or /// +# comments) as a brief description. This used to be the default behaviour. +# The new default is to treat a multi-line C++ comment block as a detailed +# description. Set this tag to YES if you prefer the old behaviour instead. + +MULTILINE_CPP_IS_BRIEF = NO + +# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented +# member inherits the documentation from any documented member that it +# re-implements. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce +# a new page for each member. If set to NO, the documentation of a member will +# be part of the file/class/namespace that contains it. + +SEPARATE_MEMBER_PAGES = NO + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. +# Doxygen uses this value to replace tabs by spaces in code fragments. + +TAB_SIZE = 8 + +# This tag can be used to specify a number of aliases that acts +# as commands in the documentation. An alias has the form "name=value". +# For example adding "sideeffect=\par Side Effects:\n" will allow you to +# put the command \sideeffect (or @sideeffect) in the documentation, which +# will result in a user-defined paragraph with heading "Side Effects:". +# You can put \n's in the value part of an alias to insert newlines. + +ALIASES = + +# 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 +# of all members will be omitted, etc. + +OPTIMIZE_OUTPUT_FOR_C = NO + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java +# sources only. Doxygen will then generate output that is more tailored for +# Java. For instance, namespaces will be presented as packages, qualified +# scopes will look different, etc. + +OPTIMIZE_OUTPUT_JAVA = NO + +# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran +# sources only. Doxygen will then generate output that is more tailored for +# Fortran. + +OPTIMIZE_FOR_FORTRAN = NO + +# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL +# sources. Doxygen will then generate output that is tailored for +# VHDL. + +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. + +EXTENSION_MAPPING = + +# 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 +# diagrams that involve STL classes more complete and accurate. + +BUILTIN_STL_SUPPORT = YES + +# If you use Microsoft's C++/CLI language, you should set this option to YES to +# enable parsing support. + +CPP_CLI_SUPPORT = NO + +# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only. +# Doxygen will parse them like normal C++ but will assume all classes use public +# instead of private inheritance when no explicit protection keyword is present. + +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 +# 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. + +IDL_PROPERTY_SUPPORT = YES + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES, then doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. + +DISTRIBUTE_GROUP_DOC = NO + +# Set the SUBGROUPING tag to YES (the default) to allow class member groups of +# the same type (for instance a group of public functions) to be put as a +# subgroup of that type (e.g. under the Public Functions section). Set it to +# NO to prevent subgrouping. Alternatively, this can be done per class using +# the \nosubgrouping command. + +SUBGROUPING = YES + +# 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 +# with name TypeT. When disabled the typedef will appear as a member of a file, +# namespace, or class. And the struct will be named TypeS. This can typically +# be useful for C code in case the coding convention dictates that all compound +# types are typedef'ed and only the typedef is referenced, never the tag name. + +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 + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# 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 + +EXTRACT_ALL = YES + +# If the EXTRACT_PRIVATE tag is set to YES all private members of a class +# will be included in the documentation. + +EXTRACT_PRIVATE = NO + +# If the EXTRACT_STATIC tag is set to YES all static members of a file +# will be included in the documentation. + +EXTRACT_STATIC = NO + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) +# defined locally in source files will be included in the documentation. +# If set to NO only classes defined in header files are included. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. When set to YES local +# methods, which are defined in the implementation section but not in +# the interface are included in the documentation. +# If set to NO (the default) only methods in the interface are included. + +EXTRACT_LOCAL_METHODS = NO + +# If this flag is set to YES, the members of anonymous namespaces will be +# 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. + +EXTRACT_ANON_NSPACES = NO + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all +# undocumented members of documented classes, files or namespaces. +# If set to NO (the default) these members will be included in the +# various overviews, but no documentation section is generated. +# This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. +# If set to NO (the default) these classes will be included in the various +# overviews. This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all +# friend (class|struct|union) declarations. +# If set to NO (the default) these declarations will be included in the +# documentation. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any +# documentation blocks found inside the body of a function. +# If set to NO (the default) these blocks will be appended to the +# function's detailed documentation block. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation +# that is typed after a \internal command is included. If the tag is set +# to NO (the default) then the documentation will be excluded. +# Set it to YES to include the internal documentation. + +INTERNAL_DOCS = NO + +# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate +# file names in lower-case letters. If set to YES upper-case letters are also +# allowed. This is useful if you have classes or files whose names only differ +# in case and if your file system supports case sensitive file names. Windows +# and Mac users are advised to set this option to NO. + +CASE_SENSE_NAMES = YES + +# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen +# will show members with their full class and namespace scopes in the +# documentation. If set to YES the scope will be hidden. + +HIDE_SCOPE_NAMES = NO + +# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen +# will put a list of the files that are included by a file in the documentation +# of that file. + +SHOW_INCLUDE_FILES = YES + +# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] +# is inserted in the documentation for inline members. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen +# will sort the (detailed) documentation of file and class members +# alphabetically by member name. If set to NO the members will appear in +# declaration order. + +SORT_MEMBER_DOCS = YES + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the +# brief documentation of file, namespace and class members alphabetically +# by member name. If set to NO (the default) the members will appear in +# declaration order. + +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. + +SORT_MEMBERS_CTORS_1ST = NO + +# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the +# hierarchy of group names into alphabetical order. If set to NO (the default) +# the group names will appear in their defined order. + +SORT_GROUP_NAMES = NO + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be +# sorted by fully-qualified names, including namespaces. If set to +# NO (the default), the class list will be sorted only by class name, +# not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the +# alphabetical list. + +SORT_BY_SCOPE_NAME = 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. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or +# disable (NO) the test list. This list is created by putting \test +# commands in the documentation. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or +# disable (NO) the bug list. This list is created by putting \bug +# commands in the documentation. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or +# disable (NO) the deprecated list. This list is created by putting +# \deprecated commands in the documentation. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional +# documentation sections, marked by \if sectionname ... \endif. + +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 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 +# documentation can be controlled using \showinitializer or \hideinitializer +# command in the documentation regardless of this setting. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated +# at the bottom of the documentation of classes and structs. If set to YES the +# list will mention the files that were used to generate the documentation. + +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. + +SHOW_FILES = YES + +# Set the SHOW_NAMESPACES tag to NO to disable the generation of the +# Namespaces page. +# This will remove the Namespaces entry from the Quick Index +# and from the Folder Tree View (if specified). The default is YES. + +SHOW_NAMESPACES = YES + +# The FILE_VERSION_FILTER tag can be used to specify a program or script that +# doxygen should invoke to get the current version for each file (typically from +# the version control system). Doxygen will invoke the program by executing (via +# popen()) the command <command> <input-file>, where <command> is the value of +# the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file +# provided by doxygen. Whatever the program writes to standard output +# is used as the file version. See the manual for examples. + +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. + +LAYOUT_FILE = + +#--------------------------------------------------------------------------- +# configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated +# by doxygen. Possible values are YES and NO. If left blank NO is used. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated by doxygen. Possible values are YES and NO. If left blank +# NO is used. + +WARNINGS = YES + +# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings +# for undocumented members. If EXTRACT_ALL is set to YES then this flag will +# automatically be disabled. + +WARN_IF_UNDOCUMENTED = YES + +# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as not documenting some +# parameters in a documented function, or documenting parameters that +# don't exist or using markup commands wrongly. + +WARN_IF_DOC_ERROR = YES + +# This WARN_NO_PARAMDOC option can be abled 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 +# documentation. + +WARN_NO_PARAMDOC = NO + +# The WARN_FORMAT tag determines the format of the warning messages that +# doxygen can produce. The string should contain the $file, $line, and $text +# tags, which will be replaced by the file and line number from which the +# warning originated and the warning text. Optionally the format may contain +# $version, which will be replaced by the version of the file (if it could +# be obtained via FILE_VERSION_FILTER) + +WARN_FORMAT = "$file:$line: $text" + +# The WARN_LOGFILE tag can be used to specify a file to which warning +# and error messages should be written. If left blank the output is written +# to stderr. + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag can be used to specify the files and/or directories that contain +# documented source files. You may enter file names like "myfile.cpp" or +# directories like "/usr/src/myproject". Separate the files or directories +# with spaces. + +INPUT = @CMAKE_SOURCE_DIR@/include + +# 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 +# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for +# the list of possible encodings. + +INPUT_ENCODING = UTF-8 + +# If the value of the INPUT tag contains directories, you can use the +# 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 + +FILE_PATTERNS = *.hpp + +# 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. +# If left blank NO is used. + +RECURSIVE = YES + +# The EXCLUDE tag can be used to specify files and/or directories that should +# 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. + +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 +# from the input. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. Note that the wildcards are matched +# against the file with absolute path, so to exclude all test directories +# for example use the pattern */test/* + +EXCLUDE_PATTERNS = + +# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names +# (namespaces, classes, functions, etc.) that should be excluded from the +# output. The symbol name can be a fully qualified name, a word, or if the +# wildcard * is used, a substring. Examples: ANamespace, AClass, +# AClass::ANamespace, ANamespace::*Test + +EXCLUDE_SYMBOLS = + +# The EXAMPLE_PATH tag can be used to specify one or more files or +# directories that contain example code fragments that are included (see +# the \include command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_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 all files are included. + +EXAMPLE_PATTERNS = + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude +# commands irrespective of the value of the RECURSIVE tag. +# Possible values are YES and NO. If left blank NO is used. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or +# directories that contain image that are included in the documentation (see +# the \image command). + +IMAGE_PATH = + +# 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 +# by executing (via popen()) the command <filter> <input-file>, where <filter> +# 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. + +INPUT_FILTER = + +# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern +# basis. +# Doxygen will compare the file name with each pattern and apply the +# 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. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will be used to filter the input files when producing source +# files to browse (i.e. when SOURCE_BROWSER is set to YES). + +FILTER_SOURCE_FILES = NO + +#--------------------------------------------------------------------------- +# configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will +# be generated. Documented entities will be cross-referenced with these sources. +# Note: To get rid of all source code in the generated output, make sure also +# VERBATIM_HEADERS is set to NO. + +SOURCE_BROWSER = NO + +# Setting the INLINE_SOURCES tag to YES will include the body +# of functions and classes directly in the documentation. + +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. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES +# then for each documented function all documented +# functions referencing it will be listed. + +REFERENCED_BY_RELATION = NO + +# If the REFERENCES_RELATION tag is set to YES +# then for each documented function all documented entities +# called/used by that function will be listed. + +REFERENCES_RELATION = NO + +# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) +# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from +# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will +# link to the source code. +# Otherwise they will link to the documentation. + +REFERENCES_LINK_SOURCE = YES + +# If the USE_HTAGS tag is set to YES then the references to source code +# will point to the HTML generated by the htags(1) tool instead of doxygen +# built-in source browser. The htags tool is part of GNU's global source +# tagging system (see http://www.gnu.org/software/global/global.html). You +# will need version 4.8.6 or higher. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen +# will generate a verbatim copy of the header file for each class for +# which an include is specified. Set to NO to disable this. + +VERBATIM_HEADERS = YES + +#--------------------------------------------------------------------------- +# configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index +# of all compounds will be generated. Enable this if the project +# contains a lot of classes, structs, unions or interfaces. + +ALPHABETICAL_INDEX = NO + +# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then +# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns +# in which this list will be split (can be a number in the range [1..20]) + +COLS_IN_ALPHA_INDEX = 5 + +# In case all classes in a project start with a common prefix, all +# classes will be put under the same header in the alphabetical index. +# The IGNORE_PREFIX tag can be used to specify one or more prefixes that +# should be ignored while generating the index headers. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES (the default) Doxygen will +# generate HTML output. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `html' will be used as the default path. + +HTML_OUTPUT = html + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for +# each generated HTML page (for example: .htm,.php,.asp). If it is left blank +# doxygen will generate files with .html extension. + +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. + +HTML_HEADER = + +# The HTML_FOOTER tag can be used to specify a personal HTML footer for +# each generated HTML page. If it is left blank doxygen will generate a +# standard footer. + +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! + +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. + +HTML_ALIGN_MEMBERS = 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). + +HTML_DYNAMIC_SECTIONS = NO + +# 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). +# To create a documentation set, doxygen will generate a Makefile in the +# HTML output directory. Running make will produce the docset in that +# 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. + +GENERATE_DOCSET = NO + +# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the +# feed. A documentation feed provides an umbrella under which multiple +# documentation sets from a single provider (such as a company or product suite) +# can be grouped. + +DOCSET_FEEDNAME = "Doxygen generated docs" + +# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that +# should uniquely identify the documentation set bundle. This should be a +# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen +# will append .docset to the name. + +DOCSET_BUNDLE_ID = org.doxygen.Project + +# 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) +# of the generated HTML documentation. + +GENERATE_HTMLHELP = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can +# be used to specify the file name of the resulting .chm file. You +# can add a path in front of the file if the result should not be +# written to the html output directory. + +CHM_FILE = + +# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can +# be used to specify the location (absolute path including file name) of +# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run +# the HTML help compiler on the generated index.hhp. + +HHC_LOCATION = + +# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag +# controls if a separate .chi index file is generated (YES) or that +# it should be included in the master .chm file (NO). + +GENERATE_CHI = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING +# is used to encode HtmlHelp index (hhk), content (hhc) and project file +# content. + +CHM_INDEX_ENCODING = + +# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag +# controls whether a binary table of contents is generated (YES) or a +# normal table of contents (NO) in the .chm file. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members +# to the contents of the HTML help documentation and to the tree view. + +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. + +GENERATE_QHP = NO + +# If the QHG_LOCATION tag is specified, the QCH_FILE tag can +# be used to specify the file name of the resulting .qch file. +# The path specified is relative to the HTML output folder. + +QCH_FILE = + +# The QHP_NAMESPACE tag specifies the namespace to use when generating +# Qt Help Project output. For more information please see +# http://doc.trolltech.com/qthelpproject.html#namespace + +QHP_NAMESPACE = + +# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating +# Qt Help Project output. For more information please see +# http://doc.trolltech.com/qthelpproject.html#virtual-folders + +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 +# 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>. + +QHP_CUST_FILTER_ATTRS = + +# 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>. + +QHP_SECT_FILTER_ATTRS = + +# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can +# be used to specify the location of Qt's qhelpgenerator. +# If non-empty doxygen will try to run qhelpgenerator on the generated +# .qhp file. + +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. + +DISABLE_INDEX = 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. + +ENUM_VALUES_PER_LINE = 4 + +# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index +# structure should be generated to display hierarchical information. +# If the tag value is set to YES, a side panel will be generated +# containing a tree-like index structure (just like the one that +# 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. + +GENERATE_TREEVIEW = NO + +# By enabling USE_INLINE_TREES, doxygen will generate the Groups, Directories, +# and Class Hierarchy pages using a tree view instead of an ordered list. + +USE_INLINE_TREES = NO + +# 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 +# is shown. + +TREEVIEW_WIDTH = 250 + +# 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 +# to manually remove any form_*.png images from the HTML output directory +# to force them to be regenerated. + +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. + +SEARCHENGINE = YES + +#--------------------------------------------------------------------------- +# configuration options related to the LaTeX output +#--------------------------------------------------------------------------- + +# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will +# generate Latex output. + +GENERATE_LATEX = NO + +# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `latex' will be used as the default path. + +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. + +LATEX_CMD_NAME = latex + +# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to +# generate index for LaTeX. If left blank `makeindex' will be used as the +# default command name. + +MAKEINDEX_CMD_NAME = makeindex + +# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact +# LaTeX documents. This may be useful for small projects and may help to +# save some trees in general. + +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. + +PAPER_TYPE = a4wide + +# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX +# packages that should be included in the LaTeX output. + +EXTRA_PACKAGES = + +# The LATEX_HEADER tag can be used to specify a personal LaTeX header for +# the generated latex document. The header should contain everything until +# the first chapter. If it is left blank doxygen will generate a +# standard header. Notice: only use this tag if you know what you are doing! + +LATEX_HEADER = + +# 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 +# This makes the output suitable for online browsing using a pdf viewer. + +PDF_HYPERLINKS = YES + +# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of +# plain latex in the generated Makefile. Set this option to YES to get a +# higher quality PDF documentation. + +USE_PDFLATEX = YES + +# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. +# command to the generated LaTeX files. This will instruct LaTeX to keep +# running if errors occur, instead of asking the user for help. +# This option is also used when generating formulas in HTML. + +LATEX_BATCHMODE = NO + +# If LATEX_HIDE_INDICES is set to YES then doxygen will not +# include the index chapters (such as File Index, Compound Index, etc.) +# in the output. + +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. + +LATEX_SOURCE_CODE = NO + +#--------------------------------------------------------------------------- +# configuration options related to the RTF output +#--------------------------------------------------------------------------- + +# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output +# The RTF output is optimized for Word 97 and may not look very pretty with +# other RTF readers or editors. + +GENERATE_RTF = NO + +# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `rtf' will be used as the default path. + +RTF_OUTPUT = rtf + +# If the COMPACT_RTF tag is set to YES Doxygen generates more compact +# RTF documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_RTF = NO + +# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated +# will contain hyperlink fields. The RTF file will +# contain links (just like the HTML output) instead of page references. +# This makes the output suitable for online browsing using WORD or other +# programs which support those fields. +# Note: wordpad (write) and others do not support links. + +RTF_HYPERLINKS = NO + +# Load stylesheet 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. + +RTF_STYLESHEET_FILE = + +# Set optional variables used in the generation of an rtf document. +# Syntax is similar to doxygen's config file. + +RTF_EXTENSIONS_FILE = + +#--------------------------------------------------------------------------- +# configuration options related to the man page output +#--------------------------------------------------------------------------- + +# If the GENERATE_MAN tag is set to YES (the default) Doxygen will +# generate man pages + +GENERATE_MAN = NO + +# The MAN_OUTPUT tag is used to specify where the man 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 `man' will be used as the default path. + +MAN_OUTPUT = man + +# The MAN_EXTENSION tag determines the extension that is added to +# the generated man pages (default is the subroutine's section .3) + +MAN_EXTENSION = .3 + +# If the MAN_LINKS tag is set to YES and Doxygen generates man output, +# then it will generate one additional man file for each entity +# documented in the real man page(s). These additional files +# only source the real man page, but without them the man command +# would be unable to find the correct page. The default is NO. + +MAN_LINKS = NO + +#--------------------------------------------------------------------------- +# configuration options related to the XML output +#--------------------------------------------------------------------------- + +# If the GENERATE_XML tag is set to YES Doxygen will +# generate an XML file that captures the structure of +# the code including all documentation. + +GENERATE_XML = NO + +# The XML_OUTPUT tag is used to specify where the XML 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 `xml' will be used as the default path. + +XML_OUTPUT = xml + +# The XML_SCHEMA tag can be used to specify an XML schema, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_SCHEMA = + +# The XML_DTD tag can be used to specify an XML DTD, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_DTD = + +# If the XML_PROGRAMLISTING tag is set to YES Doxygen will +# dump the program listings (including syntax highlighting +# and cross-referencing information) to the XML output. Note that +# enabling this will significantly increase the size of the XML output. + +XML_PROGRAMLISTING = YES + +#--------------------------------------------------------------------------- +# configuration options for the AutoGen Definitions output +#--------------------------------------------------------------------------- + +# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will +# generate an AutoGen Definitions (see autogen.sf.net) file +# that captures the structure of the code including all +# documentation. Note that this feature is still experimental +# and incomplete at the moment. + +GENERATE_AUTOGEN_DEF = NO + +#--------------------------------------------------------------------------- +# configuration options related to the Perl module output +#--------------------------------------------------------------------------- + +# If the GENERATE_PERLMOD tag is set to YES Doxygen will +# generate a Perl module file that captures the structure of +# the code including all documentation. Note that this +# feature is still experimental and incomplete at the +# moment. + +GENERATE_PERLMOD = NO + +# If the PERLMOD_LATEX tag is set to YES Doxygen will generate +# the necessary Makefile rules, Perl scripts and LaTeX code to be able +# to generate PDF and DVI output from the Perl module output. + +PERLMOD_LATEX = NO + +# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be +# nicely formatted so it can be parsed by a human reader. +# This is useful +# if you want to understand what is going on. +# On the other hand, if this +# tag is set to NO the size of the Perl module output will be much smaller +# and Perl will parse it just the same. + +PERLMOD_PRETTY = YES + +# The names of the make variables in the generated doxyrules.make file +# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. +# This is useful so different doxyrules.make files included by the same +# Makefile don't overwrite each other's variables. + +PERLMOD_MAKEVAR_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the preprocessor +#--------------------------------------------------------------------------- + +# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will +# evaluate all C-preprocessor directives found in the sources and include +# files. + +ENABLE_PREPROCESSING = YES + +# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro +# names in the source code. If set to NO (the default) only conditional +# compilation will be performed. Macro expansion can be done in a controlled +# way by setting EXPAND_ONLY_PREDEF to YES. + +MACRO_EXPANSION = YES + +# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES +# then the macro expansion is limited to the macros specified with the +# PREDEFINED and EXPAND_AS_DEFINED tags. + +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. + +SEARCH_INCLUDES = YES + +# The INCLUDE_PATH tag can be used to specify one or more directories that +# contain include files that are not input files but should be processed by +# the preprocessor. + +INCLUDE_PATH = + +# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard +# patterns (like *.h and *.hpp) to filter out the header-files in the +# directories. If left blank, the patterns specified with FILE_PATTERNS will +# be used. + +INCLUDE_FILE_PATTERNS = + +# The PREDEFINED tag can be used to specify one or more macro names that +# are defined before the preprocessor is started (similar to the -D option of +# gcc). The argument of the tag is a list of macros of the form: name +# or name=definition (no spaces). If the definition and the = are +# omitted =1 is assumed. To prevent a macro definition from being +# undefined via #undef or recursively expanded use the := operator +# instead of the = operator. + +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. + +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. + +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: +# +# 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. + +TAGFILES = + +# When a file name is specified after GENERATE_TAGFILE, doxygen will create +# a tag file that is based on the input files it reads. + +GENERATE_TAGFILE = + +# If the ALLEXTERNALS tag is set to YES all external classes will be listed +# in the class index. If set to NO only the inherited external classes +# will be listed. + +ALLEXTERNALS = NO + +# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed +# in the modules index. If set to NO, only the current project's groups will +# be listed. + +EXTERNAL_GROUPS = YES + +# The PERL_PATH should be the absolute path and name of the perl script +# interpreter (i.e. the result of `which perl'). + +PERL_PATH = /usr/bin/perl + +#--------------------------------------------------------------------------- +# Configuration options related to the dot tool +#--------------------------------------------------------------------------- + +# 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. + +CLASS_DIAGRAMS = YES + +# You can define message sequence charts within doxygen comments using the \msc +# command. Doxygen will then run the mscgen tool (see +# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the +# documentation. The MSCGEN_PATH tag allows you to specify the directory where +# the mscgen tool resides. If left empty the tool is assumed to be found in the +# default search path. + +MSCGEN_PATH = + +# If set to YES, the inheritance and collaboration graphs will hide +# inheritance and usage relations if the target is undocumented +# or is not a class. + +HIDE_UNDOC_RELATIONS = YES + +# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is +# available from the path. This tool is part of Graphviz, a graph visualization +# toolkit from AT&T and Lucent Bell Labs. The other options in this section +# have no effect if this option is set to NO (the default) + +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. + +DOT_FONTNAME = FreeSans + +# 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. + +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_GRAPH = YES + +# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect implementation dependencies (inheritance, containment, and +# class references variables) of the class with other documented classes. + +COLLABORATION_GRAPH = YES + +# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for groups, showing the direct groups dependencies + +GROUP_GRAPHS = YES + +# If the UML_LOOK tag is set to YES doxygen will generate inheritance and +# collaboration diagrams in a style similar to the OMG's Unified Modeling +# Language. + +UML_LOOK = NO + +# If set to YES, the inheritance and collaboration graphs will show the +# relations between templates and their instances. + +TEMPLATE_RELATIONS = NO + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT +# tags are set to YES then doxygen will generate a graph for each documented +# file showing the direct and indirect include dependencies of the file with +# other documented files. + +INCLUDE_GRAPH = YES + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and +# HAVE_DOT tags are set to YES then doxygen will generate a graph for each +# documented header file showing the documented files that directly or +# indirectly include this file. + +INCLUDED_BY_GRAPH = YES + +# If the CALL_GRAPH and HAVE_DOT options are set to YES then +# doxygen will generate a call dependency graph for every global function +# or class method. Note that enabling this option will significantly increase +# the time of a run. So in most cases it will be better to enable call graphs +# for selected functions only using the \callgraph command. + +CALL_GRAPH = NO + +# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then +# doxygen will generate a caller dependency graph for every global function +# or class method. Note that enabling this option will significantly increase +# the time of a run. So in most cases it will be better to enable caller +# graphs for selected functions only using the \callergraph command. + +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. + +GRAPHICAL_HIERARCHY = YES + +# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES 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. + +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. + +DOT_IMAGE_FORMAT = png + +# 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. + +DOT_PATH = + +# The DOTFILE_DIRS tag can be used to specify one or more directories that +# contain dot files that are included in the documentation (see the +# \dotfile command). + +DOTFILE_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 +# visualized by representing a node as a red box. Note that doxygen if the +# number of direct children of the root node in a graph is already larger than +# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note +# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH. + +DOT_GRAPH_MAX_NODES = 50 + +# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the +# graphs generated by dot. A depth value of 3 means that only nodes reachable +# from the root by following a path via at most 3 edges will be shown. Nodes +# that lay further from the root node will be omitted. Note that setting this +# option to 1 or 2 may greatly reduce the computation time needed for large +# code bases. Also note that the size of a graph can be further restricted by +# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction. + +MAX_DOT_GRAPH_DEPTH = 0 + +# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent +# background. This is disabled by default, because dot on Windows does not +# seem to support this out of the box. Warning: Depending on the platform used, +# enabling this option may lead to badly anti-aliased labels on the edges of +# a graph (i.e. they become hard to read). + +DOT_TRANSPARENT = NO + +# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output +# files in one run (i.e. multiple -o and -T options on the command line). This +# makes dot run faster, but since only newer versions of dot (>1.8.10) +# support this, this feature is disabled by default. + +DOT_MULTI_TARGETS = YES + +# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will +# generate a legend page explaining the meaning of the various boxes and +# arrows in the dot generated graphs. + +GENERATE_LEGEND = YES + +# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will +# remove the intermediate dot files that are used to generate +# the various graphs. + +DOT_CLEANUP = YES diff --git a/host/docs/build.rst b/host/docs/build.rst new file mode 100644 index 000000000..ee522780a --- /dev/null +++ b/host/docs/build.rst @@ -0,0 +1,220 @@ +======================================================================== +UHD - 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 Developer Tools" 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. + +**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 +* **Version:** at least 2.6 +* **Usage:** build time (required) +* **Download URL:** http://www.cmake.org/cmake/resources/software.html + +^^^^^^^^^^^^^^^^ +Boost +^^^^^^^^^^^^^^^^ +* **Purpose:** C++ library +* **Version:** at least 1.36 unix, at least 1.40 windows +* **Usage:** build time + run time (required) +* **Download URL:** http://www.boost.org/users/download/ +* **Download URL (windows installer):** http://www.boostpro.com/download + +^^^^^^^^^^^^^^^^ +LibUSB +^^^^^^^^^^^^^^^^ +* **Purpose:** USB-based hardware support +* **Version:** at least 1.0 +* **Usage:** build time + run time (optional) +* **Download URL:** http://sourceforge.net/projects/libusb/files/libusb-1.0/ +* **Download URL (windows binaries):** http://www.libusb.org/wiki/windows_backend#LatestBinarySnapshots + +^^^^^^^^^^^^^^^^ +Python +^^^^^^^^^^^^^^^^ +* **Purpose:** used by Cheetah and utility scripts +* **Version:** at least 2.6 +* **Usage:** build time + run time utility scripts (required) +* **Download URL:** http://www.python.org/download/ + +^^^^^^^^^^^^^^^^ +Cheetah +^^^^^^^^^^^^^^^^ +* **Purpose:** source code generation +* **Version:** at least 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 + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Setup the library path (Mac OS X) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Make sure that libuhd.dylib is in your DYLD_LIBRARY_PATH + +------------------------------------------------------------------------ +Build Instructions (Windows) +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Generate the project with cmake +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +* Open the cmake gui program. +* 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 the MSVC compiler. +* Set the build variables and click configure again. +* Click generate and a project file will be created in the build directory. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +LibUSB cmake 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 "Advanded 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. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 interface for editing environment variable paths in Windows is very poor. +I 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. diff --git a/host/docs/calibration.rst b/host/docs/calibration.rst new file mode 100644 index 000000000..14e66a312 --- /dev/null +++ b/host/docs/calibration.rst @@ -0,0 +1,61 @@ +======================================================================== +UHD - Calibration Application Notes +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +Self-calibration +------------------------------------------------------------------------ +The UHD comes with several self-calibration utilities for minimizing IQ imbalance and DC offset. +These utilities perform calibration sweeps using transmit leakage into the receive path +(special equipment is not required). +The results from a calibration are written to a csv file in the user's home directory. +UHD will automatically apply corrections at runtime when the user re-tunes the daughterboard LO. +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 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: + + * WBX transceiver board + * SBX transceiver board + * more to come... + +******************************************** +Calibration utilities +******************************************** +UHD installs the calibration utilities into <install-path>/bin. +**Disconnect** any extrernal hardware from the RF antenna ports, +and run the following from the command line. +Each utility will take several minutes to complete. +:: + + 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. + +******************************************** +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. + + * **Unix:** ${HOME}/.uhd/cal/ + * **Windows:** %APPDATA%\\.uhd\\cal\\ + diff --git a/host/docs/coding.rst b/host/docs/coding.rst new file mode 100644 index 000000000..ed858ceb4 --- /dev/null +++ b/host/docs/coding.rst @@ -0,0 +1,30 @@ +======================================================================== +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, 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 with +one or more channels, or multiple USRPs in a homogeneous setup. +See the documentation in *usrp/multi_usrp.hpp* for reference. diff --git a/host/docs/dboards.rst b/host/docs/dboards.rst new file mode 100644 index 000000000..d41bf824c --- /dev/null +++ b/host/docs/dboards.rst @@ -0,0 +1,381 @@ +======================================================================== +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 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. +Though the magic of aliasing, you can down-convert signals +greater than the Nyquist rate of the ADC. + +BasicRX Bandwidth (Hz): + +* For Real-Mode (A or B frontend): 250M +* For Complex (AB or BA frontend): 500M + +LFRX Bandwidth (Hz): + +* For Real-Mode (A or B frontend): 33M +* For Complex (AB or BA frontend): 66M + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Basic TX and 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. +Though the magic of aliasing, you can up-convert signals +greater than the Nyquist rate of the DAC. + +BasicTX Bandwidth (Hz): 250M + +* For Real-Mode (A or B frontend): 250M +* For Complex (AB or BA frontend): 500M + +LFTX Bandwidth (Hz): 33M + +* For Real-Mode (A or B frontend): 33M +* For Complex (AB or BA frontend): 66M + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 (Hz): 8M-66M + +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): 8M-80M + +Sensors: + +* **lo_locked**: boolean for LO lock state + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +RFX Series +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The RFX Series boards have 2 quadrature frontends, one transmit, one 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) + +Bandwidths (Hz): + +* **RX**: 40M +* **TX**: 40M + +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.0GHz) and a low band (2.4-2.5GHz). + +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 (Hz): + +* **RX**: 15M, 19M, 28M, 36M; (each +-0, 5, or 10%) +* **TX**: 24M, 36M, 48M + +Sensors: + +* **lo_locked**: boolean for LO lock state +* **rssi**: float for rssi in dBm + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +WBX Series +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The WBX Series boards have 2 quadrature frontends, one transmit, one receive. +Transmit and Receive default to direct conversion but +can be used in low IF mode through lo_offset in uhd::tune_request_t + +The WBX 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 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 (Hz): + +* **RX**: 40M +* **TX**: 40M + +Sensors: + +* **lo_locked**: boolean for LO lock state + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +SBX Series +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +The SBX Series boards have 2 quadrature frontends, one transmit, one receive. +Transmit and Receive default to direct conversion but +can be used in low IF mode through lo_offset in uhd::tune_request_t + +The SBX 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 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 (Hz): + +* **RX**: 40M +* **TX**: 40M + +Sensors: + +* **lo_locked**: boolean for LO lock state + +LEDs: + +* All LEDs flash when dboard 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: 6MHz + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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.7MHz, 6MHz, 7MHz, 8MHz, 10MHz + +Sensors: + +* **lo_locked**: boolean for LO lock state +* **rssi**: float for measured RSSI in dBm +* **temperature**: float for measured temperature in degC + +------------------------------------------------------------------------ +Daughterboard Modifications +------------------------------------------------------------------------ + +Sometimes, daughterboards will require modification +to work on certain frequencies or to work with certain hardware. +Modification usually involves moving/removing a SMT component +and burning a new daughterboard id into the eeprom. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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>/share/uhd/utils + ./usrp_burn_db_eeprom --id=0x000d --unit=RX --args=<args> --slot=<slot> + +* <args> are device address arguments (optional if only one USRP is on your machine) +* <slot> is the name of the daughterboard slot (optional if the USRP has only one slot) + +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +RFX - Mod +^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Older RFX boards require modifications to use the motherboard oscillator. +If this is the case, UHD will print a warning about the modification. +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>/share/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 is on your machine) +* <slot> is the name of the daughterboard slot (optional if the USRP has only one slot) diff --git a/host/docs/general.rst b/host/docs/general.rst new file mode 100644 index 000000000..5df89fc19 --- /dev/null +++ b/host/docs/general.rst @@ -0,0 +1,224 @@ +======================================================================== +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's advanced tuning is highly recommended as it makes it +easy to move the DC component out of your band-of-interest. This can be done by +passing your desired LO offset to the tune_request_t object, and letting UHD +handle the rest. + +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); + //fill in any additional/optional tune request fields... + usrp->set_rx_freq(tune_req); + +More information can be fonud in *tune_request.hpp*. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 detects the overflow, it prints an "O" to stdout, +and pushes an inline message packet into the receive stream. + +**Network-based devices**: +The host does not back-pressure the receive stream. +When the kernel's socket buffer becomes full, it will drop subsequent packets. +UHD detects the overflow as a discontinuity in the packet's sequence numbers, +and muxes an inline message packet into the receive stream. + +**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 shutoff, +and an inline message packet is sent to the host. +If the device was in continuous streaming mode, +the UHD will automatically restart streaming. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Underflow notes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +When transmitting, the device consumes samples at a constant rate. +Underflow occurs when the host does not produce data fast enough. +When the UHD detects underflow, it prints an "U" to stdout, +and pushes a message packet into the async message stream. + +------------------------------------------------------------------------ +Threading notes +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Thread safety notes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +For the most part, UHD 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. +The 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 the UHD spawns a new thread it may try to boost the thread's scheduling priority. +When setting the priority fails, the UHD 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 has logged in and out. + +------------------------------------------------------------------------ +Misc 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 UHD: + +:: + + #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/gpsdo.rst b/host/docs/gpsdo.rst new file mode 100644 index 000000000..f732aae63 --- /dev/null +++ b/host/docs/gpsdo.rst @@ -0,0 +1,80 @@ +======================================================================== +UHD - Internal GPSDO Application Notes +======================================================================== + +.. contents:: Table of Contents + +This application note describes the use of integrated GPS-disciplined +oscillators with Ettus Research USRP devices. It pertains specifically +to the Jackson Labs Firefly-1A device unless noted otherwise. + +------------------------------------------------------------------------ +Specifications +------------------------------------------------------------------------ +* Receiver type: 50 channel with WAAS, EGNOS, MSAS +* 10MHz ADEV: 1e-11 over >24h +* 1PPS RMS jitter: <50ns 1-sigma +* Holdover: <11us over 3h +* Phase noise: + + * **1Hz:** -80dBc/Hz + * **10Hz:** -110dBc/Hz + * **100Hz:** -135dBc/Hz + * **1kHz:** -145dBc/Hz + * **10kHz:** <-145dBc/Hz + +**Antenna Types:** + +The GPSDO is capable of supplying a 3V for active GPS antennas or supporting passive antennas + +------------------------------------------------------------------------ +Installation instructions +------------------------------------------------------------------------ +Installation instructions can be found here: +`www.ettus.com/downloads/gpsdo-kit.pdf <http://www.ettus.com/downloads/gpsdo-kit.pdf>`_ + +******************************************** +Post installation task (N-Series only) +******************************************** +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 10MHz 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>/share/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 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.rst b/host/docs/identification.rst new file mode 100644 index 000000000..deda61531 --- /dev/null +++ b/host/docs/identification.rst @@ -0,0 +1,125 @@ +======================================================================== +UHD - Device Identification Notes +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +Identifying USRPs +------------------------------------------------------------------------ +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 a --args parameter that takes a device address; +where the device address 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 | ++============+============+============================================+ +| Serial | serial | globally unique identifier | ++------------+------------+--------------------------------------------+ +| Address | addr | unique identifier on a network | ++------------+------------+--------------------------------------------+ +| Name | name | optional user-set identifier | ++------------+------------+--------------------------------------------+ +| Type | type | hardware series identifier | ++------------+------------+--------------------------------------------+ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Device discovery via command line +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Devices attached to your system can be discovered using the "uhd_find_devices" program. +The find devices 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. +The usrp probe program constructs an instance of the device and prints out its properties; +properties such as detected daughter-boards, frequency range, gain ranges, etc... + +**Usage:** +:: + + uhd_usrp_probe --args <device-specific-address-args> + +------------------------------------------------------------------------ +Naming a USRP +------------------------------------------------------------------------ +For convenience purposes, users may assign a custom name to their USRPs. +The USRP can then be identified via name, rather than a difficult to remember serial or address. + +A name has the following properties: + +* is composed of ASCII characters +* is between 0 and 20 characters +* is not required to be unique + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Set a custom name +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Run the following commands: +:: + + cd <install-path>/share/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.rst b/host/docs/images.rst new file mode 100644 index 000000000..a25268990 --- /dev/null +++ b/host/docs/images.rst @@ -0,0 +1,93 @@ +======================================================================== +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 varies 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 must manually transfer the images over ethernet. +* **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. + +------------------------------------------------------------------------ +Pre-built images +------------------------------------------------------------------------ + +Pre-built images are available for download. +See the UHD wiki for the download link. + +The pre-built images come in two forms: + +* bundled with UHD in a platform-specific installer +* stand-alone platform-independent archive files + +^^^^^^^^^^^^^^^^^^^^^^ +Platform installers +^^^^^^^^^^^^^^^^^^^^^^ +The UNIX-based installers will install the images into /usr/share/uhd/images. +On windows, the images will be installed to <install-path>/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. +The UHD 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_IMAGE_PATH environment variable. +The UHD_IMAGE_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 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Xilinx ISE 12.x and up is required to build the Xilinx FPGA images. +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. + +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 images. +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 new file mode 100644 index 000000000..f881e8585 --- /dev/null +++ b/host/docs/index.rst @@ -0,0 +1,41 @@ +======================================================================== +UHD - USRP Hardware Driver +======================================================================== + +The UHD is the "Universal Software Radio Peripheral" hardware driver. +The goal of the UHD is to provide a host driver and API for current and future Ettus Research products. +Users will be able to use the UHD driver standalone or with 3rd party applications. + +------------------------------------------------------------------------ +Contents +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^ +Building the UHD +^^^^^^^^^^^^^^^^^^^^^ +* `Build Guide <./build.html>`_ + +^^^^^^^^^^^^^^^^^^^^^ +Application Notes +^^^^^^^^^^^^^^^^^^^^^ +* `General Application Notes <./general.html>`_ +* `Device Identification Notes <./identification.html>`_ +* `Firmware and FPGA Image Notes <./images.html>`_ +* `USRP1 Application Notes <./usrp1.html>`_ +* `USRP2 Application Notes <./usrp2.html>`_ +* `USRP-N2XX Series Application Notes <./usrp2.html>`_ +* `USRP-B1XX Series Application Notes <./usrp_b1xx.html>`_ +* `USRP-E1XX Series Application Notes <./usrp_e1xx.html>`_ +* `Daughterboard Application Notes <./dboards.html>`_ +* `Transport Application Notes <./transport.html>`_ +* `Synchronization Application Notes <./sync.html>`_ +* `Internal GPSDO Application Notes <./gpsdo.html>`_ +* `Calibration Application Notes <./calibration.html>`_ + +^^^^^^^^^^^^^^^^^^^^^ +API Documentation +^^^^^^^^^^^^^^^^^^^^^ +* `Doxygen <./../../doxygen/html/index.html>`_ +* `Using the API <./coding.html>`_ +* `Device streaming <./stream.html>`_ + diff --git a/host/docs/stream.rst b/host/docs/stream.rst new file mode 100644 index 000000000..9ffec22e5 --- /dev/null +++ b/host/docs/stream.rst @@ -0,0 +1,59 @@ +======================================================================== +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. +A 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 generation2 hardware, 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 futher documentation. + +TODO provide example of convert API diff --git a/host/docs/style.css b/host/docs/style.css new file mode 100644 index 000000000..bf97bf007 --- /dev/null +++ b/host/docs/style.css @@ -0,0 +1,102 @@ +body{ +font-family:Arial, Helvetica, sans-serif; +font-size:11pt; +color:black; +background-color:white; +width:90%; +margin:0 auto 0 auto; +} + +div.document div.contents{ +border:1px solid #333333; +padding:10px 30px 10px 10px; +margin-left:50px; +color:inherit; +background-color:#FCFCFC; +display:inline-block; +} + +div.document p.topic-title{ +font-weight:bold; +} + +div.document a:link, div.document a:visited{ +color:#236B8E; +background-color:inherit; +text-decoration:none; +} + +div.document a:hover{ +color:#4985D6; +background-color:inherit; +text-decoration:none; +} + +div.document h1.title{ +font-size:150%; +border-left:1px solid #333333; +border-bottom:1px solid #333333; +text-align:left; +padding:10px 0px 10px 10px; +margin:10px 5px 20px 5px; +color:#333333; +background-color:inherit; +} + +div.document h2.subtitle, div.section h1{ +margin-top:50px; +border-bottom:1px solid #333333; +font-size:140%; +text-align:center; +padding:20px 0px 10px 0px; +color:#333333; +background-color:inherit; +} + +div.section h2{ +font-size:110%; +text-align:left; +padding:15px 0px 5px 0px; +text-decoration:underline; +color:#333333; +background-color:inherit; +} + +div.document pre.literal-block{ +border:1px inset #333333; +padding:5px; +margin:10px 5px 10px 5px; +color:inherit; +background-color:#FCFCFC; +font-size:90%; +} + +div.document table{ +padding:5px; +font-size:95%; +} + +div.document th{ +padding:3px 7px 3px 7px; +border:1px solid #333333; +text-align:center; +color:inherit; +background-color:#ECECEC; +} + +div.document tr{ +} + +div.document td{ +padding:3px 7px 3px 7px; +border:1px solid #333333; +text-align:center; +color:inherit; +background-color:#FCFCFC; +} + +div.footer{ +margin:50px auto 30px auto; +text-align:center; +font-size:85%; +} diff --git a/host/docs/sync.rst b/host/docs/sync.rst new file mode 100644 index 000000000..55c9f81f0 --- /dev/null +++ b/host/docs/sync.rst @@ -0,0 +1,164 @@ +======================================================================== +UHD - Synchronization Application Notes +======================================================================== + +.. contents:: Table of Contents + +The following application notes explain how to synchronize multiple USRPs +with the goal of transmitting or receiving time-aligned samples for MIMO +or other applications requiring multiple USRPs operating synchronously. + +**Note:** The following synchronization notes do not apply to USRP1, +which does not support the advanced features available in newer products. + +------------------------------------------------------------------------ +Common reference signals +------------------------------------------------------------------------ +USRPs take two reference signals in order to synchronize clocks and time: + +* A 10MHz reference to provide a single frequency reference for both devices. +* A pulse-per-second (1PPS) to synchronize the sample time across devices. +* Or, the 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 special parameter: + +:: + + usrp->set_time_source("_external_"); + +**Note2:** +For users generating their own signals for the external SMA connectors, +the pulse-per-second 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 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 to 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 GPSDO 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 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +USRPs with internal GPSDOs properly configured will automatically +configure themselves to set the VITA time to current UTC time. +See the `GPSDO Application Notes <./gpsdo.html>`_ for more details. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Method 4 - MIMO cable +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +A USRP can synchronize its time to another USRP via the MIMO cable. +Unlike the other methods, this does not use a real "pulse per second". +Rather, the USRP sends an encoded time message over the MIMO cable. +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 USRPs, 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 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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.rst b/host/docs/transport.rst new file mode 100644 index 000000000..7dc465b4c --- /dev/null +++ b/host/docs/transport.rst @@ -0,0 +1,153 @@ +======================================================================== +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: + +------------------------------------------------------------------------ +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 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 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +On Windows, it is important to change the default UDP behavior such that +1500 byte packets still travel through the fast path of the sockets stack. +FastSendDatagramThreshold registry key to change documented here: + +* http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx#appendix_e + +------------------------------------------------------------------------ +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>/share/uhd/utils + sudo cp uhd-usrp.rules /etc/udev/rules.d/ + sudo udevadm control --reload-rules + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Install USB driver (Windows) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +A driver package must be installed to use a USB-based product with UHD: + +* Download the driver from the UHD wiki page. +* Unzip the file into a known location. We will refer to this as the <directory>. +* Open the device manager and plug-in the USRP. You will see an unrecognized USB device in the device manager. +* Right click on the unrecognized USB device and select update/install driver software (may vary for your OS). +* In the driver installation wizard, select "browse for driver", browse to the <directory>, and select the .inf file. +* Continue through the installation wizard until the driver is installed. diff --git a/host/docs/usrp1.rst b/host/docs/usrp1.rst new file mode 100644 index 000000000..597b5b17f --- /dev/null +++ b/host/docs/usrp1.rst @@ -0,0 +1,92 @@ +======================================================================== +UHD - USRP1 Application Notes +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +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 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 can initialize with the correct clock rate. +Run the following commands to record the setting into the EEPROM: +:: + + cd <install-path>/share/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.rst b/host/docs/usrp2.rst new file mode 100644 index 000000000..d81440b07 --- /dev/null +++ b/host/docs/usrp2.rst @@ -0,0 +1,398 @@ +======================================================================== +UHD - USRP2 and N Series Application Notes +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +Load the images onto the SD card (USRP2 only) +------------------------------------------------------------------------ +**Warning!** +Use the usrp2_card_burner.py with caution. If you specify the wrong device node, +you could overwrite your hard drive. Make sure that --dev= specifies the SD card. + +**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>/share/uhd/utils/usrp2_card_burner_gui.py + + -- OR -- + + cd <install-path>/share/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>/share/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. + +**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. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use the net burner tool (unix) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:: + + <install-path>/share/uhd/utils/usrp_n2xx_net_burner_gui.py + + -- OR -- + + cd <install-path>/share/uhd/utils + ./usrp_n2xx_net_burner.py --addr=<ip address> --fw=<path for firmware image> + ./usrp_n2xx_net_burner.py --addr=<ip address> --fpga=<path to FPGA image> + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Use the net burner tool (Windows) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:: + + <path_to_python.exe> <install-path>/share/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 the UHD, if an IP address for the USRP2 is not specified, +the software will use UDP broadcast packets to locate the USRP2. +On some systems, the firewall will block UDP broadcast packets. +It is recommended that you change or disable your firewall settings. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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>/share/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>/share/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. For +example, if your network interface is set to 192.168.20.1, and the USRP is +192.168.10.2 (note the difference in the third numbers of the IP addresses), you +will likely see a 'no control response' error message. + +Fixing this is simple - just set the your host PC's IP address to the same +subnet as your USRP. 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 sends broadcast 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 yeilds 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 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 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>`_. +Use this addressing scheme with the *single_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 sink 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. +* Both 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. +* Both 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: +:: + + uhd::clock_config_t clock_config; + clock_config.ref_source = uhd::clock_config_t::REF_MIMO; + clock_config.pps_source = uhd::clock_config_t::PPS_MIMO; + usrp->set_clock_config(clock_config, slave_index); + +------------------------------------------------------------------------ +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 - 10MHz +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Using an external 10MHz reference clock, square wave will offer the best phase +noise performance, but sinusoid is acceptable. The reference clock requires the following power level: + +* **USRP2** 5 to 15dBm +* **N2XX** 0 to 15dBm + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 is on your machine) + +:: + + cd <install-path>/share/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, +channel 1 is sourced from subdevice RX2: +:: + + usrp->set_rx_subdev_spec("A:RX1 A:RX2"); diff --git a/host/docs/usrp_b1xx.rst b/host/docs/usrp_b1xx.rst new file mode 100644 index 000000000..538d60fce --- /dev/null +++ b/host/docs/usrp_b1xx.rst @@ -0,0 +1,87 @@ +======================================================================== +UHD - USRP-B1XX Series Application Notes +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +Specify a non-standard image +------------------------------------------------------------------------ +The UHD will automatically select the USRP B-Series images from the installed images package. +The image selection can be overridden with the "fpga" and "fw" device address parameters. + +Example device address string representations to specify non-standard images: + +:: + + fpga=usrp_b100_fpga_firmware.bin + + -- OR -- + + fw=usrp_b100_fw_firmware.ihx + +------------------------------------------------------------------------ +Changing the master clock rate +------------------------------------------------------------------------ +The master clock rate of the USRP embedded feeds both the FPGA DSP and the codec chip. +Hundreds of rates between 32MHz and 64MHz are available. +A few notable rates are: + +* 64MHz - maximum rate of the codec chip +* 61.44MHz - good for UMTS/WCDMA applications +* 52Mhz - good for GSM applications + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Set 61.44MHz - uses external VCXO +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +To use the 61.44MHz 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 the UHD. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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 the UHD, +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" + +------------------------------------------------------------------------ +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_e1xx.rst b/host/docs/usrp_e1xx.rst new file mode 100644 index 000000000..ef1e22b3a --- /dev/null +++ b/host/docs/usrp_e1xx.rst @@ -0,0 +1,136 @@ +======================================================================== +UHD - USRP-E1XX Series Application Notes +======================================================================== + +.. contents:: Table of Contents + +------------------------------------------------------------------------ +Specify a non-standard image +------------------------------------------------------------------------ +UHD will automatically select the USRP-Embedded FPGA image from the +installed images package. The FPGA image selection can be overridden with the +"fpga" device address parameter. + +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 32MHz and 64MHz are available. A few notable +rates are: + +* 64MHz - maximum rate of the codec chip +* 61.44MHz - good for UMTS/WCDMA applications +* 52Mhz - good for GSM applications + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Set 61.44MHz - uses external VCXO +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +To use the 61.44MHz clock rate with the USRP-Embedded, two jumpers must be moved +on the device. + +* J16 is a two pin header, remove the jumper (or leave it on pin1 only) +* J15 is a three pin header, move the jumper to (pin1, pin2) + +**Note:** See instructions below to communicate the desired clock rate into the +UHD. + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Set other rates - uses internal VCO +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +To use other clock rates, the jumpers will need to be in the default position. + +* J16 is a two pin header, move the jumper to (pin1, pin2) +* J15 is a three pin header, move the jumper to (pin2, pin3) + +To communicate the desired clock rate into the UHD, +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 exteral PPS signal for timestamp synchronization can be supplied by soldering +a connector. + +* Connector J13 (PPS) needs MCX connector WM5541-ND or similar +* Requires a square wave signal +* Amplitude: 3.3 to 5Vpp + +Test the PPS input with the following app: + +* <args> are device address arguments (optional if only one USRP is on your machine) + +:: + + cd <install-path>/share/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 will always try to detect an installed GPSDO at runtime. +There is not a special EEPROM value to burn for GPSDO detection. + +------------------------------------------------------------------------ +Hardware setup notes +------------------------------------------------------------------------ + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +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) +* other sensors are added when the GPSDO is enabled |