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

[swapnil negi]

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
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 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!

- I would work on the format of the proposal as well to help you
make a better impression and increases your chances of this being 
 accepted.
In your timeline, be sure to explicitly say what deliverable can be
expected when. It's good to know when you are going to start working on
something, but it is also important to know when you are expected to 
 have
it finished. Words like "Milestone" or even "Deliverable" might make 
 this
clear, maybe around the evaluation dates.

- I see that you included your CV, which is nice to have, but do
you _really_ want your personal data (like phone and address) out in the
open?


 I might come back with more comments, but for now this is looking
 promising!

 Cheers,
 - Nicolas


 On Fri, Mar 16, 2018 at 3:57 AM, swapnil negi  

Re: [Discuss-gnuradio] build error at uhd::time_spec_t::get_system_time()

[Michael Dickens]

Hi Piotr - The error you encountered generally means that UHD was
already installed in the same prefix as the build would be going into,
and that the UHD API changed between the versions. Normally UHD can be
build over a pre-existing install, but sometime not too long ago this
feature was broken via these 2 lines in the top level CMakeLists.txt
file: <
https://github.com/EttusResearch/uhd/blob/maint/host/CMakeLists.txt#L327
>. Specifically for the build part, the
"INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})" comes before some (but not
all) of the local-to-build INCLUDE_DIRECTORIES, which means that if the
UHD API has changed, then the old API will be picked up -- as its
headers come before the new (internal to build) headers. The easy fix
for most OSs is to comment out those 2 lines & give the build a go
again. I'm working on fixing this issue in a more robust way, since
almost all of my builds / testing are on systems with UHD already
installed into the build's prefix. Hope this helps! - MLD
On Sun, Mar 25, 2018, at 7:43 AM, Piotr Swiatkiewicz wrote:
> I am trying to build GR with PyBOMBS and apart from problems with the
> build system itself (it would not start properly when python3 is used)
> I get the following error not far away (85% complete) from the end of
> the build:> 
> [ 85%] Building CXX object gr-
> uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o> 
> /home/pswiatki/devel/gr/default/src/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx: In function 'PyObject*
> _wrap_time_spec_t_get_system_time(PyObject*, PyObject*)':> 
> /home/pswiatki/devel/gr/default/src/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx:19850:34: error: 'get_system_time' is
> not a member of 'uhd::time_spec_t'>result = 
> uhd::time_spec_t::get_system_time();
>   ^~~
> make[2]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:71: gr-
> uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1> 
> make[1]: *** [CMakeFiles/Makefile2:13301: gr-
> uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2> make: *** [Makefile:163: all] 
> Error 2
> PyBOMBS.Packager.source - ERROR - Build failed. See output above for
> error messages.> PyBOMBS.Packager.source - ERROR - Problem occurred while 
> building
> package gnuradio:> Build failed.
> PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
> Aborting.> 
> I tried building with python3 (3.6) and also with python2 (2.7). It
> fails at exactly the same point.> 
> Interestingly, I read this at
> http://files.ettus.com/manual/classuhd_1_1time__spec__t.html:> 
> static time_spec_t[1] uhd::time_spec_t::get_system_time ( void
>
> )
>
> static> DEPRECATED – Will get removed from UHD in future versions.


> Get the system time in time_spec_t[2] format. Uses the highest
> precision clock available.> So, can it be it actually got removed and there 
> is some
> incompatibility between UHD and GR?> 
> By the way, ByBOMBS pulled these commits from the respective
> repositories:> 
> UHD:
> commit 4844f66dccaa71da102b02bba7b8caf8f84a932c (HEAD -> master,
> origin/master)> Author: Trung N Tran 
> Date:   Wed Mar 14 08:31:33 2018 -0700
> 
> GNU Radio:
> commit 273392bda86688194df03cd1c3eef0819236b3b3 (HEAD -> master,
> origin/master, origin/HEAD)> Author: japm48 
> Date:   Thu Mar 15 14:37:40 2018 +0100
> 
> What am I doing wrong?
> 
> _
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Links:

  1. http://files.ettus.com/manual/classuhd_1_1time__spec__t.html
  2. http://files.ettus.com/manual/classuhd_1_1time__spec__t.html
___
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,
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 > > 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
>>
>>
>>
>
___
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]

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/surajhanchinal/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 
> 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_
> algorithm_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
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC18] Application period ends in two days: Upload proposals!

[Wunsch, Felix (CEL)]

Hi all,


