Editing GSoCIdeas

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.
+
= Summer of Code 2018: Project idea list =
  
== Summer of Code 2021: Project ideas list ==
+
This is the list of project ideas for the summer of code 2018 within GNU Radio.<br />
 
 
This is the list of project ideas for the summer of code 2021 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 [[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 [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.
  
 
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 16: Line 14:
 
Guidelines for good projects (when suggesting projects, please consider these):
 
Guidelines for good projects (when suggesting projects, please consider these):
  
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity
+
* Clearly defined scope, with a main target that can be done in 3 months
 
* Clear benefits for the GNU Radio project
 
* Clear benefits for the GNU Radio project
 
* Not specific to a certain hardware. No specific embedded devices, either, please.
 
* Not specific to a certain hardware. No specific embedded devices, either, please.
 
* Both OOTs and in-tree improvements are welcome
 
* Both OOTs and in-tree improvements are welcome
  
'''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'''
+
== Ideas ==
  
 +
=== CtrlPort backend implementation ===
  
=== QT Widgets Improvements ===
+
CtrlPort is essentially a "remote control" infrastructure with which one can introspect flowgraphs, call methods on blocks (albeit that is rarely been implemented) or get performance data.
  
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br />
+
* Existing CtrlPort builds on Thrift
This project is cleanly divided into several sub-projects:
+
* Thrift has proven to be a very problematic dependency
 +
* Hence, only a very small percentage of users able to use CtrlPort
 +
* CtrlPort was designed to be transport-agnostic, so let's replace the transport
 +
* Hottest candidate: ZeroMQ + MessagePack
 +
* Backwards compatibility is not really necessary (very small number of uses so far)
  
* Add a new widget
+
==== Prerequisites ====
** 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
+
* C++ and Python expertise
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets
+
* Basic understanding of RPC
** More Control Panels on other widgets (follow lead on the frequency sink)
+
* Basic GNU Radio understanding
** Improve UI, make more intuitive, more power to mouse users
 
** Set trigger point with mouse
 
  
* Integration / Support for QT Creator
+
==== Outcome ====
** QML design
 
** Allow to build full GUI applications from, say, GRC
 
  
'''Prerequisites'''
+
* GNU Radio has a working CtrlPort transport
 +
* Tool to list the Performance Counters that are exposed via CtrlPort
 +
* Example code how to remotely interact with a flow graph via CtrlPort/ZMQ
  
* Familiarity with QT is essential.
+
==== Mentor ====
* Widgets are written in C++, so some C++ knowledge is also required.
 
* Python skills are highly useful.
 
  
'''Mentor(s)'''
+
Marcus Müller
  
Andrej Rode
+
=== Qt5 GUI Integrations ===
  
=== Standardized High Throughput FEC Codes ===
+
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization
  
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 ====
  
'''Prerequisites'''
+
* C++, Python proficiency
 +
* Qt experienced
  
* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.
+
==== Outcome ====
  
'''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
  
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.
+
==== Mentor ====
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.
 
  
'''Mentor(s)'''
+
Marcus Müller & Sebastian "GRC-Man" Koslowski
  
* Johannes Demel
+
=== 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
  
=== GRC: View-Only Mode (Secure) ===
+
Utilities:
 +
* Auto-generate YAML files for GRC (would require another tool, also part of this project)
 +
* Facilitate inclusion of GNU Radio with other tools/frameworks
  
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.
+
There is some code in gr_modtool which does this, which can be reused and
 +
extended.
  
'''Prerequisites'''
+
===== Prerequisites =====
  
* GRC is implemented using Python. So, Python should be known pretty well.
+
* Strong knowledge of Python, including Py3k idiosyncrasies
 +
* Some text parsing experience
 +
* Some understanding of GNU Radio block structure
  
'''Outcome'''
+
===== Outcome =====
  
* Safely view other people's flowgraphs without putting your PC at risk.
+
* A tool, written in Python, merged into the GNU Radio source tree, which can 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)'''
+
===== Mentor(s) =====
  
* Sebastian Koslowski
+
Martin Braun
  
 +
=== gr-modtool overhaul ===
  
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===
+
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.
  
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.
+
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.
  
'''Prerequisites'''
+
The following items can be improved for modtool, in order of priority:
  
* Knowledge of C++ and Python. Some basic understanding about FEC in general.
+
* 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).
 +
* 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.
  
'''Outcome'''
+
===== Prerequisites =====
  
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites
+
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.
  
'''Mentor(s)'''
+
===== Outcome =====
  
* Daniel Estévez
+
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) =====
  
=== Runtime Benchmarks ===
+
Martin Braun
  
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.
+
=== GRC: View-Only Mode (Secure) ===
  
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.)
+
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.
  
