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) <[email protected]> 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 > > > [email protected] > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