this is just a friendly reminder for all students interested in GSoC 2018 that 
the application period ends in a little more than 48 hours (March 27, 16:00 
UTC)! This is a **hard deadline** and enforced by Google! Don't forget to apply 
and upload your proposals until then through the program website!


Cheers,
Felix
___
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

[Benny Alexandar]

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  
on behalf of suraj hanchinal 
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/surajhanchinal/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 
> 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_algorithm_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

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

Re: [Discuss-gnuradio] Introduction for GSoC18 participation

[Wunsch, Felix (CEL)]

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 this idea fits 
in the tree, and propose reuse of code, which is fantastic. As you mention, the 
clock is ticking and, although this idea is potentially well structured, it 
does not have a mentor assigned yet, and that puts a bit of pressure. Have a 
look at this old mailing-list thread [1], which was somewhat in the same 
position as you. If you have already contacted someone to mentor your project, 
that would be great! But if not, then writing a proposal ASAP would help us 
assess your expectations and probably make easier for any of us to hop on board 
as the 

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

[suraj hanchinal]

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/surajhanchinal/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 
> 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_algorithm_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
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build error at uhd::time_spec_t::get_system_time()

[Piotr Swiatkiewicz]

Well, I came back to GR and app development based on GR after a long break.
This is what I saw at https://wiki.gnuradio.org/index.php/
InstallingGRFromSource:

*Using PyBOMBS*

*We are moving to use PyBOMBS as our installation tool for GNU Radio. This
will take care of dependencies and allow you to easily install out-of-tree
projects. *

So, since I may be installing OOT projects, I figured perhaps PyBOMBS might
be useful and gave it a try. I guess this was the best move.
In the past, I always made sure all the pre-requisites were satisfied, then
manually pulled GR from the repository and build the "good-old" way.
I think I will have to go back to the manual mode as you suggest.

Thanks!


On 25 March 2018 at 14:45, Andi Kita  wrote:

> Why dont you install gr manually? It will install anything you need. I
> never liked building gnuradio from pybombs.
>
> A lot of people dont. But thats your choice.
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] PyBOMBS - TypeError when checking git version

[Piotr Swiatkiewicz]

Tried to set up PyBOMBS with Python 3.6 and got the following error:

[pswiatki@sdr_mobile ~]$ pybombs recipes add-defaults
PyBOMBS - INFO - PyBOMBS Version 2.3.3a0
Traceback (most recent call last):
  File "/usr/bin/pybombs", line 11, in 
load_entry_point('PyBOMBS==2.3.3a0', 'console_scripts', 'pybombs')()
  File "/usr/lib/python3.6/site-packages/pybombs/main.py", line 32, in main
return dispatch() or 0
  File "/usr/lib/python3.6/site-packages/pybombs/commands/base.py", line
194, in dispatch
return get_cmd_dict(cmd_list)[args.command](cmd=args.command,
args=args).run()
  File "/usr/lib/python3.6/site-packages/pybombs/commands/base.py", line
120, in run
return self.subcommands[self.args.sub_command]['run'](self)()
  File "/usr/lib/python3.6/site-packages/pybombs/commands/recipes.py", line
180, in run_add_defaults
if not self.add_recipe_dir(alias, uri):
  File "/usr/lib/python3.6/site-packages/pybombs/commands/recipes.py", line
347, in add_recipe_dir
Fetcher().fetch_url(uri, recipe_cache_top_level, alias, {}) # No args
  File "/usr/lib/python3.6/site-packages/pybombs/fetcher.py", line 73, in
fetch_url
result = fetcher.fetch_url(url, dest, dirname, args)
  File "/usr/lib/python3.6/site-packages/pybombs/fetchers/git.py", line 81,
in fetch_url
git_version = get_git_version()
  File "/usr/lib/python3.6/site-packages/pybombs/fetchers/git.py", line 56,
in get_git_version
subprocess.check_output(['git', '--version'])
  File "/usr/lib/python3.6/re.py", line 182, in search
return _compile(pattern, flags).search(string)
TypeError: cannot use a string pattern on a bytes-like object


so, I added the following in /usr/lib/python3.6/site-
packages/pybombs/fetchers/git.py, in get_git_version():

subprocess.check_output(['git', '--version'])*.decode('ascii')*



*TypeError is gone, but I am not sure if this is all it takes to make
PyBOMBS work properly on Python3.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] build error at uhd::time_spec_t::get_system_time()

[Piotr Swiatkiewicz]

I am trying to build GR with PyBOMBS and apart from problems with the build
system itself (it would not start properly when python3 is used) I get the
following error not far away (85% complete) from the end of the build:

[ 85%] Building CXX object gr-uhd/swig/CMakeFiles/_uhd_sw
ig.dir/uhd_swigPYTHON_wrap.cxx.o
/home/pswiatki/devel/gr/default/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
In function 'PyObject* _wrap_time_spec_t_get_system_time(PyObject*,
PyObject*)':
/home/pswiatki/devel/gr/default/src/gnuradio/build/gr-uhd/
swig/uhd_swigPYTHON_wrap.cxx:19850:34: error: 'get_system_time' is not a
member of 'uhd::time_spec_t'
   result = uhd::time_spec_t::get_system_time();
  ^~~
make[2]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:71:
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:13301:
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all]
Error 2
make: *** [Makefile:163: all] Error 2
PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
messages.
PyBOMBS.Packager.source - ERROR - Problem occurred while building package
gnuradio:
Build failed.
PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
Aborting.

I tried building with python3 (3.6) and also with python2 (2.7). It fails
at exactly the same point.

Interestingly, I read this at
http://files.ettus.com/manual/classuhd_1_1time__spec__t.html:

static time_spec_t

uhd::time_spec_t::get_system_time ( void  ) static

DEPRECATED – Will get removed from UHD in future versions.

Get the system time in time_spec_t
 format. Uses
the highest precision clock available.

So, can it be it actually got removed and there is some incompatibility
between UHD and GR?

By the way, ByBOMBS pulled these commits from the respective repositories:

UHD:
commit 4844f66dccaa71da102b02bba7b8caf8f84a932c (HEAD -> master,
origin/master)
Author: Trung N Tran 
Date:   Wed Mar 14 08:31:33 2018 -0700

GNU Radio:
commit 273392bda86688194df03cd1c3eef0819236b3b3 (HEAD -> master,
origin/master, origin/HEAD)
Author: japm48 
Date:   Thu Mar 15 14:37:40 2018 +0100

What am I doing wrong?
___
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,
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 > > 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
>>>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 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!
>>>
>>>- I would work on the format of the proposal as well to help you
>>>make a better impression and increases your chances of this being 
>>> accepted.
>>>In your timeline, be sure to explicitly say what deliverable can be
>>>expected when. It's good to know when you are going to start working on
>>>something, but it is also important to know when you are expected to have
>>>it finished. Words like "Milestone" or even "Deliverable" might make this
>>>clear, maybe around the evaluation dates.
>>>
>>>- I see that you included your CV, which is nice to have, but do you
>>>_really_ want your personal data (like phone and address) out in the 
>>> open?
>>>
>>>
>>> I might come back with more comments, but for now this is looking
>>> promising!
>>>
>>> Cheers,
>>> - Nicolas
>>>
>>>
>>> On Fri, Mar 16, 2018 at 3:57 AM, swapnil negi 
>>> wrote:
>>>
 Hello everyone, I am Swapnil Negi, an undergraduate from Indian
 Institute of Technology Roorkee, India. I wish to contribute to the project
 idea "gr-modtool overhaul". Here
 
 is the draft of my proposal. Kindly review it and give your valuable
 suggestins.
 This is something that I expected from the discussion. If there's
 something that I am missing out, please do inform me.
 Thanks!

 Regards, Swapnil Negi

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

[Sakshi Agrawal]

 Greetings,

I want to refine my implementation to a particular project. I'm
specifically interested in Adding support for new filter design concept
(cascade filter). I've included a sample code which depicts the overall
idea. I need a feedback on what else should I include to make my proposal
more clear and goal oriented?

Pointer to my proposal:
https://github.com/sakshi18agrawal1/documents/blob/master/Sakshi_GSoC2018.pdf


Regards,
Sakshi Agrawal

On Sat, Mar 24, 2018 at 8:39 PM, Sakshi Agrawal 
wrote:

>
> Hello Everyone,
>
> I have made the above changes in my proposal[0]. Please have a look at it
> and suggest furthur changes.
>
> [0]https://github.com/sakshi18agrawal1/documents/
> blob/master/Sakshi_GSoC2018.pdf
>
> Regards,
> Sakshi agrawal
>
> On Sat, Mar 24, 2018 at 8:37 PM, Sakshi Agrawal <
> sakshi18agraw...@gmail.com> wrote:
>
>> Hello Everyone,
>>
>> I have made the above changes in my proposal[0]. Please have a look at it
>> and suggest furthur changes.
>>
>> Regards,
>> Sakshi agrawal
>>
>
>
___
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 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 
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_
> algorithm_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, France
>
___
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

[jmfriedt]

> 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_algorithm_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, France

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