GSoCOldIdeas

GSoCOldIdeas

Block header parsing tool

Rough ideas:

• Python-based tool
• Can extract info from block headers (and maybe, if it has to, also from the .cc file)
  • Analyse factory signature ("make function"), analyze getters/setters
  • Analyse I/O signature

Utilities:

• Auto-generate YAML files for GRC (would require another tool, also part of this project)
• Facilitate inclusion of GNU Radio with other tools/frameworks

There is some code in gr_modtool which does this, which can be reused and extended.

Prerequisites

• Strong knowledge of Python, including Py3k idiosyncrasies
• Some text parsing experience
• Some understanding of GNU Radio block structure

Outcome

• A tool, written in Python, merged into the GNU Radio source tree, which can turn a block definition into some kind of abstract representation (the design which of is also part of this project)
• Another tool, which takes the abstract representation, and produces YAML files for GRC.
• An API into calling this which can be used by other tools (external to GNU Radio).
• Make gr_modtool use this tool instead of its builtin code.

Mentor(s)

Martin Braun, Nicolas Cuervo

Hardware in the Loop: Cycle-accurate Verilog Design Simulation Integration

Hardware accelerators are necessary or at least desirable in many SDR systems.

A typical development workflow for FPGA-accelerated DSP system looks like this:

• Write down the system specification, formulate the algorithm mathematically
• Implement the algorithm in Matlab, Python to make a Proof of Concept
• Write extensive test cases to make sure you've got everything right
• Iterate.
• Implement the same algorithm in a HDL, e.g. Verilog, and synthesize
• Write extensive (System)Verilog test benches, which mostly duplicate code from the software test cases in a less friendly development environment
• Run the test benches in simulation and the FPGA to prove functionality
• Iterate.

However, with Verilator, there's a relatively mature tool to turn Verilog modules into compilable C++ code that offers a cycle-accurate simulator of the module.

The goal would be to use integrate verilator into the GNU Radio in a way that allows for rapid prototyping of small, well-defined Verilog modules; the idea is that you can, in the end, just drop your Verilog code file name in a GNU Radio block, and behind the scenes, the C++ code is generated, necessary "adapters" from native (GNU Radio) data types to simulated signals are added, and all is then executed at flow graph run time to process digital signals from within a flow graph.

Prerequisites

• workable C++ proficiency
• basic idea of FPGA development
• Ability to read and write "hello world" verilog modules

Outcome

• 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)
• Examples and software test cases for fundamental blocks, e.g. a FIFO and a integer squarer

Mentor

Marcus Müller

gr-modtool overhaul

gr-modtool is one of the most important tools within GNU Radio, as it makes the creation of community modules much more accessible. However, it is in dire need of an overhaul, as its early codebase even predates the 3.7 API change. In its current state, gr-modtool is a fairly static chunk of code: The 'add' functionality in particular is a long string of if-then-else style static rules, which are then procedurally executed into a string of templates or file operations. A more functional style, with a less static rule set, would do the wonders to that good old tool.

Rewriting modtool in its entirety is task that is most likely way to large for a single GSoC. However, there's a lot of subtasks, so this can be broken up. When applying to this task, students should indicate which part of modtool they would like to work on. Even so, it is unlikely that more then one student will be able to work on this without too much destructive interference.

The following items can be improved for modtool, in order of priority:

• Rewrite as a plugin architecture. Currently, only GNU Radio OOTs and in-tree components can be extended. There's no reason modtool can't work for VOLK and RFNoC (thereby obsoleting rfnocmodtool).
• Find and eliminate pockets of non-Py3k compatibility.
• Python API. modtool is currently only usable as a command-line program.
• An actual UI to improve usability.

Prerequisites

Creating a better modtool requires strong knowledge of Python, including Py3k idiosyncrasies, functional design principles, template generation. Also, this task requires some knowledge of the existing modtool.

Outcome

The outcome depends on the subtasks selected by the student, but in an ideal case, the plugin architecture would be in place and would allow other projects to implement their own plugins. Documentation for this project would also be highly valuable.

Mentor(s)

Martin Braun, Nicolas Cuervo

DTV User Front-End

GNU Radio includes gr-dtv, which allows the decoding of ATSC TV signals and various other Digital Video Broadcast standards. From a DSP/decoding perspective, it's an impressive GNU Radio module. The issue is that it lacks any sort of user front-end and is difficult to use.

