/*! \page page_ctrlport ControlPort

This is the ControlPort package. It is a tool to create distributed

control applications for GNU Radio. It provides blocks that can be

/*! \page page_metadata Metadata Information

Metadata files have extra information in the form of headers that

carry metadata about the samples in the file. Raw, binary files carry

pairs out of tags from the flowgraph.

GNU Radio currently supports two types of metadata files:

with no interruptions in the data.

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

keep the sample times exact.

Metadata files are created using gr::blocks::file_meta_sink. The

default behavior is to create a single file with inline headers as

interface.

The file metadata consists of a static mandatory header and a dynamic

optional extras header. Each header is a separate PMT

this header just like the first.

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

};

\endcode

The extras section is an optional segment of the header. If 'strt' ==

METADATA_HEADER_SIZE, then there is no extras. Otherwise, it is simply

necessary to know the data type.

GNU Radio comes with a couple of utilities to help in debugging and

manipulating metadata files. There is a general parser in Python that

data with '.hdr' appended to it.

Examples are located in:

/*! \page page_msg_passing Message Passing

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

(PMTs) in GNU Radio. For further information about these data

structures, see the page \ref page_pmt.

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

message to that block's message queue.

A subscriber block must declare a message handler function to process

the messages that are posted to it. After using the

We give an example of using this below.

From the flowgraph level, we have instrumented a gr::hier_block2::msg_connect

method to make it easy to subscribe blocks to other blocks'

it is this function that is used to process the message.

ADD STUFF HERE

The following is snippets of code from blocks current in GNU Radio

that take advantage of message passing. We will be using

passed along. The next section describes how PDUs can be passed into a

flowgraph using the gr::blocks::pdu_to_tagged_stream block.

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

/*! \page page_ofdm OFDM

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,

\ref page_packet_data has an example of how to use OFDM in a packet-based

receiver.

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

symbols. Also, when viewing OFDM symbols, FFT-shifted symbols are in their

natural order, i.e. as they appear in the pass band.

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

equivalent. The advantage of using negative carrier indices is that the

FFT length can be changed without changing the carrier indexing.

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

this is valid, the symbols in \p pilot_symbols[2] will be mapped according

to \p pilot_carriers[0].

Before anything happens, an OFDM frame must be detected, the beginning of OFDM

symbols must be identified, and frequency offset must be estimated.

\image html ofdm_tx_core.png "Core elements of an OFDM transmitter"

can also perform pulse shaping on the OFDM symbols (raised cosine flanks in the

time domain).

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

/*! \page page_packet_data Packet Data Transmission

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

are easily implemented, allowing the creation of packet-based communication links

and even -networks.

Typically, a packet consists of the following elements:

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.

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

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.

\image html example_ofdm_packet_rx.png "Example: OFDM Packet Receiver"

/*! \page page_perf_counters Performance Counters

Each block can have a set of Performance Counters that the schedule

keeps track of. These counters measure and store information about

/*! \page page_pfb Polyphase Filterbanks

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.

See the documentation for the individual blocks for details about what

they can do and how they should be used. Furthermore, there are

received matched filter or channel filter that also resamples the

signal.

The following is an example of the using the channelizer. It creates

the appropriate filter to channelizer 9 channels out of an original

\include gr-filter/examples/channelize.py

GNU Radio has a PFB arbitrary resampler block that can be used to

resample a signal to any arbitrary and real resampling rate. The

/*! \page page_pmt Polymorphic Types

Polymorphic Types are opaque data types that are designed as generic

containers of data that can be safely passed around between blocks and

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

- pmt::PMT_F - a PMT False

- pmt::PMT_NIL - an empty PMT (think Python's 'None')

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

to manipulate them, and these are explained in their own sections.

PMTs have a way of representing short strings. These strings are

actually stored as interned symbols in a hash table, so in other

\endcode

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

\endcode

PMT dictionaries and lists of key:value pairs. They have a

well-defined interface for creating, adding, removing, and accessing

print "Trouble! We have key0, but it returned PMT_NIL"

\endcode

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

mutexes whenever manipulating data in a vector.

A BLOB is a 'binary large object' type. In PMT's, this is actually

just a thin wrapper around a u8vector.

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

- void pmt::set_cdr(pmt_t pair, pmt_t value): Stores value in the cdr field

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

string. This is only done here as a test.

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

/*! \page page_stream_tags Stream Tags

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

is usually the block's alias()).

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

relative item time within the work function).

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

\endcode

To get tags from a particular input stream, we again have two

functions we can use. Both of these pass back vectors of

\endcode

Tags are propagated downstream from block to block like the normal

data streams. How blocks are actually moved depends on a specific

on this enum type.

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

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.

Tags can be very useful to an application, and their use is

spreading. USRP sources generate tag information on the time, sample

/*! \page page_tagged_stream_blocks Tagged Stream Blocks

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

operate, whereas other blocks are output-driven (the scheduler tries to fill up the output

buffer are much as possible).

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

is guaranteed to contain exactly one complete PDU and enough space in the output buffer for

the output.

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

if possible.

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:

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

Finally, this is part of the actual block implementation (heavily cropped again, to highlight the relevant parts):

\code

Don't forget to return WORK_CALLED_PRODUCE in that case.

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.

on the input, if you don't want this, you must override gr::tagged_stream_block::update_length_tags().

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.

the rate. The ofdm_tx and ofdm_rx hierarchical blocks do this.

It is generally recommended to read the block documentation of gr::tagged_stream_block.

A few special cases are described here:

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.

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().

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.

gr::digital::ofdm_cyclic_prefixer implements this.

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.

Block: gr::digital::crc32_bb

This is a very simple block, and a good example to start with.

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.

Block: gr::blocks::tagged_stream_mux

Use this to multiplex any number of tagged streams.

Block: gr::digital::ofdm_cyclic_prefixer

This block uses the gr::block behaviour fallback.

<b>My flow graph crashes with the error message "Missing length tag".</b>

/*! \page page_analog Analog Modulation

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

<import>from gnuradio import analog</import>

<make>analog.ctcss_squelch_ff($rate, $freq, $level, $len, $ramp, $gate)</make>

<callback>set_level($level)</callback>

<param>

<name>Sampling Rate (Hz)</name>

<key>rate</key>

virtual float level() const = 0;

virtual void set_level(float level) = 0;

virtual int len() const = 0;

virtual int ramp() const = 0;

virtual void set_ramp(int ramp) = 0;

return -1;

}

ctcss_squelch_ff_impl::ctcss_squelch_ff_impl(int rate, float freq, float level,

int len, int ramp, bool gate)

: block("ctcss_squelch_ff",

{

d_freq = freq;

d_level = level;

// Default is 100 ms detection time

if(len == 0)

else

float f_l, f_r;

d_mute = true;

}

}

}

} /* namespace analog */

} /* namespace gr */

