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

[swapnil negi]

Hello everyone,
A brief clarification regarding GitLab profile: We use our own GitLab
hosted in our own local server.
Thanks!

Regards,
Swapnil Negi
Indian Institute of Technology Roorkee

On Tue, 27 Mar 2018, 01:57 swapnil negi,  wrote:

> Hello everyone, I have incorporated the changes mentioned by Nicolas.
> Regarding GitLab profile: As per my group's policy, the code has not been
> made open source. Hence, due to the copyright issues, the code cannot be
> published in the proposal.
>
> Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
> Code Link: https://github.com/swap-nil7/GSoC-Proposal
>
> Regards,
> Swapnil Negi
> Indian Institute of Technology Roorkee
>
> On Mon, Mar 26, 2018 at 6:41 PM, Nicolas Cuervo 
> wrote:
>
>> Hello Swapnil,
>>
>> thanks for updating your draft! I'm really excited about your
>> application. Please don't forget to officially apply and upload your
>> proposal through the program website.
>>
>> I have very, very small comments in regard of code practices,
>>
>>- Keep in mind the coding guidelines in all your code snippets.
>>- Having the functional programming as an objective, keep in mind the
>>correct syntax is used in your functions and methods. For example: the
>>__import__() function used in your plugin loader will work just fine, but
>>this usage is recommended for the interpreter. For implementations as the
>>one you are proposing, import_module() should be used (unless you are
>>expecting to load a package).
>>- Your string formatting uses the old convention. I suggest having a
>>look at 'str'.format()
>>
>> Additionally, you mention in your background that you work regularly in
>> GitLab, but you shared your Github profile instead. Do you have code in
>> there that is not in your Github profile? If so, would you mind adding a
>> link to your GitLab profile?
>>
>> All in all, I think that your proposal is well structured, and the
>> examples that you provide on how to deal with the problem at hand are on
>> point. My comments are being very picky ;) but that's because the rest of
>> your proposal seems ready! Again, dont forget to officially apply and
>> upload your proposal.
>>
>> Cheers,
>> - Nicolas
>>
>> On Sun, Mar 25, 2018 at 10:53 PM, swapnil negi 
>> wrote:
>>
>>> Hello everyone,
>>> I have incorporated all the mentioned improvements to the best of my
>>> knowledge. Please review the *almost final* draft of the proposal.
>>> Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
>>> Code Link: https://github.com/swap-nil7/GSoC-Proposal
>>> Thank you!
>>>
>>> Regards,
>>> Swapnil Negi
>>> Indian Institute of Technology Roorkee
>>>
>>>
>>> On Sun, Mar 25, 2018 at 4:55 PM, swapnil negi 
>>> wrote:
>>>
 Hello everyone,
 Thanks for the detailed review.
 I have made changes to my proposal to incorporate review/merge cycle,
 build Python API for the modtool, briefly explain the UI enhancements and
 fix typos.
 I am still quite unsure about the automated testing part. But as of
 now, thorough testing will be done locally.
 Please review the updated version of my proposal.
 Thanks! :)
 Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
 Code Link: https://github.com/swap-nil7/GSoC-Proposal

 On Tue, Mar 20, 2018 at 12:33 AM, swapnil negi <
 swapnil.neg...@gmail.com> 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
> Thank You!
>
> Regards,
> Swapnil Negi
> Indian Institute of Technology Roorkee
> India
>
>
> On Sat, Mar 17, 2018 at 3:09 AM, swapnil negi <
> swapnil.neg...@gmail.com> wrote:
>
>> Hi Nicoloas!
>> Thanks for your valuable response.
>> Regarding Python compatibility - I will work upon version independent
>> compatibility using information from the following links:
>> Link[1]  Link[2]
>> 
>> Regarding specific milestones - I have now listed the work that can
>> be assessed after the completion of various phases.
>> Regarding CV: I have removed the section of such personal details
>> from the CV as well as proposal.
>>
>> Cheers,
>> Swapnil Negi
>>
>> On Fri, Mar 16, 2018 at 5:45 PM, Nicolas Cuervo <
>> nicolas.cue...@ettus.com> wrote:
>>
>>> Hello Swapnil Negi,
>>>
>>> Thank you for your proposal! This project has been in the pipeline
>>> for long and I'm very excited to see your interest in working on it. I 
>>> have
>>> very few comments for now, but the discussion can definitely 