'''Outcome'''
+
===== Prerequisites =====
  
* Come up with interesting metrics and, if needed, implement blocks to extract them.
+
GRC is implemented using Python. So, Python should be known pretty well.
* 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'''
+
===== Outcome =====
  
* C++ programming
+
Safely view other people's flowgraphs without putting your PC at risk.
* Data evaluation and visualization
 
* Automation tools (like GNU Make to run benchmarks)
 
  
'''Mentor(s)'''
+
===== Mentor(s) =====
  
*Bastian Bloessl
+
Sebastian Koslowski
  
<div class="toccolours mw-collapsible mw-collapsed">
+
=== DTV User Front-End ===
  
== Summer of Code 2020: Project ideas list ==
+
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.
<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.
+
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:
  
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.
+
* Automatic selection of frequencies based on location
 +
* Integration with web services, such as TV program indicators
 +
* Load IQ files
 +
* Record-to-file
  
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.
+
===== Prerequisites =====
  
Please add ideas to this list (you may cannibalize old ideas, of course!).
+
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.
  
Guidelines for good projects (when suggesting projects, please consider these):
+
===== Outcome =====
  
* Clearly defined scope, with a main target that can be done in 3 months
+
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.
* 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
 
  
 +
===== Mentor(s) =====
  
 +
Johnathan Corgan
  
=== GRC: Build-in sub flowgraphs ===
+
=== Extending and Updating gr-radar ===
  
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.
+
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:
  
* GRC is written in Python which is (almost) all you need to know for this project.
+
* SAR / InSAR methods
 
+
* Better passive radar support
'''Outcome'''
+
* Speed camera applications
 
+
* Multi-antenna radar techniques
* A vastly improved workflow for structuring flowgraphs
 
 
 
'''Mentor(s)'''
 
 
 
* Sebastian Koslowski
 
  
 +
===== Prerequisites =====
  
 +
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.
  
=== Qt5 GUI Integrations ===
+
===== Outcome =====
  
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization
+
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.
  
'''Prerequisites'''
+
===== Mentor(s) =====
  
* C++, Python proficiency
+
Stefan Wunsch, Martin Braun
* Qt experienced
 
  
'''Outcome'''
+
=== Extending and Updating gr-inspector ===
  
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)
+
gr-inspector (https://github.com/gnuradio/gr-inspector) is a toolbox with focus on automated reception of unknown signals and providing analysis functionality for the same. Currently, it is possible to energy-detect signals, mix down signals as well as filter and decimate detected signals. The output of this chain can be fed in a custom signal processing chain. Also, gr-inspector features basic automatic modulation classification (AMC) functionality, using Tensorflow (https://www.tensorflow.org/) and cyclostationary features. Additionally, parameters of received OFDM signals can be estimated. The existing functionality provides a platform to extend in various directions:
* 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)'''
+
* Improve detection algorithm to provide more accuracy for signals with flat edges
 +
* Add option to manually select more than one signal
 +
* Improve AMC functionality/user experience (nicer output)
 +
* Automatic signal demodulation after modulation classification (this should be split in more subtasks)
 +
* Use database to output guesses about radio service depending on estimated parameters
  
* Marcus Müller & Sebastian "GRC-Man" Koslowski
+
==== Prerequisities ====
  
 +
Knowledge of C++ and Python as well as strong signal processing and communications engineering background. Depending on the direction of the extension, AMC and/or ML background needed. Also, signal intelligence experience is a plus.
  
 +
==== Outcome ====
  
=== Extending and Updating gr-radar ===
+
We rely on the students to pick out a set of tasks that consistently extends gr-inspector and is managable to be implemented in 3 months. All work will be merged into master branch by the end of GSoC.
 
 
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:
 
 
 
* SAR / InSAR methods
 
* Better passive radar support
 
* Speed camera applications
 
* Multi-antenna radar techniques
 
 
 
'''Prerequisites'''
 
 
 
* 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.
 
 
 
'''Outcome'''
 
 
 
* 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.
 
 
 
'''Mentor(s)'''
 
 
 
* Stefan Wunsch, Martin Braun
 
  
 +
==== Mentor(s) ====
  
 +
Sebastian Müller, Sebastian Koslowski
  
 
=== QT Widgets Improvements ===
 
=== QT Widgets Improvements ===
Line 241: Line 229:
 
** Allow to build full GUI applications from, say, GRC
 
