Reed Solomon Simulation

Hi All

I want to simulate Reed Solomon code with code rate 1/2 to compare rate
1/2 convolution code, I know that rate 1/2 RS will perform better.

So far I was using RS code of polynomial [255 239];

Can anybody please tell me how to simulate rate 1/2 code?

Your help will be appreciated.

Thanks


Chintan

>>>>> "cpshah" == cpshah  <cpshah99> writes:

    cpshah> Hi All
    cpshah> I want to simulate Reed Solomon code with code rate 1/2 to compare rate
    cpshah> 1/2 convolution code, I know that rate 1/2 RS will perform better.

You mean rate 1/2 convolutional code will perform better.  But that
depends on the channel noise.

    cpshah> So far I was using RS code of polynomial [255 239];

That's not a rate 1/2 RS code.

    cpshah> Can anybody please tell me how to simulate rate 1/2 code?

Tell us where you are now and where you want to go, and maybe we can
tell you how to get there.

Ray

Thanks for replying.

I know that [255 239] is rate 0.937 code, not rate 1/2. 

I want to simulate RS code of rate 1/2 for AWGN channel.

And if I am not wrong, rate 1/2 RS code will perform better than rate 1/2
convolution code for AWGN channel.

Thanks again.

Chintan

On Oct 24, 9:30&#4294967295;am, "cpshah99" <cpsha...@rediffmail.com> wrote:
> Thanks for replying.
>
> I know that [255 239] is rate 0.937 code, not rate 1/2.
>
> I want to simulate RS code of rate 1/2 for AWGN channel.
>
> And if I am not wrong, rate 1/2 RS code will perform better than rate 1/2
> convolution code for AWGN channel.
>
> Thanks again.
>
> Chintan

One "trick" often used to build custom sized codes (especially codes
where the original data is sent plaintext with appended parity - the
name eludes me right now) is to implicitly pad your data with zeroes
and then simply not send the zeroes. In your case you could use the
*same* code. It has 16 parity bytes, so just pack your data into 16
byte blocks, pad with (239-16=) 223 zeroes, compute parity, then send
a codeword consisting only of the original 16 bytes data plus the 16
byte parity. Then that's rate 1/2.  Do the inverse at the decoder.

Visually, take data
DDDD
add zeroes
DDDD00000000...000000
compute RS codeword with parity
DDDD00000000...000000PPPP
and abbreviate, transmitting
DDDDPPPP

Admittedly it's not the same as a "native" rate 1/2 code but it's a
place to start.

 - Kenn

Raymond Toy  <raymond.toy@ericsson.com> wrote:

> "cpshah" == cpshah  <cpshah99> writes:

>> Hi All
>> I want to simulate Reed Solomon code with code rate 1/2 to
>> compare rate 1/2 convolution code, I know that rate 1/2 RS will 
>> perform better.

>You mean rate 1/2 convolutional code will perform better.  But that
>depends on the channel noise.

I would say it depends upon your performance metric.   If you want
to see a BER of 1e-12, typically an RS code has more coding gain
in AWGN; if you only need a BER of 1e-6, then the convolutional code
has more coding gain.

This is why one needs to be careful when talking about "the"
coding gain of a code.

>> So far I was using RS code of polynomial [255 239];
>> Can anybody please tell me how to simulate rate 1/2 code?

The quick and dirty method is to shorten it to a (32,16)
code by zero-padding but that is a pretty suboptimal RS code.

Steve

On Oct 24, 9:40�am, kennheinr...@sympatico.ca wrote:

> Visually, take data
> DDDD
> add zeroes
> DDDD00000000...000000
> compute RS codeword with parity
> DDDD00000000...000000PPPP
> and abbreviate, transmitting
> DDDDPPPP


Actually, it is better to add the zeroes before
the data, i.e. 00000...0000DDDD, then encode
to get 0000...00000DDDDPPPP, and then
truncate, just transmitting DDDDPPPP.  The
advantage is that in decoding, one can use a
standard decoder for the original code, just
truncating the syndrome calculation to pretend
that it has run for 223 clock cycles during which
0's were being fed in (thus not changing the state
of the circuit which has remained as it was at
the initialization) and then running for 32 clock cycles
to get the syndrome for the shortened code.

Hi all

Thanks a lot.

I got the idea. I will try to implement, and will get back if I have any
doubts.

Thanks a lot.

Chintan

On Fri, 24 Oct 2008 08:30:18 -0500, "cpshah99"
<cpshah99@rediffmail.com> wrote:

>Thanks for replying.
>
>I know that [255 239] is rate 0.937 code, not rate 1/2. 
>
>I want to simulate RS code of rate 1/2 for AWGN channel.
>
>And if I am not wrong, rate 1/2 RS code will perform better than rate 1/2
>convolution code for AWGN channel.
>
>Thanks again.
>
>Chintan

I think which one outperforms the other is going to depend on the
codes, e.g., the constraint length of the convolutional code.

The relative complexities (of the encoders and decoders) are an
important metric to consider as well.   Running an RS encoder or
decoder at such a low rate is usually inefficient compared to a decent
Viterbi decoder.   The RS encoder will always be far more complex than
the CC encoder, especially at R=1/2.

I'd be interested in the conditions and the results if you can share
them when you're done.

Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org

Blog: http://www.dsprelated.com/blogs-1/hf/Eric_Jacobsen.php

Hi Eric

Definately I will share my results with you guys once I am done.

May be I will make a small report.

Chintan

On Oct 24, 6:32&#4294967295;pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:

>
> The relative complexities (of the encoders and decoders) are an
> important metric to consider as well. &#4294967295; Running an RS encoder or
> decoder at such a low rate is usually inefficient compared to a decent
> Viterbi decoder. &#4294967295; The RS encoder will always be far more complex than
> the CC encoder, especially at R=1/2.
>

True.  But an RS encoder/decoder for a (32,16) RS code over
GF(256) obtained by shortening a (255,239) RS code has the
same complexity as the original code.  On the other hand,
a (256,128) RS code or (255,127) RS code would be totally
impractical.

A (32,16) RS code over GF(256) s a very powerful code but
with *many* weak spots for use on an AWGN channel where
it would typically be implemented as a (256,128) binary code
with antipodal PSK signaling.  This code is guaranteed to
correct all (single) bursts of errors as long as 50 bits of the 256
bits in a block, and *some* bursts of longer lengths (up to 64
bits) can also be corrected.  But there are random bit errors
of as few as 9 bits that the code is unable to correct.
Unfortunately,
on an AWGN channel, random bit errors are generally more
likely to occur than long bursts.  A better modulation scheme for
an RS code on an AWGN channel would be M-ary orthogonal
FSK, but nobody wants to use that, do they?

--Dilip Sarwate