[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Commit-gnuradio] [gnuradio] 01/05: docs: fixed labels and references in
|
From: |
git |
|
Subject: |
[Commit-gnuradio] [gnuradio] 01/05: docs: fixed labels and references in manual. |
|
Date: |
Sun, 29 Mar 2015 01:19:01 +0000 (UTC) |
This is an automated email from the git hooks/post-receive script.
jcorgan pushed a commit to branch maint
in repository gnuradio.
commit ce73dafb67491bc785ade42c0eb4e84cc1a273ac
Author: Tom Rondeau <address@hidden>
Date: Mon Mar 23 14:32:21 2015 -0700
docs: fixed labels and references in manual.
Doxygen is getting more strict with having labels for every section,
and warns when there are section name collisions. This prefixes all
section and subsection labels with the component to make them all
unique.
---
docs/doxygen/other/ctrlport.dox | 2 +-
docs/doxygen/other/metadata.dox | 18 +++++++--------
docs/doxygen/other/msg_passing.dox | 14 ++++++------
docs/doxygen/other/ofdm.dox | 16 +++++++-------
docs/doxygen/other/packet_txrx.dox | 8 +++----
docs/doxygen/other/perf_counters.dox | 2 +-
docs/doxygen/other/pfb_intro.dox | 8 +++----
docs/doxygen/other/pmt.dox | 22 +++++++++----------
docs/doxygen/other/stream_tags.dox | 14 ++++++------
docs/doxygen/other/tagged_stream_blocks.dox | 34 ++++++++++++++---------------
gr-analog/doc/analog.dox | 2 +-
gr-audio/doc/audio.dox | 4 ++--
gr-blocks/doc/blocks.dox | 3 ++-
gr-channels/doc/channels.dox | 2 +-
gr-digital/doc/digital.dox | 4 ++--
gr-fcd/doc/fcd.dox | 4 ++--
gr-fec/doc/fec.dox | 2 +-
gr-fft/doc/fft.dox | 4 ++--
gr-filter/doc/filter.dox | 8 +++----
gr-qtgui/doc/qtgui.dox | 10 ++++-----
gr-uhd/doc/uhd.dox | 5 +++--
gr-vocoder/doc/vocoder.dox | 4 ++--
gr-zeromq/docs/zeromq.dox | 2 +-
23 files changed, 97 insertions(+), 95 deletions(-)
diff --git a/docs/doxygen/other/ctrlport.dox b/docs/doxygen/other/ctrlport.dox
index 8db156d..64bf9f7 100644
--- a/docs/doxygen/other/ctrlport.dox
+++ b/docs/doxygen/other/ctrlport.dox
@@ -1,6 +1,6 @@
/*! \page page_ctrlport ControlPort
-\section Introduction
+\section ctrlport_introduction Introduction
This is the ControlPort package. It is a tool to create distributed
control applications for GNU Radio. It provides blocks that can be
diff --git a/docs/doxygen/other/metadata.dox b/docs/doxygen/other/metadata.dox
index e29adf3..4958e08 100644
--- a/docs/doxygen/other/metadata.dox
+++ b/docs/doxygen/other/metadata.dox
@@ -1,6 +1,6 @@
/*! \page page_metadata Metadata Information
-\section Introduction
+\section metadata_introduction Introduction
Metadata files have extra information in the form of headers that
carry metadata about the samples in the file. Raw, binary files carry
@@ -54,7 +54,7 @@ it sees a stream tag, so the dictionary will contain and
key:value
pairs out of tags from the flowgraph.
-\subsection types Types of Metadata Files
+\subsection metadata_types Types of Metadata Files
GNU Radio currently supports two types of metadata files:
@@ -67,7 +67,7 @@ header file. The dat file, then, is the standard raw binary
format
with no interruptions in the data.
-\subsection updating Updating Headers
+\subsection metadata_updating Updating Headers
While there is always a header that starts a metadata file, they are
updated throughout as well. There are two events that trigger a new
@@ -99,7 +99,7 @@ segment loss is observed, it will generate a new timestamp as
a tag of
keep the sample times exact.
-\subsection implementation Implementation
+\subsection metadata_implementation Implementation
Metadata files are created using gr::blocks::file_meta_sink. The
default behavior is to create a single file with inline headers as
@@ -114,7 +114,7 @@ extra header are converted into tags and added to the
stream tags
interface.
-\section structure Structure
+\section metadata_structure Structure
The file metadata consists of a static mandatory header and a dynamic
optional extras header. Each header is a separate PMT
@@ -193,7 +193,7 @@ read this many bytes from the file. We can then deserialize
and parse
this header just like the first.
-\subsection header Header Information
+\subsection metadata_header Header Information
The header is a PMT dictionary with a known structure. This structure
may change, but we version the headers, so all headers of version X
@@ -225,7 +225,7 @@ enum gr_file_types {
};
\endcode
-\subsection extras Extras Information
+\subsection metadata_extras Extras Information
The extras section is an optional segment of the header. If 'strt' ==
METADATA_HEADER_SIZE, then there is no extras. Otherwise, it is simply
@@ -256,7 +256,7 @@ screen. Before converting from a PMT to it's natural data
type, it is
necessary to know the data type.
-\section Utilities
+\section metadata_utilities Utilities
GNU Radio comes with a couple of utilities to help in debugging and
manipulating metadata files. There is a general parser in Python that
@@ -293,7 +293,7 @@ files where the file of headers is expected to be the file
name of the
data with '.hdr' appended to it.
-\section Examples
+\section metadata_examples Examples
Examples are located in:
diff --git a/docs/doxygen/other/msg_passing.dox
b/docs/doxygen/other/msg_passing.dox
index 47d6768..df116c2 100644
--- a/docs/doxygen/other/msg_passing.dox
+++ b/docs/doxygen/other/msg_passing.dox
@@ -1,6 +1,6 @@
/*! \page page_msg_passing Message Passing
-\section intro Introduction
+\section msg_passing_introduction Introduction
GNU Radio was originally a streaming system with no other mechanism to
pass data between blocks. Streams of data are a model that work well
@@ -30,7 +30,7 @@ The message passing interface heavily relies on Polymorphic
Types
(PMTs) in GNU Radio. For further information about these data
structures, see the page \ref page_pmt.
-\section api Message Passing API
+\section msg_passing_api Message Passing API
The message passing interface is designed into the gr::basic_block,
which is the parent class for all blocks in GNU Radio. Each block has
@@ -69,7 +69,7 @@ have subscribed and uses the gr::basic_block::_post method to
send the
message to that block's message queue.
-\subsection msg_handler Message Handler Functions
+\subsection msg_passing_msg_handler Message Handler Functions
A subscriber block must declare a message handler function to process
the messages that are posted to it. After using the
@@ -98,7 +98,7 @@ is:
We give an example of using this below.
-\subsection msg_fg_connect Connecting Messages through the Flowgraph
+\subsection msg_passing_fg_connect Connecting Messages through the Flowgraph
From the flowgraph level, we have instrumented a gr::hier_block2::msg_connect
method to make it easy to subscribe blocks to other blocks'
@@ -145,12 +145,12 @@ function. When a new message is pushed onto a port's
message queue,
it is this function that is used to process the message.
-\section python_msg_passing Message Passing in Python Blocks
+\section msg_passing_python Message Passing in Python Blocks
ADD STUFF HERE
-\section examples Code Examples
+\section msg_passing_examples Code Examples
The following is snippets of code from blocks current in GNU Radio
that take advantage of message passing. We will be using
@@ -272,7 +272,7 @@ them. The data is then converted into an output stream of
items and
passed along. The next section describes how PDUs can be passed into a
flowgraph using the gr::blocks::pdu_to_tagged_stream block.
-\section posting Posting from External Sources
+\section msg_passing_posting Posting from External Sources
The last feature of the message passing architecture to discuss here
is how it can be used to take in messages from an external source. We
diff --git a/docs/doxygen/other/ofdm.dox b/docs/doxygen/other/ofdm.dox
index 62efa0c..9a3a18f 100644
--- a/docs/doxygen/other/ofdm.dox
+++ b/docs/doxygen/other/ofdm.dox
@@ -1,6 +1,6 @@
/*! \page page_ofdm OFDM
-\section intro Introduction
+\section ofdm_introduction Introduction
GNU Radio provides some blocks to transmit and receive OFDM-modulated signals.
In the following, we assume the reader is familiar with OFDM and how it works,
@@ -15,9 +15,9 @@ very little friction.
\ref page_packet_data has an example of how to use OFDM in a packet-based
receiver.
-\section conventions Conventions and Notations
+\section ofdm_conventions Conventions and Notations
-\subsection fftshift FFT Shifting
+\subsection ofdm_fftshift FFT Shifting
In all cases where OFDM symbols are passed between blocks, the default
behaviour
is to FFT-Shift these symbols, i.e. that the DC carrier is in the middle (to be
@@ -30,7 +30,7 @@ consistency's sake, this was chosen as a default for all
blocks that pass OFDM
symbols. Also, when viewing OFDM symbols, FFT-shifted symbols are in their
natural order, i.e. as they appear in the pass band.
-\subsection indexing Carrier Indexing
+\subsection ofdm_indexing Carrier Indexing
Carriers are always index starting at the DC carrier, which has the index 0
(you usually don't want to occupy this carrier). The carriers right of the
@@ -42,7 +42,7 @@ The carriers left of the DC carrier (with lower frequencies)
can be indexed
equivalent. The advantage of using negative carrier indices is that the
FFT length can be changed without changing the carrier indexing.
-\subsection carrieralloc Carrier and Symbol Allocation
+\subsection ofdm_carrieralloc Carrier and Symbol Allocation
Many blocks require knowledge of which carriers are allocated, and whether they
carry data or pilot symbols. GNU Radio blocks uses three objects for this,
typically
@@ -81,12 +81,12 @@ Note that \p pilot_symbols is longer than \p pilot_carriers
in this example--
this is valid, the symbols in \p pilot_symbols[2] will be mapped according
to \p pilot_carriers[0].
-\section detectsync Detection and Synchronisation
+\section ofdm_detectsync Detection and Synchronisation
Before anything happens, an OFDM frame must be detected, the beginning of OFDM
symbols must be identified, and frequency offset must be estimated.
-\section tx Transmitting
+\section ofdm_tx Transmitting
\image html ofdm_tx_core.png "Core elements of an OFDM transmitter"
@@ -110,7 +110,7 @@ Finally, the cyclic prefix is added to the OFDM symbols.
The gr::digital::ofdm_c
can also perform pulse shaping on the OFDM symbols (raised cosine flanks in the
time domain).
-\section rx Receiving
+\section ofdm_rx Receiving
On the receiver side, some more effort is necessary. The following flow graph
assumes that the input starts at the beginning of an OFDM frame and is
prepended
diff --git a/docs/doxygen/other/packet_txrx.dox
b/docs/doxygen/other/packet_txrx.dox
index afe8424..2a8aeae 100644
--- a/docs/doxygen/other/packet_txrx.dox
+++ b/docs/doxygen/other/packet_txrx.dox
@@ -1,6 +1,6 @@
/*! \page page_packet_data Packet Data Transmission
-\section intro Introduction
+\section packet_data_introduction Introduction
In many cases, the PHY layer of a digital transceiver uses <em>packets</em>to
break
down the transmission (as opposed to continuously broadcasting data), and GNU
Radio
@@ -11,7 +11,7 @@ With the tools provided in GNU Radio, simple digital packet
transmission schemes
are easily implemented, allowing the creation of packet-based communication
links
and even -networks.
-\section packetstructure Structure of a packet
+\section packet_data_structure Structure of a packet
Typically, a packet consists of the following elements:
@@ -26,7 +26,7 @@ The receiver has to perform a multitude of things to obtain
the packet again.
Most importantly, it has to convert an infinite stream (coming from the
receiver
device, e.g. a UHD source block) into a packetized, tagged stream.
-\section hpdemuxer The Header/Payload Demuxer and header parser
+\section packet_data_hpdemuxer The Header/Payload Demuxer and header parser
The key element to return back to packetized state is the
gr::digital::header_payload_demux.
At its first input, it receives a continuous stream of sample data, coming from
@@ -48,7 +48,7 @@ The knowledge of the header structure (i.e. how to turn a
sequence of bits into
a payload length etc.) is stored in an object of type
gr::digital::packet_header_default.
This must be passed to the header parser block.
-\section ofdm Packet receiver example: OFDM
+\section packet_data_ofdm Packet receiver example: OFDM
\image html example_ofdm_packet_rx.png "Example: OFDM Packet Receiver"
diff --git a/docs/doxygen/other/perf_counters.dox
b/docs/doxygen/other/perf_counters.dox
index 200d4dc..1a5bf40 100644
--- a/docs/doxygen/other/perf_counters.dox
+++ b/docs/doxygen/other/perf_counters.dox
@@ -1,6 +1,6 @@
/*! \page page_perf_counters Performance Counters
-\section Introduction
+\section pc_introduction Introduction
Each block can have a set of Performance Counters that the schedule
keeps track of. These counters measure and store information about
diff --git a/docs/doxygen/other/pfb_intro.dox b/docs/doxygen/other/pfb_intro.dox
index 75652d6..43bea77 100644
--- a/docs/doxygen/other/pfb_intro.dox
+++ b/docs/doxygen/other/pfb_intro.dox
@@ -1,13 +1,13 @@
/*! \page page_pfb Polyphase Filterbanks
-\section Introduction
+\section pfb_introduction Introduction
Polyphase filterbanks (PFB) are a very powerful set of filtering tools
that can efficiently perform many multi-rate signal processing
tasks. GNU Radio has a set of polyphase filterbank blocks to be used
in all sorts of applications.
-\section Usage
+\section pfb_Usage
See the documentation for the individual blocks for details about what
they can do and how they should be used. Furthermore, there are
@@ -78,7 +78,7 @@ examples (<b>gr-uhd/examples</b>) use this ability to create a
received matched filter or channel filter that also resamples the
signal.
-\section Examples
+\section pfb_examples Examples
The following is an example of the using the channelizer. It creates
the appropriate filter to channelizer 9 channels out of an original
@@ -93,7 +93,7 @@ run this example.
\include gr-filter/examples/channelize.py
-\section pfb_arb_resampl The PFB Arbitrary Resampler Kernel
+\section pfb_arb_resampler The PFB Arbitrary Resampler Kernel
GNU Radio has a PFB arbitrary resampler block that can be used to
resample a signal to any arbitrary and real resampling rate. The
diff --git a/docs/doxygen/other/pmt.dox b/docs/doxygen/other/pmt.dox
index 51e1865..6805b27 100644
--- a/docs/doxygen/other/pmt.dox
+++ b/docs/doxygen/other/pmt.dox
@@ -1,6 +1,6 @@
/*! \page page_pmt Polymorphic Types
-\section intro Introduction
+\section pmt_introduction Introduction
Polymorphic Types are opaque data types that are designed as generic
containers of data that can be safely passed around between blocks and
@@ -138,7 +138,7 @@ data types with the PMT library.
-\section datatype PMT Data Type
+\section pmt_datatype PMT Data Type
All PMTs are of the type pmt::pmt_t. This is an opaque container and
PMT functions must be used to manipulate and even do things like
@@ -185,7 +185,7 @@ The constants in the PMT library are:
- pmt::PMT_F - a PMT False
- pmt::PMT_NIL - an empty PMT (think Python's 'None')
-\section insert Inserting and Extracting Data
+\section pmt_insert Inserting and Extracting Data
Use pmt.h for a complete guide to the list of functions used to create
PMTs and get the data from a PMT. When using these functions, remember
@@ -219,7 +219,7 @@ Pairs, dictionaries, and vectors have different
constructors and ways
to manipulate them, and these are explained in their own sections.
-\section strings Strings
+\section pmt_strings Strings
PMTs have a way of representing short strings. These strings are
actually stored as interned symbols in a hash table, so in other
@@ -242,7 +242,7 @@ std::string s = pmt::symbol_to_string(str0);
\endcode
-\section tests Tests and Comparisons
+\section pmt_tests Tests and Comparisons
The PMT library comes with a number of functions to test and compare
PMT objects. In general, for any PMT data type, there is an equivalent
@@ -272,7 +272,7 @@ if(pmt::is_double(pmt_a))
\endcode
-\section dict Dictionaries
+\section pmt_dict Dictionaries
PMT dictionaries and lists of key:value pairs. They have a
well-defined interface for creating, adding, removing, and accessing
@@ -339,7 +339,7 @@ if(pmt.dict_has_key(a, key0) and pmt.eq(ref, pmt.PMT_NIL)):
print "Trouble! We have key0, but it returned PMT_NIL"
\endcode
-\section vectors Vectors
+\section pmt_vectors Vectors
PMT vectors come in two forms: vectors of PMTs and vectors of uniform
data. The standard PMT vector is a vector of PMTs, and each PMT can be
@@ -393,12 +393,12 @@ deal of harm. But it's only unlikely, not impossible.
Best to use
mutexes whenever manipulating data in a vector.
-\subsection blob BLOB
+\subsection pmt_blob BLOB
A BLOB is a 'binary large object' type. In PMT's, this is actually
just a thin wrapper around a u8vector.
-\section pairs Pairs
+\section pmt_pairs Pairs
Pairs are inspired by LISP 'cons' data types, so you will find the
language here comes from LISP. A pair is just a pair of PMT
@@ -412,7 +412,7 @@ objects. They are manipulated using the following functions:
- void pmt::set_cdr(pmt_t pair, pmt_t value): Stores value in the cdr field
-\section serdes Serializing and Deserializing
+\section pmt_serdes Serializing and Deserializing
It is often important to hide the fact that we are working with PMTs
to make them easier to transmit, store, write to file, etc. The PMT
@@ -461,7 +461,7 @@ readable, but the point of serializing is not to make a
human-readable
string. This is only done here as a test.
-\section printing Printing
+\section pmt_printing Printing
In Python, the __repr__ function of a PMT object is overloaded to call
'pmt::write_string'. This means that any time we call a formatted
diff --git a/docs/doxygen/other/stream_tags.dox
b/docs/doxygen/other/stream_tags.dox
index d48ec1d..01b91f5 100644
--- a/docs/doxygen/other/stream_tags.dox
+++ b/docs/doxygen/other/stream_tags.dox
@@ -1,6 +1,6 @@
/*! \page page_stream_tags Stream Tags
-\section Introduction
+\section stream_tags_introduction Introduction
GNU Radio was originally a streaming system with no other mechanism to
pass data between blocks. Streams of data are a model that work well
@@ -29,7 +29,7 @@ symbol and is used to identify the block that created the tag
(which
is usually the block's alias()).
-\section block_api_extensions API Extensions to the gr::block
+\section stream_tags_block_api_extensions API Extensions to the gr::block
To enable the stream tags, we have extended the API of gr::block to
understand \a absolute item numbers. In the data stream model, each
@@ -88,7 +88,7 @@ key from a particular input port between a certain range of
items (in
relative item time within the work function).
-\subsection add_item_tag Adding a Tag to a Stream
+\subsection stream_tags_add_item_tag Adding a Tag to a Stream
The two function calls to add items tags are defined here. We add a
tag to a particular output stream of the block. We can output them to
@@ -125,7 +125,7 @@ of the tag information in the function call:
\endcode
-\subsection get_item_tags Getting tags from a Stream
+\subsection stream_tags_get_item_tags Getting tags from a Stream
To get tags from a particular input stream, we again have two
functions we can use. Both of these pass back vectors of
@@ -155,7 +155,7 @@ key \a key.
\endcode
-\section tag_propagation Tag Propagation
+\section stream_tags_propagation Tag Propagation
Tags are propagated downstream from block to block like the normal
data streams. How blocks are actually moved depends on a specific
@@ -181,7 +181,7 @@ See the gr::block::tag_propagation_policy_t documentation
for details
on this enum type.
-\subsection tags_rate_changes Tag Propagation through Rate Changes
+\subsection stream_tags_rate_changes Tag Propagation through Rate Changes
When a tag is propagated through a block that has a rate change, the
item's offset in the data stream will change. The scheduler uses the
@@ -203,7 +203,7 @@ propagation internally.
In no case is the value of the tag modified when propagating through a
block. This becomes relevent when using \ref page_tagged_stream_blocks.
-\section tags_issues Notes on How to Use Tags
+\section stream_tags_issues Notes on How to Use Tags
Tags can be very useful to an application, and their use is
spreading. USRP sources generate tag information on the time, sample
diff --git a/docs/doxygen/other/tagged_stream_blocks.dox
b/docs/doxygen/other/tagged_stream_blocks.dox
index f9cadf8..4e75b29 100644
--- a/docs/doxygen/other/tagged_stream_blocks.dox
+++ b/docs/doxygen/other/tagged_stream_blocks.dox
@@ -1,6 +1,6 @@
/*! \page page_tagged_stream_blocks Tagged Stream Blocks
-\section intro Introduction
+\section tsb_introduction Introduction
A tagged stream block is a block that works on streamed, but packetized input
data.
Think of packet data transmission: A data packet consists of N bytes. However,
in
@@ -15,7 +15,7 @@ gr::sync_block etc.) in that they are driven by the input:
The PDU length tag te
operate, whereas other blocks are output-driven (the scheduler tries to fill
up the output
buffer are much as possible).
-\subsection howtheywork How do they work?
+\subsection tsb_howtheywork How do they work?
As the name implies, tagged stream blocks use tags to identify PDU boundaries.
On the first item of a streamed PDU, there \em must be a tag with a specific
@@ -26,7 +26,7 @@ The scheduler then takes care of everything. When the work
function is called, i
is guaranteed to contain exactly one complete PDU and enough space in the
output buffer for
the output.
-\subsection relatestootherblocks How do they relate to other block types (e.g.
sync blocks)?
+\subsection tsb_relatestootherblocks How do they relate to other block types
(e.g. sync blocks)?
Tagged stream blocks and sync blocks are really orthogonal concepts, and a
block could be
both (gr::digital::ofdm_frame_equalizer_vcvc is such a block). However,
because the work
@@ -41,7 +41,7 @@ The way gr::tagged_stream_block works, it is still beneficial
to specify a relat
if possible.
-\section creating Creating a tagged stream block
+\section tsb_creating Creating a tagged stream block
To create a tagged stream block, the block must be derived from
gr::tagged_stream_block.
Here's a minimal example of how the header file could look:
@@ -106,7 +106,7 @@ output items. Note how this relates to the fact that these
blocks are input-driv
These two overrides (\p work() and \p calculate_output_stream_length() ) are
what you need
for most tagged stream blocks. There are cases when you don't need to override
the latter
because the default behaviour is enough, and other cases where you have to
override more
-than these two functions. These are discussed in \ref adv_usage.
+than these two functions. These are discussed in \ref tsb_adv_usage.
Finally, this is part of the actual block implementation (heavily cropped
again, to highlight the relevant parts):
\code
@@ -179,7 +179,7 @@ signal processing code, the following things must be kept
in mind:
Don't forget to return WORK_CALLED_PRODUCE in that case.
-\subsection note_on_tp A note on tag propagation
+\subsection tsb_note_on_tp A note on tag propagation
Despite using tags for a special purpose, all tags that are not the length tag
are treated
exactly as before: use gr::block::set_tag_propagation_policy() in the
constructor.
@@ -208,7 +208,7 @@ to write the new length tag yourself. The key for the
output length tag is the s
on the input, if you don't want this, you must override
gr::tagged_stream_block::update_length_tags().
-\section connecting Connecting regular streaming blocks and tagged stream
blocks
+\section tsb_connecting Connecting regular streaming blocks and tagged stream
blocks
From the scheduler's point of view, all blocks are equivalent, and as long as
the I/O
signatures are compatible, all of these blocks can be connected.
@@ -231,13 +231,13 @@ Mixing block types: This is possible if none of the
regular stream blocks change
the rate. The ofdm_tx and ofdm_rx hierarchical blocks do this.
-\section adv_usage Advanced Usage
+\section tsb_adv_usage Advanced Usage
It is generally recommended to read the block documentation of
gr::tagged_stream_block.
A few special cases are described here:
-\subsection multiplelentags Multiple length tags
+\subsection tsb_multiplelentags Multiple length tags
In some cases, a single tag is not enough. One example is the OFDM receiver:
one OFDM frame contains a certain number of OFDM symbols, and another number of
bytes--these numbers are only
very loosely related, and one cannot be calculated from the other.
@@ -246,7 +246,7 @@ gr::digital::ofdm_serializer_vcc is such a block. It is
driven by the number of
but the output is determined by the number of complex symbols. In order to use
multiple length
tag keys, it overrides gr::tagged_stream_block::update_length_tags().
-\subsection backtogrblock Falling back to gr::block behaviour
+\subsection tsb_backtogrblock Falling back to gr::block behaviour
If, at compile-time, it is uncertain whether or not a block should be a
gr::tagged_stream_block, there is the possibility of falling back to gr::block
behaviour.
@@ -262,40 +262,40 @@ gr::tagged_stream_block::d_length_tag_key_str is empty is
a good choice.
gr::digital::ofdm_cyclic_prefixer implements this.
-\subsection otherwaysdetermineninput Other ways to determine the number of
input items
+\subsection tsb_otherwaysdetermineninput Other ways to determine the number of
input items
If the number of input items is not stored as a pmt::pmt_integer, but there is
a way to determine
it, gr::tagged_stream_block::parse_length_tags() can be overridden to figure
out the length
of the PDU.
-\section examples Examples
+\section tsb_examples Examples
-\subsection CRC32 CRC32
+\subsection tsb_CRC32 CRC32
Block: gr::digital::crc32_bb
This is a very simple block, and a good example to start with.
-\subsection ofdmeq OFDM Frame Equalizer
+\subsection tsb_ofdmeq OFDM Frame Equalizer
Block: gr::digital::ofdm_frame_equalizer_vcvc
This block would be a sync block if tagged stream blocks didn't exist. It also
uses more
than one tag to determine the output.
-\subsection muxer Tagged Stream Muxer
+\subsection tsb_muxer Tagged Stream Muxer
Block: gr::blocks::tagged_stream_mux
Use this to multiplex any number of tagged streams.
-\subsection ofdmprefixer Cyclic Prefixer (OFDM)
+\subsection tsb_ofdmprefixer Cyclic Prefixer (OFDM)
Block: gr::digital::ofdm_cyclic_prefixer
This block uses the gr::block behaviour fallback.
-\section troubleshooting Troubleshooting
+\section tsb_troubleshooting Troubleshooting
<b>My flow graph crashes with the error message "Missing length tag".</b>
diff --git a/gr-analog/doc/analog.dox b/gr-analog/doc/analog.dox
index 437eb05..b6ce1c2 100644
--- a/gr-analog/doc/analog.dox
+++ b/gr-analog/doc/analog.dox
@@ -1,6 +1,6 @@
/*! \page page_analog Analog Modulation
-\section Introduction
+\section analog_introduction Introduction
This is the gr-analog package. It contains all of the analog
modulation blocks, utilities, and examples. To use the analog blocks,
the Python namespaces is in gnuradio.analog, which would be normally
diff --git a/gr-audio/doc/audio.dox b/gr-audio/doc/audio.dox
index 6b3bbd9..d706bbb 100644
--- a/gr-audio/doc/audio.dox
+++ b/gr-audio/doc/audio.dox
@@ -1,6 +1,6 @@
/*! \page page_audio Audio Interface
-\section Introduction
+\section audio_introduction Introduction
The gnuradio audio component provides gr::audio::source and
gr::audio::sink blocks. The audio blocks stream floating point samples
@@ -40,7 +40,7 @@ after importing by using:
\endcode
-\section Usage
+\section audio_usage Usage
For an audio source, a typical OptionParser option and it's use looks
like:
diff --git a/gr-blocks/doc/blocks.dox b/gr-blocks/doc/blocks.dox
index 94b4a8e..fb7d3e6 100644
--- a/gr-blocks/doc/blocks.dox
+++ b/gr-blocks/doc/blocks.dox
@@ -1,6 +1,7 @@
/*! \page page_blocks Standard GNU Radio Blocks
-\section Introduction
+\section blocks_introduction Introduction
+
This is the gr-blocks package. It contains many of the generic,
standard, or simple blocks used for many aspects of building GNU Radio
flowgraphs. To use these blocks, the Python module is
diff --git a/gr-channels/doc/channels.dox b/gr-channels/doc/channels.dox
index 656d454..bb87ed5 100644
--- a/gr-channels/doc/channels.dox
+++ b/gr-channels/doc/channels.dox
@@ -1,6 +1,6 @@
/*! \page page_channels Channel Model Blocks
-\section Introduction
+\section channels_introduction Introduction
This is the gr-channels package. It contains signal processing blocks to
simulate channel models.
diff --git a/gr-digital/doc/digital.dox b/gr-digital/doc/digital.dox
index 5f2b3bb..08e6300 100644
--- a/gr-digital/doc/digital.dox
+++ b/gr-digital/doc/digital.dox
@@ -1,6 +1,6 @@
/*! \page page_digital Digital Modulation
-\section Introduction
+\section digtial_introduction Introduction
This is the gr-digital package. It contains all of the digital
modulation blocks, utilities, and examples. To use the digital blocks,
the Python namespaces is in gnuradio.digital, which would be normally
@@ -108,7 +108,7 @@ symbols. Each is Gray coded, but for a specific Gray coding
that is
hard-coded into the class.
-\subsection grc_constellations Constellation Objects in GRC
+\subsection digital_grc_constellations Constellation Objects in GRC
GRC provides two constellation representations that we can use to more
easily define and interact with constellation objects. These are
diff --git a/gr-fcd/doc/fcd.dox b/gr-fcd/doc/fcd.dox
index aca4dad..6f57ef9 100644
--- a/gr-fcd/doc/fcd.dox
+++ b/gr-fcd/doc/fcd.dox
@@ -1,6 +1,6 @@
/*! \page page_fcd FunCube Dongle Source
-\section Introduction
+\section fcd_introduction Introduction
This is the gr-fcd package. It contains a source block for the
FunCube Dongle hardware.
@@ -20,7 +20,7 @@ after importing by using:
help(fcd)
\endcode
-\section Dependencies
+\section fcd_dependencies Dependencies
The FCD blocks require the following dependencies.
diff --git a/gr-fec/doc/fec.dox b/gr-fec/doc/fec.dox
index 7fbbdda..5a3d12d 100644
--- a/gr-fec/doc/fec.dox
+++ b/gr-fec/doc/fec.dox
@@ -1,6 +1,6 @@
/*! \page page_fec Forward Error Correction
-\section Introduction
+\section fec_introductionIntroduction
This is the gr-fec package. It contains all of the forward error
correction (FEC) blocks, utilities, and examples. To use the FEC
diff --git a/gr-fft/doc/fft.dox b/gr-fft/doc/fft.dox
index 5bf612d..9ddf30d 100644
--- a/gr-fft/doc/fft.dox
+++ b/gr-fft/doc/fft.dox
@@ -1,6 +1,6 @@
/*! \page page_fft FFT Signal Processing Blocks
-\section Introduction
+\section fft_introduction Introduction
This is the gr-fft package. It contains signal processing blocks to
perform FFTs and FFT-related functionality.
@@ -20,7 +20,7 @@ after importing by using:
help(fft)
\endcode
-\section Dependencies
+\section fft_dependencies Dependencies
The FFT blocks require the following dependencies.
diff --git a/gr-filter/doc/filter.dox b/gr-filter/doc/filter.dox
index 8d465ab..e598d68 100644
--- a/gr-filter/doc/filter.dox
+++ b/gr-filter/doc/filter.dox
@@ -1,6 +1,6 @@
/*! \page page_filter Filter Signal Processing Blocks
-\section Introduction
+\section filter_introduction Introduction
This is the gr-filter package. It contains signal processing blocks to
perform filtering operations.
@@ -20,12 +20,12 @@ after importing by using:
help(filter)
\endcode
-\section Dependencies
+\section filter_dependencies Dependencies
The filter blocks depend on \ref page_fft.
-\section Usage
+\section filter_usage Usage
There are many filter blocks and kernels in GNU Radio. Filter blocks
are standard GNU Radio blocks that fit into a flowgraph. Filter
@@ -56,7 +56,7 @@ filter).
\li PFB arbitrary resampler (see pfb_arb_resampler.h): performs
arbitrary resampling (i.e., using any real number) using the polyphase
-filterbank method. \sa \ref pfb_arb_resampl
+filterbank method. \sa \ref pfb_arb_resampler
\li Polyphase filterbank (see polyphase_filterbank.h): a set of base
classes with standard functions for building many polyphase filterbank
diff --git a/gr-qtgui/doc/qtgui.dox b/gr-qtgui/doc/qtgui.dox
index 63530d4..1d4c309 100644
--- a/gr-qtgui/doc/qtgui.dox
+++ b/gr-qtgui/doc/qtgui.dox
@@ -1,6 +1,6 @@
/*! \page page_qtgui QT Graphical User Interface
-\section Introduction
+\section qtgui_introduction Introduction
This is the gr-qtgui package. It contains various QT-based graphical
user interface blocks that add graphical sinks to a GNU Radio
@@ -22,7 +22,7 @@ by using:
help(qtgui)
\endcode
-\subsection Blocks
+\subsection qtgui_blocks Blocks
There are a number of available QTGUI blocks for different plotting
purposes. These include:
@@ -123,7 +123,7 @@ accordingly offering more freedom. This should be a problem
in a
limited number of scenarios, but a log INFO level message is produced
when asking for the delay outside of the available range.
-\section Dependencies
+\section qtgui_dependencies Dependencies
The QT GUI blocks require the following dependencies.
@@ -134,7 +134,7 @@ The QT GUI blocks require the following dependencies.
\li Qwt (version >= 5.2)
\li PyQwt5 for Qt4 (version >= 5.2)
-\section Usage
+\section qtgui_usage Usage
To use the qtgui interface, a bit of boiler-plate lines must be
included. First, the sink is defined, then it must be exposed from C++
@@ -181,7 +181,7 @@ style, markers, etc.), the ability to start and stop the
display, the
ability to save to a file, and other plot-specific controls (FFT size
for the frequency and waterfall plots, etc.).
-\section Configuration
+\section qtgui_configuration Configuration
There is currently a single configuration option in the preferences
files to set the rendering engine of the QTGUI sinks. Located in
diff --git a/gr-uhd/doc/uhd.dox b/gr-uhd/doc/uhd.dox
index 2b7f308..da6d9d4 100644
--- a/gr-uhd/doc/uhd.dox
+++ b/gr-uhd/doc/uhd.dox
@@ -1,6 +1,7 @@
/*! \page page_uhd UHD Interface
-\section Introduction
+\section uhd_introduction Introduction
+
This is the GNU Radio UHD package. It is the interface to the UHD
library to connect to and send and receive data between the Ettus
Research, LLC product line. To use the UHD blocks, the Python
@@ -78,7 +79,7 @@ Command name | Value Type | Description
`gain` | double | Sets the Tx or Rx gain (in dB). Defaults to all
channels.
-\section Configuring a UHD object
+\section uhd_configuring Configuring a UHD object
A typical option parser setup for a UHD device looks like
diff --git a/gr-vocoder/doc/vocoder.dox b/gr-vocoder/doc/vocoder.dox
index e3be774..214d652 100644
--- a/gr-vocoder/doc/vocoder.dox
+++ b/gr-vocoder/doc/vocoder.dox
@@ -1,6 +1,6 @@
/*! \page page_vocoder Voice Coders and Decoders (Vocoders)
-\section Introduction
+\section vocoder_introduction Introduction
This is the gr-vocoder package. It contains all available vocoders in
GNU Radio. The Python namespaces is in gnuradio.vocoder, which would be
@@ -20,7 +20,7 @@ by using:
help(vocoder)
\endcode
-\section using_vocoders Using the vocoders
+\section vocoders_using Using the vocoders
Note that most vocoders use short inputs instead of floats. This means you
must convert audio signals from float to short by using a type conversion
diff --git a/gr-zeromq/docs/zeromq.dox b/gr-zeromq/docs/zeromq.dox
index 3709afc..d37d8f5 100644
--- a/gr-zeromq/docs/zeromq.dox
+++ b/gr-zeromq/docs/zeromq.dox
@@ -1,6 +1,6 @@
/*! \page page_zeromq ZeroMQ
-\section Introduction
+\section zmq_introduction Introduction
This is the gr-zeromq package. It contains bindings for ZeroMQ.