GSoCPastProjects
Google Summer of Codes: Past projects
These projects were the ones chosen by students in previous summers of code.
2020
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.
Objective
- 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
Outcome
Student
- Student: Alekh Gupta
- Mentoring: Derek Kozel
Alekh's regular blogs: https://grdpd.wordpress.com/
2019
Block header parsing tool
Arpit Gupta worked on gr-modtool - a tool to help the development process of GNU Radio modules and blocks. He integrated header parsing to automatically extract information from block header that allow automatic binding generation for GRC and, in future, also Python.
Objectives
- A tool to process a block definition into an abstract representation.
- Make gr_modtool use this tool instead of its builtin code to produces YAML files for GRC.
Student
- Student: Arpit Gupta
- Mentoring: Sebastian Koslowski, Nicolas Cuervo
Arpit's weekly blog can be found here: https://headerparser.wordpress.com/
Hardware in the Loop: Cycle-accurate Verilog Design Simulation Integration
Bowen integrated Verilator, a cycle-accurate simulator for Verilog modules, into GNU Radio. This allows rapid prototyping of small, well-defined Verilog modules directly in GNU Radio blocks.
Objectives
- Adapter code to call Verilator-generated Code of modules with fixed interface from within a GNU Radio block's work routine
- Integration of verilator into either build infrastructure or runtime infrastructure (might require further dependencies, e.g. llvm)
Student
- Student: Bowen Hu
- Mentoring: Marcus Müller
Bowens's weekly blog can be found here: https://b0wen-hu.github.io/
2017
C++ Code Generation with GRC
Håkon Vågsether implemented C++ code generation using GRC. As of end of 2017, the code is still in a side branch, but is pending merging as it has some outstanding dependencies (e.g., Python 3 support).
Objectives
- Enable C++ code generation from GRC
- Convert a substantial amount of block descriptors to enable C++ code generation
Student
- Student: Håkon Vågsether
- Mentoring: Sebastian Koslowski
Håkon's weekly blog can be found here: https://grccpp.wordpress.com/
A DAB/DAB+ Transceiver Application
Luca Schmid's work extended gr-dab to a complete transmitter/receiver application for DAB/DAB+ digital radio. He based his work on Andreas Müller's implementation of the PHY layer, implementing the entire transport protocol. An additional GUI bundles all the features in one place and let's users transmit and receive DAB/DAB+ broadcasts either from file or directly to/from an SDR.
Objectives
- Implement the missing components of the DAB/DAB+ standard, including MPEG-2/4 source coding
- Improve the existing code base
- Create a user-friendly GUI capable of transmitting/receiving DAB/DAB+ broadcasts
Student
- Student: Luca Schmid
- Mentoring: Felix Wunsch, Marcus Müller
Code is available at https://github.com/kit-cel/gr-dab. Luca's weekly blog posts can be found here: https://dabtransceiver.wordpress.com/
A Web-Based Display Mechanism
The module gr-bokehgui allows remote interaction with GUI elements using the Bokeh library.
Objectives
- Implement blocks to allow remote interaction with flowgraphs using Bokeh
- GRC integration for easy usage
Student
- Student: Kartik Patel
- Mentoring: Sebastian Koslowski
Code is available at https://github.com/kartikp1995/gr-bokehgui/ His blog including a tutorial for gr-bokehgui can be found here: http://kartikpatel.in/GSoC2017/
Implementing 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. SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf
Objectives
- Implement source and sink blocks for SigMF
- Converters for files generated with the current metadata file formats
- Static analysis tools using SigMF
Student
- Student: Kostis Triantafyllakis
- Mentoring: Sebastian Müller, Bastian Blössl
Kostis' code can be found at https://github.com/ctriant/gr-sigmf. His blog: http://ixion.csd.uoc.gr/ctriant/
2016
We summarized 2016's GSoC projects in our blog: http://gnuradio.org/blog/summer-of-code-2016-wrapping-it-up/
gr-inspector
gr-inspector is a new out-of-tree module (OOT) that is still an official part of GNU Radio. It was created during GSoC 2016, mainly driven by Sebastian Müller, who was sponsored by GSoC, and Christopher Richardson, who was sponsored through SOCIS.
Objectives
gr-inspector is a toolbox for exploring and analyzing signals using GNU Radio. It includes both sophisticated signal processing algorithms for signal detection and analysis, as well as GUIs to easily access the spectrum in a graphical manner. Specific components implemented include:
- Energy-based detection, pre-processing, and extraction
- OFDM Parameter Estimation
- Automatic Modulation Classification
The toolbox is available in all its glory via CGRAN, PyBOMBS, and on the web: https://github.com/gnuradio/gr-inspector
Students
- Student: Sebastian Müller
- Student: Christopher Richardson
- Mentoring: Sreeraj Rajendran, Sebastian Koslowski
PyBOMBS GUI
PyBOMBS is a installation helper tool, mainly geared towards (but not limited to) GNU Radio users, but not limited to those. It was only available on the command line, until GSoC 2016.
Objectives
Implement and test a QT-based GUI. Ravi implemented pybombsgui (which is based on QT) as well as pybombsurl, a package that helps run PyBOMBS directly from CGRAN.
Student
- Student: Ravi Sharan
- Mentoring: Martin Braun
2015
POLAR Codes
POLAR codes are a new class of codes that actually reach the Shannon capacity. The codes themselves were discovered less than a decade ago, and multiple implementations have been suggested. This project aims to create a free implementation as part of gr-fec.
Objectives
Implement encoders and decoders for POLAR codes and merge them into gr-fec.
Requirements
Understanding of FEC codes in general, willingness to read difficult papers on codes. Understanding of C++/Python/VOLK.
- Student: Johannes Demel (CEL / KIT)
- Mentor: Sebastian Koslowski
Video presentation at GRCon 2015: https://www.youtube.com/watch?v=D49RKQRwe_Y&index=10&list=PLbBQHMnVMR41WSEeX3wEn2gzybt7_GcQJ
2014
Radar toolbox
Radar is a great application for SDR. Creating an OOT module that implements some of the most commonly used radar processing algorithms would be a great tool for people to experiment with radar.
Objectives
Create an OOT module (gr-radar); implement and experimentally verify them.
Algorithms that could be implemented include:
- FMCW
- OFDM-Radar
Requirements
General understanding of radar and RF/antennas. Algorithms would be coded in C++ and Python, so at least a basic knowledge of these should be available.
- Student: Stefan Wunsch (CEL / KIT)
- Mentor: Martin Braun
VOLK and General Purpose Processor Optimization
VOLK is an in-tree library that provides signal processing kernels to make use of SIMD instruction sets. SSE and subsequent extensions are widely used, and there is moderate coverage of AVX. ORC is used to fill in the gaps where we know there is low hanging fruit, but have not had time to implement proto-kernels in various instruction sets. There is also a stats page to collect profiling information across processors.
There are a number of projects that could be formed by an interest in VOLK, and the exact proposal should be formed around the applicant's interests. The primary need is for more kernels. VOLK currently does not have AVX2 or AMD64 FMA extensions. NEON support is lacking as well, but that is currently being addressed and will likely be finished by the time GSoC begins.
Outside of adding different instruction set extensions VOLK could use new kernels based on profiling existing GNU Radio and OOT module code. There is (unsurprising) evidence that more complex operations benefit more from VOLK than very quick operations. This opens the door for implementing entire algorithms in VOLK such as frame detection, or channel coding. Other kernels that could be interesting include rounding out the general signal processing functions such as pow, logs, trig functions, etc... If specific algorithms are not mentioned in the applications then the first assignment would be a suggested reading list to identify a handful that would be interesting to the student.
Project Goals: This project should profile existing applications and blocks to identify CPU bottle necks that could be alleviated with SIMD acceleration, then implement proto-kernels targeting bottle necks. The mentor would be able to provide good blocks and algorithms to profile which would yield large gains from VOLK.
Requirements: An interest in software optimization with applications to DSP is the only real requirement. VOLK is a C library that is primarily used in C++. Since the target is hardware instruction set extensions knowledge of ASM programming is useful, but will not be required unless the student specifically wishes to do so.
- Mentor: Nathan West
- Student: Abhishek Bhowmick
Using hardware based co-processors in GNU Radio
Last year, there was a GSoC project that showed the basic steps for creating a Zynq based FPGA accelerator (Zynq). This year we would like to explore better GNU Radio integration by avoiding copying samples in and out of the GNU radio block, and adding real accelerators. In addition to working with the Xilinx zynq system, there are TI Keystone 2 processors that have quad ARM cortex-a15 combined with several TI DSP processors and some hardware accelerators. The Keystone 2 devices are also good candidates for improved GNU Radio hardware accelerator integration.
Objective
Improve the current state if the art of GNU Radio integration with hardware accelerators.
Requirements
The student should have access to the hardware they propose to work with. A good understanding of embedded systems will help the student complete the project successfully. The student should be comfortable working with the Linux kernel, or be prepared to learn quickly. Successful candidates are expected to particpate in the GNU Radio co-prcocessor working group.
- Mentor: Philip Balister
- Student: Alfredo Muniz
GNU Radio Performance Benchmark Analysis
The focus of this effort would be to investigate and mature the performance data analysis tools on http://stats.gnuradio.org to gain visibility into the performance impact of differing hardware, processor extension, and compiler configurations among other things. This effort should also look at the performance comparison of differing GNU Radio versions over time, such that we should notice immediately and in a quantitative way when performance-enhancing or performance-adverse changes are introduced into GNU Radio. Ultimately these tools are important from a system engineering perspective in helping size SDR applications to SDR hardware platforms, and helping focus optimization and development efforts needed to improve performance in the future.
Primary objective
Help provide improvements to GNU Radio benchmarking and performance analysis tools to improve general understanding of GNU Radio performance bottle necks and performance variation across different architectures, compilers, optimizations, etc.
Secondary Objective
Introduce new GNU Radio benchmarks to exercise important signal processing techniques and algorithms which are yet to be represented in the standard gr-benchmark suite of tools.
Tertiary Objective
Test and collect performance data on interesting processing platforms which have yet to be included in the stats.gnuradio.org data set. This could include Tilera, Epiphany, ARM-A15, MIPS, Paralella, PPC, or any number of interesting platforms. Ensuring everything is operating correctly on ARM platforms and potentially focusing on improving performance on this platform is a potential as well.
Requirements
This project requires an understanding of C++, Python, and software performance profiling but not neccisarily a large background in signal processing, although it would be helpful. Skills working with Google's JSAPI and MySQL would be helpful for performing data analysis and presentation as well - an ability to navigate the linux operating system would be extremely helpful, but is not the only key OS of relevence here. The student must also communicate with the community on both the mailing list and the IRC channel (#gnuradio).
- Mentor: Tim O'Shea
- Student: Marcus Müller (CEL / KIT)
gr-trellis improvements
- Mentor: Sebastian Koslowski
- Student: Jan Krämer (CEL / KIT)
2013
LDPC Codes / More FEC
Details: Low Density Parity Check codes are known to be a class of codes that is able to approach the Shannon limit in AWGN channels. The goal of the project is to implement encoder and decoder in GNU Radio and to demonstrate their capabilities in transmission. After understanding and implementation of encoder and decoder in a high-level language, the goal of the project is to develop generic and optimized coders capable of real time operation.
Students: Tracie Perez and Manu TS.
Mentor: Jens Elsner, KIT
Result:
Both students passed and presented their work at GRCon13 (see Manu's and Tracie's presentation).
Improving the GNU Radio Companion
Details: GRC is probably the single most import improvement in terms of GNU Radio usability.
However, at the moment it is limited to creating Python flow graphs. The biggest problem is that it blocks the user from the code; unless the user is already proficient in GNU Radio, there is a mental barrier between the view from GRC and the actual source code.
This project consists of several sub-projects:
1. Granting access to the sources and Doxgyen/Sphinx docs from within GRC
A right-click on a block in GRC would allow the user to jump to the code and/or the auto-generated documentation.
2. Creating new blocks from within GRC and edit them
With Python blocks in particular, this would be an amazing way to rapid-prototype flow graphs; a comparable feature is the way that Simulink allows the inclusion of blocks written in m-code. The user should be able to create a new block from within GRC, edit the source code using his or her favourite editor, and quickly see the changes. These blocks could easily be embedded in the GRC source file. gr-modtool already does a lot of the code generation necessary.
This would probably mean that GRC needs to know about an active out-of-tree module (active meaning that it's currently under development). If GRC could load blocks out of an active module, this would even enable the recompiling of C++ blocks without installing it after every recompile, allowing the user to debug blocks with scopes and FFTs while developing.
Even easier would be the option of having embedded Python blocks. They could be saved in the GRC XML, making them portable between machines, without having to exchange modules.
3. Create C++ flow graphs; parse existing flow graphs and create the GRC file
These are backup subprojects in case the rest is too easy :)
Skills required: Understanding of development cycles, Python
Student: Aneela Yasmeen
Mentor: Sebastian Koslowski, KIT
Result:
Aneela passed the final evalulation. The project was redefined from the initial proposal, which was extremely extensive. She could not attend GRCon13, but was represented by her mentor (presentation.
802.11a/n/? receiver and wireshark connector
Details: With the new PDU and OFDM code, it should be possible to directly bridge USRPs or other receivers to Wireshark. Demodulating wifi packets would be a possible demonstration of this feature and would also showcase how GNU Radio works as a generic receiver tool, even in interaction with other programs.
The student would write code that detects and demodulates 802.11a packets received through an USRP or other SDR hardware. These packets are then passed to Wireshark for analysis.
For decoding the packets the receiver involves implementing:
1) time and frequency synchronizations control loops,
2) channel estimation algorithm.
Recently, a 802.11a receiver was developed at the University of Innsbruck. When writing your proposal, make sure you've checked out their implementation and describe how you plan to extend it.
Also, there's a lot of new OFDM code in the master and next branches. Your work should be taking that into account, as well.
Wireshark I/F: The wireshark captures packets using libpcap (http://www.tcpdump.org/). The socket developed inside GNURadio framework act as a new network I/F that will talk with libpcap to deliver the PDUs, which will be sniffed by wireshark.
Socket <-> libpcap <-> Wireshark.
Skills required: Signal Processing, Python
Student: Shashank Gaur
Mentor: Ankit Kaushik, KIT
Result: Shashank passed his final evaluation. He had already attended GRCon12, and presented his GSoC work at GRCon13 ([1]| presentation]).
ACP port on Xilinx Zynq
The Xilinx Zynq processor/FPGA is a dual core ARM A9 processor with an attached FPGA. One connection between the ARM and the FPGA is the ACP port. This port is designed to support accelerators in the FPGA. For GSoC, the student would write code interfacing gnuradio to simple accelerators in the FPGA. The student will need a Zedboard (http://www.zedboard.org) (or other Zynq hardware) for this project.
Student: Jonathon Pendlum
Mentor: Philip Balister
Result:
Jonathon passed his final evaluations. His presentation at GRCon13 won him the best speaker award.
2012
In 2012, three GSoC projects were completed under the GNU Radio name. We are happy to say that all of these were successful!
DRM transmitter/receiver
Original project description:
DRM (Digital Radio Mondiale is a standard that is used for digital HF broadcasting (High Frequency: from 0.3 to 30 MHz). Because of the interesting physical electromagnetic wave properties of HF channels, DRM transmissions can be used for global communications. A GNU Radio DRM receiver would hence be of use for anyone anywhere in the world interested in radio communications.
An upcoming extension of DRM, DRM+, uses VHF/UHF broadcasting (Very High Frequency: 30 - 300 MHz and Ultra High Frequency: 300 - 3000 MHz), that might well replace analog FM broadcasting in the long run. A starting point for development is the existing code base of the DREAM project. Porting this code to GNU Radio will yield many signal processing blocks that are necessary in any communication system and will allow easy extension and improvement of the standard. For example, a global data communication link could be created with GNU Radio by replacing the payload with IP packets.
Knowledge prerequisite: Signal processing, some C++, some Python
Student: Felix Wunsch
Mentor: Jens Elsner (CEL, KIT)
The code is available at https://github.com/kit-cel/gr-drm. We are happy to say that Felix continued working on the DRM code even after GSoC 2012 and presented his results at GRCon12.
Extend and improve the filter design components
Original project description:
Digital filters are a main component of digital signal processing systems. GNU Radio has one of the few true free, open source (F/LOSS) filter design tools available out there. However, it's in need of some improvement! This project has two main sub-components:
- Extend and test the filter design routines
- Improve the user interface
The first part requires some in-depth knowledge of digital filter theory, so some DSP knowledge would be very useful. The most critical missing component in the current filter design methods (and therefore one which should definitely be approached during this project) is a method to estimate the number of required taps for the Parks-McClellan method of filter design, given a tolerance mask. Also, there are filter types which are not at all designable with the current tools, e.g. half-band filters, cascaded filters and all types of IIR filters (we already have some code available for this part).
In its current state, the filter design code is not filled with an abundance of unit tests, and some 'fringe' examples of filters may not even work. This would be a good time to add some filter tests and maybe crush some bugs.
The user interface also needs improvement. In the current state, there's a graphical filter design tool (gr_filter_design.py), but that could be greatly improved (starting with including the newly developed filter design methods). However, the GUI offers graphical possibilities for filter design which go beyond the mere filter design algorithms, e.g. mouse-draggingg poles/zeros (and then seeing the filter response change graphically in a different window), or sketching filter responses and then checking how well such a filter can be designed. A good example of a GUI for filter design is fdatool which comes with Matlab, but we are free to innovate the look and features of our tool as we see necessary.
The current version of the filter design tool.
Of course, the UI doesn't stop at gr_filter_design.py. Since filter taps are rarely needed by themself, but rather as part of a flow graph, the integration of the filter design in the rest of GNU Radio is something to consider. GRC should be able to make use of the GUI to import taps directly into filter blocks, and the filter design code exposed to the Python and C++ domains could be more user-friendly.
To summarize the list of possible improvements to the tool:
- Improved GUI look and feel.
- Ease of use of gr_filter_design.py with GNU Radio applications (importing taps, running the design program, integration with the GNU Radio Companion).
- Estimation of number of taps with the Parks-McClellan algorithm
- Design tools for IIR filters
- Pole-zero plots
- Interactive GUI
- Drag poles and zeros to recreate filter response
- Ability to draw the outline of a filter and build a closest match
- More complete QA and test code for design algorithms
If you apply for this project, it is not expected that you do every single item in this project description, it is meant as a starting point (but also a guideline). Own ideas regarding the filter design components are encouraged, and since some flaws will only come to light while working with this module, it might expose further to-do items. The mentor will work with the student to identify the priority and secondary tasks for the summer project.
Knowledge prerequisite: Digital signal processing (esp. digital filters), some C++ & Python
Student: Sreeraj Rajendran
Mentor: Martin Braun
The new filter design code is now part of the core GNU Radio code. Sreeraj has stayed with the project and is maintainer for filter-design related issues.
GNSS Receiver
Original project Description: Global Navigation Satellite Systems (GNSS) is the general concept used to identify those systems that allow user positioning based on a constellation of satellites. Specific GNSS are the well-known American GPS, the Russian GLONASS or the forthcoming European Galileo and Chinese Compass/Beidou. Governments around the World are expending billions of dollars of tax payers' money in building and maintaining an infrastructure with explicitly free civilian usage. However, users only have access to a small fraction of the full capability of GNSS, in terms of accuracy, robustness and reliability of the provided service at a reasonable cost. Professional, full-featured receivers are expensive, and even in those cases the users have limited access (if any) to know exactly how position and time information were computed.
Some commercial, industrial and scientific applications of GNSS signals and data require non-standard features of the receiver. Access to intermediate signals is not possible in mass-market receivers, and professional equipment is costly and often a ¿black box¿ that does not offer exact information about how signals are being processed. Since all the processing is done in ASICs or SoCs, one cannot change the implementation of a certain functional block and assess the impact of that change on the whole receiver performance.
As a matter of fact, the landscape of GNSS is going to change rapidly in the following years (modernization of GPS and GLONASS, advent of Galileo and COMPASS). A bunch of new signals will be readily available for navigation, providing means to determine position and time with an unforeseen degree of performance. Nevertheless, the multi-constellation, multi-frequency approach poses several technological challenges. In that sense, the flexibility provided by the software defined radio approach (and, specifically, the GNU Radio framework) appears as an ideal environment for rapid prototyping and testing of new receiver architectures.
We propose the implementation of an open-source GNSS software receiver freely available under the GPL. This project provides a common platform for GNSS signal processing and data gathering for scientific applications, testing of algorithms, receiver design, and educational purposes. This tool is intended to foster collaboration, increase awareness, and reduce development costs in the field of GNSS receiver design and customized use of GNSS signals.
Project status - Spring 2012: Implementing a GNSS software receiver is a task far beyond the reasonable scope of coding activities over one summer. However, we propose as starting point the (GNSS-SDR, an open-source C++ project based on the GNU Radio framework that implements a generic architecture of a GNSS software defined receiver and already provides a working implementation of a whole processing chain of a GPS L1 C/A receiver, from the output of a RF front-end to the computation of position, velocity and time. It also provides outputs in standard formats (KML, RINEX. The software allows an arbitrary number of different algorithms and implementations for each required processing block functionality (signal conditioning, acquisition, tracking and so on, see Figure), allowing the definition of completely customized receiver flowgraph by choosing one of the existing alternatives for each block. This modular nature of the receiver allows the definition of clearly-specified, scoped activities (interface to different front-ends, new synchronization algorithms, interfaces to other sources of information, a multi-frequency / multi-constellation approach, the addition of new cool features, etc.), that can be completed in a summer time frame.
Proposed work: We propose here a set of focused scope activities that could be done in the framework of GSoC. They have been carefully chosen to be enablers of further developments and addition of new features:
- Universal Hardware Driver (UHD). Currently, GNSS-SDR accepts as input a file storing signal samples collected by a data grabber. This activity is intended to implement the communication between a wide range of RF front-ends and the software receiver by using the UHD library, paving the way for multiple receiver configurations.
- Implementation of acquisition algorithms for either GLONASS / Galileo / COMPASS, following the example already implemented for GPS. This would facilitate research on truly multi-constellation receivers (e.g., GPS+GLONASS) working with real signals.
- Demodulation of the navigation message for either GLONASS / Galileo / COMPASS, opening the door to open innovation in multi-constellation receivers and addressing topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning.
Objective by the end of the summer: To provide a working implementation of a GNSS receiver (working with GPS L1 and at least another signal), delivering RINEX files (the standard input of geodesic software libraries for high¿accuracy positioning) and an on-the-fly navigation solution (that is, computation of position, velocity and time of the user¿s receiver).
Knowledge prerequisite: Digital signal processing basics, modern C++ style (with C++11 in mind)
Student: Luis Esteve
Mentor: Carles Fernández-Prades (CTTC, more mentors available.
Outcomes from that summer:
- Galileo E1B and E1C acquisition and tracking modules tested with real-life signals.
- Presentation at GNU Radio Conference 2012
- Publication:
C. Fernández-Prades, J. Arribas, L. Esteve-Elfau, D. Pubill, P. Closas, An Open Source Galileo E1 Software Receiver, in Proceedings of the 6th ESA Workshop on Satellite Navigation Technologies (NAVITEC 2012), 5-7 December 2012, ESTEC, Noordwijk (The Netherlands).
2006
The very first GSoC project in GNU Radio was completed in the year 2006.
Development of GNURadio blocks for Convolutional and Turbo Coding
Student: Michael Dickens Mentor: Eric Blossom