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

[Daniel Estévez]

El 30/12/21 a las 16:39, pwhines2@verizon.net escribió:
> Hello Daniel,
>
> I've been experimenting with the RS decoder in gr-satellites for the past few 
> weeks and I've had some great results, thanks for pointing me in that 
> direction.  However, I'm still running into a few problems -- some directly 
> involve gr-satellites and some are just about basic tagging issues.  Here's 
> what they are
>
>
> 1. Is there any way to disable the gr::log/debug info from displaying in the 
> terminal/grc file?  I'm dealing with bursty transmissions which transmit one 
> after another, and occasionally the logs aren't able to catch up and cause my 
> program to freeze.  Obviously this isn't ideal, hopefully there's a way to 
> disable these from displaying either in grc or in the python file that it 
> generates.

Hi Patrick,

See this:

https://wiki.gnuradio.org/index.php/Logging#Logging_Configuration

Also, I have noticed that the "built-in terminal window" in GNU Radio 
Companion is not very performant and if your flowgraph produces a lot of 
text output (logs or anything else that goes to stdout o stderr), then 
GNU Radio Companion will choke. To get around this, I often run the 
generated Python file in a "real terminal emulator".

> 2. I'm getting a very strange output from the "Sync and create packed PDU" 
> block from gr-satellites.  Here's an example of the output for a single transmission, 
> 0xAAAAAAAAAAAA being the header, 0x0123456789 being the payload, and 0xFF being the noise 
> around the transmission.
>
>         AAAAAAAAAAAA0123456789FFFF
>         AAAAAAAAAAA0123456789FFFFF
>         AAAAAAAAAA0123456789FFFFFF
>         AAAAAAAAA0123456789FFFFFFF
>         AAAAAAAA0123456789FFFFFFFF
>         AAAAAAA0123456789FFFFFFFFF
>         AAAAAA0123456789FFFFFFFFFF
>         AAAAA0123456789FFFFFFFFFFF
>         AAAA0123456789FFFFFFFFFFFF
>         AAA0123456789FFFFFFFFFFFFF
>         AA0123456789FFFFFFFFFFFFFF
>         A0123456789FFFFFFFFFFFFFFF
>         0123456789FFFFFFFFFFFFFFFF
>         123456789FFFFFFFFFFFFFFFFF
>         23456789FFFFFFFFFFFFFFFFFF
>         FFFFFFFFFFFFFFFFFFFFFFFFFF
>         FFFFFFFFFFFFFFFFFFFFFFFFFF
>         FFFFFFFFFFFFFFFFFFFFFFFFFF
>         FFFFFFFFFFFFFFFFFFFFFFFFFF
>
> As you can see it creates multiple tags for a singular transmission, I think it 
> has to do with my header being the same character throughout.  It then prints 
> out the packet multiple times with the beginning trimmed by half a byte.  My 
> syncword is just 0xAAAAA and my threshold is 4, which sort of makes sense that 
> it prints out more than one packet, but it this is far more strange.

The gr-satellites sync and create PDU will generate PDUs from any 
matches of the syncword, allowing the number of bit errors given in the 
threshold, even if some of these PDUs overlap. Other alternatives out 
there do not allow overlapping PDUs and will only generate one of them. 
This is by design, when you get overlapping PDUs usually you don't know 
which is the correct one. So if you only generate one (say, the first 
syncword match), then chances are you'll miss the correct one. So by 
generating all possible matches, we will typically have the correct one 
among them and the others can be discarded because they have a wrong CRC 
or whatever.

0xAAAAA is not a very good syncword, as you can see. Typically a 
syncword is chosen so that the correlation of the syncword with any of 
its time shifts is small. That would prevent the problem you're seeing here.

>  I'm sort of stuck in this scenario since my headers will also have varying 
> lengths for different packets, ranging from 5 bytes to 8 bytes.

In this case I would probably use a different sync and create PDU block 
for each of the possible packet formats.

>  No matter how I change the threshold or the length of the syncword it still 
> tags a packet multiple times, how can I get this block to do it only once?

If you indeed want this behaviour, the tags to PDU block from 
gr-pdu_utils does this. But then you need to make sure that your SOF 
tags are set correctly and not to a false detection of the syncword, for 
otherwise you'll lose the frame.

> 3. Finally, how would I remove the excess noise around the packets the "Sync and create packed PDU" block is outputting?  I imagine it might have something to do with the Header/Payload Demux block...?  
When I remove the squelch on my flowgraph the RS decoder tries to 
correct the noise instead of the packet (which also causes the program 
to freeze because the logs can't catch up).  Eventually I want to get 
rid of the squelch but as of now I'm stuck with it until I can only pass 
these packets through and nothing else.

The Reed-Solomon decoder will discard most of the wrong frames. If 
besides this you have a CRC, then you'll get virtually no wrong frames 
at the output.

In my experience, a syncword threshold of 4 bits for a 32 bit syncword 
doesn't add too many false detection that would hurt performance, but 
this will depend to some extent on how good the syncword you use is, and 
on what symbol rate you need to process vs. how much CPU power you have 
for it.

Best,

Daniel.

OpenPGP_signature
Description: OpenPGP digital signature