[Discuss-gnuradio] VOLK v1.3.1 and v1.4

[West, Nathan]

Hi all,

After a long time, new Volk releases are out. Release notes and downloads
are in the normal places on libvolk.org with md5sums and signatures signed
by me (nathan.w...@gnuradio.org).

v1.3.1 is a support release with bug fixes. I've switched to the "merge
back" model for this release where everything goes in to master and I
cherry-pick commits back to a support branch. I think this makes it easier
to keep all of the changes in one place-- but I'd like to know what kind of
support users would like. If you care about stable APIs for a long time I'd
like to hear about it so that I can develop a sense of how long or how many
"stable" branches I should keep around.

v1.4 has a ton of new stuff... It builds with python3, has new kernels, new
protokernels with lots of AVX support, and some added NEON support. I'm
pretty excited about this release since it adds a good bit of fast code!

Call for development:
v1.5 is not out yet (or started), but I imagine that it will add support
for AVX512 and purge boost (that might make it in to a v1.4.1) as a
dependency and maybe replace some verbose support code with c++11. Right
now there are 2 remaining lines that require boost. If you care about that
kind of thing check out the boost::filesystem use in volk_profile. I have
heard of someone adding AVX512 support, but I don't have a machine that
supports it-- continue down that path if you have a machine with support!

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

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

[swapnil negi]

Hello everyone, I have incorporated the changes mentioned by Nicolas.
Regarding GitLab profile: As per my group's policy, the code has not been
made open source. Hence, due to the copyright issues, the code cannot be
published in the proposal.

Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
Code Link: https://github.com/swap-nil7/GSoC-Proposal

Regards,
Swapnil Negi
Indian Institute of Technology Roorkee

On Mon, Mar 26, 2018 at 6:41 PM, Nicolas Cuervo 
wrote:

> Hello Swapnil,
>
> thanks for updating your draft! I'm really excited about your application.
> Please don't forget to officially apply and upload your proposal through
> the program website.
>
> I have very, very small comments in regard of code practices,
>
>- Keep in mind the coding guidelines in all your code snippets.
>- Having the functional programming as an objective, keep in mind the
>correct syntax is used in your functions and methods. For example: the
>__import__() function used in your plugin loader will work just fine, but
>this usage is recommended for the interpreter. For implementations as the
>one you are proposing, import_module() should be used (unless you are
>expecting to load a package).
>- Your string formatting uses the old convention. I suggest having a
>look at 'str'.format()
>
> Additionally, you mention in your background that you work regularly in
> GitLab, but you shared your Github profile instead. Do you have code in
> there that is not in your Github profile? If so, would you mind adding a
> link to your GitLab profile?
>
> All in all, I think that your proposal is well structured, and the
> examples that you provide on how to deal with the problem at hand are on
> point. My comments are being very picky ;) but that's because the rest of
> your proposal seems ready! Again, dont forget to officially apply and
> upload your proposal.
>
> Cheers,
> - Nicolas
>
> On Sun, Mar 25, 2018 at 10:53 PM, swapnil negi 
> wrote:
>
>> Hello everyone,
>> I have incorporated all the mentioned improvements to the best of my
>> knowledge. Please review the *almost final* draft of the proposal.
>> Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
>> Code Link: https://github.com/swap-nil7/GSoC-Proposal
>> Thank you!
>>
>> Regards,
>> Swapnil Negi
>> Indian Institute of Technology Roorkee
>>
>>
>> On Sun, Mar 25, 2018 at 4:55 PM, swapnil negi 
>> wrote:
>>
>>> Hello everyone,
>>> Thanks for the detailed review.
>>> I have made changes to my proposal to incorporate review/merge cycle,
>>> build Python API for the modtool, briefly explain the UI enhancements and
>>> fix typos.
>>> I am still quite unsure about the automated testing part. But as of now,
>>> thorough testing will be done locally.
>>> Please review the updated version of my proposal.
>>> Thanks! :)
>>> Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
>>> Code Link: https://github.com/swap-nil7/GSoC-Proposal
>>>
>>> On Tue, Mar 20, 2018 at 12:33 AM, 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
 Thank You!

 Regards,
 Swapnil Negi
 Indian Institute of Technology Roorkee
 India


 On Sat, Mar 17, 2018 at 3:09 AM, swapnil negi  wrote:

