Re: Reed-Solomon Decoding (Not for Digital Television)

[Daniel Estévez]

Hi Patrick and Ron,

Besides the DVB-T Reed-Solomon blocks, there is also the Reed-Solomon 
blocks from gr-satellites. The gr-satellites blocks expose a couple more 
parameters about the Reed-Solomon code definition. These are the "first 
consecutive root" and the "primitive element". These parameters come 
straight from libfec's generic Reed-Solomon implementation. In many 
codes these two parameters have the value 1, and I guess this is what 
the DVB-T blocks use. But if you need other values, for your code, then 
you can use the gr-satellites blocs.

Additionally, there are two main difference between the gr-satellites 
blocks and the DVB-T Reed-Solomon blocks:

1. The gr-satellites blocks use PDUs rather than stream vectors.
2. Because of this, the gr-satellites blocks get the message size from 
the PDU size, so you don't need to set this in advance and can be variable.

I think that for a burst application, depending on whether you already 
have the data as PDUs or not, it might be easier to use the 
gr-satellites or the DVB-T blocks.

Best,

Daniel.

El 13/12/21 a las 3:01, Ron Economos escribió:
> Reed-Solomon predates digital television and is used in many 
> applications. Here's a nice article about Voyager 1.
>
> https://destevez.net/2021/12/voyager-1-and-reed-solomon/
>
> The DVB-T Reed-Solomon blocks expose all the parameters, so you can 
> reuse them for whatever block size you'd like. The default for DVB-T is 
> 188 byte input packets and 204 byte output packets for the encoder and 
> the reverse for the decoder.
>
> Here's an explanation of each parameter.
>
> 1) p and m are not used. These are leftovers from a previous 
> implementation and retained to keep the block API the same.
>
> 2) GF polynomial. This is the Field Generator polynomial and 285 (1 0001 
> 1101) corresponds to x^8 + x^4 + x^3 + x^2 + 1.
>
> 3) N. This is the size of the field and is always 255.
>
> 4) K. This is the message size. 239 means that there will be 255 - 239 = 
> 16 parity bytes (that can correct up to 8 message bytes).
>
> 5) t is not used.
>
> 6) Shortening size. This is the number of message bytes padded with 
> zeroes. For DVB-T, 239 - 51 = 188, which is the size of a MPEG-2 
> Transport Stream packet.
>
> 7) Blocks. This determines the vector size of the input and output pins. 
> 188 * 8 = 1504 for the encoder input and 204 * 8 = 1632 for the encoder 
> output. It can be set to 1 if desired.
>
> So you have to chose a message size that you can live with and all your 
> messages have to be the same size (or padded to the same size). And of 
> course, you have to use the encoder at the transmitter and the decoder 
> at the receiver.
>
> Ron
>
> On 12/12/21 12:32 PM, pwhines2@verizon.net wrote:
> > Hello all,
> >
> > My question is fairly simple, how would I perform Reed-Solomon error 
> > correction after demodulating my incoming signal?  I see there are a 
> > few uses of RS decoding for digital television, but my signal is just 
> > bursts of data and has nothing to do with television.  From what I’ve 
> > gathered I think I need to use the FEC Decoder block and somehow tell 
> > it to use RS decoding, but I’m not 100% sure.  I would preferably like 
> > to use blocks that come with gnuradio for this, but if that’s not 
> > possible then I’ll settle for whatever solution is available.
> >
> > The end of my flowgraph is Binary Slicer > Pack K Bits > File Sink, 
> > and I would imagine the FEC would go after the binary slicer.  The 
> > packets I’m demodulating now are correct, however there are some 
> > errors in the packets while the bursts are demodulated (which is why I 
> > need FEC).  Anyone know how I would go about doing this?
> >
> > Thanks,
> >
> > Patrick

OpenPGP_signature
Description: OpenPGP digital signature