Re: [Discuss-gnuradio] OFDM TX/RX

[Martin Braun]

On 03/16/2018 09:33 AM, guillaume.toc...@orange.com wrote:
> Hello all,
> 
> I want to make a flow graph for transmitting and receiving OFDM
> modulated data. To be precise, I want to do a LTE-M "like"
> transmission/reception, so I am trying to transmit data with a BW of
> 1.08 MHz OFDM.
> To do so, I use the following configuration : samp_rate = 1.92 MHz, fft
> length = 128, number of sub carriers = 72 , cp = 32
> 
> I modified the tx_ofdm.grc example file
> (/gnuradio/gr-digital/examples/ofdm/tx_ofdm.grc)
> To summary, I change the occupied carriers : range(-36, -21) +
> range(-20, -7) + range(-6, 0) + range(1, 7) + range(8, 21) + range(22,
> 37),) ; pilot carriers and symbols unchanged ; double the sync words to
> be equal to fft length.
> 
> The problem is at the output of the "Tag debug" I have just those
> messages :
> INFO: Parser returned #f
> INFO: Detected an invalid packet at item 1496
> ..
> INFO: Parser returned #f
> INFO: Detected an invalid packet at item 681901
> 
> And the spectrum isn't "stable" at 1.08 MHz BW.

Are you going across the air? The most common cause for this is too much
gain, and resulting distortions caused by large PAPR. If you've
increased the number of carriers, PAPR also goes up (a bit).

-- M
>  
> 
> What am I doing wrong ? How the sync words are determine ? Should I add
> pilot/symbol carriers ?
> 
> 
> Best Regards and thanks by advance,
> 
> Guillaume Tochou
> 
> 
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC2018] Adding Passive radar and multiple device support to gr-radar toolbox

[Martin Braun]

On 03/23/2018 11:26 AM, Müller, Marcus (CEL) wrote:
> Hi Suraj,
> 
> thank you very much for sending us your proposal! This already looks 
> very nice. Can I wish for you to add something like a rough block
> diagram that describes how your simulated illuminator, your signal
> recoverer, your radar estimator and your clutter reducer work
> together, and which information you plan on letting these exchange?
> That would allow us to "mentally" map what you're doing each week in
> your proposed timeline to components of the system.
> 
> All in all, this is pretty ambitious, but exciting!


Sure is!

There's a couple of typos in the proposal, and I always think that
distracts from the quality of content and the content itself.

My main issue with this proposal is its vagueness. I would recommend you
expand the sections that explain the algorithms you want to implement *a
lot*. In particular, we need to know if you've understood the underlying
math, DSP, and implementation requirements.
Do you have thoughts on a clutter removal algorithm? Like Marcus says,
it will better to do a simple approach first. You could, e.g. remove all
zero-Doppler targets.
As a result of this vagueness, I believe the timeline is probably
inaccurate.

GUIs are nice, but you should either make them stretch goals, or actual
first-class citizens.
It's always better to limit your main deliverables to make sure there's
time for cleanup and merging. What if the gr-radar maintainer has issues
with your pull requests? You're planning to add a of stuff. Were you
planning on submitting PRs continuously? If so, I recommend writing that.

I'm also curious how you do your signal recovery.

The overall proposal is interesting, though, no doubt about that!

-- M





> How will you tackle the OFDM signal recovery? I think your reference 
> [2] is really much to be completely done in one GSoC, so it would be 
> totally OK to say you just picked a reduced approach. Still, if you 
> want to do that in all its glory, that would be cool, too, but I'd
> ask Martin how much work he'd expect that to be, and if necessary,
> reserve more time for the algorithmic part alone. I'm also including
> Jean- Michel Friedt of low-cost passive radar fame[A], as I hope he
> might have a moment to read and comment on your proposal.
> 
> Best regards, Marcus
> 
> [A] http://jmfriedt.free.fr/URSI.pdf On Fri, 2018-03-23 at 12:54
> +0530, suraj hanchinal wrote:
>> Hello Everyone, I am Suraj Hanchinal, a second year undergraduate
>> in Electrical Engineering at the Indian Institute of Technology,
>> Kanpur. I had approached the mailing list and communicated with
>> Martin Braun, the mentor and others regarding the gr-radar toolbox
>> extension idea. I decided to work on adding passive radar support
>> to the toolbox after these discussions. I have finally completed
>> the proposal [1] and I would like feedback as well as suggestions
>> for improvement on the proposal.
>> 
>> Thank you,
>> 
>> Regards, Suraj Hanchinal
>> 
>> Proposal [1]
>> https://github.com/surajhanchinal/GSoC_proposal/blob/master/My%20GSoc%20Proposal.pdf
>> 
>> 
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> 
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC2018][Filter Design Tool Enhancements][Need Feedback]

