[Top][All Lists]

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

Re: [Discuss-gnuradio] Problem in framer_sink

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] Problem in framer_sink
Date: Tue, 13 Mar 2007 17:04:03 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)


there are many options. One is a (31,16) BCH code
with 3 bits error correction capability.

It would have been nice to have a generic BCH encoder/decoder
block that can also do mixed error correction/detection...

In the absence of that, we can always use a rate 1/2 convolutional code
off the self.


Eric Blossom wrote:
On Sun, Mar 11, 2007 at 02:59:58PM -0700, Johnathan Corgan wrote:

Achilleas Anastasopoulos wrote:

Regarding protecting the length field, a rate 1/2 linear block code
can always be used.

The way it is now it is a repetition code which offers little

As-is there is no FEC in in the digital packet code anyway.  When we add
that, we'll likely do it for the complete header and payload at the same

I don't think so.  We need to be able to reliably determine the length
of the packet (which we get from the header), to find the end of the

I think Achilleas' suggestion of a rate 1/2 block code for the header is
the way to go.  Achilleas, do you have a specific suggestion?  Golay
would protect 12-bits.  Any off-the-shelf code that does a good job on
16-bits of payload?

Also, splitting the PHY layer framing from the handling of the payload
CRC / FEC allows upper layers to be independent of the low-level
framing mechanism.


reply via email to

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