Hi,

I'm looking for an error correcting scheme to be used in a packet of 16-bit
words to be efficiently implemented in a DSP. 
Basically I receive a packet of 1023 16-bits words, for which I put 16-bit
CRC at the end. This only allows me to detect errors and discard the whole
packet. Also, start of these packets are identified with a sync word and
then whole packet is buffered to the length word. Therefore, when
transmitting these packets back-to-back, if the length word is received
wrong, there is a chance that I will miss the next packets sync word. 

So I want to implement a simple (because there's not much processing power
left in my old ADSP) FEC scheme I can use with 16-bit word packets. Any
suggestions are highly appreciated.

Thank you.

On Jul 2, 10:24=A0am, "m26k9" <maduranga.liyanage@n_o_s_p_a_m.gmail.com>
wrote:
> Hi,
>
> I'm looking for an error correcting scheme to be used in a packet of 16-b=
it
> words to be efficiently implemented in a DSP.
> Basically I receive a packet of 1023 16-bits words, for which I put 16-bi=
t
> CRC at the end. This only allows me to detect errors and discard the whol=
e
> packet. Also, start of these packets are identified with a sync word and
> then whole packet is buffered to the length word. Therefore, when
> transmitting these packets back-to-back, if the length word is received
> wrong, there is a chance that I will miss the next packets sync word.
>
> So I want to implement a simple (because there's not much processing powe=
r
> left in my old ADSP) FEC scheme I can use with 16-bit word packets. Any
> suggestions are highly appreciated.
>
> Thank you.

What kinds of errors do you expect? Occasional random bit errors
(how occasional?) or occasional random _bursts_ of errors?  again,
how occasional? how long a burst?  How many words can you
use as redundant (parity-check) words in addition to (or in lieu
of) the single CRC word that you currently have? Suitable
suggestions would need to take such matters into account.

Dilip Sarwate

"m26k9" <maduranga.liyanage@n_o_s_p_a_m.gmail.com> wrote in message 
news:rZWdnS2pOIeOIGzSnZ2dnUVZ_j2dnZ2d@giganews.com...
> Hi,
>
> I'm looking for an error correcting scheme to be used in a packet of 
> 16-bit
> words to be efficiently implemented in a DSP.

How many errors are expected at the input? What kind of errors (bursts, 
random, sync loss) ?
How much of data redundancy is affordable?

> Basically I receive a packet of 1023 16-bits words, for which I put 16-bit
> CRC at the end. This only allows me to detect errors and discard the whole
> packet.

A 16-bit CRC allows  to correct at least one single bit error.

> Also, start of these packets are identified with a sync word and
> then whole packet is buffered to the length word.

So, the packet payload is variable length up to 1023 words?

> So I want to implement a simple (because there's not much processing power
> left in my old ADSP)

How much MIPS and memory could be allocated to FEC ?

> FEC scheme I can use with 16-bit word packets. Any
> suggestions are highly appreciated.

Depending on how much is "high appreciation", I could develop error 
correction scheme for you.

Vladimir Vassilevsky
DSP and Mixed Signal Consultant
www.abvolt.com

On Mon, 02 Jul 2012 10:24:03 -0500, "m26k9"
<maduranga.liyanage@n_o_s_p_a_m.gmail.com> wrote:

>Hi,
>
>I'm looking for an error correcting scheme to be used in a packet of 16-bit
>words to be efficiently implemented in a DSP. 
>Basically I receive a packet of 1023 16-bits words, for which I put 16-bit
>CRC at the end. This only allows me to detect errors and discard the whole
>packet. Also, start of these packets are identified with a sync word and
>then whole packet is buffered to the length word. Therefore, when
>transmitting these packets back-to-back, if the length word is received
>wrong, there is a chance that I will miss the next packets sync word. 
>
>So I want to implement a simple (because there's not much processing power
>left in my old ADSP) FEC scheme I can use with 16-bit word packets. Any
>suggestions are highly appreciated.
>
>Thank you.

As has been mentioned already, the expected error probability and
error distribution will make a difference in evaluating candidate
codes.

Also, how much overhead can you afford to allocate for
parity/redundancy?    In other words, is there a part of the data
field that you can use to support, for example, parity bits or parity
words?  If you want the length word protected separately, do you have
control over what the length word loooks like?  e.g., can part of the
length word indicate length and the rest be parity?

All these sorts of considerations will help determine a path to
possible solutions.



Eric Jacobsen
Anchor Hill Communications
www.anchorhill.com

On Mon, 02 Jul 2012 10:24:03 -0500, m26k9 wrote:

