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