A well-designed UI for gr-dtv would be a great addition to GNU Radio. It would nicely demonstrate how GNU Radio can be used to create real-world applications. It could also include the following features:

• Automatic selection of frequencies based on location
• Integration with web services, such as TV program indicators
• Load IQ files
• Record-to-file

Prerequisites

Since gr-dtv already includes the bulk of the DSP/decoding part, this would be primarily GUI development. The programming language may be chosen by the student, although Python is probably the most viable candidate. Experience in GUI development is a strong requirement, though.

Outcome

The result of this project should be a simple, click-to-launch app that immediately allows watching DTV, assuming the availability of some SDR hardware. The fact that a GNU Radio flowgraph is running in the background should be nicely hidden away.

Mentor(s)

Johnathan Corgan

Extending and Updating gr-inspector

gr-inspector (https://github.com/gnuradio/gr-inspector) is a toolbox with focus on automated reception of unknown signals and providing analysis functionality for the same. Currently, it is possible to energy-detect signals, mix down signals as well as filter and decimate detected signals. The output of this chain can be fed in a custom signal processing chain. Also, gr-inspector features basic automatic modulation classification (AMC) functionality, using Tensorflow (https://www.tensorflow.org/) and cyclostationary features. Additionally, parameters of received OFDM signals can be estimated. The existing functionality provides a platform to extend in various directions:

• Improve detection algorithm to provide more accuracy for signals with flat edges
• Add option to manually select more than one signal
• Improve AMC functionality/user experience (nicer output)
• Automatic signal demodulation after modulation classification (this should be split in more subtasks)
• Use database to output guesses about radio service depending on estimated parameters

Prerequisities

Knowledge of C++ and Python as well as strong signal processing and communications engineering background. Depending on the direction of the extension, AMC and/or ML background needed. Also, signal intelligence experience is a plus.

Outcome

We rely on the students to pick out a set of tasks that consistently extends gr-inspector and is managable to be implemented in 3 months. All work will be merged into master branch by the end of GSoC.

Mentor(s)

Sebastian Müller, Sebastian Koslowski

Others

Improve PyBOMBS

PyBOMBS is a meta-package-manager, mainly designed to easily access all of the out-of-tree modules from the GNU Radio ecosystem. It has become its own sub-project out of the GNU Radio community, and is used by a large subset of the GNU Radio community to access GNU Radio modules, and painlessly install GNU Radio and OOTs on different platforms. Cross-compiling, multiple prefixes and recipe databases are features that make PyBOMBS so compelling.

Recently, PyBOMBS 2.0 was developed to replace the rusty codebase from PyBOMBS1. It features a modular design, and is extensible in many directions, including host platforms, fetch mechanisms etc. However, it still lacks a couple of features the original PyBOMBS had. The goal of this project would be to fill those gaps, and further improve PyBOMBS 2.0.

Objectives

PyBOMBS2 has its own issue tracker on https://github.com/gnuradio/pybombs/issues. Main goal of this project would be to close as many issues as possible from this tracker.
A summary of the tasks is as follows:

• Make PB2 feature-complete with comparison to PB1
• Improve the user interface, add a graphical interface
• Improve the experience for different types of users, including groups working in airgapped systems, or behind firewalls
• Add proper archiving capabilities
• Improve collaboration with existing systems/tools, such as Pythons packaging infrastructure, or embedded toolchains such as bitbake, to avoid reinventing the wheel to often

Prerequisites

PyBOMBS is written in Python, and a good understanding of Python is required.

Mentor(s)

Martin Braun

Implement optimized, standardized channel codes

GNU Radio comes with FECAPI and a range of different codes. Most of those codes are very slow and thus aren't usable in real-world applications.

GNU Radio would benefit from standardized convolutional, Turbo, and LDPC codes. Encoders and decoders should achieve a throughput well above 1 Mbit/s and strive for more than 10 Mbit/s. Modern CPU's should achieve this kind of speed on even a single thread. Fast codes would allow GNU Radio users to integrate FEC into their flowgraphs without adding a huge bottleneck.

Similarly, many standards and signals reuse similar values and structures of FEC codes. GNU Radio should support these where possible, even to the point of over-optimizing for some subsets of well-known and heavily used codes. The current convolutional encoder is highly optimized for the Voyager code (rate 1/2, K=7), for example.

Objectives

Choose a code of interest.

• Evaluate standardized codes (e.g., LDPC for WiMAX/10GE, LTE Turbo code, etc.).
• Provide python test code. This can be done generically, but it helps others to improve on the C++ code.
• Implement the encoders and decoders as FEC API variables.
• Optimize codes in terms of data type, algorithmic simplifications, etc.
• Make use of VOLK and optimize encoder and decoder.

Outcome

At least one standard code would be implemented completely and optimized for speed.

Prerequisites

Prior C++ experience is certainly a big advantage here. Also knowledge about the code that should be implemented. Prior experience with SIMD programming might also be helpful.

Mentor(s)

Jan Krämer, Sebastian Koslowski, Johannes Demel

Speed Optimization and Application for ATSC Receivers

We have recently updated our ATSC receiver code with a more modern approach to using GNU Radio. As part of our gr-dtv component, we now have single, simpler to use flowgraphs for demodulating ATSC signals and producing MPEG files from. One flowgraph reads in an already-captured file and demodulates it offline while another uses a USRP source block to pull in the signal over the air and demodulate it in real-time. We have seen real-time demodulation done in real-time on a very capable server, but less capable desktops and laptops still struggle with the amount of work necessary. Currently, the ATSC code has not made significant use of the VOLK library, and so there are a number of areas that could provide dramatic improvement in speed if implemented properly in VOLK. The main area that looks promising is the multiple parallel Viterbi decoders. The bit stream is demuxed into multiple streams and each stream is run through a Viterbi decoder. We should be able to implement the demux and Viterbi algorithms in VOLK, which could lead to significant improvements in the runtime speed of full demod chain.

gr-perf-monitorx graph of the ATSC demod chain

We would also like a better graphical user interface for the ATSC receiver with support for adjusting parameters like gain, frequency, and possible other ways to modify and adjust the running system. We have an example within GNU Radio that provides performance feedback about the ATSC demodulator that shows the equalizer taps and bit error rate estimates from the FEC blocks.

Objectives

• Implement the demux and Viterbi algorithms in VOLK and test speed improvements.
• Find other areas of high computational issues and see how to address.
• Document the process of using performance measurement tools (like gr-perf-monitorx, perf, etc.) used in the study to lead to a model for doing similar work in other areas.
• Improve the diagnostic tool for ATSC receiver performance. Add a user control interface for changing channels/stations and other radio parameters.

Prerequisites

A good understanding C/C++ programming. Knowledge of SIMD.

Mentor(s)

Johnathan Corgan, Nathan West, Andy Walls

Offline Analysis and Visualization Tools

GNU Radio provides a small set of command-line tools for plotting files saved to disk. These programs read in one of more data files with some parameters, such as where in the file to start, how much to plot, and other things like the sample rate of the signal. Each tool is specific to plot type (e.g., spectrogram, PSD, constellation, etc.) and data type (e.g., complex or float). Within these tools, we provide some amount of configuration for adjusting the graph look and feel. The tools need quite a lot of work to be usable more easily and with more features.

• Tabbed to display signal in multiple domains in the same application.
• Support for applying basic math operations (e.g., scaling and raising the signal to a power) and filtering (e.g., applying a low pass filter).
• More feedback and point-and-click features.
• Send-to-flowgraph feature (i.e. integration with our streaming architecture)

Any GUI solution that we'll add to GNU Radio must be written in QT, including this.

Prerequisites

Some familiarity with QT is advantageous. These tools can be written in either Python or C++, so familiarity with either one of those languages is essential. Basic DSP knowledge.

Mentor(s)

Tim O'Shea, Johannes Demel

Ham / Amateur Radio Transceiver

Students applying for this project are invited to submit two applications, one under the GNU Radio project and another under the Debian Project

The aim of this project is to make ready-to-run solutions for ham radio enthusiasts.

The typical use case is a ham who has a spare computer in his shack, he should be able to boot the computer from DVD or USB stick using the Debian Ham Radio Live Blend or the GNU Radio Live SDR and have a functional transceiver within a few minutes.

A student may not be able to do everything required for this project in one summer. We are looking for a student who can make any incremental improvement to bring us closer to this goal.

Here are some of the tasks that may be involved:

• survey the existing GNU Radio samples for ham radio, many are listed on the HamRadio page of this wiki.
• design user interface improvements for the samples to make them more intuitive to new users and traditional radio operators. Consider how they can interact with Hardware such as a VFO tuning knob, PTT microphone switch and even a morse key
• look through the other packages in the Debian Ham Radio metapackage list and consider how they could interact with GNU Radio. In particular, we are interested in the use of message bus solutions, such as ZeroMQ or D-Bus - for example, GNU Radio could send alerts on the bus when incoming signals exceed the squelch threshold. GNU Radio could also receive events over a message bus, for example, patching "gpredict"http://gpredict.oz9aec.net/ to send Doppler shift information.
• developing and packaging libraries needed to process digital voice transmissions
• look at how one or more of the samples can be deployed as a Debian package so users can just install the package and have a working radio

Prerequisites

The following experience is highly desirable:

• ham radio license
• GNU/Linux skills (Debian or Ubuntu)
• use of version control systems (Git)
• C++ or Python or both

Mentor(s)

• Daniel Pocock (VK3TQR/M0GLR/HB9FZT)

GNU Radio NCurses Support

Currently GNU Radio Companion, Control Port Monitor, Profiling tools, gr-qtgui and gr-qxgui plotters all require X windows and rely on either WX or Qt widgets underneath. However numerous radio systems are deployed and remotely managed over SSH and low bandwidth or high latency links. For this rason it would be a massive benefit to have NCurses style console tools for building and running flowgraphs, and inspecting output data streams and intermediate flowgraph values.

Prerequisites

Plotting widgets are generally written in C++, while GNU Radio Companion and most of the remote diagnostic GUIs are written in python, proficiency in both of these languages is ideal. Basic understanding of how GNU Radio and GRC is also required, but may be obtained in the ramp-up phase.

Outcome

Develop console based GRC and plotting widgets or other tools that allow for remote development, modification, introspection, or analysis on GNU Radio flowgraphs without the need for typical windowing packages requiring X-Windows.

Mentor(s)

Martin Braun

GNU Radio Android Apps

GNU Radio will be releasing patches and instructions for building GNU Radio apps for use on Android. The model uses the Android NDK and Java Native Interface (JNI) to write a GNU Radio flowgraph in C++ with blocks for I/O to the Android hardware (sensors and audio system), radios, and the Java application. With this, we can easily develop and port many of our flowgraphs to Android systems. Since Android and the systems that use Android tend to have high-resolution, touch-screen interfaces, we would like to see how we can build better applications that interact with the underlying flowgraph and present an interesting, easy to use, and useful user interface.

Objectives

• Build a user interface to control a radio frontend and provide displays of the data in various domains.
• Take an existing GNU Radio project and adapt it for Android
  • One possible app is gr-air-modes

Potential mentor(s)

Tom Rondeau

Synthetic-Aperture Radar and/or MIMO-Extension for gr-radar

Synthetic-Aperture Radar is a technique to increase the aperture (and hence imaging quality) of radars by performing multiple measurements at different positions. gr-radar is a radar toolbox for GNU Radio which currently implements mostly single-antenna and single-measurement techniques (some extensions for MIMO are already there, but it's pretty basic).

Objectives

Extend the gr-radar OOT with SAR capabilities. Design and run experiments that show how this is used in real life.

Potential mentor(s)

Martin Braun

POLAR-Codes Implementation for gr-fec

Polar codes are a fairly recent breakthrough in code design, being the first channel codes to both provably reach the channel capacity under some assumptions and be of reasonable computational complexity.

Objectives

Any channel codes to be added to GNU Radio need to work with the gr-fec framework, and these are no exception. The scope of this project would be to implement the polar codes, and set up tests to demonstrate how well they work, but also benchmarks to gauge their computational burden.
If need be, individual operations of the en- and decoding steps shall be factored out to VOLK kernels.

Potential mentor(s)

tbd

DECT Tools

Details: DECT is a standard used to connect wireless phones to basestations (for landline operation). DECT for GNU Radio has been attempted before , 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:

• Create a new OOT (gr-dect)
• 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

GRC Improvements

An eternal point on this list -- and still, there's so, so much to be done. Why not join the QT/GRC team this summer?

There's a long list of items to be done here; the exact details need to be arranged with the GRC Working Group on a short notice, due to the high-paced development we currently have there. Here's a non-exhaustive list of items that need to be addressed:

• Better graphics export (SVG)
• GUI builder
• C++ support
• On-canvas notes and annotations
• Multi-layer flow graphs
• Multi-page flow graphs
• Easier access to verbosity levels
• Faster iteration dev cycles for OOTs
• Editable Python blocks

Skills required: Python, Good feel for UIs (and UX)

SigInt Functionality

This would be a meta-project with the goal to tie together project (and add some own functions) for a basic SIGINT monitoring station. Such a system would be able to automatically detect signals, attempt to demod and receive them, etc.
The actual DSP required is immense, and not feasible for this project. However, a GUI shall be provided with the ability to link in components which are able to do these things and connect them.

In order to pass, a working demo of some kind shall be made available at GRCon'15.

Objectives

• Develop a GUI that ties to together visualization tools for signal analysis
• Create a working demo
• Demonstrate at least an energy-based detection and decoding of a typical simple wireless protocol (e.g. HF comms)

Skills required: Wireless Comms, C++, Python, GUI/QT development

GNU Radio packet radio (gr-gdtp)

Packet radio is still a niche in GNU Radio at the moment. Therefore, it'd be interesting to extend support for it and add more applications that make use of it.

Libgdtp is a new library written in C++ that combines a number of features such as framing, ARQ, scheduling, multiplexing, addressing, etc. The library will be released soon and a GR OOT module is on its way too that uses the library. One goal of libgdtp is to allow the user to specify certain communication requirements such as the level of reliability or minimum throughput on a per-application basis. The protocol would then try to accommodate the user requirements such that these requirements are fulfilled if possible.
The library has been developed as a research project and still misses a number of features that would make it more powerful including more advanced ARQ mechanisms or frame schedulers. The goal of this GSoC work item is to enhance it towards this direction.

Objectives

• Improve OOT module
• Improve library interface
• Improve GRC support
• Implement advanced ARQ mechanisms such as Goback-N or selective repeat
• Implement advanced scheduling algorithms such as Token-bucket scheduling

Skills required

• C++, Python
• Communication protocols

Potential mentor(s)

Andre Puschmann

Industry standard channel decoders for gr-fec

The interest in using industry standard channel encoders and decoders in software stacks is ever growing. The goal of this project is to enhance gr-fec and add some of the most commonly used codes. Examples for these codes are the codes used in LTE, UMTS, IEEE 802.11 (Wifi), DVB-RCS1/2 and the codes NASA is using for their deep space probes (Cassini, Pathfinder). Because the codes to be implemented are specific ones, they can be vastly optimised using SIMD instructions to maximize the throughput. SIMD Kernels then can be added to VOLK and used in gr-fec.

Objectives

• Implement standard codes in gr-fec
• Optimise implementations using SIMD instructions

Skills required

• C/C++, Python
• SIMD
• Channel encoding/decoding

Potential mentor(s)

tbd

These ideas for projects did not find a student in previous SoCs. The project ideas are left in here for archaeological purposes and future reference.

Signal Processing

Vector Network analyzer

With SDR than can transmit and receive and even receive several channels in a coherent way, this opens up the possibility to implement a VNA :

http://en.wikipedia.org/wiki/Network_analyzer_%28electrical%29

Objectives

Create an GNU Radio application that perform a sweep of a DUT and outputs its S11/S12/S21/S22 curves (or a subset of those, depends on available HW and connections).
That application should be able to perform calibration sweeps (open/short/thru). It should also try to minimize the impact of any hardware limitations (like DC offset / LO leakage / dynamic range limitations / tuning delay). It should ideally support real-time display (to help tuning antennas / filters for instance).

Caveat

Might require access to some specific RF hardware depending on the chosen architecture (things like B210, directional couplers, or RF switches, ...). We might be able to supply some of these.

Potential mentor(s)

Sylvain Munaut

Wireless Networks In-the-Loop

The basic idea behind "Wireless Networks In-the-Loop" (WiNeLo) is to build a GR-based network emulator. This implies the modeling of the underlying SDR hardware, the individual channels & interference characteristics, as well as the timing behavior (produce correct amount of noise samples if no node is transmitting). The project already started in 2011 and as a outcome, the basic functionality -- the framework with client-server based "sample dispatcher" as well as some example hardware & channel models -- has already been implemented in the gr-winelo OOT, which will be published on github soon. See [[1]] for a quick introduction to "Wireless Networks In-the-Loop".

Objectives

There are various tasks covering several areas. Possible (sub-)projects are:

• (Signal Processing) Implementation of new hardware/channel models like a SDR platform/specific daughterboards or reference channels.
• (Optimization & Performance) Improve performance of existing implementation (port python code to C/C++, develop new mechanisms to collect & distribute samples between several nodes).
• (Signal Processing & Development Tools) Implementation of new development tools like "breakpoints on the air link" (pause the entire emulation if certain criteria (BER, SNR, interference/collisions) is fulfilled on the virtual channel/at single nodes).

Potential mentor(s)

Nico Otterbach

MIMO transceiver

MIMO is a great technology which utilizes multiple antennas at both transmitter and receiver to improve communication performance. With the advent of gigabit level wireless network, MIMO becomes more prevalent now. Although there are many works on MIMO in GNU Radio, those works are choosy in terms of the application context and the hardware used. Also, MIMO is not a standard application in GNU Radio yet. This project aims at creating an OOT module (gr-mimo) that implements the basic encoding and decoding algorithms and allow GNU Radio beginners to enjoy the benefits MIMO brings.

Objectives

• Build a MIMO transceiver with 2 antennas, this transceiver can support concurrent transmission based on OFDM PHY.
• Implement the MRC decoding algorithm at the MIMO transceiver, upon receiving the frames, the transceiver combines the two streams of symbols and utilizes MRC decoding to decode them.
• Implement the Beamforming encoding algorithm at the MIMO transceiver, by precoding the signals, the MIMO transceiver should be able to broadcast two different frames simultaneously.

Requirements

Understanding of OFDM and MIMO. Algorithms would be coded in both C++ and Python.

Potential mentor(s)

Micheal Dickens

Advanced Signal Visualization and Analysis

Interest in Software-Defined Radio (SDR) is intensifying in the hacker community. Software for locating, visualizing, and dissecting unknown target signals is lacking at present. I propose creating an open framework for viewing wideband signal captures, identifying and extracting interesting features, and analyzing those features to obtain the data within.

Objectives

• Display simultaneous spectrogram and time-domain views of a captured signal.
• Ability to select regions of the frequency- or time-domain view for deeper analysis. This includes support for 2D selection within the spectrogram to eliminate signals outside the frequency range of interest.
• Demodulation view, showing the selected signal's instantaneous amplitude, frequency, and other characteristics.
• Signal analysis, allowing symbol filters to be applied to the target signal.
• Symbol filter processing options to combine the symbol filter outputs into a symbol stream suitable for clock and symbol recovery.
• Clock recovery view which allows manual grid placement of symbol timing, or application of algorithmic clock recovery.
• Recovered bits output.
• GNU Radio flow graph generation from the symbol and clock recovery parameters.
• Analyze the entire capture file (or another capture file) using the obtained parameters.
• Statistical analysis of bits recovered candidate data from the analysis, to identify likely packet length(s), preamble/access code/header/ID) fields, CRC/checksum field, and data field boundaries.

I have already done some preliminary work on this, including:

• Identification of signals against the noise floor.
• ASK/OOK and FSK demodulation algorithms with tweak-able parameters.
• Somewhat successful attempts at identifying modulation characteristics.
• Heuristics and techniques for identifying bit encoding (e.g. Manchester vs. differential Manchester), data field delineation, CRC vs. checksums vs. parity vs. check fields.
• Viewing and zooming of spectrograms of large capture files.

Requirements

Experience with Python and/or C.

Potential mentor(s)

Jared Boone

Optimization and Performance

Integration of OpenAirInterface LTE software modem blocks into VOLK

OpenAirInterface (www.openairinterface.org) is open-source project created and maintained by Eurecom (www.eurecom.fr). It features an open-source software modem for LTE (both UE and eNB) entirely written in C. This software modem uses highly optimized SIMD kernles and is performant enought to run a 20MHz eNB on a dual-core off-the shelf x86 PC. The goal of this project is to integrate some of the building blocks of this software modem such as the FFTs or the channel codes into the VOLK framework of GNURadio.

Project Goals: The project should integrate the following blocks from OpenAirInterface into VOLK:

• Turbo channel coder and decoder
  
• Viterbi channel coder and decoder
  

Functional tests and benchmarking of the above block should be performed as well

Requirements: The student should have good knowledge in C (for OpenAirInterface) and C++ (for VOLK) as well as basic knowledge of channel coding and SIMD processing.

Potential Mentors: Nathan West (for support with VOLK), Florian Kaltenberger and Raymond Knopp (for support with OpenAirInterface)

Automatic Filter Optimization

In SDR and signal processing, filtering is one of the most fundamentally important tools. We use them to filter out interfering signals and noise, shape signals properties, and perform rate conversions. And since a filter performs convolution, it is very easy to turn the filter around to also perform correlations. In many cases, a filter may be the first thing add to your flowgraph when building a GNU Radio application.

Filter styles and implementations come in different forms, though we'll stick to those available in GNU Radio right now. The filters themselves can be finite impulse response (FIR) or infinite impulse response (IIR). While IIR filters tend to allow us to use fewer taps, which reduces the computational demands of the filter, they suffer from stability guarantees in the design and non-constant group delay and non-linear phase in the passband. FIR filters are typically slower conceptually because of the larger numbers of taps used but have better characteristics with regards to stability and passband properties. It's important to understand that a filter tap is a coefficient that adds another multiply and add operation to the convolution process.

The other aspect of FIR filters that makes them attractive to software radio is that the calculations can be easily parallelized and pipelined. IIR filters have a feedback path, making these concepts, while not impossible, much harder. And finally, FIR filters benefit greatly from the concept of fast convolution, which states that convolution in time is multiplication in frequency. Using FFTs, we can move into the frequency domain, perform the filtering operation there, and then move back to the time domain. There is a trade-off here where at some number of taps the FFT methods (using O (nlogn)) perform faster than doing straight time convolution. The trade-off is partially algorithmic and partially implementation and architecture specific. In GNU Radio, we find using AVX SIMD optimizations, we have a cross-over point of ~10 taps, after which using the FFT method is faster. On a non-AVX Intel box, we found that this cross-over point is closer to ~22 taps. The following figure shows the trade-off space for one particular machine this test was run on for complex samples with complex taps:

We would like to better understand this trade-off space for different processors and processor architectures (i.e., various generations and styles of Intel chips, ARM chips, etc). From here, we can look to have a meta-filter structure that selects the best type of filter for us depending on the given machine and filter size.

Thanks to Marcus Leech for suggesting this on IRC.

Primary objective

Benchmark and profile existing filter structures in GNU Radio and make results available on stats.gnuradio.org. The filter structures considered are: gr::filter::fir_filter_XXX, gr::filter::fft_filter_XXX, gr::filter::pfb_channelizer_ccf, gr::filter::pfb_synthesizer_ccf, gr::filter::pfb_decimator_ccf, and gr::filter::pfb_interpolator_ccf.

Because of our interest in the performance on various processors, we want to create a benchmarking script that can be run by others in the community on various machines. This would preferably become a part of the gr-benchmark project, which already provides both structure and support for important pieces of the data collection.

Based on the results of the benchmarks, the project goal is to create code that uses the benchmarking information to select the best filter implementation to use for a given task.

Secondary Objective

Use the profiling of the filter blocks to identify specific problem areas in the implementation of the different filter blocks and work to correct them. In particular, a work-in-progress (that will be published before the summer of code begins) is to allow us to use either FIR or FFT filters in the polyphase filterbank (PFB) blocks. Understanding the trade-off and the implementation issues involved here would help these blocks greatly.

Tertiary Objective

Implement other filter design routines that minimize the number of taps for a given bandwidth, transition band, stop-band attenuation, etc. GNU Radio currently designs symmetric filters using either windows (in gr::filter::firdes) or the Parks-McClellen algorithm (Python-only in gr.filter.optfir). There are other filter design techniques for FIR filters that make non-symmetric but minimal tap filters, which can reduce the filter's group delay but may also affect the linearity of the phase. Implementing some of these filter design techniques can improve filter performance by reducing the total number of taps.

Requirements

This project requires a good understanding of C++ and a decent understanding of Python. A background in signal processing is helpful, but there are many text and reference code already available to learn what would be required here. The student must show a good understanding of data analysis and presentation, which we will use to decide how to enable the optimizations and improvements necessary. The student must also communicate with the community on both the mailing list and the IRC channel (#gnuradio).

This project does not require access to radio hardware. Instead, we are most interested in behavior of the filters on different processors and architectures, including Intel and ARM chips. Access to ARM-based systems and SDKs will be made available to the student for remote login.

Potential Mentor(s)

Tom Rondeau

GRC and Development Tools

Remote deployment and control of flow graphs from within GRC

Users might want to run flow graphs on an embedded device or a distant machine. Currently in order to do this they will have to turn their GRC generated flowgraph into a Python file and transport it to the remote machine via scp. With control port we already have a way to remotely interact with flow graphs; however, remote deployment of a flowgraph is currently not possible. This could be achieved by using, e.g., python-execnet and a new "Generate" option. As for remote control/monitoring, a new component or OOT-module "gr-htmlgui" might be a flexible solution.

Requirements:

Although most of the parts for this are already scattered over GNU Radio, the student should be comfortable in reading and writing (!) (simple) network code in Python and (or) C++.

Primary Goal:

Allow for remote control and execution of GNU Radio applications by extending control port.

Potential Mentor(s):

Moritz Fischer, Sebastian Koslowski

GNU Radio Companion improvements

GNU Radio Companion is the most prominent part of GNU Radio, and continuing to improve the GUI and the workflow is a never-ending story. We have a list of improvements we want to have at our GRC roadmap.

Objective

Add new features and improve existing ones. This includes for example new/extended methods to handle blocks within (large) flow graphs like an automated bootstrapping/update of hierarchical blocks, visual grouping of helper blocks (like imports, params) and a parameter dialog with tabs.

Requirements

A decent understanding of Python is required and some user-level experience with GRC is helpful.

Potential Mentor(s)

Sebastian Koslowski

QT and Python3 port of the GNU Radio Companion

GNU Radio companion is a graphical tool to generate flowgraphs and therefore probably the most prominent part of GNU Radio. It is written in Python2 using GTK for the GUI and Cheetah to generate the flowgraphs. As GNU Radio is trying to move more and more stuff to QT and also make the jump to Python3 (compatibility) at some point, porting GRC is an ongoing project.

Objective

Help to port GUI of GRC to QT.

Secondary Objective

Port the code to Python3 and find a suitable replacement for Cheetah.

Requirements

A decent understanding of Python and QT are required.

Potential Mentor(s)

Sebastian Koslowski

Improve PyBombs

To find out more about PyBombs, see http://gnuradio.org/pybombs.

Objectives

Possible goals are:

• Develop documentation and tutorials
• Improve UI
• Improve app store
• Integrate with CGRAN
• Test on additional operating systems and software configurations
• Develop automated test build systems to verify the working state of development branches of all packages, these could be then exported to the CGRAN website

Potential mentor(s)

Tim O'Shea

Measurement Toolbox

As being widely used in the scientific area, an often recurring task when working with GR is measuring. The idea is to design and implement a new "gr-measurement" or "gr-sensornet" toolbox. Central aspects are "automation" and "centralization".

Objectives

Possible (sub-)projects are:

• Implementation of a distributed measurement tool Start flowgraphs on different hardware platforms (see also project idea "Remote deployment and control of flow graphs from within GRC"), collect measured samples or post-processed data from every platform after running the measurement & store the measurement with the appropriate tags in a "central measurement database", (create a nice-looking GUI).
• Development and implementation of methods for synchronized distributed measurements (GPS, NTP, ...) - allow synchronized measurements at different locations, e.g. simultaneous spectrum observation at different locations.

Potential mentor(s)

Nico Otterbach

Network Coding Toolbox

Network coding is a theoretical field of research which is slowly starting to become more attractive for experiments. Actually building a network which uses network coding would be an interesting showcase for GNU Radio capabilities which appeared in the last two years.

Objectives

Implement some of the most commonly known network coding algorithms and verify them over the air.

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.

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.