GSoCIdeas

Note- also check out Grant Ideas for additional ideas that are more suited towards grant money than GSoC.

Summer of Code 2023: Project ideas list

This is the list of project ideas for the summer of code 2023 within GNU Radio.
Remember that these are ideas and are merely meant as an inspiration for you to write your own proposal.

Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The GNU Radio discussion mailing list is the best place to contact all of us. Please do not contact us off-list for the sake of discussing the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.

Reviewing the Google GSoC FAQ page for a broader understanding of project, mentor, and student responsibilities is recommended.

If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.

Please add ideas to this list (you may cannibalize old ideas, of course!).

Guidelines for good projects (when suggesting projects, please consider these):

• Clearly defined scope, with a main target that can be done in 3 months
• Clear benefits for the GNU Radio project
• Not specific to a certain hardware. No specific embedded devices, either, please.
• Both OOTs and in-tree improvements are welcome

QT Widgets Improvements

The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.
This project is cleanly divided into several sub-projects:

• Add a new widget
  • Compass display (e.g. for direction-finding applications)
  • MPEG display (e.g. for video demod output)
  • Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)

• Improve current widgets
  • Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets
  • More Control Panels on other widgets (follow lead on the frequency sink)
  • Improve UI, make more intuitive, more power to mouse users
  • Set trigger point with mouse

• Integration / Support for QT Creator
  • QML design
  • Allow to build full GUI applications from, say, GRC

Prerequisites

• Familiarity with QT is essential.
• Widgets are written in C++, so some C++ knowledge is also required.
• Python skills are highly useful.

Project length

350 hours

Difficulty

Hard

Mentor(s)

Andrej Rode

GPU Accelerated Signal Processing Blocks

GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see FOSDEM 2022 Presentation.

One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:

• Matx
• cuSignal (Python signal processing)
• CUSP

Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using gr-cuda custom buffers, and expanding this module as needed

This project can be broken into several subprojects:

• Create gr-matx OOT
  • Add Matx Custom Buffer Type (after gr-cuda)
  • Create blocks wrapping Matx operations
• Expand gr-cuda
  • Additional custom buffer types - pinned, unified
  • Create python custom buffers allowing zero copy into python blocks
• Create gr-cuSignal
  • Wrap cuSignal functionality (dependent on python zero copy)
• Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)
  • Target for extensions to Matx, cuSignal, or CUSP (within our control)
  • FIR Filters
  • Polyphase Resampler
  • Signal Source
  • Moving Average
  • Polyphase Clock Sync
  • Stream Operators
  • ...

Prerequisites

• Knowledge of C++ and Python.
• Familiarity with CUDA programming

Project length

350 hours

Difficulty

Medium

Mentor(s)

Josh Morman

GRC: Standalone application and pluggable workflows

GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see GREP 0025. In its most basic form, GRC does the following:

• User sets high level options (type of flowgraph)
• User draws flowgraph graphically with blocks and connections
• Flowgraph uses templates (Mako) to render to a python script

The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:

• Python QT GUI
• C++ QT GUI
• Python No GUI
• C++ No GUI
• Bokeh GUI

The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.

Steps

• Move GRC as a separate repository (while maintaining git history)
• Remove dependence of GRC on gnuradio
• Modularized options block
• Modularized templates
• Allow templating with jinja as well
• If time allows:
  • Modularize gr-modtool templates as well per GREP 0026
  • Support multiple domains' workflows.

Prerequisites

• Knowledge of Python.

Project length

350 hours

Difficulty

Medium

Mentor(s)

Josh Morman, Håkon Vågsether, Sebastian Koslowski, ?? Someone else that is a GRC Wizard

GRC: Build-in sub flowgraphs

GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly.

Prerequisites

• GRC is written in Python which is (almost) all you need to know for this project.

Outcome

• A vastly improved workflow for structuring flowgraphs

Project length

175 hours

Difficulty

Easy

Mentor(s)

Håkon Vågsether

Revitalize old modules

Some of the in-tree modules are in need of attention. For example, gr-wavelet does not have any examples, and several of the tests in gr-trellis are failing.

Prerequisites

• Knowledge of C++, Python and DSP.

Outcome

• More example code, tests and flowgraphs for various in-tree modules

Project length

175 hours

Difficulty

Easy

Mentor(s)

Håkon Vågsether, ?

CI for maintenance branches and select OOT modules

It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs.

Prerequisites

• Experience with Docker?
• ?

Outcome

• Automated PPAs, Snaps, Flatpak apps

Project length

175 hours

Difficulty

Easy

Mentor(s)

Håkon Vågsether, ?

Old Ideas

Feel free to browse old ideas from previous years for inspiration.