Problem in designing Coded OFDM Rxr (using, trellis-viterbi )

GNU Radio
1

=========
Problem:
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
metrics
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
gr-trellis!

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,
Achilleas

2

Hi Achilleas A.,

       Thanks for the reply and clarification on trellis metric

computation.

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 ??

    • 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 A.
<[email protected]

3

Venkat,

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 8K
    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 8K trellis steps and
    produces 8    K bytes (each worth 2 bits), so you will probably want to
    pack them into 8K/4=2K 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…

Best
Achilleas