discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] GSOC 2016: Help Review Project Proposal


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] GSOC 2016: Help Review Project Proposal
Date: Wed, 23 Mar 2016 08:56:56 -0400



On Wed, Mar 23, 2016 at 4:03 AM, Jan Krämer <address@hidden> wrote:
Hi Tanero,

It seems that you know your way around LDPC Codes and the theory behind it, which is a really good thing. But there are still things to improve.

- Check your spelling and grammar again. Also the formatting needs reshaping (at least in Githubs preview and Fedoras document viewer) .
- Regarding optimizations. If you manage to highlight a bit more, how SIMD could help improve the speed by parallelizing steps and how reducing the Parity check matrixes helps with random memory accesses that would be a great plus for your proposal.
- You should try to get a bit more familiar with the FEC-API. You have an extra timeslot dedicated to integrating the finished OOT blocks into the FEC-API. Just for the record, you can have your own OOT block that is already using the FEC-API. Transferring that OOT block is to core-GNURadio would just be a copy of the source files and adjusting of the gr-fec CMakeLists.txt. I think it would fine with developing the blocks first as an OOT module (if it is using the FEC-API from the beginning) and then porting it to gr-fec. But directly integrating the LDPC blocks in gr-fec would be also an option.

Cheers and happy hacking,
Jan

 

2016-03-22 5:11 GMT+01:00 Tanero Juthero <address@hidden>:
  I made an update to the proposal,mentors please help me review the proposal,your opinions highly

awaited.Here is the link https://github.com/tanerochris/gsoc-2016/blob/master/%20gsoc_2016_application.pdf

Thanks.


Following on from Jan's suggestion, please make sure you understand the FEC-API and gr-fec. We have different implementations of LDPC already in GNU Radio's gr-fec component. More than new codes, we need to optimize the structures that we currently have. And new LDPC work should be close enough to the current LDPC to make choosing different implementations easy and efficient.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]