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 <[email protected]
> 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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
