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 <[email protected]> On Behalf Of Daniel Estévez Sent: Tuesday, December 14, 2021 2:43 PM To: [email protected] 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, [email protected] 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 >>
