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.
author: Tom Rondeau <tom@trondeau.com> 2015-03-23 14:32:21 -0700
committer: Tom Rondeau <tom@trondeau.com> 2015-03-23 14:32:21 -0700
commit: ce73dafb67491bc785ade42c0eb4e84cc1a273ac (patch)
tree: 91d3d6c9c1406acd1d7fca9991d4b7f29ac8f5fb /docs/doxygen/other
parent: f042e44d18c481e7e2ca37895afbd6ecf42061a3 (diff)
10 files changed, 69 insertions, 69 deletions
diff --git a/docs/doxygen/other/ctrlport.dox b/docs/doxygen/other/ctrlport.dox
index 8db156dfbd..64bf9f7d38 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 e29adf306e..4958e08aaa 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 47d6768ea0..df116c2ba1 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 62efa0cce5..9a3a18fab8 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 afe84240ff..2a8aeae51e 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 200d4dcf96..1a5bf40cba 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 75652d65bf..43bea77777 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 51e1865d39..6805b27a8a 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 d48ec1ddee..01b91f5e21 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 f9cadf8196..4e75b29c6b 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>
author	Tom Rondeau <tom@trondeau.com>	2015-03-23 14:32:21 -0700
committer	Tom Rondeau <tom@trondeau.com>	2015-03-23 14:32:21 -0700
commit	ce73dafb67491bc785ade42c0eb4e84cc1a273ac (patch)
tree	91d3d6c9c1406acd1d7fca9991d4b7f29ac8f5fb /docs/doxygen/other
parent	f042e44d18c481e7e2ca37895afbd6ecf42061a3 (diff)