Google Summer of Code (GSoC)¶
GSoC is a Google-sponsored event to get students involved in Open Source projects (Website). GNURadio has participated in GSoC 2012 and 2013, and is now preparing applications for GSoC 2014.
- Google Summer of Code (GSoC)
- List of ideas
- Signal Processing
- Optimization and Performance
- GRC and Development Tools
- Old GSoC ideas
- Network Coding Toolbox
- Improved support for many-core floating-point accelerators
- 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)
- Turbo Equalizer (first proposed: 2013)
- List of ideas
List of ideas¶
This is the list of project ideas for GSoC 2014 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 merely meant as an inspiration for you to write your own proposal.
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The 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.
GSM analysis tool (replacement for airprobe)¶
Airprobe is a tool that was used to analyse GSM signals a while back. It no longer works with current GNU Radio versions, and doesn't make use of any of the new GNU Radio features. A modular rewrite would make a great out-of-tree module (gr-gsm). While this seems a daunting task, there are already many building blocks available which can be used (of course giving the original authors credit where due!).
Create an OOT module which decodes GSM signals. Real-time capabilities would be nice.
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.
Create an OOT module (gr-radar); implement and experimentally verify them.
Algorithms that could be implemented include:
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.
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 :
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).
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.
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 http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm for a quick introdcution 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).
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.
- 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.
Understanding of OFDM and MIMO. Algorithms would be coded in both C++ and Python.
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.
- 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.
Experience with Python and/or C.
Optimization and Performance¶
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.
Potential Mentor(s): Nathan West
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 or infinite impulse response. 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.
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.
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 GSoC 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.
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.
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.
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 (http://gnuradio.org/redmine/projects/gnuradio/wiki/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.
Improve the current state if the art of GNU Radio integration with hardware accelerators.
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.
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.
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.
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.
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.
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).
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.
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++.
Allow for remote control and execution of GNU Radio applications by extending control port.
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.
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.
A decent understanding of Python is required and some user-level experience with GRC is helpful.
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.
Help to port GUI of GRC to QT.
Port the code to Python3 and find a suitable replacement for Cheetah.
A decent understanding of Python and QT are required.
To find out more about PyBombs, see http://gnuradio.org/pybombs.
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
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.
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.
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.
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.
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.
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.
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
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
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).
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
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
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)