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
OpenPGP_signature