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

[Feng Andrew Ge]

Achilleas,

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.

Regards,
Andrew




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
>         <address@hidden>
> Message-ID:<address@hidden>
> Content-Type: text/plain; charset=GB2312
>
> inter,
>
> 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