** Allow to build full GUI applications from, say, GRC
  
'''Prerequisites'''
+
===== Prerequisites =====
  
* Familiarity with QT is essential.
+
Familiarity with QT is essential. Widgets are written in C+'', so some C''+ knowledge is also required. Python skills are highly useful.
* Widgets are written in C+'', so some C''+ knowledge is also required.
 
* Python skills are highly useful.
 
  
'''Mentor(s)'''
+
===== Mentor(s) =====
  
 
Tim O'Shea
 
Tim O'Shea
 
 
 
 
 
  
 
=== Android ===
 
=== Android ===
Line 267: Line 248:
 
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs
 
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs
 
* Interactivity concepts
 
* Interactivity concepts
** Gestures and config for radio parameters (e.g., freq, gain, bandwidth)
+
** 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
 
** 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 =====
 
 
'''Prerequisites'''
 
  
 
* Some Android experience
 
* Some Android experience
Line 278: Line 257:
 
* C++/Java experience
 
* C++/Java experience
  
'''Mentor(s)'''
+
===== Mentor(s) =====
  
* Bastian Bloessl
+
Ben Hilburn
 
 
=== 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 ===
 
=== Filter Design Tool Enhancements ===
Line 312: Line 268:
  
 
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.
 
* 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
+
* It still currently runs on PyQWT, which is obsolete and needs to be updated to QT4/QT5
 
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui
 
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui
 
* Add more support for filter design concepts and other filters.
 
* Add more support for filter design concepts and other filters.
Line 318: Line 274:
 
** Better support for creating PFB filters
 
** Better support for creating PFB filters
  
'''Prerequisites'''
+
===== Prerequisites =====
  
* Strong DSP background required.
+
Strong DSP background required. Python and QT knowledge highly useful (at least one of those is a must).
* Python and QT knowledge highly useful (at least one of those is a must).
 
  
'''Mentor(s)'''
+
===== Mentor(s) =====
  
* Marcus Leech
+
Sebastian Müller, Marcus Leech
  
 +
=== Implement SigMF functionality for GNU Radio ===
  
 +
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
 +
 +
GNU Radio needs its own implementation of SigMF that ties into the block structure. The following things need to be written:
 +
 +
* Source and Sink blocks for SigMF (similar to the current metadata blocks)
 +
* Converters for files generated with the current metadata file formats
 +
* Static analysis tools using SigMF
 +
 +
===== Prerequisites =====
 +
 +
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 />
 +
Depending on the precise path that the student and the mentor define, experience in GUI development would also be useful.
  
=== Implement SigMF functionality for the GNU Radio Ecosystem ===
+
===== Outcome =====
  
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 />
+
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 />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf
+
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.
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:
+
===== Mentor(s) =====
  
* qgrx (https://github.com/csete/gqrx)
+
Bastian Bloessl, Sebastian Müller
* inspectrum (https://github.com/miek/inspectrum)
 
* ...
 
  
Any additional tools are welcome in a proposal.
+
=== Statistical Toolbox for GRC ===
  
'''Prerequisites'''
+
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.
  
* Knowledge of the programming language of the covered tools.
+
===== Prerequisites =====
* Hands-on experience with the respective tools.
 
* Familiarity with the SigMF specification.
 
  
'''Outcome'''
+
Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / datascience modeling.
  
* The tools worked on have capability to load and save files in the SigMF format.
+
===== Outcome =====
* 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)'''
+
An OOT module that provides statistical analysis capabilities for GNU Radio.
  
* Sebastian Müller, Andrej Rode
+
===== Mentor(s) =====
  
 +
Ben Hilburn
  
 +
=== Standardized High Throughput FEC Codes ===
  
=== Statistical Toolbox for GRC ===
+
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.
  
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'''
+
===== Prerequisites =====
  
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.
+
Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.
  
'''Outcome'''
+
===== Outcome =====
  
* An OOT module that provides statistical analysis capabilities for GNU Radio.
+
Standardized Codes, e.g. LTE Turbo Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''. The prefered goal is to find a highly optimized implementation and integrate these into GNU Radio.
  
'''Mentor(s)'''
+
===== Mentor(s) =====
  
* Ben Hilburn
+
Johannes Demel
  
</div>
 
</div>
 
 
== Application process ==
 
== Application process ==
  
Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].
+
* Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].
* Please introduce yourself on the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]
+
* 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
 
* 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.
 
* 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.

Please note that all contributions to GNU Radio are considered to be released under the Creative Commons Attribution-ShareAlike (see GNU Radio:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)