Google Summer of Code (GSoC)¶
GSoC is a Google-sponsored event to get students involved in Open Source projects (Website). GNU Radio is participating as an independent organization in 2013. Check out our GSoC page for details.
Students interested in participating, read the student instructions.
- Google Summer of Code (GSoC)
- List of ideas
- GSoC 2012
- Old GSoC ideas
- Performance metric suite for GNU Radio (first proposed: 2012)
- Channel Sounder (first proposed: 2012)
- Generic compressive sensing framework (first proposed: 2012)
- Rewrite tunnel.py (first proposed: 2012)
- Integration of GNU Radio into Eclipse. (first proposed: 2012)
- Vector-network analyzer
- AGC loop for the USRP. (first proposed: 2012)
- DECT Tools (first proposed: 2013)
- FPGA pre-correlation (first proposed: 2013)
- DVB-T transmitter / receiver (first proposed: 2013)
- Turbo Equalizer (first proposed: 2013)
- MIMO stuff (first proposed: 2013)
- Wireless networks in-the-loop (first proposed: 2013)
List of ideas¶
This is the list of project ideas for GSoC 2013 within GNU Radio. All of these projects have mentors, so if you have any questions, feel free to contact them!
Remember that these are ideas and are meant as an inspiration for you to write your own proposal.
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The GNU Radio discussion mailing list is the best place to contact all of us. Please do not contact us off-list for the sake of discussing GSoC, unless you're contacting a mentor listed here to get feedback on a proposal.
Reviewing the Google FAQ page for a broader understanding of project, mentor, and student responsibilities is recommended.
If you need a USRP to complete the project, we will be able to arrange something.
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
Mentor: Sebastian Koslowski, KIT
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
Mentor: Ankit Kaushik, KIT
Vector signal analyzer¶
Details: A vector signal analyzer pertmits to visualize simultaneously signals in various domains. For example, it is possile to visualize a modulated signal in time domain, the constellation of the signal, its PSD (Power Spectrum Density), and depending on the demodulators disponile in the equipment, to visualize the demodulated signal.
In this project a vector-signal analyzer app (qtgui based) will be implemented. It will be possible to visualize and to export the visualized signal to data files and figures (eps, ps and pdf). Using demodulator disponible, o implemented u the user, it will be possile to visualize the demodulated signal.
Mentor: Edmar Gurjao, UFCG, Brazil
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.
Mentor: Jens Elsner, KIT
Performance Counters¶
Extending the tools for viewing, monitoring, and/or analyzing the new performance counters in GNU Radio. See:
http://gnuradio.org/redmine/projects/gnuradio/wiki/performancecounters
There is current work to build a tool using ControlPort to visualize the running graph and show the different performance counters for each block. There are two versions located in gnuradio-core/src/python/gnuradio/ctrlport called gr-perf-monitor and gr-perf-monitorx. The former is a simple QT-based tool that displays all of the performance counters for each block and buffer. It is a fairly crude rendering that makes it difficult to easily parse the data.
The second tool, gr-perf-monitorx uses Python's Matplotlib an NetworkX modules to draw the graph. An example of this graph is shown below using the pfb_sync_test-qt.grc example from GNU Radio. It displays the graph as a set of nodes and edges. The size of the nodes are directly proportional to the "work_time" performance counter (how much time is spent in work). The width and darkness of the edges is directly proportional to the amount of data in the buffers between blocks.
We have also created separate tabs where we can view these numbers in either table form or bar graph. Further, we can select if we want to use the instantaneous, average, or variance metrics in each display. We can also drag-and-drop nodes on the canvas to make it easier to see the graph.
While this is a good starting point, we could improve these tools, add on to it, add more performance counters, or provide some other tool(s) to understand the performance counters. More easily viewable and the addition of the other performance counters would be a good start.
The goal is to provide both useful tools for us to visualize the performance of a running GNU Radio application. Also, we hope that this will lead to a better understanding of GNU Radio's performance in general, possibly even being able to use these counters to set traps when something is going wrong or performance limitations are being reached.
Mentor: Tom Rondeau
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.
Mentor: Philip Balister
Improved support for many-core floating-point accelerators¶
Functionality to enable the effective use of MIMD floating-point accelerator hardware, using the Parallella board as a reference platform. For example:
- further development of Performance Counters and Block Core Affinity
- implementing message passing using on-chip networks
A project could choose something like a digital waveform receiver and use one of the above to optimise for throughput.
Note that work has been started on porting blocks to Epiphany, but it's likely that the student will need to do further porting work in order to complete and evaluate the benefit of the project.
Hardware will be supplied by the Parallella Project, along with support on the architecture, SDK and OpenCL implementation. While the student is waiting to receive hardware it should be possible to provide remote access to a Parallella prototype at the ORBIT test bed at WINLAB, Rutgers.
Mentor: Tommy Tracy II, High Performance Low Power Lab, University of Virginia.
GSoC 2012¶
In 2012, three GSoC projects were completed under the GNU Radio name. We are happy to say that all of these were successful!
Successful / completed projects¶
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.
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-McClellen 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 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.
- Universal Hardware Driver. 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.
- 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).
Old GSoC ideas¶
These ideas for projects did not find a student in previous GSoCs. The project ideas are left in here for archaeological purposes and future reference.
Performance metric suite for GNU Radio (first proposed: 2012)¶
Details: Build a set of performance measurement tools for GNU Radio to enable accurate measurement of a variety of metrics including processor load, throughput (of a flow-graph) and end-to-end latency. For example, an existing set of patches to GNU Radio (and a Linux libc include file) was developed to measure latency between GNU Radio and the USB-based Ettus Research USRP1 (ArchitecureLatencyMeasurements). However, this project has not been updated to use the new UHD interface, and therefore does not work with the network-based or embedded varieties of the USRP family. Further, this project was not intended for end-to-end latency measurements of a complete GNU Radio application and is specific to the USRP radio front-end.
In addition, GNU Radio has been developing the VOLK library to provide platform-specific, optimized signal processing blocks. The intent is expose and make the use of vector processing capabilities in general purpose processors easy. Since the idea of VOLK is to improve performance, having a general purpose tool to measure application-level metrics is critical. The goal is to build a suite of performance measurement tools that can track end-to-end application-level metrics such as latency and speed, and which complements profiling tools such as OProfile to help guide optimization work. An initial attempt at VOLK benchmarking was done in GNU Radio and is discussed here, but a more complete, easy to use toolset is called for.
Knowledge Prerequisite: General Linux/Unix programming, C++, maybe Python
Access to USRPs required.
Mentor: Doug Geiger
Channel Sounder (first proposed: 2012)¶
Details: Channel sounding describes the process of measuring a multipath propagation channel and obtain information about excess delay, Doppler spread and fading properties. The final product should make use of USRPs for channel sounding (the high timing constraints require use of the FPGA) and provide a complete measurement tool which can be used to gather statistics about mobile communication channels.
Knowledge prerequisite: Digital signal processing basics, FPGA basics
Access to USRPs required.
Mentor: Johnathan Corgan
Generic compressive sensing framework (first proposed: 2012)¶
Details: By correlating the incoming signal with pseudo-random sequences, it may become possible to obtain the entire 100 MHz spectrum at once via Ethernet, albeit in a different base than the usual regular sampling time base. One proven application for this is Compressed Spectral Estimation. This project includes developing an FPGA image to correlate with pseudo-random sequences.
Knowledge prerequisite: Some FPGA experience, basic digital signal processing
Mentor: Jens Elsner
Rewrite tunnel.py (first proposed: 2012)¶
Details: Tunnel.py has been around for quite some time and has served as a simple example of how GNU Radio could be used for basic MAC layer development. Basically, it's a transceiver radio which connects GNU Radio to the networking stack of the operating system through virtual network devices (i.e. TUN/TAP devices). This allows to tunnel any IP traffic through GNU Radio and therefore use it similar to a normal Wifi device. In the recent past however, it turned out that tunnel.py is not really working as it is supposed to do. For many GNU Radio users it doesn't work at all. That's because tunnel.py is quite choosy in terms of modulation type, rate+gain settings, the daughterboard used etc. This project therefore aims at rewriting tunnel.py in order to turn it into a working example again which also allows GNU Radio beginners to see how powerful it is.
Knowledge prerequisite: C++ & Python, basic digital signal processing
Mentor: Andre Puschmann
Integration of GNU Radio into Eclipse. (first proposed: 2012)¶
Details: Create a development environment for GNU Radio based on Eclipse (see also: Call20120119). The goal is to make the entry point into GNU Radio easier for beginners. The Eclipse extension could help in the actual coding process (e.g. code completion, knowledge of GNU Radio modules etc.) but also provide graphical tools (possibly a GRC integration).
Vector-network analyzer¶
Details: Build a vector-network analyzer app (qtgui based) that can show PSD, constellations, maybe other representations of the signal. Demodulate some basic modulation schemes (BPSK, QPSK, GMSK, QAM, etc.).
AGC loop for the USRP. (first proposed: 2012)¶
Details: Make an AGC loop for the USRP (i.e., in hardware with direct, low-latency control over analog gain stages).
Access to USRPs required.
DECT Tools (first proposed: 2013)¶
Details: DECT is a standard used to connect wireless phones to basestations (for landline operation). DECT for GNU Radio has been attempted before (see https://www.cgran.org/wiki/GR_DECT), but is lacking a stable release. With all the new features in-place a fully functional and nicely integrated DECT transceiver should be possible.
Goals of this project:- Receive a clear voice signal from an unencrypted DECT signal (DECT sniffer)
- Can we use GNU Radio to actually connect to a DECT base station?
Skills required: DSP, C++, Python
Mentor: tba
FPGA pre-correlation (first proposed: 2013)¶
If there was a possibility to pre-correlate and decimate on the FPGA, this could help a lot downstream and allow usage of high bandwidths with lower sampling frequencies.
Applications:- Channel Sounding
- Spectrum estimation
- Compressive Sensing
- DS-CDMA
DVB-T transmitter / receiver (first proposed: 2013)¶
Turbo Equalizer (first proposed: 2013)¶
Details: A turbo equalizer is a receiver component similar to turbo codes, see also https://en.wikipedia.org/wiki/Turbo_equalizer. The performance of such equalizers is very good; even in tricky channels, the bit error rates converge closely to theoretical limits.
Implementing such an equalizer is difficult on several levels: first of all, the theory behind turbo equalizers must be understood. Then, the iterative nature of such systems requires a highly optimized implementation if it should be usable in real-time systems.
Skills required: DSP theory, C++, Python, SIMD-codes (e.g. VOLK)
Mentor: tba