[Martin Braun]

Sakshi,

your proposal does also not meet the formal requirements. Please take a
look at the GNU Radio wiki pages on GSoC.

Thanks,
Martin



On 03/23/2018 02:42 AM, Felix Wunsch wrote:
> Hello Sakshi,
> 
> great to hear that you are interested in improving the filter design tool!
> 
> Your proposal, however, still needs some work. Please read the
> guidelines carefully, we have a list of specific information we need
> from you without which we can't consider your proposal.
> 
> About your timeline: Please make that more detailed. A detailed timeline
> can show us very well how clear your vision for the project is and how
> much time you think you need for the different parts. I also have to say
> that tests only appear in the last week of the coding phase. For the
> code to be mergeable and maintainable, tests are an absolutely mandatory
> requirement.
> 
> It would also be nice if you could expand your personal background
> section a bit. What kind of projects did you already work on? Were they
> related to DSP, and which programming language(s) did you use? Do you
> maybe even have a GitHub account with relevant code? As the project idea
> states, you will need a strong DSP background as well as good knowledge
> of at least Qt or Python.
> 
> Best regards,
> Felix
> 
> 
> On 03/23/2018 07:10 AM, Sakshi Agrawal wrote:
>>
>> Hello Everyone,
>>
>> This is Sakshi Agrawal, Graduated in Electronics Engineering. I have
>> been following DSP industries. A few days back I ran into GSoC
>> programme. I have seen some GSoC projects proposed by GNU radio in
>> filter design. Having proper coding knowledge and strong DSP
>> background from my undergraduate coursework I thought of contributing
>> to GNU radio.
>>
>> The Filter and Design tool by GNU radio is already very neatly
>> designed and contributing to that will be an experience. The current
>> to-be-solve issues are to improve the ease of using the tool, add more
>> functionality and more support for filter design.
>>
>> "This project is to improve our uses of these tools and blocks to make
>> it more obvious to the users as well as automate some of the decisions
>> for optimally using them."
>>
>> Here are some thoughts which I think will be an extra feature to
>> consider (may or may not be necessary) :
>>
>> 1. Tip the user when selection is to be made. Also, automate some
>> obvious decisions.
>>
>> 2. Implement a tool that can save the current results into a file and
>> also can import the existing file/plot which further can be used in
>> other work or can be modified as per user requirement.
>>
>> 3. Implement a bidirectional support to graph or plot i.e. plot can be
>> changed by values and also by a hand tool user can tweak the plot
>> which will give desired values.
>>
>> 4.Implement a slider which changes the plot as the user slides on the
>> values
>>
>> 5. Add support to more filter design and new filter specs
>>
>> Specifically, I want to contribute to a module can be integrated to GR
>> and gives a new functionality/concept like adding support for
>> cascading filter.
>>
>> Two  filter design concepts:
>>
>> 1. Add more support for Cascaded filters
>>
>> 2. Better support for creating PFB filters
>>
>>
>> I have been working on my proposal[0]. I would request you to go
>> through it and point out any flaw that I should know or some general
>> suggestions to make it better.
>>
>> Best
>> Sakshi Agrawal
>>
>> [0]https://github.com/sakshi18agrawal1/documents/blob/master/Sakshi_GSoC2018.pdf
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> -- 
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
> 
> Felix Wunsch, M.Sc.
> Research Associate
> 
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
> 
> Phone: +49 721 608-46276
> Fax: +49 721 608-46071
> E-Mail: felix.wun...@kit.edu
> 
> www.cel.kit.edu
> 
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSoC 2018: Compas Widget

[Martin Braun]

Valian,

based on your original email, I wasn't entirely sure if this was even an
expression of interest in GSoC. A compass widget would be good, but like
Nicolas says, it's not really enough for a project.

-- Martin

