[Top][All Lists]

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

Re: [Discuss-gnuradio] How to decode the convolutional code in the GRC

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] How to decode the convolutional code in the GRC
Date: Fri, 01 Apr 2011 10:55:51 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

Regarding interleaver, this is already implemented in gr-trellis in
a very general (block) form (any kind of permutation of n units of arbitrary byte length. See interleaver.h/cc and trellis_permitation.h/cc/i files for details.

Regarding BCH it would be nice to have a gnuradio "module"
with general block coding including BCH codes.
If the code exists out there, it should
be pretty straightforward to import it as gnuradio "blocks".
But someone has to do it...

I do not remember the 2007 discussions but one point to be made is the following: gr_trellis as well as some other blocks in gnuradio are providing generic modules to do things. The examples you mention provide complete transmission "systems" and thus there is no ONE BEST way to do things...

For example, synchronization is NOT the task of the viterbi algorithm.
If you want to do joint decoding and synchronization you have to write a different block and it is bound to be specific to the application (well....to a large extend...) These are more complex systems and i don't think that SDR is at this level of sophistication at this point: just take a look at how simple DPSK transmission/reception is implemented: all tasks (frequency/phase sync, timing sync, decoding, etc) are implemented separately; forget about joint decoding and synchronization...


On 4/1/2011 10:14 AM, Feng Andrew Ge wrote:

I have looked at the gr-trellis code and my understanding is that the
code is used mainly for simulation in GNU Radio (signals don't go over
the air). I was thinking about integrating the code into the digital
examples, e.g., transmit_path.py and receiver_path.py. However, I have
two concerns: (a) its computational complexity might be too high at a
high data rate, e.g., 500kb/s, therefore introducing big delays; (b)
there is no synchronization for recognizing the start and end bits of
encoded bit blocks. Further, I also want to introduce interleaver for
handling burst errors.

To resolve the computational complexity, as alternative to trellis code,
I am thinking about linear block code. I found your 2007 online
discussion with Eric and Johnathan about using BCH code for the packet
header (two lengths) --- unfortunately it seems that no following work
happened after the discussion. Would you please give some comments about
using BCH code in the digital examples? For example, what might be a
good code, BCH(31, 16), BCH(127, 36), or extended Golay codes?

Further, do you have any thought about interleaver implementation
together with a linear block code?

Finally, in the 2007 discussion between you and Eric, Eric preferred
that the access code should not be encoded. Currently the access coded
is recognized in the receiver_path.py by a correlator with a default
threshold of 12 based on Hamming distance. Is this a good approach if we
introduce coding for the packet header plus the payload with CRC?

Of course, any other comments/thought will be quite welcomed.


On 03/14/2011 12:00 PM, address@hidden wrote:
Date: Mon, 14 Mar 2011 10:11:44 -0400
From: Achilleas Anastasopoulos<address@hidden>
Subject: Re: [Discuss-gnuradio] How to decode the convolutional code,
in the GRC
To: intermilan<address@hidden>, gnuradio mailing list
Content-Type: text/plain; charset=GB2312


as i said in my previous email, you just have to consider the equivalent
channel (the fact that it is noiseless is irrelevant in this discussion)
from the output of the FSM encoder to the input of the VA.
It seems you prefer to call it equivalent "modulator"; that's fine!
Once you realize what this equivalent channel/modulator is
(what is its input/output alphabet and what kind of symbols it
inputs/outputs) then it will be strainghtforward to see what the viterbi
decoder block should look like.
If I were to guess from your description, i would say that your
equivallent channel
has input/output alphabet equal to the output alphabet of the FSM.
Its input is a coded symbol from the FSM encoder and its output is also
such a symbol from the packet decoder.
So all you need is to do VA with symbol-wise hamming distance as your
metric. You can achieve that using the viterbi_combined block with
a trivial 1-D chunks to symbols block (identity) and the appropriate
parameter for the metric_type.


Achilleas Anastasopoulos                        
Associate Professor
EECS Department               Voice : (734)615-4024
UNIVERSITY OF MICHIGAN        Fax   : (734)763-8041
Ann Arbor, MI 48109-2122      E-mail: address@hidden
URL: http://www.eecs.umich.edu/~anastas/        

reply via email to

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