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

[Venkat Vinod]

Hi Achilleas Anastasopoulos,

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

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> wrote:

=========
*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

--
Venkat Vinod Patcha
Tel: +1 225 328 7356