discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]