[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:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 |
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 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...
Best
Achilleas
On 11/17/2010 2:28 AM, Venkat Vinod wrote:
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 <mailto: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