GSoCIdeas: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
(Add another 2025 project - easy and small-medium)
 
(22 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.
Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.


== Summer of Code 2022: Project ideas list ==


This is the list of project ideas for the summer of code 2022 within GNU Radio.<br />
== Summer of Code 2025: Project ideas list ==
 
This is the list of project ideas for the summer of code 2025 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.


Line 21: Line 22:
* Both OOTs and in-tree improvements are welcome
* Both OOTs and in-tree improvements are welcome


=== QT Widgets Improvements ===
=== FM Broadcast Radio application ===
 
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br />
This project is cleanly divided into several sub-projects:


* Add a new widget
GNU Radio has built-in capabilities to receive, decode and play FM broadcast radio stations. With additional projects https://github.com/bastibl/gr-rds we are able to decode RDS data alongside.
** Compass display (e.g. for direction-finding applications)
The project does not (yet) have a fully fledged demo application which would allow potential users and beginners to see how to build a production-grade application (almost). The goal for this project
** MPEG display (e.g. for video demod output)
is to build an application which works plug&play with many SDRs and automatically scans (all) potential FM broadcast frequencies, gives a channel list and allows users to tune/select a radio station they would like to listen to.
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)


* Improve current widgets
Therefore one part of the project is to focus on a polished user experience in the frontend application. Since this should be a good demo the other part of the project should focus on developing a well-functioning flowgraph with
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets
the existing signal processing blocks and potentially also porting gr-rds to a newer GNU Radio and/or integrating it in the GNU Radio source tree. This flowgraph should then be started/halted on demand of the frontend application.
** More Control Panels on other widgets (follow lead on the frequency sink)
Potentially multiple streams could be recorded at the same time or decoded and some of the signal processing signals can be shown in a debug view so potential beginners and users can perform introspection on the application.
** 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'''
'''Prerequisites'''
* Programming skills in Python
* Interest in designing a functional and polished graphical user interface
* Preferred: Familiarity with basic signal processing libraries in Python (e.g., SciPy).
* Interest working with real radio signals


* Familiarity with QT is essential.
'''Expected Outcome'''
* Widgets are written in C++, so some C++ knowledge is also required.
* Fully fledged FM broadcast receiver application with integrated RDS and spectrum scanning
* Python skills are highly useful.
* A clean example application which shows how the signal processing can be combined well with a GUI
 
'''Project length'''
 
350 hours


'''Difficulty'''
'''Project Length'''
* Small (100 hours) – Medium (200 hours)


Hard
'''Difficulty''''
* Easy


'''Mentor(s)'''
'''Mentor(s)'''
* Andrej Rode


Andrej Rode
=== 5G Cell Scanner ===
 
 
=== 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 [https://fosdem.org/2022/schedule/event/radio_gr3_10/ 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:


* [https://github.com/NVIDIA/MatX Matx]
Cell scanning by passively observing the RF environment using an SDR and decoding received signals based on the waveforms defined in the 2G/3G/4G/5G standards is a well-established approach for assessing cellular connectivity in the surrounding environment. While multiple cell scanners are publicly available, they often employ opaque signal processing methods and frequently cease analysis prematurely, failing to provide detailed information about the cells. This includes not decoding the Master Information Block (MIB) and the System Information Block (SIB1) to extract cell properties and signal quality metrics.
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)
Our objective is to develop a high-quality cell scanner using GNU Radio in a transparent way that delivers the most information possible (depending on the cells’ signal levels) in a trustable manner. The general procedure will be based on the initial synchronization and cell identification process on the user-equipment side of 5G (see further reads).
* [https://github.com/gnuradio/cusp CUSP]
Depending on the student’s experience, we can also go a step further and parallelize the cell scanning process by observing multiple frequency bands simultaneously by applying channelization and parallel processing techniques to the signal.
 
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
 
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'''
'''Prerequisites'''
* Proficiency with GNU Radio.
* Basic programming skills in Python.
* Preferred: Familiarity with basic signal processing libraries in Python (e.g., SciPy).
* Preferred: General understanding of the 5G waveform and experience with 5G processing libraries in Python.


* Knowledge of C++ and Python.
'''Expected Outcome'''
* Familiarity with CUDA programming
* Development of an Out-Of-Tree (OOT) module or flowgraphs capable of interacting with SDR input streams and automatically generating detailed visualizations of cell search results.
 
* Capability to export results as a function of time and SDR location to enable the creation of coverage maps.
'''Project length'''