> Hi Nicoloas!
> Thanks for your valuable response.
> Regarding Python compatibility - I will work upon version independent
> compatibility using information from the following links:
> Link[1]  Link[2]
> 
> Regarding specific milestones - I have now listed the work that can be
> assessed after the completion of various phases.
> Regarding CV: I have removed the section of such personal details from
> the CV as well as proposal.
>
> Cheers,
> Swapnil Negi
>
> On Fri, Mar 16, 2018 at 5:45 PM, Nicolas Cuervo <
> nicolas.cue...@ettus.com> wrote:
>
>> Hello Swapnil Negi,
>>
>> Thank you for your proposal! This project has been in the pipeline
>> for long and I'm very excited to see your interest in working on it. I 
>> have
>> very few comments for now, but the discussion can definitely continue 
>> open:
>>
>> So the timeline that you are proposing is:
>> 1) Python3 Compatible
>> 2) Implement Plugin Architecture
>> 3) Restructure code in favor of functional behavior
>> 4) work on UI if time allows
>>
>> And I agree with this timeline, as it puts core focus on the
>> architectural overhaul without disregarding other details aside.
>>

Re: [Discuss-gnuradio] Dependency Problem

[Derek Kozel]

Hello Burak,

First, it's much easier for us to look at the error if you past the text
into your email rather than taking a screenshot.

Apt is saying that there are broken packages on your system. You (almost
certainly) have the myriad-rf PPA installed and are trying to use gnuradio
from that. Unfortunately the version of GNU Radio built in that PPA relies
on the UHD PPA which has been updated more recently than the GNU Radio
package on Myriad RF's PPA. This is what has caused the dependency problem
as the UHD 3.10.3.0 package is no longer available.

You can build the specific release of UHD manually and then force the
installation of the gnuradio package from the myriad-rf PPA, or build
gnuradio and the other packages from source. You could also revert back to
using the default packages in the Ubuntu repository which are all
consistent.

Regards,
Derek

On Mon, Mar 26, 2018 at 3:13 PM, Burak KESKIN  wrote:

> Hi everyone,
>
> I'm tried to install gnuradio but got following error:
>
>
> The following packages have unmet dependencies:
>
> gnuradio : Depends: libgnuradio-uhd3.7.10 but it is not going to be
> installed.
>
>  Depends: linuhd003.010.003 but it is not installable.
>
>
> I used command "sudo apt-get install gnuradio gnuradio-dev" and I'm using
> ubuntu 16.04.
>
> Has anyone got same error or I'm doing something wrong.
>
>
> Thank you,
>
>
> Regards,
>
> Burak KESKIN
>
>
> ___
> 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] Repeatability of FEC Decoder Decisions

[Greg Rendon]

I'm working on a satellite radio downlink implementation that uses the
CCSDS recommended error correction, i.e. 7, 1/2, (109,79) inner convolution
code and Reed-Solomon (255,223) outer code.  I'm using the suggested FECAPI
set (FEC Extended Decoder, CC Decoder definition) for my inner decoder.  To
generate some metric on the symbol decisions from the receiver I'm
re-encoding the extended decoder output using the FEC Extended Encoder and
CC Encoder definition.  I'm acquiring a BER by providing packed bits to the
BER block. However, I can't seem to get my bit error rate lower than
log10(-1.2).  Running individual block checks I found that supplying the
same input to two identical decoders results in a minimum BER around
log10(-1.24), i.e. the decoder results do not seem to be very consistent.