On 03/20/2018 03:48 AM, Nicolas Cuervo wrote:
> Hello Valian,
> 
> Thank you for your interest in GNU Radio and GSoC! 
> 
> that compass you put together seems like a good start for what we'd like
> to have. Answering your question: optimally we'd like to have all the
> ones that are listed (and probably even more if we see the necessity or
> applicability of a new one along the way!) But for the sake of clarity
> regarding GSoC, we expect neither a coding wonder nor a very small task.
> My point is: if you are interested in working on this, don't hesitate to
> draft a proposal. We will analyze your proposed milestones and assess
> how real are the deliverables that you propose. If we see that your
> focus is too broad, or that your workload is too low/high, we will be
> very clear on that as well. Just one QtWidget seems too little for a
> Summer of Code (you already have the compass halfway there!) and
> assessing all the proposed points might or might not be too much work.
> It depends on how you would plan to approach the problem in question and
> your experience with all the frameworks involved.
> 
> Have a look at the GSoC Student Guide [1], which has a section on
> "writing a proposal", or keep asking questions regarding this topic if
> you still need a bit more clarification. Keep in mind that the
> application deadline is *March 27, 2018 at 18:00* *(CEST), *so you are
> better off planning accordingly and parallel your interests.
> 
> Regards,
> - Nicolas
> 
> [1] 
> https://developers.google.com/open-source/gsoc/resources/guide#student_manual
> 
> 
> On Tue, Mar 20, 2018 at 3:35 AM, Valian Masdani  > wrote:
> 
> Greetings, 
> 
> I've read the ideas list for GSoC 2018 and I somehow managed to get
> the compass working in Qt using the QPainter coordinate system, and
> I think this can be appliable in the Qt Widgets Improvement idea.
> I've attached the screenshot of the widget in this mail. I haven't
> learned how to change the font size and such, though. I also read
> that you also need the MPEG decoder and Matrix display in the
> subtopic, not just the compass. Do you need all of them or just one
> of them?
> 
> Best regards, 
> Valian Masdani
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-modtool overhaul: Proposal draft

[Martin Braun]

On 03/19/2018 12:03 PM, swapnil negi wrote:
> Hello everyone! 
> I have uploaded my proposal to the GitHub pages. So, please review and
> provide me suggestions to improve the same.
> Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
> Code Link: https://github.com/swap-nil7/GSoC-Proposal

Swapnil,

this is a great proposal. There's a couple of typos and areas where the
optics can be improved, for example, the code snippets you provide as
examples are not all Python 3k compliant, and don't follow PEP8 or GNU
Radio coding guidelines.

But overall, this is a really good proposal. Well bound, useful, it
addresses a tool we all use a lot.

As for Nicolas' comments:

> And I agree with this timeline, as it puts core focus on the
> architectural overhaul without disregarding other details aside. 
> 
>   * If I understand correctly, your first task to tackle is the
> Py3k compatibility, which is great. This is definitely
> something that needs to be done, as there is a continuous
> effort on making the whole GNURadio Python3 compatible. But
> Python2 is not EOL for little less than 2 years more, so
> continuous compatibility is something that has to be kept in
> mind. Let's take your proposed code for raiseException,
> whose implementation won't work on Python2. There are ways
> to ensure compatibility (using wrappers from 'six' for
> example, which adds a dependency - which can be discussed) 
> I, however, see that the Python3 branch from GNU Radio
> already implements the syntax that you are proposing, so I
> might being just too picky on this. I expect comments on the
> matter from the list.

I very much agree with this. It'll need to support Py2k and Py3k (and
yeah, that's annoying, but for tools like this is not too much of a hassle).

>   * I see that you have put efforts in contributing already to
> the project by fixing some issues on the tool, and there is
> hardly a better way to get used to it and contribute to the
> project. No comment here apart from saying that we do
> appreciate you took that path as it puts you into context
> and improves the project. Win-Win!

Agree very much.

I have a couple of my own comments:

- This may be obvious to you, but the way you've structured your
timeline means you can probably submit PRs while you're coding, and the
review/merge cycle can be pipelined with the development. I would
encourage you to write something to the effect, e.g, you could make it a
goal that the Py3k compat is *merged* into master before the midterms.

- One of the many things that modtool sucks at (<= I'm allowed to say
that :D ) is that it has no automated checking. At the very least, we
could run PyLint against it (maybe as part of 'make check'...although
that means PyLint becomes a build-time dependency... hmmm) and then
BuildBot would pick it up too. Even better would be full unit testing,
although I'm not quite sure how that would work. I guess you could run
newmod, add, remove in that sequence and make sure it doesn't fail. More
advanced would be to check the generated code for validity, but I really
don't have a good suggestion on how to do that.

