Editing GSoCIdeas

Jump to navigation Jump to 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 publish 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 2020: Project ideas list ==


== Summer of Code 2022: Project ideas list ==
This is the list of project ideas for the summer of code 2019 within GNU Radio.<br />
 
This is the list of project ideas for the summer of code 2022 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 21: Line 19:
* Both OOTs and in-tree improvements are welcome
* Both OOTs and in-tree improvements are welcome


=== QT Widgets Improvements ===


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


* Add a new widget
=== GRC: Build-in sub flowgraphs ===
** 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
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. 
** 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.
* GRC is written in Python which is (almost) all you need to know for this project.
* Widgets are written in C++, so some C++ knowledge is also required.
* Python skills are highly useful.


'''Project length'''
'''Outcome'''


350 hours
* A vastly improved workflow for structuring flowgraphs
 
'''Difficulty'''
 
Hard


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


Andrej Rode
* Sebastian Koslowski




=== 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].
=== Qt5 GUI Integrations ===


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:
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization
 
* [https://github.com/NVIDIA/MatX Matx]
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)
* [https://github.com/gnuradio/cusp CUSP]
 
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'''


* Knowledge of C++ and Python.
* C++, Python proficiency
* Familiarity with CUDA programming
* Qt experienced


'''Project length'''
'''Outcome'''


350 hours
* 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
'''Difficulty'''
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph
 
* Integration of that into GRC-generated Python code
Medium


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


Josh Morman
* Marcus Müller & Sebastian "GRC-Man" Koslowski
 
 
=== Standalone GRC ===
 
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:
 
* 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 [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]
 
'''Prerequisites'''
 
* Knowledge of Python.
 
'''Project length'''
 
175 hours
 
'''Difficulty'''
 
Easy
 
'''Mentor(s)'''
 
Josh Morman,
Håkon Vågsether,
Sebastian Koslowski,
?? Someone else that is a GRC Wizard
 
=== GNU Radio goes Browser: Web Assembly (WASM) port ===
 
 
[[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 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.
 
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.
 
This project has subprojects, from which the student is to pick '''one''':
 
* 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.
 
'''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'''
 
175 hours
 
'''Difficulty'''
 
Medium
 
'''Mentor(s)'''
 
* Marc Newlin
* Marcus Müller
* Depending on topic: further member of the GNU Radio community
 
<div class="toccolours mw-collapsible mw-collapsed">
 
== Summer of Code 2021: Project ideas list ==
<div class="mw-collapsible-content">
 
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.
 
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 at 50% capacity
* 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
 
'''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'''
 
 
=== 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 a new widget
** Compass display (e.g. for direction-finding applications)
** MPEG display (e.g. for video demod output)
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)
 
* Improve current widgets
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets
** More Control Panels on other widgets (follow lead on the frequency sink)
** Improve UI, make more intuitive, more power to mouse users
** Set trigger point with mouse
 
* Integration / Support for QT Creator
** QML design
** Allow to build full GUI applications from, say, GRC
 
'''Prerequisites'''
 
* Familiarity with QT is essential.
* Widgets are written in C++, so some C++ knowledge is also required.
* Python skills are highly useful.
 
'''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'''
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.
'''Mentor(s)'''
* Johannes Demel




Line 290: Line 76:


* Sebastian Koslowski
* Sebastian Koslowski
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===
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.
'''Prerequisites'''
* Knowledge of C++ and Python. Some basic understanding about FEC in general.
'''Outcome'''
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites
'''Mentor(s)'''
* Daniel Estévez
=== 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 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)'''
*Bastian Bloessl
<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 ===
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. 
'''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
'''Mentor(s)'''
* Sebastian Koslowski
=== 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)'''
* Marcus Müller & Sebastian "GRC-Man" Koslowski




Line 456: Line 138:




=== 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'''
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.
'''Mentor(s)'''
* Johannes Demel




Line 470: Line 168:
** 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


Line 483: Line 181:
'''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 515: Line 192:


* 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 532: Line 209:




=== Implement SigMF functionality for the GNU Radio Ecosystem ===
=== 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 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
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:
GNU Radio needs its own implementation of SigMF that ties into the block structure. The following things need to be written:


* qgrx (https://github.com/csete/gqrx)
* Source and Sink blocks for SigMF (similar to the current metadata blocks)
* inspectrum (https://github.com/miek/inspectrum)
* Converters for files generated with the current metadata file formats
* ...
* Static analysis tools using SigMF
 
Any additional tools are welcome in a proposal.


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


* Knowledge of the programming language of the covered tools.
* Basic understanding of how to write GNU Radio blocks is required.
* Hands-on experience with the respective tools.
* 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.
* Familiarity with the SigMF specification.
* Depending on the precise path that the student and the mentor define, experience in GUI development would also be useful.


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


* The tools worked on have capability to load and save files in the SigMF format.
* 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 />
* Depending on the specific tool, SigMF meta data is displayed within the tool.
This leaves plenty of time for further development.
* The number of tools worked on needs to be determined by the student, depending on his/her experience.
* 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)'''
'''Mentor(s)'''


* Sebastian Müller, Andrej Rode
* Bastian Bloessl, Sebastian Müller




Line 566: Line 240:
=== Statistical Toolbox for GRC ===
=== 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.
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.


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


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


'''Outcome'''
'''Outcome'''
Line 580: Line 254:
* Ben Hilburn
* Ben Hilburn


</div>
 
</div>
 
=== Digital Pre-Distortion ===
 
Digital Pre-Distortion (DPD) is a technique allowing transmitters to compensate for non-linear responses in their hardware, most notably the power amplifier. This improves SNR and can allow more spectral and power efficient operation of a given set of hardware.
 
DPD is widely used and is increasingly necessary as many multicarrier signals such as what are seen in DVB and LTE exhibit high peak to average power ratios (PAPRs). DPD implementations are not widely available in the open source community. This is a deficit that this project hopes to correct. Over the course of the project the student would implement standard DPD algorithms in to a GNU Radio out of tree module so that they can be available for use directly or as reference designs.
 
'''Prerequisites'''
 
* Workable C++ proficiency, basic knowledge of radio systems, ideally familiarity with GNU Radio and/or Digital Pre-Distortion
 
'''Outcome'''
 
* Implement standard memory-less and memory based DPD algorithms
* Implement the training algorithms for such DPD application algorithms.
* Implement a GUI tool or testbench for viewing the AM-AM and AM-PM responses of an amplifier
 
'''Mentor(s)'''
 
* Derek Kozel
 
 
 
== Application process ==
== Application process ==


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)