Forums

Reed Solomon Simulation

Started by cpshah99 October 24, 2008
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&#2013266080;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&#2013266080;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&#2013266080;pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:

> > The relative complexities (of the encoders and decoders) are an > important metric to consider as well. &#2013266080; Running an RS encoder or > decoder at such a low rate is usually inefficient compared to a decent > Viterbi decoder. &#2013266080; 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