- The plugin architecture is *great*. Something else that modtool is
missing is that it only has the CLI, and no API. Maybe you can kill two
birds with one stone here: It would be nice if modtool was not only
controllable from the command line, but would also be scriptable from
other Python scripts. Then you could build Eclipse plugins around
modtool, and stuff like that.

- You mention a UI in the timeline, but not in the text (or did I miss
that). Are you talking about a *graphical* user interface? Or the CLI?

Other than that, this is a very good proposal.

-- Martin














___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC2018] Adding Passive radar and multiple device support to gr-radar toolbox

[CEL]

Hi Suraj,

thank you very much for sending us your proposal! This already looks
very nice.
Can I wish for you to add something like a rough block diagram that
describes how your simulated illuminator, your signal recoverer, your
radar estimator and your clutter reducer work together, and which
information you plan on letting these exchange? That would allow us to
"mentally" map what you're doing each week in your proposed timeline to
components of the system.

All in all, this is pretty ambitious, but exciting!
How will you tackle the OFDM signal recovery? I think your reference
[2] is really much to be completely done in one GSoC, so it would be
totally OK to say you just picked a reduced approach. Still, if you
want to do that in all its glory, that would be cool, too, but I'd ask
Martin how much work he'd expect that to be, and if necessary, reserve
more time for the algorithmic part alone. I'm also including Jean-
Michel Friedt of low-cost passive radar fame[A], as I hope he might
have a moment to read and comment on your proposal.

Best regards,
Marcus

[A] http://jmfriedt.free.fr/URSI.pdf
On Fri, 2018-03-23 at 12:54 +0530, suraj hanchinal wrote:
> Hello Everyone, 
> I am Suraj Hanchinal, a second year undergraduate in Electrical Engineering 
> at the Indian Institute of Technology, Kanpur. I had approached the mailing 
> list and communicated with Martin Braun, the mentor and others regarding the 
> gr-radar toolbox extension idea. I decided to work on adding passive radar 
> support to the toolbox after these discussions. I have finally completed the 
> proposal [1] and I would like feedback as well as suggestions for improvement 
> on the proposal.
> 
> Thank you,
> 
> Regards,
> Suraj Hanchinal
> 
> Proposal [1] 
> https://github.com/surajhanchinal/GSoC_proposal/blob/master/My%20GSoc%20Proposal.pdf
>  
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] synchronization problem

[CEL]

Can you elaborate on what kind of signal you're sending, and what kind
of synchronization you need?
Synchronization exist for carrier frequency, symbol rates, timing
offsets, phase and packets, to name the lowest-level forms of
synchronization.
How synchronization is done usually depends on the kind of signals
you're sending. There's no general method that works for everything!

Best regards,
Marcus

On Fri, 2018-03-23 at 16:19 +0900, 김무연 wrote:
> Hi guys
> I want to ask something about synchronization
> I am researching about beamforming so I use 2 usrps as transmitters and I use 
> one usrp as a receiver
> I can check they send signals and it receives signals
> but I need to synchronize Rx with Tx to check the change of amplitude in 
> received signal
> Are there any ways to synchronize using normal blocks in gnu radio?
> Because still I have no idea about making customized blocks in gnu radio
> Thanks
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Johannes Demel]

Hi Harshit,

I read your proposal and I have quite a few suggestions for improvement.

General remarks
Your references must be updated. They do not point to the actual sources 
but some general landing page. Also, I found at least one reference that 
points to an incorrect source.


Introduction
This section needs to be better structured. Give a brief analysis of the 
current state and what you want to achieve.

e.g.: current GR codes. Why use LDPC? 5G standard. Overall goal.

Features
here you need to clearly state what you want to do. Which codes? What 
should they achieve? Tools? Language?


LDPC code theory [missing]
Discuss how LDPC codes are defined. This includes a short discussion on 
Gallager's and MacKay's work. Discuss how Tanner graphs work. Discuss 
known decoder algorithm.

Also: http://www.inference.org.uk/mackay/codes/data.html

Workflow
Discuss the `gr-fec` interface for encoder and decoder objects. You want 
to integrate your work into GNU Radio. Show us how you want to achieve 
this. And show us that you worked through the FECAPI.

