GSoCIdeas: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
(Add additional context for CyberEther track.)
 
(64 intermediate revisions by 15 users not shown)
Line 1: Line 1:
= Summer of Code 2018: Project idea list =
Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.


This is the list of project ideas for the summer of code 2018 within GNU Radio.<br />
 
== Summer of Code 2024: Project ideas list ==
 
This is the list of project ideas for the summer of code 2024 within GNU Radio.<br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.
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 [http://gnuradio.org/redmine/projects/gnuradio/wiki/MailingLists 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.
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.
Line 19: Line 22:
* Both OOTs and in-tree improvements are welcome
* Both OOTs and in-tree improvements are welcome


==== Block header parsing tool ====


Rough ideas:
* Python-based tool
* Can extract info from block headers (and maybe, if it has to, also from the .cc file)
** Analyse factory signature ("make function"), analyze getters/setters
** Analyse I/O signature


Utilities:
=== Graphical interoperability between CyberEther and GNU Radio ===
* Auto-generate YAML files for GRC (would require another tool, also part of this project)
 
* Facilitate inclusion of GNU Radio with other tools/frameworks
The [https://github.com/luigifcruz/CyberEther CyberEther] project comes with some neat graphical sinks that would be great to have access to in GNU Radio. This project entails creating a new CyberEther GUI workflow much like the [https://github.com/gnuradio/gr-bokehgui gr-bokehgui] project, such that users can create flowgraphs with CyberEther sinks. This would allow the user to visualize GNU Radio data streams in one of the high-performance CyberEther plots (lineplot, waterfall, spectrogram, etc).
 
'''Prerequisites'''
 
* Knowledge of C++ and some Python
* Familiarity with graphical APIs (OpenGL, Vulkan, Metal)
* Basic Qt understanding
 
'''Outcome'''
 
* OOT module with CyberEther sinks
* Support for both GNU Radio main branch and 3.10?
 
'''Project length'''
 
Long (350 hours)
 
'''Difficulty'''
 
Medium
 
'''Mentor(s)'''
 
Luigi Cruz, Håkon Vågsether
 
=== GPU Accelerated Signal Processing Blocks ===


There is some code in gr_modtool which does this, which can be reused and
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 [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].
extended.


===== Prerequisites =====
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:


* Strong knowledge of Python, including Py3k idiosyncrasies
* [https://github.com/NVIDIA/MatX Matx]
* Some text parsing experience
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)
* Some understanding of GNU Radio block structure
* [https://github.com/gnuradio/cusp CUSP]


===== Outcome =====
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed


* A tool, written in Python, merged into the GNU Radio source tree, which can
This project can be broken into several subprojects:
  turn a block definition into some kind of abstract representation (the design
  which of is also part of this project)
* Another tool, which takes the abstract representation, and produces YAML
  files for GRC.
* An API into calling this which can be used by other tools (external to GNU
  Radio).
* Make gr_modtool use this tool instead of its builtin code.


===== Mentor(s) =====
* 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
** ...


Martin Braun
'''Prerequisites'''


==== gr-modtool overhaul ====
* Knowledge of C++ and Python.
* Familiarity with CUDA programming


gr-modtool is one of the most important tools within GNU Radio, as it makes the creation of community modules much more accessible. However, it is in dire need of an overhaul, as its early codebase even predates the 3.7 API change. In its current state, gr-modtool is a fairly static chunk of code: The 'add' functionality in particular is a long string of if-then-else style static rules, which are then procedurally executed into a string of templates or file operations. A more functional style, with a less static rule set, would do the wonders to that good old tool.


Rewriting modtool in its entirety is task that is most likely way to large for a single GSoC. However, there's a lot of subtasks, so this can be broken up. When applying to this task, students should indicate which part of modtool they would like to work on. Even so, it is unlikely that more then one student will be able to work on this without too much destructive interference.
'''Outcome'''


The following items can be improved for modtool, in order of priority:
Depends on chosen subprojects (see above).


* Rewrite as a plugin architecture. Currently, only GNU Radio OOTs and in-tree components can be extended. There's no reason modtool can't work for VOLK and RFNoC (thereby obsoleting rfnocmodtool).
'''Project length'''
* Find and eliminate pockets of non-Py3k compatibility.
* Python API. modtool is currently only usable as a command-line program.
* An actual UI to improve usability.


===== Prerequisites =====
350 hours


Creating a better modtool requires strong knowledge of Python, including Py3k idiosyncrasies, functional design principles, template generation. Also, this task requires some knowledge of the existing modtool.
'''Difficulty'''


===== Outcome =====
Medium


The outcome depends on the subtasks selected by the student, but in an ideal case, the plugin architecture would be in place and would allow other projects to implement their own plugins. Documentation for this project would also be highly valuable.
'''Mentor(s)'''


===== Mentor(s) =====
Josh Morman


Martin Braun
=== GRC and GR 4.0 ===


==== GRC: View-Only Mode (Secure) ====
Development of GR 4.0 is progressing quickly. In the current runtime prototype a plugin architecture is used to properly register blocks with the runtime.
This allows a more dynamic construction of flowgraphs and introspection into the blocks. But this means the current way of assembling a flowgraph by generating a Python or C++
file needs updates.


When a flowgraph from an untrusted source is opened if GRC, arbitrary Python code can be executed. This poses a potential security risk. Storing the all evaluated values of all parameters within a flow graph (.grc) file would allow us to open such flow graphs without compromising security. No code would be have to executed to draw the flow graph and block parameters can be viewed safely. Only if the flow graph is modified the user would have to choose to trust the flow graph thus enabling normal eval operations.
The idea is to port and change necessary parts of GRC (Qt development version) to use the block registry in the new GNU Radio runtime https://github.com/fair-acc/graph-prototype/ and assemble some of the example flowgraphs defined in GRC files and make them run.  
The design for this is not finalized and therefore you will have freedom to propose your ideas.


===== Prerequisites =====
'''Prerequisites'''


GRC is implemented using Python. So, Python should be known pretty well.
* Good Knowledge of C++ and Python
* Experience with inter-language bindings (not necessarily C++ & Python) is useful
* Basic Qt understanding


===== Outcome =====
'''Outcome'''


Safely view other people's flowgraphs without putting your PC at risk.
* Prototype integration of GRC with the new plugin architecture of GR 4.0


===== Mentor(s) =====
'''Project length'''


Sebastian Koslowski
Long (350 hours)


==== DTV User Front-End ====
'''Difficulty'''


GNU Radio includes gr-dtv, which allows the decoding of ATSC TV signals and various other Digital Video Broadcast standards. From a DSP/decoding perspective, it's an impressive GNU Radio module. The issue is that it lacks any sort of user front-end and is difficult to use.
Challenging


A well-designed UI for gr-dtv would be a great addition to GNU Radio. It would nicely demonstrate how GNU Radio can be used to create real-world applications. It could also include the following features:
'''Mentor(s)'''


* Automatic selection of frequencies based on location
Andrej Rode, Josh Morman
* Integration with web services, such as TV program indicators
* Load IQ files
* Record-to-file


===== Prerequisites =====
=== GRC: Standalone application and pluggable workflows ===


Since gr-dtv already includes the bulk of the DSP/decoding part, this would be primarily GUI development. The programming language may be chosen by the student, although Python is probably the most viable candidate. Experience in GUI development is a strong requirement, though.
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 [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025].  In its most basic form, GRC does the following:


===== Outcome =====
* 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 result of this project should be a simple, click-to-launch app that immediately allows watching DTV, assuming the availability of some SDR hardware. The fact that a GNU Radio flowgraph is running in the background should be nicely hidden away.
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:


===== Mentor(s) =====
* Python QT GUI
* C++ QT GUI
* Python No GUI
* C++ No GUI
* Bokeh GUI


Johnathan Corgan
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.


==== Extending and Updating gr-radar ====
'''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 [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]
** Support multiple domains' workflows.


gr-radar (https://github.com/kit-cel/gr-radar/) was a great and successful GSoC project that provided a few methods of radar in GNU Radio. This module is heavily used by academics, researchers, cybersecurity folks, and hobbyists. This project would work to improve upon the concepts already in there as well as add more radar techniques.
'''Prerequisites'''


There are uncountable methods and techniques that could be added to this project, such as:
* Knowledge of Python.


* SAR / InSAR methods
'''Outcome'''
* Better passive radar support
* Speed camera applications
* Multi-antenna radar techniques


===== Prerequisites =====
* GRC as a GNU Radio-independent application
* Support for additional workflows in GRC
* Depends on chosen subprojects (see above).


Signal processing and some radar basics are required. Code is written in C++ with some Python on the side, so the student must be able to handle these languages at the least.
'''Project length'''


===== Outcome =====
350 hours


Based on the student's interest, a subset of the radar techniques listed above (or others) are chosen as milestones for this project. All code must be merged back into gr-radar by the end of the summer.
'''Difficulty'''


===== Mentor(s) =====
Medium


Stefan Wunsch, Martin Braun
'''Mentor(s)'''


==== GNU Radio Companion Extensions: Output C++ Code ====
Josh Morman,
Håkon Vågsether,
Sebastian Koslowski,
?? Someone else that is a GRC Wizard


GRC currently only outputs Python code, which is convenient for a number of reasons of usability and dynamic development. Some people prefer to work in, build, and release compiled binaries. Our Android work in GNU Radio requires C+''-based flowgraphs compiled into a static library. Being able to tell GRC to output a C''+ project with the actual .cc/.cpp code and the Makefile structure to build both dynamic linked and static linked apps would be a great addition to GNU Radio in general.
=== GRC: Build-in sub flowgraphs ===


===== Prerequisites =====
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. 


The generated code is C++, and GRC uses Python for the generation, so these two languages should be known to a decent level. Basic understanding of how GNU Radio and GRC is also required, but may be obtained in the ramp-up phase.
'''Prerequisites'''


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


Add a feature to GRC that will allow to select the output language. Port some blocks to include XML bindings for C++ and use those to test generation of buildable source packages and binaries.
'''Outcome'''


===== Mentor(s) =====
* A vastly improved workflow for structuring flowgraphs


Sebastian Koslowski, Felix Wunsch
'''Project length'''


==== QT Widgets Improvements ====
175 hours


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


* Add new widgets
Easy
** 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
'''Mentor(s)'''
** 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
Håkon Vågsether
** 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.
=== Revitalize in-tree and out-of-tree (OOT) modules ===


===== Mentor(s) =====
A lot has changed since version 3.7, and GNU Radio has made great technical strides the last few years. However, some OOT modules haven't been updated to support the latest versions of GNU Radio, and these modules currently require the user to install an older version of the framework. This is unfortunate, and lowers the useability of GNU Radio as a whole. Some of these modules have been superseded by others, but might still have some blocks or flowgraphs that are useful, and these could be updated and moved in-tree. Some in-tree modules are also in need of attention, like gr-wavelet, which does not have any examples.


Tim O'Shea
'''Prerequisites'''


==== Android ====
* Knowledge of C++, Python and DSP.


One effort of the past years was to improve Android support for GNU Radio. We're getting to a point where we've figured out '''how''' to do it, so the next step is to make it more accessible to users and developers.
'''Outcome'''


The Android ecosystem is an entirely different beast from the rest of GNU Radio. To make writing Android/GR apps easy, the following needs to happen (and shall be part of this project):
* More example code, tests and flowgraphs for various in-tree modules
* Porting various OOT modules to support recent versions of GNU Radio
* Possibly blocks/flowgraphs from old OOT modules moved in-tree


* Improve support for development environment
'''Project length'''
** Create Dockers for easy start of development
* Visualization classes for PSD, spectrogram and oscilloscope
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs
* Interactivity concepts
** Gestures and config for radio params (e.g., freq, gain, bandwidth)
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures


===== Prerequisites =====
Small (90 hours) - Medium (175 hours)


* Some Android experience
'''Difficulty'''
* Enjoy writing GUI widgets
* C++/Java experience


===== Mentor(s) =====
Easy - Medium


Ben Hilburn
'''Mentor(s)'''


==== Filter Design Tool Enhancements ====
Håkon Vågsether, ?


GNU Radio provides many tools to design and use digital filters. Using these tools requires both some expertise in these areas as well as an understanding of the performance on the given platform. One example is the selection between FIR (convolution-based) and FFT (fast convolution-based) filters for different resampling rates. Another example is doing stages of filter decomposition when doing large down-sampling. Included in this is the polyphase filterbanks, which again are provided as primitive blocks that need tweaking to work.
=== Forward Error Correction in GNU Radio ===


This project is to improve our uses of these tools and blocks to make it more obvious to the users as well as automate some of the decisions for optimally using them. Some pointers:
Over the years many different forward error correction (FEC) methods ( e.g. Polar Encoder/Decoder, LDPC Encoder/Decoder) have been added to GNU Radio.
In other open-source projects (e.g. Aff3ct,  more modern methods and possibly more performant methods have been implemented.


* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.
The goal of this project is to update and possibly overhaul the FEC implementations within GNU Radio. Since there are quite some methods in the wild,  
* It still currently runs on PyQWT, which is obsolete and needs to be updated to QT4/QT5
we need to coordinate on which methods and other libraries should be included in the comparison. Same goes for the already available methods for error coding in GNU Radio.
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui
* Add more support for filter design concepts and other filters.
** Cascaded filters
** Better support for creating PFB filters


===== Prerequisites =====
'''Prerequisites'''


Strong DSP background required. Python and QT knowledge highly useful (at least one of those is a must).
* Knowledge of C++, Python and DSP.
* Interest in information theory and error coding
* No fear of reading & comparing other implementations


===== Mentor(s) =====
'''Outcome'''


Sebastian Müller, Marcus Leech
* Updated & polished FEC experience in GNU Radio
* Addition of more performant and updated methods for error coding
* Deletion of possibly redundant and inperformant methods


==== Implement SigMF functionality for GNU Radio ====
'''Project length'''


SigMF is the "Signal Metadata Format" that was defined during the 2017 DARPA Hackfest in Brussels. Its purpose is to annotate raw binary dumps of signals with metadata, thus giving meaning to a raw mass of samples.<br />
Medium (175 hours) - Long (350 hours)
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf


GNU Radio needs its own implementation of SigMF that ties into the block structure. The following things need to be written:
'''Difficulty'''


* Source and Sink blocks for SigMF (similar to the current metadata blocks)
Medium - Hard
* Converters for files generated with the current metadata file formats
* Static analysis tools using SigMF


===== Prerequisites =====
'''Mentor(s)'''


Basic understanding of how to write GNU Radio blocks is required. Also, the student needs to explain that she or he has understood the concepts of SigMF, although SigMF is a very simple, JSON-based file format.<br />
Andrej Rode, ?
Depending on the precise path that the student and the mentor define, experience in GUI development would also be useful.


===== Outcome =====
=== CI for maintenance branches and select OOT modules ===


The source and sink blocks are by the far the most important outcomes of this project. We estimate it would take about a third of the active coding time to implement those, and have them merged around the midterms.<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs.  
This leaves plenty of time for further development. The next most important task are the converters, so existing metadata files will continue to be useful. After that, the student should define own tasks based on their interests. A very relevant problem is the ability to effectively visualize metadata in combination with signals.


===== Mentor(s) =====
'''Prerequisites'''


Bastian Bloessl, Sebastian Müller
* Experience with Docker?
* ?


==== Statistical Toolbox for GRC ====
'''Outcome'''


A statistical toolbox for GRC would enable GUI-based statistical analysis. Currently, such analysis can be done by writing an independent program (e.g., with Scipy), but there is no actual integration with GNU Radio. By developing the statistical toolbox, we provide blocks for probability distribution fitting, hypothesis testing, extracting statistical parameters for one-dimensional as well as multi-dimensional data. This would significantly expand GNU Radio users' ability to perform datascience analysis and modeling on signal data.
* Automated PPAs, Snaps, Flatpak apps


===== Prerequisites =====
'''Project length'''


Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / datascience modeling.
175 hours


===== Outcome =====
'''Difficulty'''


An OOT module that provides statistical analysis capabilities for GNU Radio.
Easy


===== Mentor =====
'''Mentor(s)'''


Ben Hilburn
Håkon Vågsether, ?


=== Application process ===
== Old Ideas ==


* Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.
* To apply, please introduce yourself on both the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]
* Fill in the formal application for GNU Radio
* Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.

Latest revision as of 16:36, 23 February 2024

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


Summer of Code 2024: Project ideas list

This is the list of project ideas for the summer of code 2024 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


Graphical interoperability between CyberEther and GNU Radio

The CyberEther project comes with some neat graphical sinks that would be great to have access to in GNU Radio. This project entails creating a new CyberEther GUI workflow much like the gr-bokehgui project, such that users can create flowgraphs with CyberEther sinks. This would allow the user to visualize GNU Radio data streams in one of the high-performance CyberEther plots (lineplot, waterfall, spectrogram, etc).

Prerequisites

  • Knowledge of C++ and some Python
  • Familiarity with graphical APIs (OpenGL, Vulkan, Metal)
  • Basic Qt understanding

Outcome

  • OOT module with CyberEther sinks
  • Support for both GNU Radio main branch and 3.10?

Project length

Long (350 hours)

Difficulty

Medium

Mentor(s)

Luigi Cruz, Håkon Vågsether

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:

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


Outcome

Depends on chosen subprojects (see above).

Project length

350 hours

Difficulty

Medium

Mentor(s)

Josh Morman

GRC and GR 4.0

Development of GR 4.0 is progressing quickly. In the current runtime prototype a plugin architecture is used to properly register blocks with the runtime. This allows a more dynamic construction of flowgraphs and introspection into the blocks. But this means the current way of assembling a flowgraph by generating a Python or C++ file needs updates.

The idea is to port and change necessary parts of GRC (Qt development version) to use the block registry in the new GNU Radio runtime https://github.com/fair-acc/graph-prototype/ and assemble some of the example flowgraphs defined in GRC files and make them run. The design for this is not finalized and therefore you will have freedom to propose your ideas.

Prerequisites

  • Good Knowledge of C++ and Python
  • Experience with inter-language bindings (not necessarily C++ & Python) is useful
  • Basic Qt understanding

Outcome

  • Prototype integration of GRC with the new plugin architecture of GR 4.0

Project length

Long (350 hours)

Difficulty

Challenging

Mentor(s)

Andrej Rode, 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.

Outcome

  • GRC as a GNU Radio-independent application
  • Support for additional workflows in GRC
  • Depends on chosen subprojects (see above).

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 in-tree and out-of-tree (OOT) modules

A lot has changed since version 3.7, and GNU Radio has made great technical strides the last few years. However, some OOT modules haven't been updated to support the latest versions of GNU Radio, and these modules currently require the user to install an older version of the framework. This is unfortunate, and lowers the useability of GNU Radio as a whole. Some of these modules have been superseded by others, but might still have some blocks or flowgraphs that are useful, and these could be updated and moved in-tree. Some in-tree modules are also in need of attention, like gr-wavelet, which does not have any examples.

Prerequisites

  • Knowledge of C++, Python and DSP.

Outcome

  • More example code, tests and flowgraphs for various in-tree modules
  • Porting various OOT modules to support recent versions of GNU Radio
  • Possibly blocks/flowgraphs from old OOT modules moved in-tree

Project length

Small (90 hours) - Medium (175 hours)

Difficulty

Easy - Medium

Mentor(s)

Håkon Vågsether, ?

Forward Error Correction in GNU Radio

Over the years many different forward error correction (FEC) methods ( e.g. Polar Encoder/Decoder, LDPC Encoder/Decoder) have been added to GNU Radio. In other open-source projects (e.g. Aff3ct, more modern methods and possibly more performant methods have been implemented.

The goal of this project is to update and possibly overhaul the FEC implementations within GNU Radio. Since there are quite some methods in the wild, we need to coordinate on which methods and other libraries should be included in the comparison. Same goes for the already available methods for error coding in GNU Radio.

Prerequisites

  • Knowledge of C++, Python and DSP.
  • Interest in information theory and error coding
  • No fear of reading & comparing other implementations

Outcome

  • Updated & polished FEC experience in GNU Radio
  • Addition of more performant and updated methods for error coding
  • Deletion of possibly redundant and inperformant methods

Project length

Medium (175 hours) - Long (350 hours)

Difficulty

Medium - Hard

Mentor(s)

Andrej Rode, ?

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.

Retrieved from "https://wiki.gnuradio.org/index.php?title=GSoCIdeas&oldid=13780"