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

[pwhines2]

Hello Ron and Daniel,

First of all I appreciate the replies, you've given me some great starting 
places for this, so thanks.

I guess my next question would be how to implement this into my existing 
flowgraph given the output of my demodulator and the input of the blocks.  
Right now I have my GMSK signal being demodulated with the final block being a 
binary slicer, which outputs a constant stream of binary data (working on 
understanding the correlate access code to remove noise between bursts).  How 
would one go about converting the data from a byte stream to a stream vector or 
PDU?  I would need to convert the signal back to a byte stream afterwards for 
my TCP/File sinks as well.  Right now I keep getting an error saying the source 
IO size doesn't match the sink IO size, which I believe Daniel mentioned if I 
understood correctly.  I've never dealt with stream vectors in GNU Radio so 
this is all new to me.

As a side note, is it possible to find out the RS parameters from the protocol, 
or do you need documentation about the codes used for the original signal?  My 
signal has a BT of 0.2 if that helps...

Again, thanks for the help so far, I'm fairly new to the world of error 
correction for the most part

Patrick

-----Original Message-----
From: Discuss-gnuradio <discuss-gnuradio-bounces+pwhines2=verizon.net@gnu.org> 
On Behalf Of Daniel Estévez
Sent: Tuesday, December 14, 2021 2:43 PM
To: discuss-gnuradio@gnu.org
Subject: Re: Reed-Solomon Decoding (Not for Digital Television)

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
>>