To isolate the decoder I generated a test flowgraph (attached) with a
(Gaussian) random input to a constellation soft decoder, into a pair of
identical decoders and found that the BER is inversely related to the frame
size as defined in the CC Decoder definition.  Additionally, observing the
output bitstreams of the two decoders it can be seen that decision
disagreements are concentrated near, though not exclusively at frame
edges.  I've tried using all four available streaming behavior options,
with and without byte padding, and all options have roughly the same BER
for a given frame size.

I'm still educating myself on Viterbi decoding, particular for streaming
implementations, but it seems that these results are (hopefully)
anomalous.  At the very least, they are problematic.  I'll keep chugging
away at this, but if anyone could provide insight/clarification I would be
most appreciative.  In particular,
-  Is there some resource already available in GNURadio literature that
I've missed that addresses this?
-  Is there something I'm doing wrong or misunderstanding about the Viterbi
algorithm or how FEC should be implemented in GNURadio that would explain
this behavior?
-  If not, perhaps this an issue with how the blocks handle data between
calls to work() and/or something in the butterfly setup?  If so,
suggestions on debugging?
-  Something else blatantly obvious that I've overlooked?

Thanks,
Greg


greg_fec_decoder_test.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] synchronization problem

[CEL]

Hm, cosine wave as baseband signal means you get two symmetric spectral
peaks around your carrier frequency. In that case, I'd actually just go
for a really simple costas loop. You could also do kind of a "matched
filter" M with a cosine receive filter, but I don't see the
advantage.

Notice that sending a cosine can't convey any information. Are you sure
this is all you need? The only reason I can instantly think of is using
that signal as frequency normal for a different system, and in that
case, you're only telling us a tiny fraction of the whole system you're
 building.

Especially the wording "…is about frequency-offset *I think*" suggests
you're very much subject to the XY Problem [1], and it would be a very
good idea to describe the whole thing you're trying to build, instead
of only the very small problem you're acutely trying to solve.

Best regards,
Marcus

[1] http://xyproblem.info
On Tue, 2018-03-27 at 00:06 +0900, 김무연 wrote:
> Hi last time i asked about synchronization
> But my question was too broad
> So i couldn't get an answer
> I use cosine wave as a baseband signal
> And I use 1-bit feedback
> I use 2 usrps as a transmitters and 1 usrp as a receiver
> And the synchronization i want is about frequency-offset I think
> 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

[Discuss-gnuradio] synchronization problem

[김무연]

Hi last time i asked about synchronizationBut my question was too broadSo i couldn't get an answerI use cosine wave as a baseband signalAnd I use 1-bit feedbackI use 2 usrps as a transmitters and 1 usrp as a receiverAnd the synchronization i want is about frequency-offset I thinkThanks___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] High Pass and Low Pass performance not inverse

[Andrej Rode]

Hi John, 

On Tue, Mar 13, 2018 at 09:15:33AM -0400, John Ackermann N8UR wrote:
> I'm setting up a measurement program to look at the channel power inside 
> and outside a defined bandwidth centered at zero.  The idea is to get 
> the ratio of the power within a low pass filter (nominally 500 Hz), and 
> the power in the rest of the spectrum (192 kHz) with that same 500 Hz 
> chunk notched out.  Attached are a screenshot of the the flowgraph and 
> of an FFT showing the results.
> 
> What puzzles me is that the low pass filter has a defined flat-top, 
> while the high pass filter shows a very narrow notch.  I would expect 
> the two to have a similar shape.  (I'm using rectangular windows because 
> I want to get the actual noise power for the given bandwidth.)

Running this short python script will generate filtertaps from the
firdes functions in GNU Radio and plot the amplitude of their transfer functions
linearly.