From theory to practice:
- Start with generic implementation of LDPC codes (Python?)
- Work through 5G standard to learn the complete code space.
- Start with one code and implement it in C++.
- Discuss how you want to ensure code quality. i.e. unittests.

You mention a GUI. I'd argue a GUI would be a distraction from your 
actual goal.


Deliverables
It is a difficult task to implement and optimize one code. Focus on LDPC 
codes. Drop the Turbo Code part. Also, be way more specific here. What 
will be the outcome of your project? Think of it in terms of milestones.
Discuss which parts you want to implement how. Python/C++. Also, discuss 
SIMD if you want to use this. There are quite a few different 
approaches. OpenMP, AVX/SSE, Neon, etc. How are they related to Python/C++?


This section should be accompanied by a detailed timeline. At least what 
you want to achieve each week. Show us how you envision your progress 
and what you want to do. Show us that you put some thought into this.
Start with your timeline from now on. Show us how you want to become 
part of our community.


Implementation
Create your own figures. Show us how you understand things.
There are good LaTeX tools to create Listings with C++ highlighting. Use 
them for your code example. So far your code example is very vague. I'd 
suggest you show us how you would implement a LDPC node. Or something 
similar.
Keep in mind GNU Radio does generally target CPUs. Thus, your GPU 
implementation part seems to be out of place. Unless, you want to 
implement LDPC codes on GPUs. In this case discuss the technologies you 
want to use. And also, how do you want to integrate your work into GNU 
Radio in this case? I'd suggest to go for a CPU implementation, though.
Do not copy code from other sources. Also, please do not copypasta 
equations into your proposal from other sources. Show us that you 
understand what you are talking about and make your proposal consistent. 
These suggestions apply to `algorithm 1` as well.


3GPP 5G/Release 15 discussion
Do not copy parts of the standard. Discuss the specifics of the LDPC 
codes in the standard and how they work. What are ptifalls? simplifications?


License
Do you want to publish all your code under GPLv3? Then state this. Also, 
discuss if you want to create an OOT or you want to merge your code into 
the main GNU Radio project. This would require a CLA I guess.


Your background
Please give us a short CV here and discuss your previous experience.

All in all, I'm happy you want to pick up this project.

Cheers
Johannes


On 22.03.2018 22:42, 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) > 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 

Re: [Discuss-gnuradio] [GSoC2018][Filter Design Tool Enhancements][Need Feedback]

[Felix Wunsch]

Hello Sakshi,

great to hear that you are interested in improving the filter design tool!

Your proposal, however, still needs some work. Please read the
guidelines carefully, we have a list of specific information we need
from you without which we can't consider your proposal.

About your timeline: Please make that more detailed. A detailed timeline
can show us very well how clear your vision for the project is and how
much time you think you need for the different parts. I also have to say
that tests only appear in the last week of the coding phase. For the
code to be mergeable and maintainable, tests are an absolutely mandatory
requirement.

It would also be nice if you could expand your personal background
section a bit. What kind of projects did you already work on? Were they
related to DSP, and which programming language(s) did you use? Do you
maybe even have a GitHub account with relevant code? As the project idea
states, you will need a strong DSP background as well as good knowledge
of at least Qt or Python.

Best regards,
Felix


On 03/23/2018 07:10 AM, Sakshi Agrawal wrote:
>
> Hello Everyone,
>
> This is Sakshi Agrawal, Graduated in Electronics Engineering. I have
> been following DSP industries. A few days back I ran into GSoC
> programme. I have seen some GSoC projects proposed by GNU radio in
> filter design. Having proper coding knowledge and strong DSP
> background from my undergraduate coursework I thought of contributing
> to GNU radio.
>
> The Filter and Design tool by GNU radio is already very neatly
> designed and contributing to that will be an experience. The current
> to-be-solve issues are to improve the ease of using the tool, add more
> functionality and more support for filter design.
>
> "This project is to improve our uses of these tools and blocks to make
> it more obvious to the users as well as automate some of the decisions
> for optimally using them."
>
> Here are some thoughts which I think will be an extra feature to
> consider (may or may not be necessary) :
>
> 1. Tip the user when selection is to be made. Also, automate some
> obvious decisions.
>
> 2. Implement a tool that can save the current results into a file and
> also can import the existing file/plot which further can be used in
> other work or can be modified as per user requirement.
>
> 3. Implement a bidirectional support to graph or plot i.e. plot can be
> changed by values and also by a hand tool user can tweak the plot
> which will give desired values.
>
> 4.Implement a slider which changes the plot as the user slides on the
> values
>
> 5. Add support to more filter design and new filter specs
>
> Specifically, I want to contribute to a module can be integrated to GR
> and gives a new functionality/concept like adding support for
> cascading filter.
>
> Two  filter design concepts:
>
> 1. Add more support for Cascaded filters
>
> 2. Better support for creating PFB filters
>
>
> I have been working on my proposal[0]. I would request you to go
> through it and point out any flaw that I should know or some general
> suggestions to make it better.
>
> Best
> Sakshi Agrawal
>
> [0]https://github.com/sakshi18agrawal1/documents/blob/master/Sakshi_GSoC2018.pdf
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Harshit Gupta]