> Hi,
> 
> I'm looking for an error correcting scheme to be used in a packet of
> 16-bit words to be efficiently implemented in a DSP. Basically I receive
> a packet of 1023 16-bits words, for which I put 16-bit CRC at the end.
> This only allows me to detect errors and discard the whole packet. Also,
> start of these packets are identified with a sync word and then whole
> packet is buffered to the length word. Therefore, when transmitting
> these packets back-to-back, if the length word is received wrong, there
> is a chance that I will miss the next packets sync word.
> 
> So I want to implement a simple (because there's not much processing
> power left in my old ADSP) FEC scheme I can use with 16-bit word
> packets. Any suggestions are highly appreciated.

What everyone else has said, plus:

I'm seeing quite a few protocols that have a short header with a CRC, 
followed by a long packet, again with a CRC.

The benefit to the header CRC is that if the header is good but the 
packet is corrupt, then at least you know you have a good length.  And if 
the header is _bad_, then you can immediately start searching for the 
next header flag word.

For serious FEC you need to add more error correction bits, and you run 
afoul of the whole problem of corrupted headers.  There may be cool ways 
around this, but particularly if your errors are bursty you may do better 
to just use backwards error correction with a header CRC.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Thank you very much all for replying.
Sorry I did not give much information about the system.

I am mostly expecting random errors due to white noise, but there are
occasions with bursty errors. But we deal with these with re-transmissions
or in worst case a full buffer reset.

My initial goal is to address the random errors. Right now we have a BER of
about 10e-6. Which is good enough. But our system has two DSPs,
transmitting simultaneously. But my idea is to dedicate one DSP solely for
FEC, when we are dealing with a low data rate required. In that case I will
have a lot of processing available. The DSP is a ADSP-21062 with
~60MFLOPS.

I'm looking for something simple and efficient. Without much overhead. My
data packet can be upto 1023 words. And I suppose I can afford additional
few  16-bit words as overhead if it helps to correct few bit errors in the
whole packet.

I'm basically looking for a FEC scheme where I can efficiently perform the
FEC on the 16-words already in my buffer.

Thank you very much.  

On Mon, 02 Jul 2012 21:02:34 -0500, "m26k9"
<maduranga.liyanage@n_o_s_p_a_m.gmail.com> wrote:

>Thank you very much all for replying.
>Sorry I did not give much information about the system.
>
>I am mostly expecting random errors due to white noise, but there are
>occasions with bursty errors. But we deal with these with re-transmissions
>or in worst case a full buffer reset.
>
>My initial goal is to address the random errors. Right now we have a BER of
>about 10e-6. Which is good enough. But our system has two DSPs,
>transmitting simultaneously. But my idea is to dedicate one DSP solely for
>FEC, when we are dealing with a low data rate required. In that case I will
>have a lot of processing available. The DSP is a ADSP-21062 with
>~60MFLOPS.
>
>I'm looking for something simple and efficient. Without much overhead. My
>data packet can be upto 1023 words. And I suppose I can afford additional
>few  16-bit words as overhead if it helps to correct few bit errors in the
>whole packet.
>
>I'm basically looking for a FEC scheme where I can efficiently perform the
>FEC on the 16-words already in my buffer.
>
>Thank you very much.  

In general it sounds like a Reed-Solomon code or something similar
might suit you, but if you have a BER of 10e-6 and that's good enough
why do you want to add FEC?   A packet of of 1023 16-bit words is only
16k bits, so at Pe = 10e-6 the likelihood of even a single bit error
is low.   Unless you're having latency problems ARQ for the few
errored packets is probably more bandwidth efficient than adding
overhead for FEC if you already have Pe = 10e-6.




Eric Jacobsen
Anchor Hill Communications
www.anchorhill.com

"m26k9" <maduranga.liyanage@n_o_s_p_a_m.gmail.com>

> My initial goal is to address the random errors. Right now we have a BER 
> of
> about 10e-6.
> I'm looking for something simple and efficient. Without much overhead. My
> data packet can be upto 1023 words. And I suppose I can afford additional
> few  16-bit words as overhead if it helps to correct few bit errors in the
> whole packet.
> I'm basically looking for a FEC scheme where I can efficiently perform the
> FEC on the 16-words already in my buffer.

There is no need to change packet structure; all necessary fields are in 
place already. A 16 bit ECC is adequate for BER of 1e-5 with 16kbit packets. 
Variable length of data is not a problem, as the data could assumed to be 
padded with zeroes to max. size.  Optimum code polynomial could be bit 
tricky.

> Thank you very much.

This is a project for weekend; would do for $1500.

Vladimir Vassilevsky
www.abvolt.com