```
#!/usr/bin/env python2

from gnuradio import filter
import numpy as np
import matplotlib.pyplot as plt


def main():
  lp = filter.firdes_low_pass(1.0, 192e3, 250.0, 25.0, 
filter.firdes.WIN_RECTANGULAR)
  hp = filter.firdes_high_pass(1.0, 192e3, 250.0, 25.0, 
filter.firdes.WIN_RECTANGULAR)

  plt.plot(np.abs(np.fft.fftshift(np.fft.fft(lp
  plt.plot(np.abs(np.fft.fftshift(np.fft.fft(hp

  plt.show()
  return True

if __name__ == "__main__":
  exit(not main())

```

Given your GNU Radio modules are in the Python path and you have
Matplotlib installed.
You can also run more verifications using the impulse responses.

> 
> Any thoughts on why this is happening, or on ways to make the two 
> responses more precisely mirror each other?

According to the impulse responses they mirror each other pretty well
and shouldn't cause what you are seeing.  I did not look at the source
code of the firdes_* functions though.

Cheers
Andrej

-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

[Discuss-gnuradio] Dependency Problem

[Burak KESKIN]

Hi everyone,

I'm tried to install gnuradio but got following error:


The following packages have unmet dependencies:

gnuradio : Depends: libgnuradio-uhd3.7.10 but it is not going to be installed.

 Depends: linuhd003.010.003 but it is not installable.


I used command "sudo apt-get install gnuradio gnuradio-dev" and I'm using 
ubuntu 16.04.

Has anyone got same error or I'm doing something wrong.


Thank you,


Regards,

Burak KESKIN
___
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

[suraj hanchinal]

Hello everyone,

After receiving feedback and suggestions from all of you, I am modified and
refined my application and incorporated all your ideas.I request you to
please do read the proposal and provide feedback to the updated proposal
since the date is closing in. I have linked the GSoC proposal below.

Thanking you,
Regards,

Suraj Hanchinal

GSoC proposal :
https://github.com/surajhanchinal/GSoC_proposal/blob/master/My%20GSoC%20Proposal%20.pdf

On Sun, Mar 25, 2018 at 8:37 PM, suraj hanchinal 
wrote:

> Hello everyone,
> Thank you JM Friedt. I apologise sincerely for these trivial mistakes.
> Thanks for pointing them out. I have linked the corrected GSoC proposal.
> Please do provide feedback.
> Thanking you,
>
> Regards,
> Suraj Hanchinal
>
> GSoC Proposal: https://github.com/surajhanchinal/GSoC_proposal/
> blob/master/My%20GSoC%20Proposal%20.pdf
>
> On Sun, Mar 25, 2018 at 8:33 PM, suraj hanchinal  > wrote:
>
>> Hi Ben,
>> In case of using WiFi as signals of opportunity, we do not use
>> directional antennas or set the reference receiver in a specific direction.
>> Here the reference signal is the signal received from a receiver kept in
>> Line of Sight with the main transmitter. The surveillance receiver does use
>> a directional antenna pointed in the general location of the target.
>>
>> Thank you,
>> Suraj Hanchinal
>>
>> On Sun, Mar 25, 2018 at 8:07 PM, Benny Alexandar 
>> wrote:
>>
>>> Hi Suraj,
>>>
>>> I would like to know for measuring the reference signal how do you
>>> determine the direction of transmitter ?  In case of WiFi which direction
>>> you set your antenna for making it as reference ?
>>>
>>> -ben
>>> --
>>> *From:* Discuss-gnuradio >> outlook@gnu.org> on behalf of suraj hanchinal <
>>> surajhanchi...@gmail.com>
>>> *Sent:* Sunday, March 25, 2018 7:36 PM
>>> *To:* jmfriedt
>>> *Cc:* mar...@gnuradio.org; discuss-gnuradio@gnu.org
>>> *Subject:* Re: [Discuss-gnuradio] [GSoC2018] Adding Passive radar and
>>> multiple device support to gr-radar toolbox
>>>
>>> Hello everyone,
>>> After reading the suggestions as well as feedback from Marcus Muller and
>>> Martin Braun, I have made the suggested changes as well as explained the
>>> algorithms in greater detail. Please read the updated proposal and provide
>>> feedback and suggestions.
>>>
>>> Thanking you,
>>>
>>> Regards,
>>> Suraj Hanchinal
>>>
>>> GSoC Proposal: https://github.com/surajhanchi
>>> nal/GSoC_proposal/blob/master/My%20GSoC%20Proposal.pdf
>>>
>>> On Sun, Mar 25, 2018, 2:18 PM suraj hanchinal 
>>> wrote:
>>>
>>> Hello Jean-Michel Friedt,
>>>
>>> Thank you for your valuable feedback. That is a very good insight since
>>> I overlooked the cross-ambiguity function and its calculation considering
>>> them trivial. I will definitely look into the papers that you mentioned and
>>> include them in my proposal.
>>>
>>> Thank you,
>>>
>>> Regards,
>>> Suraj Hanchinal
>>>
>>> On Sun, Mar 25, 2018 at 2:12 PM, jmfriedt >> r> wrote:
>>>
>>> > 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.
>>>
>>> I am not sure I can provide useful comments on the proposal, whose
>>> various iterations I have been reading as they were being updated. Real
>>> time passive radar processing seems challenging to me, and I would
>>> advise looking at alternatives to the brute force cross correlation of
>>> the Doppler shifted signal. You might want to have a look at
>>> https://www.researchgate.net/publication/279069212_Batches_a
>>> lgorithm_for_passive_radar_A_theoretical_analysis
>>> and especially its Table I which lists computational complexity of
>>> various algorithms. An updated version of the document cited by Marcus
>>> is at http://jmfriedt.free.fr/dvbt_hardware.pdf (submitted for
>>> publication but not yet accepted): beyond the improved batches
>>> algorithm allowing for much faster computation, we also address using
>>> multiple receivers in parallel, each tuned to different carrier
>>> frequencies.
>>>
>>> JM
>>>
>>> --
>>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>>> 
>>> 25000 Besancon, Fr Michaelance
>>>
>>>
>>>
>>
>

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

[Nicolas Cuervo]

Hello Swapnil,

thanks for updating your draft! I'm really excited about your application.
Please don't forget to officially apply and upload your proposal through
the program website.

I have very, very small comments in regard of code practices,

   - Keep in mind the coding guidelines in all your code snippets.
   - Having the functional programming as an objective, keep in mind the
   correct syntax is used in your functions and methods. For example: the
   __import__() function used in your plugin loader will work just fine, but
   this usage is recommended for the interpreter. For implementations as the
   one you are proposing, import_module() should be used (unless you are
   expecting to load a package).
   - Your string formatting uses the old convention. I suggest having a
   look at 'str'.format()

Additionally, you mention in your background that you work regularly in
GitLab, but you shared your Github profile instead. Do you have code in
there that is not in your Github profile? If so, would you mind adding a
link to your GitLab profile?

All in all, I think that your proposal is well structured, and the examples
that you provide on how to deal with the problem at hand are on point. My
comments are being very picky ;) but that's because the rest of your
proposal seems ready! Again, dont forget to officially apply and upload
your proposal.

Cheers,
- Nicolas

On Sun, Mar 25, 2018 at 10:53 PM, swapnil negi 
wrote:

> Hello everyone,
> I have incorporated all the mentioned improvements to the best of my
> knowledge. Please review the *almost final* draft of the proposal.
> Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
> Code Link: https://github.com/swap-nil7/GSoC-Proposal
> Thank you!
>
> Regards,
> Swapnil Negi
> Indian Institute of Technology Roorkee
>
>
> On Sun, Mar 25, 2018 at 4:55 PM, swapnil negi 
> wrote:
>
>> Hello everyone,
>> Thanks for the detailed review.
>> I have made changes to my proposal to incorporate review/merge cycle,
>> build Python API for the modtool, briefly explain the UI enhancements and
>> fix typos.
>> I am still quite unsure about the automated testing part. But as of now,
>> thorough testing will be done locally.
>> Please review the updated version of my proposal.
>> Thanks! :)
>> Proposal Link: https://swap-nil7.github.io/gsoc-proposal.pdf
>> Code Link: https://github.com/swap-nil7/GSoC-Proposal
>>
>> On Tue, Mar 20, 2018 at 12:33 AM, 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
>>> Thank You!
>>>
>>> Regards,
>>> Swapnil Negi
>>> Indian Institute of Technology Roorkee
>>> India
>>>
>>>
>>> On Sat, Mar 17, 2018 at 3:09 AM, swapnil negi 
>>> wrote:
>>>
 Hi Nicoloas!
 Thanks for your valuable response.
 Regarding Python compatibility - I will work upon version independent
 compatibility using information from the following links:
 Link[1]  Link[2]
 
 Regarding specific milestones - I have now listed the work that can be
 assessed after the completion of various phases.
 Regarding CV: I have removed the section of such personal details from
 the CV as well as proposal.

 Cheers,
 Swapnil Negi

 On Fri, Mar 16, 2018 at 5:45 PM, Nicolas Cuervo <
 nicolas.cue...@ettus.com> wrote:

> Hello Swapnil Negi,
>
> Thank you for your proposal! This project has been in the pipeline for
> long and I'm very excited to see your interest in working on it. I have
> very few comments for now, but the discussion can definitely continue 
> open:
>
> So the timeline that you are proposing is:
> 1) Python3 Compatible
> 2) Implement Plugin Architecture
> 3) Restructure code in favor of functional behavior
> 4) work on UI if time allows
>
> 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

Re: [Discuss-gnuradio] Introduction for GSoC18 participation

[CEL]

Hi Luca,

after having read your proposal, I really like the way you're
approaching all this. I second everything that Felix said, and
especially that since existing OFDM methods take care of sync for you,
you should, for now, stick to that. My guess is that reusable single-
carrier blocks kind of are what you'd implement for unit testing,
anyway, minus the sync. I'd be interested in mentoring you, as I feel
this is dear to my heart, which belongs to upstream GNU Radio.

Thanks for this very interesting proposal,
Marcus

