Re: [Discuss-gnuradio] Problem in framer_sink

[Achilleas Anastasopoulos]

Eric,

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.

Achilleas



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
> > > protection.
> >
> > 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
> > time.
>
>
> 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
> packet.
>
> 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.
>
> Eric