[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Problem in designing Coded OFDM Rxr (using, trell

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] Problem in designing Coded OFDM Rxr (using, trellis-viterbi )
Date: Wed, 17 Nov 2010 13:23:47 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20101027 Thunderbird/3.1.6


I assume you are working with a (2,1) trellis code, ie,
1 bit in two bits out.
I also assume that you unpack each input byte to 8 single bits (carried in a byte) before trellis encoding and you pack every 4 2-bit worth bytes into a single byte after trellis encoding. This means that for every information bearing byte (before unpacking) you should get 2 coded bytes (after packing).
Further I will assume that you work with the trellis_encoder_bb block.

In order to design a meaningful system you have to look at the
"equivalent inner channel" you have created between the trellis encoder and the viterbi decoder, including the packing/message queuing/ofdm modulation/demodulation, etc, up until the input to the metric calculation block (or the input of the viterbi_combined block). This "equivalent inner channel" has to be a byte-in byte-out channel, where each byte is carrying only 2 bits.
Once you do that the rest is easy: the metrics you want to define are
"symbol-wise Hamming distance", and the viterbi block will do its job.

So first make sure that your INNER channel is as specified above; then you can move on to adding error correction on this channel.

Regarding your questions:

1) I do not understand the meaning of "I doubt in losing packet modularity". You do not loose anything in this process...

2) Figure out how many info bits you want to input to the trellis encoder (for the encoder info bits are anything at its input; the encoder does not know/care if these bits represent flags/sync patterns etc for the outer channels). Let's assume that you want to input 8*K such bits. These are probably generated in the form of packed bytes from the outer system, so you need to collect K bytes, unpack them to 8*K single-bit bytes and feed them to the CC. The CC runs for 8*K trellis steps and produces 8*K bytes (each worth 2 bits), so you will probably want to pack them into 8*K/4=2*K packed bytes. You see : K info bytes resulted in 2*K output bytes, which is consistent with rate=1/2.

3) Here is the idea:
if these headers are added BEFORE trellis encoding, then they should be treated as info bits that will be encoded by the CC and decoded by the Viterbi, so you should NOT remove them before Viterbi decoding, but AFTER. If these headers are added AFTER the trellis block (ie, to aid synchronization in the inner modulation etc) then these should be removed BEFORE the viterbi block. How to do this is not part of gr-trellis...


On 11/17/2010 2:28 AM, Venkat Vinod wrote:
Hi Achilleas Anastasopoulos,

            Thanks for the reply and clarification on trellis metric
I tried your  idea  to connect the ofdm demod block to trellis metric
(to perform both hamming and euclidean distance metrics;as the soft or
hard decision decoding can be performed on output ofdm symbols.)and
connect it to viterbi ,but it was unsuccessful. So,*I'm suspicious about *
*the approach of implementation and integrity of packet.*

For Transmission :
I  have achieved the transmitter blocks by passing the packet
(containing  header,payload and CRC) into a message queue that counts
the incoming items, when reached certain limit passes the message to a
trellis encoder that  is bypassed from a unpack to pack module(for
proper input stream to the encoder).The output  of trellis encoder is
packed into a message and passed through the ofdm_mod block.

*Flow Graph Model *
*packets from message source --------> pack to unpack---------->trellis
encoder --------> unpack to pack------->stream to vector
--------->packets to a message sink
ofdm_mod(packets from message sink) -------> ampl--------> usrp.*

Suppose my uncoded packet size is of 256 bytes and if my coding rate is
1/2, then the output packet size of trellis encoder should be 512 bytes.

Questions ??
1. * I doubt in losing packet modularity in  my approach for packing
byte stream of coded data back into a packet??? *
*2. Also, i used a trellis step size for decoder as K=256 * 8(packet
size in bits) /1 (bits per symbol).*
*Is it correct ??*
*3. The removal of header and packing back (payload and CRC) that is
usually done in ofdm_frame sink should be performed after the viterbi
decoding.How can I achieve it ??*

For question 3.I added a access code to my packet, so at
the receiver the output of viterbi is provided to a access_ correlator
block and then to a framer_sink_1 block(similar to the benchmark_tx,py
  and benchmark_rx.py implementation).Is it correct ??

Hope you respond to the email.Thanks for the help.

On Fri, Nov 12, 2010 at 1:23 PM, Achilleas Anastasopoulos
<address@hidden <mailto:address@hidden>> wrote:

    The channel decoding should be  performed on the output of ofdm_demod
    block(ofdm_frame_sink ; the last block   that produces demodulated OFDM
    symbols). But, the combined_ viterbi block performs the demodulation
    of BPSK
    or QPSK based on the signal constellation and provides appropriate
    to viterbi_algorithm.

    This is NOT true. The Viterbi block (combined or not) can work with
    a number of different metrics (eg, symbol wise Hamming distance!)
    So you can implement your approach with this block as well.

    In fact this kind of modularity was the MAIN design feature of the

    Of course, this does not mean that your "approach" is not going to
    work; indeed you are trying to perform
    soft-input decoding which is better.

    let me know if you have further problems with that,

Venkat Vinod Patcha
Tel: +1 225 328 7356

reply via email to

[Prev in Thread] Current Thread [Next in Thread]