[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] [GSOC 2018] Ideas please!
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] [GSOC 2018] Ideas please! |
Date: |
Sat, 14 Oct 2017 18:08:35 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
Marcus,
these are great suggestions! As far as the packaging task goes, it's
important that we keep it within well defined *coding* tasks. For
example, GSoC clearly states that documentation changes are not for
GSoC. Scripting/maintenance falls into a grey zone, gr_modtool updates
are OK.
Cheers,
Martin
On 10/14/2017 03:21 AM, Marcus Müller wrote:
> Hi Felix!
>
>
> to get this started:
>
> I've got some ideas that I'd be willing to mentor (not all of them at
> once, and for some I'd like to have a "peer" mentor, or at least input
> from someone who's done that kind of software engineering before). I
> don't think this list is even exhaustive, but these are the things that
> popped into my mind quickest, so I guess that speaks for them:
>
> * Radar implementations
> o MIMO Radar: 1-by-2, 2-by-2 radar? Or a generalized approach? I'm
> sure there's a wealth of existing implementations out there, but
> we have no "well demonstratable, halfway clean" impl
> o passive radar using e.g. DVB-T2 or -S2 as signal donor (we
> happen to have demod/mod for that already, anything else would
> fly, too)?
> That with a distributed approach (i.e. two independent observers
> extracting/regenerating the "clean" direct path from the RX,
> then crosscorrelating the RX with that to get a PDP, then
> combine the two PDPs to find objects on the ℝ²)
> * Make Ctrlport good (again):
> o We've all been having quite some trouble with the unstable mess
> Thrift has turned out to be, and with ZeroMQ in-tree and
> low-hanging fruit RPC alternatives (ZeroRPC, which is Msgpack
> over ZMQ, for example), and the original idea that the RPC
> transport beneath Ctrlport should be switchable, I'd like to see
> someone actually implement an RPC transport mechanism that
> allows us to get rid of the Thrift dependency
> I'm also very open to having someone do e.g. a REST kind of RPC
> API, but I do think we need a low-overhead RPC mechanism, so
> this is kind of a thing I'd rather see "nearly comes for free
> after ZeroRPC works" with a ZWS (ZMQ over websocket transport)
> impl (we already have python-based XMLRPC, and it works for slow
> things that are variables or function calls in the GRC-generated
> Python file)
> * Packaging: While that does sound like a core dev team/maintainer's
> job, packaging is important, and there's a lot of interesting
> footwork to be done that's less of a coordinating and more of a
> read-the-docs/implementation thingie:
> o Write scripts (CMake, bash, Python?) and add them to the
> gr-modtool template that
> + automatically generate a good-style Deb, RPM, Arch Pkg,
> Whatever-the-brew-we-use on OS X, maybe even an MSI that
> works with Geoff's Windows port/ /
> + a minimal script/git branch you can merge/diff to add that
> functionality to existing modules
> + a script to upload the resulting package (source packages)
> to the respective build services of major Distros (that
> being COPR, Launchpad, build.opensuse.org…)
> + maybe even: CGRAN gets an interface that checks whether a
> OOT module has native packages, and on which platforms these
> build correctly according to above build services
> o Make GNU Radio main tree packaging good (again) for people who
> aren't on debian(oids): adopt Maitland's great "gnuradio is a
> package depending on libgnuradio-runtime, libgnuradio-fft,
> libgnuradio-audio, libgnuradio-uhd…" for all distros
> + Entails writing RPM specs, arch pkg, and
> the-rest-of-what's-realistic-from-above
> + benefit: People can install gnuradio-runtime, and exactly
> these in-tree modules they need. No need to install UHD and
> QT5 on a raspberry pi that doesn't have a USRP nor a screen
> + From there on, kind of a maintainer's job to keep in touch
> with the distro maintainers to push out the results, XOR
> + keep things on our own repos (not that hard with above build
> services) and have our own package trees that explicitly
> conflict with stock distro packages (not good in the FOSS
> community sense, but will work out for users if we also
> build the application packages the distros package (mainly:
> GQRX, I guess, maybe gr-airmodes))
> * GUI Integration: Looks like we're sticking with Qt5 – so, let's have
> an easy way to integrate into Qt5 GUI.
> o Idea: Wrap the Qt GUI sinks to appear in QtCreator, including
> the GUI aspects of their parameterization
> + Export of GUI yields UIC (XML file describing the form)
> + Load that UIC in the "Options" Block in GRC
> + GRC shows dialog to map existing QT Sinks in Flow graph to
> GUI elements from UIC
> # Possibly even visually! You can load the UIC and
> preview, then hook up double click signal slots.
> + Generates python that loads UIC, places the sink widgets
> where they belong
>
> Cheers,
>
> Marcus
>
> On 14.10.2017 10:42, Wunsch, Felix (CEL) wrote:
>>
>> Hi all,
>>
>>
>> even though GSoC 2017 has ended not too long ago, we already need to
>> start the preparations for next year!
>>
>>
>> After 5 years of being org admin, Martin has asked for somebody else
>> to take over that task and I'm happy to volunteer for this. Having
>> profited from the GSoC experience myself, this is a great way for me
>> to give back some of the support I received back then.
>>
>>
>> And at this point, we need your support! Do you have a project in mind
>> that could be realized by a student in about 3 months of coding and/or
>> want to mentor? Let's discuss your ideas here on the list and then add
>> them to the wiki so we have a nice range of fleshed-out projects when
>> the org application period starts on January 4. If you are interested
>> but need some inspiration, have a look at the current ideas list and
>> past GSoC projects!
>>
>>
>> Current list: https://wiki.gnuradio.org/index.php/GSoCIdeas
>>
>> Old projects: https://wiki.gnuradio.org/index.php/GSoCPastProjects
>>
>>
>> Cheers,
>> Felix
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
Re: [Discuss-gnuradio] [GSOC 2018] Ideas please!, Benny Alexandar, 2017/10/16