Hello everyone,

The link was pointing to an older version. I have fixed the link. I need
some feedback on my proposal [0].

Some queries:
What exactly should I include in 'Implementation'? I have put generic
decoder code and sample code for optimal implementation of FEC codes
(specifically LDPC).




[0]
https://github.com/harshit4084/MyDoc/blob/master/gsoc2018_Harshit_Gupta.pdf




Regards,
Harshit Gupta

On Fri, Mar 23, 2018, 3:12 AM 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) 
> 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 +, 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 

[Discuss-gnuradio] [GSoC2018] Adding Passive radar and multiple device support to gr-radar toolbox

[suraj hanchinal]

Hello Everyone,
I am Suraj Hanchinal, a second year undergraduate in Electrical Engineering
at the Indian Institute of Technology, Kanpur. I had approached the mailing
list and communicated with Martin Braun, the mentor and others regarding
the gr-radar toolbox extension idea. I decided to work on adding passive
radar support to the toolbox after these discussions. I have finally
completed the proposal [1] and I would like feedback as well as suggestions
for improvement on the proposal.

Thank you,

Regards,
Suraj Hanchinal

Proposal [1]
https://github.com/surajhanchinal/GSoC_proposal/blob/master/My%20GSoc%20Proposal.pdf
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] synchronization problem

[김무연]

Hi guysI want to ask something about synchronizationI am researching about beamforming so I use 2 usrps as transmitters and I use one usrp as a receiverI can check they send signals and it receives signalsbut I need to synchronize Rx with Tx to check the change of amplitude in received signalAre there any ways to synchronize using normal blocks in gnu radio?Because still I have no idea about making customized blocks in gnu radioThanks___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC2018][Filter Design Tool Enhancements][Need Feedback]

[Sakshi Agrawal]

Hello Everyone,

This is Sakshi Agrawal, Graduated in Electronics Engineering. I have been
following DSP industries. A few days back I ran into GSoC programme. I have
seen some GSoC projects proposed by GNU radio in filter design. Having
proper coding knowledge and strong DSP background from my undergraduate
coursework I thought of contributing to GNU radio.

The Filter and Design tool by GNU radio is already very neatly designed and
contributing to that will be an experience. The current to-be-solve issues
are to improve the ease of using the tool, add more functionality and more
support for filter design.

"This project is to improve our uses of these tools and blocks to make it
more obvious to the users as well as automate some of the decisions for
optimally using them."

Here are some thoughts which I think will be an extra feature to consider
(may or may not be necessary) :

1. Tip the user when selection is to be made. Also, automate some obvious
decisions.

2. Implement a tool that can save the current results into a file and also
can import the existing file/plot which further can be used in other work
or can be modified as per user requirement.

3. Implement a bidirectional support to graph or plot i.e. plot can be
changed by values and also by a hand tool user can tweak the plot which
will give desired values.

4.Implement a slider which changes the plot as the user slides on the values

5. Add support to more filter design and new filter specs

Specifically, I want to contribute to a module can be integrated to GR and
gives a new functionality/concept like adding support for cascading filter.

Two  filter design concepts:

1. Add more support for Cascaded filters

2. Better support for creating PFB filters

I have been working on my proposal[0]. I would request you to go through it
and point out any flaw that I should know or some general suggestions to
make it better.

Best
Sakshi Agrawal

[0]
https://github.com/sakshi18agrawal1/documents/blob/master/Sakshi_GSoC2018.pdf
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio