[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] [GSOC 2018] Ideas please!
From: |
Marcus Müller |
Subject: |
[Discuss-gnuradio] [GSOC 2018] Ideas please! |
Date: |
Sat, 14 Oct 2017 12:21:22 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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
Re: [Discuss-gnuradio] [GSOC 2018] Ideas please!, Benny Alexandar, 2017/10/16