Re: [Discuss-gnuradio] [GSoC2018][Standard FEC Decoders][Need Feedback]

[CEL]

I don't understand – you still haven't addressed any of the mandatory
things that I complained were missing. Since having all the formal
requirements and information and specified on the wiki page is a
**requirement**, we can't work with the proposal in its current shape! 

Best regards,
Marcus

On Thu, 2018-03-22 at 21:42 +0000, Harshit Gupta wrote:
> Greeting Mr Muller and community,
> 
> I have made improvement in the proposal. Have a  glimpse of it,
> 
> Some queries:
> What exactly should I include in 'Implementation'? I have put generic decoder 
> code and sample code for optimal implementation of FEC codes.
> What can be the outcome of a specific process?
> 
> Link to my git repo for proposal is [0].
> 
> 
> [0]   
> https://github.com/harshit4084/MyDoc/blob/master/gsoc2018_Harshit_Gupta.pdf
> 
> 
> 
> 
> 
> 
> On Thu, Mar 22, 2018 at 8:01 PM, Müller, Marcus (CEL) <address@hidden> wrote:
> > Hi Harshit Gupta,
> > 
> > thanks for showing up and being interested in GNU Radio!
> > I'm very happy that someone with an information theory background
> > decided to give channel code implementations a try.
> > 
> > From a quick scan of the proposal, I'd say that you have not adhered to
> > all the mandatory things on our GSoCStudentInfo wiki page; doing so is
> > mandatory, so please make sure to really check of *all* the items on
> > that list, or your proposal might simply not be eligible.
> > 
> > I'm missing a bit on your personal experience and background. You
> > really don't seem to follow the "Background on yourself" section on the
> > aforementioned Wiki page at all. Is this the first time you're
> > implementing channel codes or using C++, do you have experience in
> > optimizing existing code? Can you show us code you've written? I'm
> > really excited about all the cool stuff that we could do if you did
> > your GSoC on this, but we need to know who we're dealing with, and what
> > the skills are that you bring to this very challenging proposal.
> > 
> > You cite a lot from two papers, which is very fine by me, but doesn't
> > really allow myself to understand what part you're expecting to have to
> > implement yourself, and what part is existing code? If I understand
> > your proposal correctly, you aim to do all en- and decoding on GPU, not
> > CPU, which is cool, but also raises the question of your experience in
> > that field, and access to hardware you have.
> > 
> > From an aesthetic point of view, the citing/copying from different
> > sources doesn't really make for a consistent flow while reading. This
> > isn't top priority, but you might want to get your proposal as nice as
> > you would want a job application to be by the moment you finally upload
> > it.
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-03-22 at 19:06 +0000, Harshit Gupta wrote:
> > > Greetings,
> > >
> > > My name is Harshit Gupta, graduated in Electrical Engineering. Currently 
> > > pursuing masters from Indian Institute of Technology, Delhi.  Having 
> > > studied information theory in my post-graduate coursework, I can 
> > > understand FEC codes in a better manner. I want to contribute to GNU 
> > > Radio with my coding skills and knowledge of channel coding.
> > >  I am very interested to work on FEC decoders particularly starting from 
> > > LDPC decoders. GNU Radio would benefit from these integrations.
> > >
> > > The gr-fec API by GNU is an implementation of a few channel coding 
> > > techniques but are quite slow to be used in high throughput applications. 
> > > The current issue is to use standardized decoders in the coding 
> > > techniques to make gr-fec API suitable for high-performance applications 
> > > and integrate it with GNU radio.
> > >
> > > I went through some recent research paper like in QPP-Block-LDPC Codes 
> > > which proposes new approaches to implement the existing codes. The 
> > > relevant list can be found here[1].
> > >
> > > I went through gr::fec::code::cc_encoder Class and 
> > > gr::fec::code::ccsds_encoder, which implements the above code that is 
> > > more highly optimized for specific settings (rate 1/2, K=7, and 
> > > polynomials [109, 79]).
> > >
> > > Also, I went through the application of LDPC. It seems 5G will greatly 
> > > benefit from fast LDPC code. A project on fast implementation of LDPC 
> > > code will be a good experience. I searched through 3GPP 38 series of 
> > > documents [2] and found the used LDPC algorithm.
> > > I have listed out steps for optimal implementation.
> > >
> > > My queries are:
> > > 1. what kind of generic code for decoder I should add in my proposal?
> > > 2.Please look at my draft proposal[3]. Is there any redundant information?
> > > 3. Fast LDPC decoder and optimal implementation of 3GPP used LDPC codes 
> > > Both are good but which to choose?
> > >
> > >
> > > Deadline is quite near. Hence I am diligently working on the proposal
> > >
> > > Links:
> > > [1] http://aff3ct.github.io/hof_ldpc.html
> > > [2] http://www.3gpp.org/DynaReport/38-series.htm
> > > [3] 
> > > https://github.com/harshit4084/MyDoc/blob/master/gsoc2018_Harshit_Gupta.pdf
> > >
> > >
> > > .
> > >
> > > Thank you,
> > > Harshit Gupta
> > >
> > >
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>

smime.p7s
Description: S/MIME cryptographic signature