diff options
| author | Martin Braun <martin.braun@kit.edu> | 2013-05-14 18:23:13 +0200 |
|---|---|---|
| committer | Martin Braun <martin.braun@kit.edu> | 2013-05-15 09:44:06 +0200 |
| commit | 18c4026ccaa010109b06a91037b4019c96c67802 (patch) | |
| tree | ce904f173b5b62cce210ef53052549c5cab05d15 /docs/doxygen/other | |
| parent | d39cb0f9cd182e96ecbc8ca51675855b46d8ac48 (diff) | |
docs: Manual pages for OFDM and packet tx/rx
Diffstat (limited to 'docs/doxygen/other')
| -rw-r--r-- | docs/doxygen/other/main_page.dox | 1 | ||||
| -rw-r--r-- | docs/doxygen/other/ofdm.dox | 143 |
2 files changed, 144 insertions, 0 deletions
diff --git a/docs/doxygen/other/main_page.dox b/docs/doxygen/other/main_page.dox index 8e35cb3c87..85c3ff4fac 100644 --- a/docs/doxygen/other/main_page.dox +++ b/docs/doxygen/other/main_page.dox @@ -46,6 +46,7 @@ More details on GNU Radio concepts: \li \ref volk_guide \li \ref page_pfb \li \ref page_tagged_stream_blocks +\li \ref page_ofdm \li \ref page_packet_data diff --git a/docs/doxygen/other/ofdm.dox b/docs/doxygen/other/ofdm.dox new file mode 100644 index 0000000000..62efa0cce5 --- /dev/null +++ b/docs/doxygen/other/ofdm.dox @@ -0,0 +1,143 @@ +/*! \page page_ofdm OFDM + +\section intro 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, +for an introduction to OFDM refer to standard textbooks on digital communication. + +The blocks are designed in a very generic fashion. As a developer, this means that +often, a desired functionality can be achieved by correct parametrization of the +available blocks, but in some cases, custom blocks have to be included. The design +of the OFDM components is such that adding own functionality is possible with +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 + +\subsection 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 +precise, it is on carrier \f$\lfloor N/2 \rfloor\f$ where N is the FFT length and +carrier indexing starts at 0). + +The reason for this convention is that some blocks require FFT-shifted ordering +of the symbols to function (such as gr::digital::ofdm_chanest_vcvc), and for +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 + +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 +DC carrier (the ones at higher frequencies) are indexed with 1 through N/2-1 +(N being the FFT length again). + +The carriers left of the DC carrier (with lower frequencies) can be indexed +-N/2 through -1 or N/2 through N-1. Carrier indices N-1 and -1 are thus +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 + +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 +called \p occupied_carriers (for the data symbols), \p pilot_carriers and +\p pilot_symbols (for the pilot symbols). + +Every one of these objects is a vector of vectors. \p occupied_carriers and +\p pilot_carriers identify the position within a frame where data and pilot +symbols are stored, respectively. + +\p occupied_carriers[0] identifies which carriers are occupied on the first +OFDM symbol, \p occupied_carriers[1] does the same on the second OFDM symbol etc. + +Here's an example: +\code + occupied_carriers = ((-2, -1, 1, 3), (-3, -1, 1, 2)) + pilot_carriers = ((-3, 2), (-2, 3)) +\endcode +Every OFDM symbol carries 4 data symbols. On the first OFDM symbol, they are on carriers -2, -1, 1 and 3. +Carriers -3 and 2 are not used, so they are where the pilot symbols can be placed. +On the second OFDM symbol, the occupied carriers are -3, -1, 1 and 2. The pilot +symbols must thus be placed elsewhere, and are put on carriers -2 and 3. + +If there are more symbols in the OFDM frame than the length of \p occupied_carriers +or \p pilot_carriers, they wrap around (in this example, the third OFDM symbol +uses the allocation in \p occupied_carriers[0]). + +But how are the pilot symbols set? This is a valid parametrization: +\code + pilot_symbols = ((-1, 1j), (1, -1j), (-1, 1j), (-1j, 1)) +\endcode + +The position of these symbols are thos in \p pilot_carriers. So on the first OFDM +symbol, carrier -3 will transmit a -1, and carrier 2 will transmit a 1j. +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 + +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 + +\image html ofdm_tx_core.png "Core elements of an OFDM transmitter" + +This image shows a very simple example of a transmitter. It is assumed that the +input is a stream of complex scalars with a length tag, i.e. the transmitter +will work on one frame at a time. + +The first block is the carrier allocator (gr::digital::ofdm_carrier_allocator_cvc). +This sorts the incoming complex scalars onto OFDM carriers, and also places the +pilot symbols onto the correct positions. +There is also the option to pass OFDM symbols which are prepended in front of every +frame (i.e. preamble symbols). These can be used for detection, synchronisation +and channel estimation. + +The carrier allocator outputs OFDM symbols (i.e. complex vectors of FFT length). +These must be converted to time domain signals before continuing, which is why +they are piped into an (I)FFT block. Note that because all the OFDM symbols are +treated in the shifted form, the IFFT block must be shifting as well. + +Finally, the cyclic prefix is added to the OFDM symbols. The gr::digital::ofdm_cyclic_prefixer +can also perform pulse shaping on the OFDM symbols (raised cosine flanks in the +time domain). + +\section 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 +with a Schmidl & Cox preamble for coarse frequency correction and channel +estimation. Also assumed is that the fine frequency offset is already corrected +and that the cyclic prefix has been removed. The latter can be achieved by a +gr::digital::header_payload_demux, the former can be done using a +gr::digital::ofdm_sync_sc_cc. + +\image html ofdm_rx_core.png "Core elements of an OFDM receiver" + +First, an FFT shifts the OFDM symbols into the frequency domain, where the signal +processing is performed (the OFDM frame is thus in the memory in matrix form). +It is passed to a block that uses the preambles to perform channel estimation +and coarse frequency offset. Both of these values are added to the output stream +as tags; the preambles are then removed from the stream and not propagated. + +Note that this block does not correct the OFDM frame. Both the coarse frequency +offset correction and the equalizing (using the initial channel state estimate) +are done in the following block, gr::digital::ofdm_frame_equalizer_vcvc. +The interesting property about this block is that it uses a +gr::digital::ofdm_equalizer_base derived object to perform the actual equalization. + +The last block in the frequency domain is the gr::digital::ofdm_serializer_vcc, +which is the inverse block to the carrier allocator. +It plucks the data symbols from the \p occupied_carriers and outputs them as a +stream of complex scalars. These can then be directly converted to bits, or passed +to a forward error correction decoder. + +*/ |