float d_freq;

float d_level;

int d_len;

bool d_mute;

fft::goertzel *d_goertzel_l;

fft::goertzel *d_goertzel_c;

fft::goertzel *d_goertzel_r;

protected:

virtual void update_state(const float &in);

std::vector<float> squelch_range() const;

float level() const { return d_level; }

int len() const { return d_len; }

int ramp() const { return squelch_base_ff_impl::ramp(); }

void set_ramp(int ramp) { squelch_base_ff_impl::set_ramp(ramp); }

d_pwr = d_iir.filter(in.real()*in.real()+in.imag()*in.imag());

}

} /* namespace analog */

} /* namespace gr */

std::vector<float> squelch_range() const;

double threshold() const { return 10*log10(d_threshold); }

int ramp() const { return squelch_base_cc_impl::ramp(); }

void set_ramp(int ramp) { squelch_base_cc_impl::set_ramp(ramp); }

void

squelch_base_cc_impl::set_ramp(int ramp)

{

d_ramp = ramp;

}

void

squelch_base_cc_impl::set_gate(bool gate)

{

d_gate = gate;

}

int j = 0;

for(int i = 0; i < noutput_items; i++) {

update_state(in[i]);

/*! \page page_audio Audio Interface

The gnuradio audio component provides gr::audio::source and

gr::audio::sink blocks. The audio blocks stream floating point samples

\endcode

For an audio source, a typical OptionParser option and it's use looks

like:

/*! \page page_blocks Standard GNU Radio Blocks

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

/*! \page page_channels Channel Model Blocks

This is the gr-channels package. It contains signal processing blocks to

simulate channel models.

/*! \page page_digital Digital Modulation

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

hard-coded into the class.

GRC provides two constellation representations that we can use to more

easily define and interact with constellation objects. These are

dtv_dvbt2_paprtr_cc.xml

dtv_dvbt2_p1insertion_cc.xml

dtv_dvbt2_miso_cc.xml

DESTINATION ${GRC_BLOCKS_DIR}

COMPONENT "dtv_python"

)

<block>dtv_dvbt2_p1insertion_cc</block>

<block>dtv_dvbt2_miso_cc</block>

</cat>

</cat>

</cat>

dvbt2_paprtr_cc.h

dvbt2_p1insertion_cc.h

dvbt2_miso_cc.h

DESTINATION ${GR_INCLUDE_DIR}/gnuradio/dtv

COMPONENT "dtv_devel"

)

dvbt2/dvbt2_paprtr_cc_impl.cc

dvbt2/dvbt2_p1insertion_cc_impl.cc

dvbt2/dvbt2_miso_cc_impl.cc

)

if(ENABLE_GR_CTRLPORT)

#include "atsc_interleaver_impl.h"

#include "gnuradio/dtv/atsc_consts.h"

namespace gr {

namespace dtv {