Consolidate FEC coders - Githubissues

jdemel commented 5 years ago

GR has a couple of places to look for FEC codes. Some encoders/decoders can be found in gr-trellis others are part of gr-fec and even more are found in gr-dvbt.

I suggest to convert all of them to use FECAPI.

There are a couple of benefits

clearly separate implementation from use case
identify code duplication
consolidate codes that have different implementations
make it easier to find a code implementation to use it for a new use case

Originally, gr-dvbt comes into mind because it includes BCH and LDPC codes which are tied to exactly those flowgraphs.

I do NOT suggest to make existing implementations more general. Specialization is a good way to make them run faster etc. Though, I do suggest to make it easier to use these implementations in a different context.

drmpeg commented 5 years ago

Sorry, but I'm not convinced that anything needs to change in gr-dtv. All the FEC codes are application specific and not useful for anything except digital television.

jdemel commented 5 years ago

These FEC codes are not meant to change. They should support exactly the rates and codeword sizes they currently do. The idea is just to make it easier to use these exact codes in a different application.

noc0lour commented 5 years ago

I don't see a real reason why it's a bad idea to consolidate all FEC encoders & decoders in the right module. It's obvious the gr-dtv FEC are not immediately useful for other applications, but might offer good insight how to optimize for special cases. Also, other, custom applications (in the lab) could benefit from that. Why do you think it is a problem, really nothing should change in gr-dtv (aside from using blocks from gr-fec with the correct encoder/decoder blocks) ? @drmpeg

drmpeg commented 5 years ago

It's a lot of work. For the LDPC encoder, there are 57 parity tables that would have to be converted (and tested) from the current format to alist. That would mean 57 more files in gr-fec/ldpc_alist. Also, can you even select a file with a drop-down menu?

The DTV LDPC encoder has also been optimized for performance from the R&S engineering competition. Can gr-fec match that performance?

Finally, there's DVB specific puncturing and shortening. I suppose that can be handled outside of gr-fec, but I'm not sure.

I haven't even looked at the BCH encoder. Is there a BCH encoder in gr-fec?

Sorry, but for gr-dtv, this seems like a solution looking for a problem.

noc0lour commented 5 years ago

Well, that's the thing. The functional code stays the same. Performance improvements are untouched. Maybe some interfaces have to be modified to match the correct API, but it would be a good example how to use core GNU Radio blocks for real applications. Otherwise it looks more like "just write everything yourself from scratch" type of thing.

Not having a BCH encoder is just more reason to pull it in there. Same for 3 different viterbi implementations scattered all over. (with no viterbi impl being particularly fast). I see you don't want your code changed, but I don't see a technical reason (aside from some work) speaking against it.

jdemel commented 5 years ago

@drmpeg Why would anything need to be converted?

My idea was to use the code as is. I hope it is possible to plug this code into FECAPI. I'm sure we can create FECAPI block definitions that match the ones present in gr-dtv.

Also, it would be great to make it easier to use this code in a different context. Specifically in a lab. That is actually the main idea behind my proposal. I want to make the optimized performance available to a broader audience.

Imagine you had an application that requires some FEC. You want to use some standard code with good performance and good throughput. In this case you just grab one off the shelf. e.g. an LDPC code as used in DVB. You just parameterize your system such that the encoder/decoder definitions get a valid amount of input and you can handle their output.

Another use case that comes to mind is a code performance comparison. You implement your own code and want to benchmark it against standardized codes. If it was easy to use DVB codes, this would be a good candidate for a comparison.

It would be great to have a BCH decoder available in gr-fec. Even better if it just implements a specific standard.

I could also imagine to have a 5G Polar code implementation that just implements possible 5G parameters.

Questions that come to mind:

Does gr-dtv require any special signaling during runtime? I can't find any message ports. Also, it seems like there are no tags.
Since the GRC examples use vector inputs, I assume these blocks require fixed sizes to encode blocks. FECAPI can handle this. It would be possible to ensure that this requirement is met.

If it would be possible to take a specific code from gr-dtv and plug it into FECAPI without ruining its throughput and no changes to the inner algorithm, would this be a path forward for you? Also, this issue is a good place to discuss the various issues that come to mind.

drmpeg commented 5 years ago

My bad, I totally misunderstood what's being suggested. I thought you wanted to use the LDPC encoder in gr-fec for DTV.

So let me get this straight. You're suggesting to move the LDPC encoder (and possibly other stuff) from gr-dtv to gr-fec? So there will be two LDPC encoders in gr-fec? Isn't this more confusing than having them in separate components?

drmpeg commented 5 years ago

@noc0lour The Viterbi decoder in gr-dtv is fast. See:

http://yo3iiu.ro/blog/?p=1393

noc0lour commented 5 years ago

@drmpeg giving me more reasons to take a closer look and maybe somehow adapt for other codes as well (: (given I find time under some rug)

drmpeg commented 5 years ago

Now that I'm on the same page, I have no real problem with this. However, it seems a little second order given all the other work that needs to be done on 3.8.

marcusmueller commented 9 months ago

agreeing – needs consolidation, testing, better coverage

gnuradio / gnuradio

Consolidate FEC coders #2299