350 hours
'''Further Reads'''
* https://de.mathworks.com/help/5g/ug/nr-cell-search-and-mib-and-sib1-recovery.html
* https://de.mathworks.com/help/5g/gs/synchronization-signal-blocks-and-bursts.html


'''Difficulty'''
'''Project Length'''
* Small (100 hours) – Medium (200 hours)


Medium
'''Difficulty''''
* Medium


'''Mentor(s)'''
'''Mentor(s)'''
* Michael Petry
* Andrej Rode


Josh Morman


=== Expanding the GNU Radio 4.0 Block Set ===


=== Standalone GRC ===
GNU Radio 4.0 has reached a stage where real signal processing applications can achieve performance improvements over GNU Radio 3.x. To maximize its adoption, we aim to expand the set of available blocks, making it easier for the community to build applications with readily available components.  The goal of this project is to migrate existing GR 3.x blocks (e.g. gr-digital, gr-analog, gr-audio ...) into GR 4.0.  A good list of blocks in GR3 that should be ports has been maintained here:  [https://github.com/fair-acc/gnuradio4/issues/161]


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


* User sets high level options (type of flowgraph)
* Knowledge of modern C++
* User draws flowgraph graphically with blocks and connections
* Signal processing understanding
* 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:
'''Outcome'''
 
* 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 [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]


'''Prerequisites'''
* GR4 OOT module with a substantial number of blocks
* Each block should have CI tests and an example flowgraph
* Document the process so that other block developers can be guided


* Knowledge of Python.


'''Project length'''
'''Project length'''


175 hours
Long (350 hours)


'''Difficulty'''
'''Difficulty'''


Easy
Medium


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


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


=== GNU Radio goes Browser: Web Assembly (WASM) port ===


=== Graphical interoperability between CyberEther and GNU Radio ===


[[File:WASM-preview.jpg|thumb|link=https://mobile.twitter.com/marcnewlin/status/1490577402086313984/photo/1|A view of GRC running on WASM-compiled Python]]
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).


The main goal of WebAssembly is to enable high-performance applications on web pages. Originally quite restricted to single-threaded applications, only interacting with the browser's notion of the world through a JavaScript interaction layer, today it has become quite capable, with support for threads, exceptions, SIMD and a lot of other performance-critical features.
'''Prerequisites'''


Obviously, that's great news! GNU Radio in the Browser means zero-installation, fully portable SDR for the masses. This GSoC project strives to take Marc Newlin's current work and make something functional, with the big goal of having a fully functional GNU Radio on WASM.
* Knowledge of C++ and some Python
* Familiarity with graphical APIs (OpenGL, Vulkan, Metal)
* Basic Qt understanding


This project has subprojects, from which the student is to pick '''one''':
'''Outcome'''
 
* porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted set of intrinsics
* working to bring GRC in the feature-grc-qt branch to parity with GRC in main
* WebUSB driver porting (I have prototyped standalone drivers for UHD, HackRF and PlutoSDR which haven't get been integrated, and then porting gr-osmosdr would be awesome).
* creating blocks for ZMQ over websockets


in addition to making a (minimal) web page to which the current development state can be tested on, updated automatically from Github.
* OOT module with CyberEther sinks
 
* Support for both GNU Radio main branch and 3.10?
'''Steps'''
 
* Make (and test!) Marc Newlin's WASM build locally
* Add a CI step to build a WASM binary
* Implement one of the points above
* Implement a suitable demonstration for it and deploy
 
'''Prerequisites'''
 
* Basic knowledge of Python
* Working (especially, reading) knowledge of C++
* Basic knowledge of WASM


'''Project length'''
'''Project length'''


175 hours
Long (350 hours)


'''Difficulty'''
'''Difficulty'''
Line 197: Line 137:
'''Mentor(s)'''
'''Mentor(s)'''


* Marc Newlin
Luigi Cruz, Håkon Vågsether
* Marcus Müller
* Depending on topic: further member of the GNU Radio community


<div class="toccolours mw-collapsible mw-collapsed">
=== GPU Accelerated Signal Processing Blocks ===


== Summer of Code 2021: Project ideas list ==
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].
<div class="mw-collapsible-content">


This is the list of project ideas for the summer of code 2021 within GNU Radio.<br />
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:
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 [[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.
* [https://github.com/NVIDIA/MatX Matx]
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)
* [https://github.com/gnuradio/cusp CUSP]


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


If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.
This project can be broken into several subprojects:


Please add ideas to this list (you may cannibalize old ideas, of course!).
* Create gr-matx OOT
 
** Add Matx Custom Buffer Type (after gr-cuda)
Guidelines for good projects (when suggesting projects, please consider these):
** Create blocks wrapping Matx operations
 
* Expand gr-cuda
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity
** Additional custom buffer types - pinned, unified
* Clear benefits for the GNU Radio project
** Create python custom buffers allowing zero copy into python blocks
* Not specific to a certain hardware. No specific embedded devices, either, please.
* Create gr-cuSignal
* Both OOTs and in-tree improvements are welcome
** Wrap cuSignal functionality (dependent on python zero copy)
 
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)
'''The time a student can spend on a GSoC project has been reduced by 50% for 2021 - keep this in mind when submitting your ideas'''
** Target for extensions to Matx, cuSignal, or CUSP (within our control)
 
** FIR Filters
 
** Polyphase Resampler
=== QT Widgets Improvements ===
** Signal Source
 
** Moving Average
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br />
** Polyphase Clock Sync
This project is cleanly divided into several sub-projects:
** Stream Operators
 
** ...
* 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'''
'''Prerequisites'''


* Familiarity with QT is essential.
* Knowledge of C++ and Python.
* Widgets are written in C++, so some C++ knowledge is also required.
* Familiarity with CUDA programming
* Python skills are highly useful.
 
'''Mentor(s)'''
 
Andrej Rode
 
=== Standardized High Throughput FEC Codes ===
 
Channel coding is essential to modern communications. Also, it is computationally very heavy. As of now, there exist implementations in GNU Radio which are too slow to be integrated into high throughput applications. GNU Radio would benefit from integration of standardized decoders for Turbo and LDPC codes. These codes would only support a certain subset of the whole code class but would be well optimized.
 
'''Prerequisites'''


* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.


'''Outcome'''
'''Outcome'''


* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.
Depends on chosen subprojects (see above).
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.


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


* Johannes Demel
350 hours


'''Difficulty'''


=== GRC: View-Only Mode (Secure) ===
Medium
 
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.
 
'''Prerequisites'''
 
* GRC is implemented using Python. So, Python should be known pretty well.
 
'''Outcome'''
 
* Safely view other people's flowgraphs without putting your PC at risk.


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


* Sebastian Koslowski
Josh Morman, Andrej Rode


=== GRC and GR 4.0 ===


=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===
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.


Even though the 8b10b line coding is primarily used for byte-level synchronization and spectral shaping, it adds some redundancy to the data, so it can be used as a forward error correction method to fix some bit errors in the received data. From the perspective of the decoder there is one bit of hidden state, so 8b10b line coding is amenable to Viterbi decoding, as hinted in [http://www.bigideatrouble.com/AMSAT%202013%20FOX1%20Paper.pdf this document about the AMSAT FOX satellites]. One goal of this project is to create Viterbi decoder block(s) for 8b10b and possibly other similar line codes, so that these blocks can be eventually upstreamed in-tree. The error correction performance of this method will be studied using simulations with these blocks. The second goal is to use the Viterbi decoder and gr-satellites to create a full decoder for the FOX satellites from AMSAT.
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/gnuradio/gnuradio4/ 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'''


* Knowledge of C++ and Python. Some basic understanding about FEC in general.
* Good Knowledge of C++ and Python
* Experience with inter-language bindings (not necessarily C++ & Python) is useful
* Basic Qt understanding


'''Outcome'''
'''Outcome'''


* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites
* Prototype integration of GRC with the new plugin architecture of GR 4.0


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


* Daniel Estévez
Long (350 hours)


'''Difficulty'''


=== Runtime Benchmarks ===
Challenging
 
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput). This data is required to compare alternate approaches and to become aware of performance regressions early in the process.
 
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our server, allowing us to crowdsource data. (Similar to our online stats for SIMD performance.)
 
'''Outcome'''
 
* Come up with interesting metrics and, if needed, implement blocks to extract them.
* Come up with interesting flowgraph topologies that should be benchmarked.
* Set up automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).
* Parse, evaluate, and visualize the data.
* Add an option to upload the performance data to our web server.
 
'''Prerequisites'''
 
* C++ programming
* Data evaluation and visualization
* Automation tools (like GNU Make to run benchmarks)


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


*Bastian Bloessl
Andrej Rode, Josh Morman


<div class="toccolours mw-collapsible mw-collapsed">


== Summer of Code 2020: Project ideas list ==
<div class="mw-collapsible-content">
This is the list of project ideas for the summer of code 2020 within GNU Radio.<br />
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 [[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.
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






=== GRC: Build-in sub flowgraphs ===
=== Revitalize in-tree and out-of-tree (OOT) modules ===


GNU Radio has the hierarchical blocks 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.
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'''
'''Prerequisites'''


* GRC is written in Python which is (almost) all you need to know for this project.
* Knowledge of C++, Python and DSP.


'''Outcome'''
'''Outcome'''


* A vastly improved workflow for structuring flowgraphs
* 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


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


* Sebastian Koslowski
Small (90 hours) - Medium (175 hours)


'''Difficulty'''


 
Easy - Medium
=== Qt5 GUI Integrations ===
 
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization
 
'''Prerequisites'''
 
* C++, Python proficiency
* Qt experienced
 
'''Outcome'''
 
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)
* Possible to import generate Qt GUI description file (UIC) into GRC
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph
* Integration of that into GRC-generated Python code


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


* Marcus Müller & Sebastian "GRC-Man" Koslowski
Andrej Rode, Håkon Vågsether
 
 
 
=== Extending and Updating gr-radar ===


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.


There are uncountable methods and techniques that could be added to this project, such as:
=== CI for maintenance branches and select OOT modules ===


* SAR / InSAR methods
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs.
* Better passive radar support
* Speed camera applications
* Multi-antenna radar techniques


'''Prerequisites'''
'''Prerequisites'''


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


'''Outcome'''
'''Outcome'''


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


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


* Stefan Wunsch, Martin Braun
175 hours


'''Difficulty'''


 
Easy
=== 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.<br />
This project is cleanly divided into several sub-projects:
 
* Add new widgets
** 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.
 
'''Mentor(s)'''
 
Tim O'Shea
 
 
 
 
 
 
=== Android ===
 
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.
 
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):
 
* Improve support for development environment
** 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 parameters (e.g., freq, gain, bandwidth)
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures
 
You can find a summary of the work that has been done on this (years ago) here: [[Android]]
 
'''Prerequisites'''
 
* Some Android experience
* Enjoy writing GUI widgets
* C++/Java experience
 
'''Mentor(s)'''
 
* Bastian Bloessl
 
=== Runtime Benchmarks ===
 
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput).
This data is required to compare alternate approaches and to become aware of performance regressions early in the process.
 
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our sever, allowing us to crowdsource data. (Similar to our [http://stats.gnuradio.org/ online stats] for SIMD performance.)
 
* Come up with interesting metrics and, if needed, implement blocks to extract them.
* Come up with interesting flowgraph topologies that should be benchmarked.
* Setup automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).
* Parse, evaluate, and visualize the data.
* Add an option to upload the performance data to our web sever.
 
'''Prerequisites'''
 
* C++ programming
* Data evaluation and visualization
* Automation tools (like GNU Make to run benchmarks)
 
'''Mentor(s)'''
 
* Bastian Bloessl, Marcus Mueller
 
=== Filter Design Tool Enhancements ===
 
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.
 
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:
 
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.
* It still currently runs on PyQWT, which is obsolete and needs to be updated to Qt5
** 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'''
 
* Strong DSP background required.
* Python and QT knowledge highly useful (at least one of those is a must).
 
'''Mentor(s)'''
 
* Marcus Leech
 
 
 
=== Implement SigMF functionality for the GNU Radio Ecosystem ===
 
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 />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf
There is an out-of-tree module providing SigMF functionality for GNU Radio as well: https://github.com/skysafe/gr-sigmf
 
However, SigMF is not represented well in the GNU Radio tooling landscape. Therefore, a subset of tools can be extended by SigMF support. Incomplete lists of possible tools benefitting from SigMF support:
 
* qgrx (https://github.com/csete/gqrx)
* inspectrum (https://github.com/miek/inspectrum)
* ...
 
Any additional tools are welcome in a proposal.
 
'''Prerequisites'''
 
* Knowledge of the programming language of the covered tools.
* Hands-on experience with the respective tools.
* Familiarity with the SigMF specification.
 
'''Outcome'''
 
* The tools worked on have capability to load and save files in the SigMF format.
* Depending on the specific tool, SigMF meta data is displayed within the tool.
* The number of tools worked on needs to be determined by the student, depending on his/her experience.
 
'''Mentor(s)'''
 
* Sebastian Müller, Andrej Rode
 
 
 
=== Statistical Toolbox for GRC ===
 
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 data-science analysis and modeling on signal data.
 
'''Prerequisites'''
 
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.
 
'''Outcome'''
 
* An OOT module that provides statistical analysis capabilities for GNU Radio.


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


* Ben Hilburn
Håkon Vågsether, ?


</div>
== Old Ideas ==
</div>
== Application process ==


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.
* Please introduce yourself on 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 20:31, 27 February 2025

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


Summer of Code 2025: Project ideas list

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

FM Broadcast Radio application

GNU Radio has built-in capabilities to receive, decode and play FM broadcast radio stations. With additional projects https://github.com/bastibl/gr-rds we are able to decode RDS data alongside. The project does not (yet) have a fully fledged demo application which would allow potential users and beginners to see how to build a production-grade application (almost). The goal for this project is to build an application which works plug&play with many SDRs and automatically scans (all) potential FM broadcast frequencies, gives a channel list and allows users to tune/select a radio station they would like to listen to.

Therefore one part of the project is to focus on a polished user experience in the frontend application. Since this should be a good demo the other part of the project should focus on developing a well-functioning flowgraph with the existing signal processing blocks and potentially also porting gr-rds to a newer GNU Radio and/or integrating it in the GNU Radio source tree. This flowgraph should then be started/halted on demand of the frontend application. Potentially multiple streams could be recorded at the same time or decoded and some of the signal processing signals can be shown in a debug view so potential beginners and users can perform introspection on the application.


Prerequisites

  • Programming skills in Python
  • Interest in designing a functional and polished graphical user interface
  • Preferred: Familiarity with basic signal processing libraries in Python (e.g., SciPy).
  • Interest working with real radio signals

Expected Outcome

  • Fully fledged FM broadcast receiver application with integrated RDS and spectrum scanning
  • A clean example application which shows how the signal processing can be combined well with a GUI

Project Length

  • Small (100 hours) – Medium (200 hours)

Difficulty'

  • Easy

Mentor(s)

  • Andrej Rode

5G Cell Scanner

Cell scanning by passively observing the RF environment using an SDR and decoding received signals based on the waveforms defined in the 2G/3G/4G/5G standards is a well-established approach for assessing cellular connectivity in the surrounding environment. While multiple cell scanners are publicly available, they often employ opaque signal processing methods and frequently cease analysis prematurely, failing to provide detailed information about the cells. This includes not decoding the Master Information Block (MIB) and the System Information Block (SIB1) to extract cell properties and signal quality metrics. Our objective is to develop a high-quality cell scanner using GNU Radio in a transparent way that delivers the most information possible (depending on the cells’ signal levels) in a trustable manner. The general procedure will be based on the initial synchronization and cell identification process on the user-equipment side of 5G (see further reads). Depending on the student’s experience, we can also go a step further and parallelize the cell scanning process by observing multiple frequency bands simultaneously by applying channelization and parallel processing techniques to the signal.

Prerequisites

  • Proficiency with GNU Radio.
  • Basic programming skills in Python.
  • Preferred: Familiarity with basic signal processing libraries in Python (e.g., SciPy).
  • Preferred: General understanding of the 5G waveform and experience with 5G processing libraries in Python.

Expected Outcome

  • Development of an Out-Of-Tree (OOT) module or flowgraphs capable of interacting with SDR input streams and automatically generating detailed visualizations of cell search results.
  • Capability to export results as a function of time and SDR location to enable the creation of coverage maps.

Further Reads

Project Length

  • Small (100 hours) – Medium (200 hours)

Difficulty'

  • Medium

Mentor(s)

  • Michael Petry
  • Andrej Rode


Expanding the GNU Radio 4.0 Block Set

GNU Radio 4.0 has reached a stage where real signal processing applications can achieve performance improvements over GNU Radio 3.x. To maximize its adoption, we aim to expand the set of available blocks, making it easier for the community to build applications with readily available components. The goal of this project is to migrate existing GR 3.x blocks (e.g. gr-digital, gr-analog, gr-audio ...) into GR 4.0. A good list of blocks in GR3 that should be ports has been maintained here: [1]

Prerequisites

  • Knowledge of modern C++
  • Signal processing understanding

Outcome

  • GR4 OOT module with a substantial number of blocks
  • Each block should have CI tests and an example flowgraph
  • Document the process so that other block developers can be guided


Project length

Long (350 hours)

Difficulty

Medium

Mentor(s)

John Sallay, Josh Morman


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

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/gnuradio/gnuradio4/ 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




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)

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

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