[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: Feng Andrew Ge
Subject: Re: [Discuss-gnuradio] How to decode the convolutional code in the GRC
Date: Fri, 01 Apr 2011 10:14:48 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8


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.


reply via email to

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