« Previous - Version 38/123 (diff) - Next » - Current version
Tom Rondeau, 02/24/2012 03:34 pm
More details and links for interested students.


Google Summer of Code (GSoC)

GSoC is a Google-sponsored event to get students involved in Open Source projects (Website)

List of ideas

Please post project ideas here. Make sure to include a description of the project, ideally including prerequisites and an expected outcome. For an idea how this could look like, check out the KDE idea list.

Projects are sorted by category. If you feel your project idea does not match an existing category, create a new one. If you're posting an idea, consider if you can mentor this project, and put your name down.

Reviewing the Google FAQ page for a broader understanding of project, mentor, and student responsibilities is recommended.

GNU Radio Development

Integration of GNU Radio into Eclipse.

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).
Mentor: tba

Performance metric suite for GNU Radio

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 USRP1(ArchitecureLatencyMeasurements). However, this has not been updated to use the UHD interface, and therefore does not work with the network-based or embedded varieties of the USRP family, and also was not intended for end-to-end latency measurements of a complete flowgraph. In addition, with the development of the VOLK library to provide platform-specific, optimized signal processing blocks, having a general purpose tool to measure application-level metrics is even more important. The goal is to build a suite of performance measurement tools that can track end-to-end application-level metrics such as latency, and complements profiling tools such as OProfile to help guide optimization work.
Knowledge Prerequisite: General Linux/Unix programming
Access to USRPs required.
Mentor: Doug Geiger

Applications

DRM receiver

Details: DRM (Digital Radio Mondiale) is a standard that is used for digital HF broadcasting. DRM transmission can be used for global communications due to the special properties of electromagnetic waves in the HF (0.3 MHz - 30 MHz) bands. A GNU Radio DRM receiver would hence be of use for anyone anywhere in the world interested in radio communications. An extension is the new and coming VHF/UHF broadcasting standard DRM+, 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++
Mentor: Jens Elsner (CEL, KIT)

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.).
Mentor: tba

Channel Sounder

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

GNSS Receiver

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.

GNSS software receiver concept

Current Project status: 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.

General diagram of the modules that form the GNSS software receiver. Each module accepts multiple implementations, which can be selected by the user.

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)
Mentor: Carles Fernández-Prades (CTTC), more mentors available.

(Digital) Signal Processing Components

Extend and improve the filter design components

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:

  1. Extend and test the filter design routines
  2. 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 who says this is how the best GUI should look?

gr_filter_design.py in it's current state 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 maybe the filter design code exposed to the Python and C++ domains could be more user-friendly.

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.

Knowledge prerequisite: Digital signal processing (esp. digital filters), some C++ & Python
Mentor: Martin Braun

Generic compressive sensing framework

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: tba

USRP/Hardware related projects

AGC loop for the USRP.

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.
Mentor: tba

Applying as a student

If you're interested in participating as a student, have a look at the GSoC student FAQ. Some points are worth highlighting here:

  • Don't hesitate to contact us beforehand. Of course we have no influence on whether or not you're accepted, but to figure out details about your project it might be worth taking the time.
  • Read the "Students and Eligibility" section on the FAQ webpage.
  • Applications for students will take place from March 27 - April 9, 2012 if GNU Radio is accepted as a mentoring organization.

gr-perf-monitorx.png - performance monitor example (218 KB) Tom Rondeau, 03/27/2013 04:25 pm

gr-perf-monitorx-small.png (105 KB) Martin Braun, 03/28/2013 05:06 pm

fir_vs_fft_ccc-scaled.png - FIR vs. FFT filter performance (41.2 KB) Tom Rondeau, 02/05/2014 09:29 am