On Sun, 2018-03-25 at 14:32 +, Wunsch, Felix (CEL) wrote:
> Hi Luca,
> 
> thanks for sharing your proposal draft! Here are some remarks:
> 
> 1. You list a MIMO channel model as deliverable. For slow, flat flading you 
> can use (as you correctly stated) a simple matrix multiplication block. That, 
> however, already exists in GNU Radio. Or were you thinking of a wrapper 
> around that functionality for some specific reason?
> 
> 2. Without wanting to overload you with additional deliverables, I think a 
> differential STBC such as [0] would be a nice addition. As it's very similar 
> to the Alamouti STBC it shouldn't be much work but it dispenses with CSI 
> estimation at the receiver, which simplifies implementation and potential 
> applications quite a bit.
> 
> 3. I'm not too familiar with the OFDM equalizer that is currently in the 
> tree, but you should try to use the existing code where possible.
> 
> 4. You write that you want to integrate the different MIMO schemes into 
> gr-digitals OFDM. What exactly will that integration look like in the end? I 
> would love to see some ready-to-use flow graphs as examples and potential 
> building blocks for (even) more advanced applications. You would need and 
> build them during development anyway, so this should also not really add to 
> your workload, but immensely help GNU Radio users who want to use your work!
> 
> 5. From your proposal, I'm not really sure if you are planning to do only 
> OFDM-based examples or also narrowband ones (you write something about 
> developing MIMO training sequences and channel estimation before you speak 
> about OFDM). Personally, I think you should limit the scope of your proposal 
> to OFDM. Narrowband systems require a  totally different synchronization and 
> that is just overhead for you. Of course, you should still try to separate 
> your, e.g., STBC encoding and decoding from the OFDM processing in a way that 
> makes it usable for single-carrier schemes (Right now, I'm thinking of simply 
> accepting different vector lengths for the respective blocks).
> 
> 6. There are some minor typo / grammatical / wording issues, it would be 
> great if you could also take care of that.
> 
> Despite of all the remarks I think you wrote a very nice proposal!
> 
> Cheers,
> Felix
> 
> [0] 
> https://pdfs.semanticscholar.org/ba1d/ba8af2e3cee3213794fe722d13e90de5baac.pdf
> 
> 
> Von: Discuss-gnuradio  
> im Auftrag von Luca Schmid 
> Gesendet: Samstag, 24. März 2018 22:24
> An: Sebastian Müller; Nicolas Cuervo Benavides
> Cc: GNURadio Discussion List
> Betreff: Re: [Discuss-gnuradio] Introduction for GSoC18 participation
>  
> Hi everyone,
> @Nico @Sebastian, thank you for commenting on my first thoughts about a MIMO 
> project for GSoC.
> I just uploaded a draft of my proposal on github.
> It would be really nice, if you could read it, comment on it and share your 
> ideas and thoughts, especially about my milestones and the timeline, with me.
> 
> Best and thank you in advance
> Luca
> 
> 2018-03-22 19:03 GMT+01:00 Sebastian Müller :
> > Hi Luca,
> > 
> > great to hear from you again!
> > MIMO is definitely a topic that deserves to be tackled by GNU Radio. Your 
> > idea seems well thought of and sensible (and of course your last year’s 
> > work speaks for itself). If I understand correctly, your proposed approach 
> > would only cover the MIMO-OFDM case. I would like to point out that other 
> > modulation schemes than OFDM might be of interest as well for some users, 
> > and therefore I think it is sensible to provide an easy extensibility of 
> > your work. It would be great if you could cover that topic in your proposal!
> > As Nicolas pointed out, you should have a first draft of your proposal 
> > online in just a few days in order to get more feedback on the mailing list 
> > before the deadline on March 27! I’m looking forward to hear more from you 
> > soon.
> > 
> > Cheers,
> > 
> > Sebastian Müller
> > gse...@gmail.com
> > PGP ID DC2AA3EE
> > 
> > Am 22. März 2018 um 11:10:37, Nicolas Cuervo (nicolas.cue...@ettus.com) 
> > schrieb:
> > > Hello Luca!
> > > 
> > > Thank you for showing interest in GSoC (once again! :) ) 
> > > 
> > > Your idea sounds very cool and also very useful for users that want to 
> > > have a first approach to MIMO, and you did your homework checking where 
> > > 

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

[Johannes Demel]

Hi Harshit,

some more comments on your proposal.
- be really specific about GR integration
- explain WHAT you want to implement.
- explain HOW you want to implement it.
- show us how you understand FECAPI.
- explain how you want to build on existing LDPC code in GR.

your deliverables are too vague. Tell us what you want to achieve. You 
want to implement a fast decoder, but you state you want to implement it 
mainly in Python. Also, you want to integrate your encoder/decoder into 
the FECAPI, which is a C++ API. You want to optimize your decoder with 
specific tools. Show us how you want to use those tools. Also, how do 
those tools fit into GR? And thus into your project.


Your timeline lacks measurable milestones. Also, keep in mind "It's the 
summer of CODE, not the summer of RESEARCH" (by Marcus Müller).


You want to focus on 5G LDPC codes. I'd recommend to go through the 
standard docs and map the description there to your LDPC theory.


Cheers
Johannes

On 25.03.2018 06:43, Harshit Gupta wrote:

Greetings,

Thanks Demel for the detailed feedback. I have updated most of the 
parts. Please have a look [0] and report for any ambiguity.


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




Best Regards,
Harshit Gupta

On Fri, Mar 23, 2018 at 10:06 AM, Johannes Demel 
> wrote:


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