https://wiki.gnuradio.org/api.php?action=feedcontributions&user=Haakov&feedformat=atomGNU Radio - User contributions [en]2024-03-29T15:38:13ZUser contributionsMediaWiki 1.39.5https://wiki.gnuradio.org/index.php?title=GSoCStudentInfo&diff=13792GSoCStudentInfo2024-03-20T20:36:24Z<p>Haakov: /* Schedule */</p>
<hr />
<div>= GSoC - Information for students =<br />
<br />
Here's the most important steps of applying for GSoC with GNU Radio:<br />
<br />
* Read this '''entire''' page before submitting applications. We will not consider your application otherwise.<br />
* Read Google's [https://developers.google.com/open-source/gsoc/faq FAQ]<br />
* Take a look at our [[GSoCIdeas|list of ideas]]<br />
* Come up with project that you're interested in (be it on the list or not!)<br />
* Write a first draft proposal and get someone to review it for you (perhaps one of the mentors)<br />
* Submit it using Google's web interface<br />
* '''Important: Make sure you have followed all the instructions on this page. Failing to do so will cause us to ignore your proposal, as we usually have many more applicants than we have slots!'''<br />
<br />
For accepted students, we have guidelines in place for during GSoC, see our [[GSoCManifest|rules of conduct]] page.<br />
<br />
== Student/Contributor Eligibility ==<br />
<br />
'''This year (2022), participants no longer need to be enrolled at a university to be eligible for GSoC.'''<br />
<br />
The formal requirements are that you:<br />
<br />
* must be at least 18 years old at time of registration.<br />
* must be an open source beginner.<br />
* must be eligible to work in your country of residence during the duration of program.<br />
* must be a resident of a country not currently embargoed by the United States.<br />
<br />
== The Project ==<br />
<br />
Choose a project that suits you. We have project ideas on our GSoC page you can choose from, but you can also submit your own ideas. If you do so, tell us early enough about that! It is also OK to use the ideas as a rough guideline for your project, but to vary from that.<br />
<br />
Note that if you submit your own idea, even if it's awesome, there might be no mentor who has the technical know-how to supervise that, or simply no-one who want to supervise that specific project. If you post your idea early enough, this is usually not a problem, though.<br />
<br />
Whatever you do, it is very important that you understand the project you'll be working on. Proving that you understand the problem is basically the first hurdle for you to get our attention.<br />
<br />
You can submit several applications for GNU Radio, so if there are several projects you feel like doing, submit one for each project. Time has shown that it's usually better to eventually focus on one proposal, because it's already quite some work to get one excellent proposal finished.<br />
<br />
== The Proposal ==<br />
<br />
The proposal, which you submit to the GSoC page, is the single most important part of your application.<br /><br />
In the time before the proposal submission, you should contact the GNU Radio mailing list.<br /><br />
The mentors (and other community members) will give you some feedback on your proposal, but that does mean you have to have to actually write a proposal on which you can get feedback.<br />
<br />
It might seem odd to publically announce an unfinished proposal. You might be concerned that other students will read and copy your proposal. However, in the past, that has never happened. Students who submit early, and gather feedback, have always been the most successful students. We recommend having a proposal e.g. as a Google doc, or on an site like github, and treat it like open source software. Experience has shown that your chances are better if you start early with a '''publicly available proposal''' than developing your proposal trying to do it in private.<br />
<br />
An example of a successful proposal from 2012 can be [https://github.com/zeroXzero/gsoc_proposals/blob/master/filter_enhancements.pdf?raw=true found here (filter design)].<br />
<br />
The following things '''must''' be in the proposal, or it is considered incomplete and will not be considered for acceptance! We will simply mark your proposal as 'incomplete' and ignore communications from you.<br />
<br />
=== Topic background ===<br />
<br />
If there's any theory necessary for your project, include some pointers and explain the basics. Prove to us that you know what you're talking about.<br />
<br />
Something like this is good:<br />
<br />
> Herring-Codes were initially proposed in the seminal paper "Herring-Codes in a fishy radio environment" [1]. They are based on the mathematical theory that...<br />
<br />
Also, you should start getting a good idea about what's available in GNU Radio and other projects. This means you should have a look at the source code of GNU Radio. Here's an idea:<br />
<br />
> In GNU Radio, there are codes available in the component <code>gr-fec</code>. Having looked at the available blocks, it is clear that the available blocks in <code>gr-fec</code>, such as the ccsds_27_bb blocks, cannot trivially be modified to include Herring-Codes. It therefore makes sense to add these to GNU Radio.<br />
<br />
One major difference between some free software projects and GNU Radio is that the required technical background can be quite daunting, up to a point where some GSoC projects can't possibly be worked upon by people without a communications engineering background. However, we try to make GSoC accessible to all clever students, and have a variety of topics available.<br />
<br />
Important: This is the summer of code, '''not the summer of research'''! Your first goal must be coded deliverables. If it is possible to get some research done at the same time, or even write a paper on the subject, that's fantastic. But don't forget the code!<br />
<br />
=== The Deliverables ===<br />
<br />
Inside the proposal, your deliverables are the most important thing.<br /><br />
Clearly outline what you are planning to code, including the platform (host or USRP?) and the programming language (VHDL, C++, Python?).<br /><br />
Don't be vague! The following is not a good deliverable:<br />
<br />
* Deliverable 1: Include Herring-Codes in GNU Radio<br />
<br />
Rather, write it like this:<br />
<br />
* Deliverable 0: Create on out-of-tree module for Herring codes (<code>gr-herring</code>), using gr-modtool.<br />
* Deliverable 1: Add blocks for Herring codes (written in C++). This will require two blocks (<code>herring_X</code> and <code>herring_Y</code>), with the specs shown in Fig Z.<br />
<br />
Also, write what you're not doing if it's not explicitly clear. Something like this would be OK:<br />
<br />
* Often, Herring-Codes are mentioned in connection with Trout-Codes. These will not be included in <code>gr-herring</code>.<br />
<br />
=== License ===<br />
<br />
In most cases, the code submitted must be GPLv3 licensed. In most cases, there is no choice about this (e.g., if you are adding to the GNU Radio main tree, or writing typical OOT-modules). If you want to use another license, do tell us and lay out the reasons. In any case, specify the licence you will be using. This also shows us you care about free software licences and know a bit about them.<br />
<br />
=== Schedule ===<br />
<br />
Check the schedule on the GSoC website. Then figure out how you want to spend the time allocated to coding. Again, be specific - this shows us that you've put some thought into planning your summer. Of course we are aware that plans often need to be changed, so the schedule is of course changeable during the course of GSoC (in coordination with your mentor!).<br />
<br />
Don't forget to include time to write documentation, add QA codes and, most importantly, fix bugs! Don't leave docs etc. for the end.<br />
<br />
Other things to include:<br />
<br />
* How many hours per week are you planning to code? Be honest, and don't forget: we expect you to work full-time on this.<br />
* Is there a period where you won't be coding? During 3 months, it is not unreasonable to have a week 'off' for whatever reason, be it exams or other issues. Just be honest about this, and tell us beforehand.<br />
* Do you have other commitments during the summer that will take time away from coding? Tell us about that!<br />
* How many hours in total (90, 175 or 350) is your project?<br />
* How long is your coding period? It can be anywhere from 10 to 22 weeks. This number can be changed during the coding period, so don't worry too much about it, but you still need to include an estimate in your proposal.<br />
<br />
=== Proof of your coding capabilities / prerequisite capabilities ===<br />
<br />
Despite having close contact with your mentor, it will not be possible to work on a project if you're not already capable of writing code. Depending on the project, you will need different skills, typically C++ and/or Python to a good degree, and sometimes other skills, such as DSP, wireless communication, low-level processor architecture, or something like that.<br />
<br />
Make sure your proposal gives us a way of knowing you're capable of doing these things. For code, the best way is to show us to previous projects of yours (e.g., your github page, contributions to other projects, something like that). For more theoretical subjects, a good way is to explain something in your proposal, in your own words.<br />
<br />
=== Formalities ===<br />
<br />
Include these things (again, these are not optional!):<br />
<br />
* Your name, place of residence<br />
* Your university and students status (are you a grad, undergrad... Note that university enrollment is no longer a requirement!)<br />
* Tell us if your GSoC work is in connection with your university work. Are you getting credit for your GSoC project? (None of this affects whether or not you're selected, we're just curious. It still needs to be in your application).<br />
<br />
Of course, check what Google requires you to reveal about yourself.<br />
<br />
Note that the layout, language etc. of the proposal matter. Make it look good, both content-wise and literally.<br />
<br />
=== Background on yourself ===<br />
<br />
Tell us about yourself. In particular we're interested in your coding history. Also, remember that you will be working closely with one of our mentors for three months, so we want to know what it's like working with you. Show us that you're used to working with other people!<br />
<br />
Also, remember that your mentor might be on another continent, speak another language, live in another time zone. How do you propose working with us? Are you on Skype, G+...?<br />
<br />
Most of the time, you will be speaking English with your mentor (you might get lucky and get a mentor that speaks your language, but be prepared to end up with a mentor of another nationality). Is your English good enough? Tell us about that.<br />
<br />
Proof of your technical proficiency is also required. Point us to your github, or '''show us any code you've produced in the past'''! Don't omit any of these questions:<br />
<br />
* Have you participated in an open source project before? If yes, which one? (If not, explicitly say so! A lot of our previous participants have had little experience in the free software world. Be honest!)<br />
* If you have, we'd like to see specific commits and contributions to those projects, please.<br />
* What code have you written? Upload as much as possible to github before applying, so we can have a look. If there's no code at all, we assume you can't code (and won't consider your application).<br />
* Which languages have you mastered so far?<br />
<br />
Finally, we want to know about your relationship to the GNU Radio community, such as<br />
<br />
* Have you participated in GNU Radio before?<br />
* How are you planning to contribute to GNU Radio after GSoC?<br />
<br />
A neat idea on how to present yourself is to upload a video of yourself explaining something.<br />
<br />
=== Acknowledge the three strikes rule ===<br />
<br />
On our [[GSoCManifest|rules of conduct]] page, we have outlined some rules including the three strikes rule. In your application, make a note that you have acknowledged and understood this rule.<br />
<br />
=== The secret code word ===<br />
<br />
Somewhere in your application, include the secret code word: "Cyberspectrum is the best spectrum". We will scan for this code word and simply not read the rest of your application if we can't find it.<br />
<br />
== Being a community member ==<br />
<br />
First of all: You do '''not''' have to be an active developer of GNU Radio to participate! For us, it's just as important to get new people into the project as it is to actually see the projects being coded, maybe more so. Perhaps you just heard about GNU Radio through GSoC? That's fine!<br />
<br />
However, we '''do''' want to get to know you, and see you integrate into our community. So, once you've decided you want to participate in GSoC, definetely sign up to the mailing list (which is the most important hub for the GNU Radio community).<br /><br />
Introduce yourself, tell us you want to participate and tell us about what you want to do.<br />
<br />
Earlier is better than later. The more time you spend on the list, discussing your and other projects, the more familiar you will be with how the community ticks, and we will get to know you better, as well. We try to be objective when grading proposals, but if someone's already made a good impression and we all know she or he writes good code, that definitely counts in your favour.<br />
<br />
== Working with a mentor (before and during GSoC) ==<br />
<br />
Mentors have the biggest say (next to Google) who participates in GSoC, so be nice to them. Also, mentors are volunteers, and don't get paid for GSoC, unlike you (if you're selected). This means they '''won't''' be working full-time mentoring you, so don't expect them to micro-manage your project.<br />
<br />
For this reason, it is important you prove that you're able to work independently and autonomously (if you and your mentor live in different time zones, you might have a call once a week and some chats/emails in between).<br />
<br />
=== Before the summer of code ===<br />
<br />
* Contact the mailing list, ask for feedback on your proposal, become engaged in the community. Don't spam us, that doesn't look good.<br />
* Make sure they know you're serious about GSoC by asking good questions.<br />
* If necessary, brush up your coding skills and play around with GNU Radio.<br />
<br />
=== During GSoC ===<br />
<br />
* Make sure you have regular contact with your mentor.<br />
* We require weekly updates that are publically visible for the entire community. A blog etc. is a good way to do this.<br />
<br />
== How we grade proposals ==<br />
<br />
The following points are considered when grading proposals:<br />
<br />
* How well do we understand what the student exactly is going to do?<br />
* How likely is success with this project?<br />
* How much does GNU Radio benefit from this project?<br />
* What are the chances of the student becoming an active member of the community after GSoC?<br />
<br />
Of course, all the other things on this page must also be considered.<br />
<br />
== GSoC is good for your education! ==<br />
<br />
[[File:gsoc.jpg|250px]]<br />
<br />
To be very clear here: GSoC is '''not''' part of your degree. If you want to apply in order to "clear GSoC" for your curriculum or whatever, go elsewhere. We want people who are actually passionate about this project, and free software. Sure, it will look good on your CV. But that's not a good motivation to apply here.<br />
<br />
That said, GSoC '''will''' make you smarter. And if your university is cooperative, there's no reason for GSoC and your university education to be mutually exclusive. In the past, universities have often supported GSoC students by giving them access to their labs, or even awarding credit for the project. Being a student is no longer a prerequisite to joining GSoC, but if you are, feel free to talk to us about collaborating, and talk to your university advisor if they are willing to give some support.<br />
<br />
== Hints ==<br />
<br />
There are some good hints on some of these pages from other projects:<br />
<br />
* [http://community.kde.org/GSoC#Hints KDE GSoC page]<br />
* [http://www.postgresql.org/developer/summerofcodeadvice/ PostgreSQL GSoC]<br />
* [http://danielpocock.com/getting-selected-for-google-summer-of-code-2015 Want to be selected for GSoC?] (a generic but very thorough guide, not specific to any one organization)<br />
<br />
Some more hints which have come up over the years:<br />
<br />
* People tend to want to do signal processing stuff. We also like project diversity, and your chances will increase if you apply to work in other areas, such as improving user interfaces (if you do that, a lot of people will be affected by your work; they might buy you beers)<br />
* The more we know about you, the better your chances. Make the proposal a personal matter<br />
* Don't forget the secret code word.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=13774GSoCIdeas2024-02-17T12:19:36Z<p>Haakov: /* Graphical interoperability between CyberEther and GNU Radio */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2024 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== Graphical interoperability between CyberEther and GNU Radio ===<br />
<br />
The [https://github.com/luigifcruz/CyberEther CyberEther] project comes with some neat graphical sinks that would be great to have access to in GNU Radio. This project entails creating a new CyberEther GUI workflow much like the [https://github.com/gnuradio/gr-bokehgui gr-bokehgui] project, such that users can create flowgraphs with CyberEther sinks.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and some Python<br />
* Familiarity with graphical APIs (OpenGL, Vulkan, Metal)<br />
* Basic Qt understanding<br />
<br />
'''Outcome'''<br />
<br />
* OOT module with CyberEther sinks<br />
* Support for both GNU Radio main branch and 3.10?<br />
<br />
'''Project length'''<br />
<br />
Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Luigi Cruz, Håkon Vågsether<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
<br />
'''Outcome'''<br />
<br />
Depends on chosen subprojects (see above).<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
=== GRC and GR 4.0 ===<br />
<br />
Development of GR 4.0 is progressing quickly. In the current runtime prototype a plugin architecture is used to properly register blocks with the runtime. <br />
This allows a more dynamic construction of flowgraphs and introspection into the blocks. But this means the current way of assembling a flowgraph by generating a Python or C++ <br />
file needs updates. <br />
<br />
The idea is to port and change necessary parts of GRC (Qt development version) to use the block registry in the new GNU Radio runtime https://github.com/fair-acc/graph-prototype/ and assemble some of the example flowgraphs defined in GRC files and make them run. <br />
The design for this is not finalized and therefore you will have freedom to propose your ideas.<br />
<br />
'''Prerequisites'''<br />
<br />
* Good Knowledge of C++ and Python<br />
* Experience with inter-language bindings (not necessarily C++ & Python) is useful<br />
* Basic Qt understanding<br />
<br />
'''Outcome'''<br />
<br />
* Prototype integration of GRC with the new plugin architecture of GR 4.0<br />
<br />
'''Project length'''<br />
<br />
Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Challenging<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode, Josh Morman<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Outcome'''<br />
<br />
* GRC as a GNU Radio-independent application<br />
* Support for additional workflows in GRC<br />
* Depends on chosen subprojects (see above).<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize in-tree and out-of-tree (OOT) modules ===<br />
<br />
A lot has changed since version 3.7, and GNU Radio has made great technical strides the last few years. However, some OOT modules haven't been updated to support the latest versions of GNU Radio, and these modules currently require the user to install an older version of the framework. This is unfortunate, and lowers the useability of GNU Radio as a whole. Some of these modules have been superseded by others, but might still have some blocks or flowgraphs that are useful, and these could be updated and moved in-tree. Some in-tree modules are also in need of attention, like gr-wavelet, which does not have any examples.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
* Porting various OOT modules to support recent versions of GNU Radio<br />
* Possibly blocks/flowgraphs from old OOT modules moved in-tree<br />
<br />
'''Project length'''<br />
<br />
Small (90 hours) - Medium (175 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Easy - Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
=== Forward Error Correction in GNU Radio === <br />
<br />
Over the years many different forward error correction (FEC) methods ( e.g. Polar Encoder/Decoder, LDPC Encoder/Decoder) have been added to GNU Radio.<br />
In other open-source projects (e.g. Aff3ct, more modern methods and possibly more performant methods have been implemented.<br />
<br />
The goal of this project is to update and possibly overhaul the FEC implementations within GNU Radio. Since there are quite some methods in the wild, <br />
we need to coordinate on which methods and other libraries should be included in the comparison. Same goes for the already available methods for error coding in GNU Radio.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
* Interest in information theory and error coding<br />
* No fear of reading & comparing other implementations<br />
<br />
'''Outcome'''<br />
<br />
* Updated & polished FEC experience in GNU Radio<br />
* Addition of more performant and updated methods for error coding<br />
* Deletion of possibly redundant and inperformant methods<br />
<br />
'''Project length'''<br />
<br />
Medium (175 hours) - Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Medium - Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode, ?<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=13763GSoCIdeas2024-02-12T06:27:15Z<p>Haakov: Add outcomes to GSoC ideas</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2024 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== Graphical interoperability between CyberEther and GNU Radio ===<br />
<br />
The [https://github.com/luigifcruz/CyberEther CyberEther] project comes with some neat graphical sinks that would be great to have access to in GNU Radio. This project entails creating a new CyberEther GUI workflow much like the [https://github.com/gnuradio/gr-bokehgui gr-bokehgui] project, such that users can create flowgraphs with CyberEther sinks.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and some Python<br />
* Familiarity with graphical APIs (i.e. OpenGL, Vulkan, Metal)<br />
* Basic Qt understanding<br />
<br />
'''Outcome'''<br />
<br />
* OOT module with CyberEther sinks<br />
* Support for both GNU Radio main branch and 3.10?<br />
<br />
'''Project length'''<br />
<br />
Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Luigi Cruz, Håkon Vågsether<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
<br />
'''Outcome'''<br />
<br />
Depends on chosen subprojects (see above).<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
=== GRC and GR 4.0 ===<br />
<br />
Development of GR 4.0 is progressing quickly. In the current runtime prototype a plugin architecture is used to properly register blocks with the runtime. <br />
This allows a more dynamic construction of flowgraphs and introspection into the blocks. But this means the current way of assembling a flowgraph by generating a Python or C++ <br />
file needs updates. <br />
<br />
The idea is to port and change necessary parts of GRC (Qt development version/standalone version) https://github.com/haru-02/gnuradio-companion to use the block registry in the new GNU Radio runtime https://github.com/fair-acc/graph-prototype/ and assemble some of the example flowgraphs defined in GRC files and make them run. <br />
The design for this is not finalized and therefore you will have freedom to propose your ideas.<br />
<br />
'''Prerequisites'''<br />
<br />
* Good Knowledge of C++ and Python<br />
* Experience with inter-language bindings (not necessarily C++ & Python) is useful<br />
* Basic Qt understanding<br />
<br />
'''Outcome'''<br />
<br />
* Prototype integration of GRC with the new plugin architecture of GR 4.0<br />
<br />
'''Project length'''<br />
<br />
Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Challenging<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode, Josh Morman<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Outcome'''<br />
<br />
* GRC as a GNU Radio-independent application<br />
* Support for additional workflows in GRC<br />
* Depends on chosen subprojects (see above).<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize in-tree and out-of-tree (OOT) modules ===<br />
<br />
A lot has changed since version 3.7, and GNU Radio has made great technical strides the last few years. However, some OOT modules haven't been updated to support the latest versions of GNU Radio, and these modules currently require the user to install an older version of the framework. This is unfortunate, and lowers the useability of GNU Radio as a whole. Some of these modules have been superseded by others, but might still have some blocks or flowgraphs that are useful, and these could be updated and moved in-tree. Some in-tree modules are also in need of attention, like gr-wavelet, which does not have any examples.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
* Porting various OOT modules to support recent versions of GNU Radio<br />
* Possibly blocks/flowgraphs from old OOT modules moved in-tree<br />
<br />
'''Project length'''<br />
<br />
Small (90 hours) - Medium (175 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Easy - Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
=== Forward Error Correction in GNU Radio === <br />
<br />
Over the years many different forward error correction (FEC) methods ( e.g. Polar Encoder/Decoder, LDPC Encoder/Decoder) have been added to GNU Radio.<br />
In other open-source projects (e.g. Aff3ct, more modern methods and possibly more performant methods have been implemented.<br />
<br />
The goal of this project is to update and possibly overhaul the FEC implementations within GNU Radio. Since there are quite some methods in the wild, <br />
we need to coordinate on which methods and other libraries should be included in the comparison. Same goes for the already available methods for error coding in GNU Radio.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
* Interest in information theory and error coding<br />
* No fear of reading & comparing other implementations<br />
<br />
'''Outcome'''<br />
<br />
* Updated & polished FEC experience in GNU Radio<br />
* Addition of more performant and updated methods for error coding<br />
* Deletion of possibly redundant and inperformant methods<br />
<br />
'''Project length'''<br />
<br />
Medium (175 hours) - Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Medium - Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode, ?<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=13754GSoCIdeas2024-02-06T22:39:33Z<p>Haakov: /* Graphical interoperability between CyberEther and GNU Radio */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2024 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== Graphical interoperability between CyberEther and GNU Radio ===<br />
<br />
The [https://github.com/luigifcruz/CyberEther CyberEther] project comes with some neat graphical sinks that would be great to have access to in GNU Radio. This project entails creating a new CyberEther GUI workflow much like the [https://github.com/gnuradio/gr-bokehgui gr-bokehgui] project, such that users can create flowgraphs with CyberEther sinks.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and some Python<br />
* Familiarity with graphical APIs (i.e. OpenGL, Vulkan, Metal)<br />
* Basic Qt understanding<br />
<br />
'''Project length'''<br />
<br />
Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Luigi Cruz, Håkon Vågsether<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize in-tree and out-of-tree (OOT) modules ===<br />
<br />
A lot has changed since version 3.7, and GNU Radio has made great technical strides the last few years. However, some OOT modules haven't been updated to support the latest versions of GNU Radio, and these modules currently require the user to install an older version of the framework. This is unfortunate, and lowers the useability of GNU Radio as a whole. Some of these modules have been superseded by others, but might still have some blocks or flowgraphs that are useful, and these could be updated and moved in-tree. Some in-tree modules are also in need of attention, like gr-wavelet, which does not have any examples.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
* Porting various OOT modules to support recent versions of GNU Radio<br />
* Possibly blocks/flowgraphs from old OOT modules moved in-tree<br />
<br />
'''Project length'''<br />
<br />
Small (90 hours) - Medium (175 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Easy - Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=13753GSoCIdeas2024-02-06T18:35:20Z<p>Haakov: Add CyberEther GSoC project</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2024 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== Graphical interoperability between CyberEther and GNU Radio ===<br />
<br />
TBA: https://github.com/luigifcruz/CyberEther<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and some Python<br />
* Familiarity with graphical APIs (i.e. OpenGL, Vulkan, Metal)<br />
* Basic Qt understanding<br />
<br />
'''Project length'''<br />
<br />
Long (350 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Luigi Cruz, Håkon Vågsether<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize in-tree and out-of-tree (OOT) modules ===<br />
<br />
A lot has changed since version 3.7, and GNU Radio has made great technical strides the last few years. However, some OOT modules haven't been updated to support the latest versions of GNU Radio, and these modules currently require the user to install an older version of the framework. This is unfortunate, and lowers the useability of GNU Radio as a whole. Some of these modules have been superseded by others, but might still have some blocks or flowgraphs that are useful, and these could be updated and moved in-tree. Some in-tree modules are also in need of attention, like gr-wavelet, which does not have any examples.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
* Porting various OOT modules to support recent versions of GNU Radio<br />
* Possibly blocks/flowgraphs from old OOT modules moved in-tree<br />
<br />
'''Project length'''<br />
<br />
Small (90 hours) - Medium (175 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Easy - Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=13752GSoCIdeas2024-02-06T17:12:37Z<p>Haakov: /* Revitalize old modules */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2024 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize in-tree and out-of-tree (OOT) modules ===<br />
<br />
A lot has changed since version 3.7, and GNU Radio has made great technical strides the last few years. However, some OOT modules haven't been updated to support the latest versions of GNU Radio, and these modules currently require the user to install an older version of the framework. This is unfortunate, and lowers the useability of GNU Radio as a whole. Some of these modules have been superseded by others, but might still have some blocks or flowgraphs that are useful, and these could be updated and moved in-tree. Some in-tree modules are also in need of attention, like gr-wavelet, which does not have any examples.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
* Porting various OOT modules to support recent versions of GNU Radio<br />
* Possibly blocks/flowgraphs from old OOT modules moved in-tree<br />
<br />
'''Project length'''<br />
<br />
Small (90 hours) - Medium (175 hours)<br />
<br />
'''Difficulty'''<br />
<br />
Easy - Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=13749GSoCIdeas2024-02-02T22:43:27Z<p>Haakov: GSoC: 2023 -> 2024</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2024 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize old modules ===<br />
<br />
Some of the in-tree modules are in need of attention. For example, gr-wavelet does not have any examples, and several of the tests in gr-trellis are failing. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=13748GSoCIdeas2024-02-02T22:09:25Z<p>Haakov: GSoC: 2023 -> 2024</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize old modules ===<br />
<br />
Some of the in-tree modules are in need of attention. For example, gr-wavelet does not have any examples, and several of the tests in gr-trellis are failing. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=OldGSoCIdeas&diff=13747OldGSoCIdeas2024-02-02T22:07:50Z<p>Haakov: GSoC: Fix typo</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2023: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize old modules ===<br />
<br />
Some of the in-tree modules are in need of attention. For example, gr-wavelet does not have any examples, and several of the tests in gr-trellis are failing. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
== Summer of Code 2022: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2022 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GNU Radio goes Browser: Web Assembly (WASM) port ===<br />
<br />
<br />
[[File:WASM-preview.jpg|thumb|link=https://mobile.twitter.com/marcnewlin/status/1490577402086313984/photo/1|A view of GRC running on WASM-compiled Python]]<br />
<br />
The main goal of WebAssembly is to enable high-performance applications on web pages. Originally quite restricted to single-threaded applications, only interacting with the browser's notion of the world through a JavaScript interaction layer, today it has become quite capable, with support for threads, exceptions, SIMD and a lot of other performance-critical features.<br />
<br />
Obviously, that's great news! GNU Radio in the Browser means zero-installation, fully portable SDR for the masses. This GSoC project strives to take Marc Newlin's current work and make something functional, with the big goal of having a fully functional GNU Radio on WASM.<br />
<br />
This project has subprojects, from which the student is to pick '''one''':<br />
<br />
* porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted set of intrinsics<br />
* working to bring GRC in the feature-grc-qt branch to parity with GRC in main<br />
* WebUSB driver porting (I have prototyped standalone drivers for UHD, HackRF and PlutoSDR which haven't get been integrated, and then porting gr-osmosdr would be awesome). <br />
* creating blocks for ZMQ over websockets<br />
<br />
in addition to making a (minimal) web page to which the current development state can be tested on, updated automatically from Github.<br />
<br />
'''Steps'''<br />
<br />
* Make (and test!) Marc Newlin's WASM build locally<br />
* Add a CI step to build a WASM binary<br />
* Implement one of the points above<br />
* Implement a suitable demonstration for it and deploy<br />
<br />
'''Prerequisites'''<br />
<br />
* Basic knowledge of Python<br />
* Working (especially, reading) knowledge of C++<br />
* Basic knowledge of WASM <br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marc Newlin<br />
* Marcus Müller<br />
* Depending on topic: further member of the GNU Radio community<br />
<br />
<br />
== Summer of Code 2021: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2021 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
'''The time a student can spend on a GSoC project has been reduced by 50% for 2021 - keep this in mind when submitting your ideas'''<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
=== Standardized High Throughput FEC Codes ===<br />
<br />
Channel coding is essential to modern communications. Also, it is computationally very heavy. As of now, there exist implementations in GNU Radio which are too slow to be integrated into high throughput applications. GNU Radio would benefit from integration of standardized decoders for Turbo and LDPC codes. These codes would only support a certain subset of the whole code class but would be well optimized. <br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.<br />
<br />
'''Outcome'''<br />
<br />
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.<br />
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Johannes Demel<br />
<br />
<br />
=== GRC: View-Only Mode (Secure) ===<br />
<br />
When a flowgraph from an untrusted source is opened if GRC, arbitrary Python code can be executed. This poses a potential security risk. Storing the all evaluated values of all parameters within a flow graph (.grc) file would allow us to open such flow graphs without compromising security. No code would be have to executed to draw the flow graph and block parameters can be viewed safely. Only if the flow graph is modified the user would have to choose to trust the flow graph thus enabling normal eval operations.<br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is implemented using Python. So, Python should be known pretty well.<br />
<br />
'''Outcome'''<br />
<br />
* Safely view other people's flowgraphs without putting your PC at risk.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===<br />
<br />
Even though the 8b10b line coding is primarily used for byte-level synchronization and spectral shaping, it adds some redundancy to the data, so it can be used as a forward error correction method to fix some bit errors in the received data. From the perspective of the decoder there is one bit of hidden state, so 8b10b line coding is amenable to Viterbi decoding, as hinted in [http://www.bigideatrouble.com/AMSAT%202013%20FOX1%20Paper.pdf this document about the AMSAT FOX satellites]. One goal of this project is to create Viterbi decoder block(s) for 8b10b and possibly other similar line codes, so that these blocks can be eventually upstreamed in-tree. The error correction performance of this method will be studied using simulations with these blocks. The second goal is to use the Viterbi decoder and gr-satellites to create a full decoder for the FOX satellites from AMSAT.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python. Some basic understanding about FEC in general.<br />
<br />
'''Outcome'''<br />
<br />
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites<br />
<br />
'''Mentor(s)'''<br />
<br />
* Daniel Estévez<br />
<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput). This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our server, allowing us to crowdsource data. (Similar to our online stats for SIMD performance.)<br />
<br />
'''Outcome'''<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Set up automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web server.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
*Bastian Bloessl<br />
<br />
<br />
== Summer of Code 2020: Project ideas list ==<br />
This is the list of project ideas for the summer of code 2020 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has the hierarchical blocks to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
<br />
=== Qt5 GUI Integrations ===<br />
<br />
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization<br />
<br />
'''Prerequisites'''<br />
<br />
* C++, Python proficiency<br />
* Qt experienced<br />
<br />
'''Outcome'''<br />
<br />
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)<br />
* Possible to import generate Qt GUI description file (UIC) into GRC<br />
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph<br />
* Integration of that into GRC-generated Python code<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Müller & Sebastian "GRC-Man" Koslowski<br />
<br />
<br />
<br />
=== Extending and Updating gr-radar ===<br />
<br />
gr-radar (https://github.com/kit-cel/gr-radar/) was a great and successful GSoC project that provided a few methods of radar in GNU Radio. This module is heavily used by academics, researchers, cybersecurity folks, and hobbyists. This project would work to improve upon the concepts already in there as well as add more radar techniques.<br />
<br />
There are uncountable methods and techniques that could be added to this project, such as:<br />
<br />
* SAR / InSAR methods<br />
* Better passive radar support<br />
* Speed camera applications<br />
* Multi-antenna radar techniques<br />
<br />
'''Prerequisites'''<br />
<br />
* Signal processing and some radar basics are required.<br />
* Code is written in C++ with some Python on the side, so the student must be able to handle these languages at the least.<br />
<br />
'''Outcome'''<br />
<br />
* Based on the student's interest, a subset of the radar techniques listed above (or others) are chosen as milestones for this project. <br />
* All code must be merged back into gr-radar by the end of the summer.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Stefan Wunsch, Martin Braun<br />
<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add new widgets<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C+'', so some C''+ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Tim O'Shea<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Android ===<br />
<br />
One effort of the past years was to improve Android support for GNU Radio. We're getting to a point where we've figured out '''how''' to do it, so the next step is to make it more accessible to users and developers.<br />
<br />
The Android ecosystem is an entirely different beast from the rest of GNU Radio. To make writing Android/GR apps easy, the following needs to happen (and shall be part of this project):<br />
<br />
* Improve support for development environment<br />
** Create Dockers for easy start of development<br />
* Visualization classes for PSD, spectrogram and oscilloscope<br />
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs<br />
* Interactivity concepts<br />
** Gestures and config for radio parameters (e.g., freq, gain, bandwidth)<br />
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures<br />
<br />
You can find a summary of the work that has been done on this (years ago) here: [[Android]]<br />
<br />
'''Prerequisites'''<br />
<br />
* Some Android experience<br />
* Enjoy writing GUI widgets<br />
* C++/Java experience<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput).<br />
This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our sever, allowing us to crowdsource data. (Similar to our [http://stats.gnuradio.org/ online stats] for SIMD performance.)<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Setup automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web sever.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl, Marcus Mueller<br />
<br />
=== Filter Design Tool Enhancements ===<br />
<br />
GNU Radio provides many tools to design and use digital filters. Using these tools requires both some expertise in these areas as well as an understanding of the performance on the given platform. One example is the selection between FIR (convolution-based) and FFT (fast convolution-based) filters for different resampling rates. Another example is doing stages of filter decomposition when doing large down-sampling. Included in this is the polyphase filterbanks, which again are provided as primitive blocks that need tweaking to work.<br />
<br />
This project is to improve our uses of these tools and blocks to make it more obvious to the users as well as automate some of the decisions for optimally using them. Some pointers:<br />
<br />
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.<br />
* It still currently runs on PyQWT, which is obsolete and needs to be updated to Qt5<br />
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui<br />
* Add more support for filter design concepts and other filters.<br />
** Cascaded filters<br />
** Better support for creating PFB filters<br />
<br />
'''Prerequisites'''<br />
<br />
* Strong DSP background required.<br />
* Python and QT knowledge highly useful (at least one of those is a must).<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Leech<br />
<br />
<br />
<br />
=== Implement SigMF functionality for the GNU Radio Ecosystem ===<br />
<br />
SigMF is the "Signal Metadata Format" that was defined during the 2017 DARPA Hackfest in Brussels. Its purpose is to annotate raw binary dumps of signals with metadata, thus giving meaning to a raw mass of samples.<br /><br />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf<br />
There is an out-of-tree module providing SigMF functionality for GNU Radio as well: https://github.com/skysafe/gr-sigmf<br />
<br />
However, SigMF is not represented well in the GNU Radio tooling landscape. Therefore, a subset of tools can be extended by SigMF support. Incomplete lists of possible tools benefitting from SigMF support:<br />
<br />
* qgrx (https://github.com/csete/gqrx)<br />
* inspectrum (https://github.com/miek/inspectrum)<br />
* ...<br />
<br />
Any additional tools are welcome in a proposal.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of the programming language of the covered tools.<br />
* Hands-on experience with the respective tools.<br />
* Familiarity with the SigMF specification.<br />
<br />
'''Outcome'''<br />
<br />
* The tools worked on have capability to load and save files in the SigMF format.<br />
* Depending on the specific tool, SigMF meta data is displayed within the tool.<br />
* The number of tools worked on needs to be determined by the student, depending on his/her experience.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Müller, Andrej Rode<br />
<br />
<br />
<br />
=== Statistical Toolbox for GRC ===<br />
<br />
A statistical toolbox for GRC would enable GUI-based statistical analysis. Currently, such analysis can be done by writing an independent program (e.g., with SciPy), but there is no actual integration with GNU Radio. By developing the statistical toolbox, we provide blocks for probability distribution fitting, hypothesis testing, extracting statistical parameters for one-dimensional as well as multi-dimensional data. This would significantly expand GNU Radio users' ability to perform data-science analysis and modeling on signal data.<br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.<br />
<br />
'''Outcome'''<br />
<br />
* An OOT module that provides statistical analysis capabilities for GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Ben Hilburn<br />
<br />
</div><br />
</div><br />
== Application process ==<br />
<br />
Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].<br />
* Please introduce yourself on the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]<br />
* Fill in the formal application for GNU Radio<br />
* Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=OldGSoCIdeas&diff=13746OldGSoCIdeas2024-02-02T22:07:32Z<p>Haakov: GSoC: Add 2023 ideas to old ideas page</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2024: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize old modules ===<br />
<br />
Some of the in-tree modules are in need of attention. For example, gr-wavelet does not have any examples, and several of the tests in gr-trellis are failing. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
== Summer of Code 2022: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2022 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GNU Radio goes Browser: Web Assembly (WASM) port ===<br />
<br />
<br />
[[File:WASM-preview.jpg|thumb|link=https://mobile.twitter.com/marcnewlin/status/1490577402086313984/photo/1|A view of GRC running on WASM-compiled Python]]<br />
<br />
The main goal of WebAssembly is to enable high-performance applications on web pages. Originally quite restricted to single-threaded applications, only interacting with the browser's notion of the world through a JavaScript interaction layer, today it has become quite capable, with support for threads, exceptions, SIMD and a lot of other performance-critical features.<br />
<br />
Obviously, that's great news! GNU Radio in the Browser means zero-installation, fully portable SDR for the masses. This GSoC project strives to take Marc Newlin's current work and make something functional, with the big goal of having a fully functional GNU Radio on WASM.<br />
<br />
This project has subprojects, from which the student is to pick '''one''':<br />
<br />
* porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted set of intrinsics<br />
* working to bring GRC in the feature-grc-qt branch to parity with GRC in main<br />
* WebUSB driver porting (I have prototyped standalone drivers for UHD, HackRF and PlutoSDR which haven't get been integrated, and then porting gr-osmosdr would be awesome). <br />
* creating blocks for ZMQ over websockets<br />
<br />
in addition to making a (minimal) web page to which the current development state can be tested on, updated automatically from Github.<br />
<br />
'''Steps'''<br />
<br />
* Make (and test!) Marc Newlin's WASM build locally<br />
* Add a CI step to build a WASM binary<br />
* Implement one of the points above<br />
* Implement a suitable demonstration for it and deploy<br />
<br />
'''Prerequisites'''<br />
<br />
* Basic knowledge of Python<br />
* Working (especially, reading) knowledge of C++<br />
* Basic knowledge of WASM <br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marc Newlin<br />
* Marcus Müller<br />
* Depending on topic: further member of the GNU Radio community<br />
<br />
<br />
== Summer of Code 2021: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2021 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
'''The time a student can spend on a GSoC project has been reduced by 50% for 2021 - keep this in mind when submitting your ideas'''<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
=== Standardized High Throughput FEC Codes ===<br />
<br />
Channel coding is essential to modern communications. Also, it is computationally very heavy. As of now, there exist implementations in GNU Radio which are too slow to be integrated into high throughput applications. GNU Radio would benefit from integration of standardized decoders for Turbo and LDPC codes. These codes would only support a certain subset of the whole code class but would be well optimized. <br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.<br />
<br />
'''Outcome'''<br />
<br />
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.<br />
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Johannes Demel<br />
<br />
<br />
=== GRC: View-Only Mode (Secure) ===<br />
<br />
When a flowgraph from an untrusted source is opened if GRC, arbitrary Python code can be executed. This poses a potential security risk. Storing the all evaluated values of all parameters within a flow graph (.grc) file would allow us to open such flow graphs without compromising security. No code would be have to executed to draw the flow graph and block parameters can be viewed safely. Only if the flow graph is modified the user would have to choose to trust the flow graph thus enabling normal eval operations.<br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is implemented using Python. So, Python should be known pretty well.<br />
<br />
'''Outcome'''<br />
<br />
* Safely view other people's flowgraphs without putting your PC at risk.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===<br />
<br />
Even though the 8b10b line coding is primarily used for byte-level synchronization and spectral shaping, it adds some redundancy to the data, so it can be used as a forward error correction method to fix some bit errors in the received data. From the perspective of the decoder there is one bit of hidden state, so 8b10b line coding is amenable to Viterbi decoding, as hinted in [http://www.bigideatrouble.com/AMSAT%202013%20FOX1%20Paper.pdf this document about the AMSAT FOX satellites]. One goal of this project is to create Viterbi decoder block(s) for 8b10b and possibly other similar line codes, so that these blocks can be eventually upstreamed in-tree. The error correction performance of this method will be studied using simulations with these blocks. The second goal is to use the Viterbi decoder and gr-satellites to create a full decoder for the FOX satellites from AMSAT.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python. Some basic understanding about FEC in general.<br />
<br />
'''Outcome'''<br />
<br />
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites<br />
<br />
'''Mentor(s)'''<br />
<br />
* Daniel Estévez<br />
<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput). This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our server, allowing us to crowdsource data. (Similar to our online stats for SIMD performance.)<br />
<br />
'''Outcome'''<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Set up automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web server.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
*Bastian Bloessl<br />
<br />
<br />
== Summer of Code 2020: Project ideas list ==<br />
This is the list of project ideas for the summer of code 2020 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has the hierarchical blocks to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
<br />
=== Qt5 GUI Integrations ===<br />
<br />
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization<br />
<br />
'''Prerequisites'''<br />
<br />
* C++, Python proficiency<br />
* Qt experienced<br />
<br />
'''Outcome'''<br />
<br />
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)<br />
* Possible to import generate Qt GUI description file (UIC) into GRC<br />
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph<br />
* Integration of that into GRC-generated Python code<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Müller & Sebastian "GRC-Man" Koslowski<br />
<br />
<br />
<br />
=== Extending and Updating gr-radar ===<br />
<br />
gr-radar (https://github.com/kit-cel/gr-radar/) was a great and successful GSoC project that provided a few methods of radar in GNU Radio. This module is heavily used by academics, researchers, cybersecurity folks, and hobbyists. This project would work to improve upon the concepts already in there as well as add more radar techniques.<br />
<br />
There are uncountable methods and techniques that could be added to this project, such as:<br />
<br />
* SAR / InSAR methods<br />
* Better passive radar support<br />
* Speed camera applications<br />
* Multi-antenna radar techniques<br />
<br />
'''Prerequisites'''<br />
<br />
* Signal processing and some radar basics are required.<br />
* Code is written in C++ with some Python on the side, so the student must be able to handle these languages at the least.<br />
<br />
'''Outcome'''<br />
<br />
* Based on the student's interest, a subset of the radar techniques listed above (or others) are chosen as milestones for this project. <br />
* All code must be merged back into gr-radar by the end of the summer.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Stefan Wunsch, Martin Braun<br />
<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add new widgets<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C+'', so some C''+ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Tim O'Shea<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Android ===<br />
<br />
One effort of the past years was to improve Android support for GNU Radio. We're getting to a point where we've figured out '''how''' to do it, so the next step is to make it more accessible to users and developers.<br />
<br />
The Android ecosystem is an entirely different beast from the rest of GNU Radio. To make writing Android/GR apps easy, the following needs to happen (and shall be part of this project):<br />
<br />
* Improve support for development environment<br />
** Create Dockers for easy start of development<br />
* Visualization classes for PSD, spectrogram and oscilloscope<br />
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs<br />
* Interactivity concepts<br />
** Gestures and config for radio parameters (e.g., freq, gain, bandwidth)<br />
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures<br />
<br />
You can find a summary of the work that has been done on this (years ago) here: [[Android]]<br />
<br />
'''Prerequisites'''<br />
<br />
* Some Android experience<br />
* Enjoy writing GUI widgets<br />
* C++/Java experience<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput).<br />
This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our sever, allowing us to crowdsource data. (Similar to our [http://stats.gnuradio.org/ online stats] for SIMD performance.)<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Setup automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web sever.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl, Marcus Mueller<br />
<br />
=== Filter Design Tool Enhancements ===<br />
<br />
GNU Radio provides many tools to design and use digital filters. Using these tools requires both some expertise in these areas as well as an understanding of the performance on the given platform. One example is the selection between FIR (convolution-based) and FFT (fast convolution-based) filters for different resampling rates. Another example is doing stages of filter decomposition when doing large down-sampling. Included in this is the polyphase filterbanks, which again are provided as primitive blocks that need tweaking to work.<br />
<br />
This project is to improve our uses of these tools and blocks to make it more obvious to the users as well as automate some of the decisions for optimally using them. Some pointers:<br />
<br />
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.<br />
* It still currently runs on PyQWT, which is obsolete and needs to be updated to Qt5<br />
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui<br />
* Add more support for filter design concepts and other filters.<br />
** Cascaded filters<br />
** Better support for creating PFB filters<br />
<br />
'''Prerequisites'''<br />
<br />
* Strong DSP background required.<br />
* Python and QT knowledge highly useful (at least one of those is a must).<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Leech<br />
<br />
<br />
<br />
=== Implement SigMF functionality for the GNU Radio Ecosystem ===<br />
<br />
SigMF is the "Signal Metadata Format" that was defined during the 2017 DARPA Hackfest in Brussels. Its purpose is to annotate raw binary dumps of signals with metadata, thus giving meaning to a raw mass of samples.<br /><br />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf<br />
There is an out-of-tree module providing SigMF functionality for GNU Radio as well: https://github.com/skysafe/gr-sigmf<br />
<br />
However, SigMF is not represented well in the GNU Radio tooling landscape. Therefore, a subset of tools can be extended by SigMF support. Incomplete lists of possible tools benefitting from SigMF support:<br />
<br />
* qgrx (https://github.com/csete/gqrx)<br />
* inspectrum (https://github.com/miek/inspectrum)<br />
* ...<br />
<br />
Any additional tools are welcome in a proposal.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of the programming language of the covered tools.<br />
* Hands-on experience with the respective tools.<br />
* Familiarity with the SigMF specification.<br />
<br />
'''Outcome'''<br />
<br />
* The tools worked on have capability to load and save files in the SigMF format.<br />
* Depending on the specific tool, SigMF meta data is displayed within the tool.<br />
* The number of tools worked on needs to be determined by the student, depending on his/her experience.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Müller, Andrej Rode<br />
<br />
<br />
<br />
=== Statistical Toolbox for GRC ===<br />
<br />
A statistical toolbox for GRC would enable GUI-based statistical analysis. Currently, such analysis can be done by writing an independent program (e.g., with SciPy), but there is no actual integration with GNU Radio. By developing the statistical toolbox, we provide blocks for probability distribution fitting, hypothesis testing, extracting statistical parameters for one-dimensional as well as multi-dimensional data. This would significantly expand GNU Radio users' ability to perform data-science analysis and modeling on signal data.<br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.<br />
<br />
'''Outcome'''<br />
<br />
* An OOT module that provides statistical analysis capabilities for GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Ben Hilburn<br />
<br />
</div><br />
</div><br />
== Application process ==<br />
<br />
Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].<br />
* Please introduce yourself on the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]<br />
* Fill in the formal application for GNU Radio<br />
* Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13739GRC Qt2024-01-15T17:25:53Z<p>Haakov: GRC Qt: New features</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu. The settings are saved in .gnuradio/grc.conf. grc/gui_qt/resources/available_preferences.yml specifies which settings are available from GRC Qt.<br />
<br />
[[File:grcqt_prefs.png|upright=1|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
=== Automatic block wiki loading ===<br />
<br />
When clicking a block (either in the flowgraph canvas or in the block library to the left), the wiki tab to the right will automatically load the page from wiki.gnuradio.org corresponding to the block.<br />
<br />
== Code structure ==<br />
<br />
WIP<br />
<br />
== Code tour ==<br />
<br />
The following sections are meant to give the reader an understanding of what happens in GRC under the hood when a user interacts with a flowgraph. This will hopefully make it easier for new contributors to familiarise themselves with the GRC code. Please note that the code snippets below may be outdated.<br />
<br />
=== What happens when a block is moved? ===<br />
<br />
Once the user clicks and drags a block, a ''mousePressEvent'' is issued. The event is passed down from the FlowgraphView (QGraphicsView subclass), which is the widget that displays the Flowgraph (which is a QGraphicsScene subclass). The event passes through the Flowgraph, which records the position of the click:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/flowgraph.py#L270-L277 grc/gui_qt/components/flowgraph.py#L270-L277]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, event):<br />
item = self.itemAt(event.scenePos(), QtGui.QTransform())<br />
selected = self.selectedItems()<br />
self.moving_blocks = False<br />
if item:<br />
if item.is_block:<br />
self.moving_blocks = True<br />
self.clickPos = event.scenePos()<br />
</syntaxhighlight><br />
<br />
The click ends up in the block:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L359-L369 grc/gui_qt/components/canvas/block.py#L359-L369]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, e):<br />
super(self.__class__, self).mousePressEvent(e)<br />
log.debug(f"{self} clicked")<br />
url_prefix = str(self.parent.app.platform.config.wiki_block_docs_url_prefix)<br />
self.parent.app.WikiTab.setURL(QUrl(url_prefix + self.label.replace(" ", "_")))<br />
<br />
self.moveToTop()<br />
</syntaxhighlight><br />
<br />
<br />
A ''mouseMoveEvent'' is also issued, but the QGraphicsView framework's default handler does everything we need, so we don't need to modify it. The block (which is a QGraphicsItem) is being redrawn continuouslish as the block is dragged, using ''block.paint()'' (quite long):<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L228 grc/gui_qt/components/canvas/block.py#L228]<br />
<syntaxhighlight lang="python" line="line"><br />
def paint(self, painter, option, widget):<br />
(...)<br />
</syntaxhighlight><br />
<br />
If the block passes through another block's ''boundingRect'', the other block will also be redrawn.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L340-L343 grc/gui_qt/components/canvas/block.py#L340-L343]<br />
<syntaxhighlight lang="python" line="line"><br />
def boundingRect(self): # required to have<br />
return QtCore.QRectF( # TODO: Calculate comment box size<br />
-2.5, -2.5, self.width + 5, self.height + (5 if not self.comment else 50)<br />
) # margin to avoid artifacts<br />
</syntaxhighlight><br />
<br />
The movement also causes the block's ''itemChange'' slot to be triggered, which repositions the block if the '''Snap to grid''' setting has been enabled:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L384-L391 grc/gui_qt/components/canvas/block.py#L384-L391]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if change == QtWidgets.QGraphicsItem.ItemPositionChange and self.scene() and self.snap_to_grid:<br />
grid_size = 10<br />
value.setX(round(value.x()/grid_size)*grid_size)<br />
value.setY(round(value.y()/grid_size)*grid_size)<br />
return value<br />
else:<br />
return QtWidgets.QGraphicsItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Some blocks have ports, and they move with their parent block. This means that they will also notice the position change, and their ''itemChange'' slots make sure that the port's connections move accordingly:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/port.py#L60-L67 grc/gui_qt/components/canvas/port.py#L60-L67]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if self._dir == "sink":<br />
self.connection_point = self.scenePos() + QtCore.QPointF(0.0, self.height / 2.0)<br />
else:<br />
self.connection_point = self.scenePos() + QtCore.QPointF(self.width, self.height / 2.0)<br />
for conn in self.connections():<br />
conn.updateLine()<br />
return QtWidgets.QGraphicsLineItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Finally the user releases the mouse and drops the block in its new position. This leads to a ''mouseReleaseEvent'' in the Flowgraph, which emits an ''itemMoved'' signal.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/flowgraph.py#L343-L345 grc/gui_qt/components/flowgraph.py#L343-L345]<br />
<syntaxhighlight lang="python" line="line"><br />
if self.clickPos != event.scenePos():<br />
if self.moving_blocks:<br />
self.itemMoved.emit(event.scenePos() - self.clickPos)<br />
</syntaxhighlight><br />
<br />
The ''itemMoved'' signal is caught by the QMainWindow, where it has been connected to the ''registerMove'' slot. Note that the block is already in its new position, the ''registerMove'' just registers the move as a MoveAction and places it in the undo stack.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/window.py#L210-L215 grc/gui_qt/components/window.py#L210-L215]<br />
<syntaxhighlight lang="python" line="line"><br />
@QtCore.Slot(QtCore.QPointF)<br />
def createMove(self, diff):<br />
self.currentFlowgraph.set_saved(False)<br />
action = MoveAction(self.currentFlowgraph, diff)<br />
self.currentFlowgraph.undoStack.push(action)<br />
self.updateActions()<br />
</syntaxhighlight><br />
<br />
=== What happens when a block's properties is changed? (coming) ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13722GRC Qt2023-12-30T20:02:06Z<p>Haakov: GRC Qt: Update git hash in links</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
=== Automatic block wiki loading ===<br />
<br />
When clicking a block (either in the flowgraph canvas or in the block library to the left), the wiki tab to the right will automatically load the page from wiki.gnuradio.org corresponding to the block.<br />
<br />
== Code structure ==<br />
<br />
WIP<br />
<br />
== Code tour ==<br />
<br />
The following sections are meant to give the reader an understanding of what happens in GRC under the hood when a user interacts with a flowgraph. This will hopefully make it easier for new contributors to familiarise themselves with the GRC code. Please note that the code snippets below may be outdated.<br />
<br />
=== What happens when a block is moved? ===<br />
<br />
Once the user clicks and drags a block, a ''mousePressEvent'' is issued. The event is passed down from the FlowgraphView (QGraphicsView subclass), which is the widget that displays the Flowgraph (which is a QGraphicsScene subclass). The event passes through the Flowgraph, which records the position of the click:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/flowgraph.py#L270-L277 grc/gui_qt/components/flowgraph.py#L270-L277]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, event):<br />
item = self.itemAt(event.scenePos(), QtGui.QTransform())<br />
selected = self.selectedItems()<br />
self.moving_blocks = False<br />
if item:<br />
if item.is_block:<br />
self.moving_blocks = True<br />
self.clickPos = event.scenePos()<br />
</syntaxhighlight><br />
<br />
The click ends up in the block:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L359-L369 grc/gui_qt/components/canvas/block.py#L359-L369]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, e):<br />
super(self.__class__, self).mousePressEvent(e)<br />
log.debug(f"{self} clicked")<br />
url_prefix = str(self.parent.app.platform.config.wiki_block_docs_url_prefix)<br />
self.parent.app.WikiTab.setURL(QUrl(url_prefix + self.label.replace(" ", "_")))<br />
<br />
self.moveToTop()<br />
</syntaxhighlight><br />
<br />
<br />
A ''mouseMoveEvent'' is also issued, but the QGraphicsView framework's default handler does everything we need, so we don't need to modify it. The block (which is a QGraphicsItem) is being redrawn continuouslish as the block is dragged, using ''block.paint()'' (quite long):<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L228 grc/gui_qt/components/canvas/block.py#L228]<br />
<syntaxhighlight lang="python" line="line"><br />
def paint(self, painter, option, widget):<br />
(...)<br />
</syntaxhighlight><br />
<br />
If the block passes through another block's ''boundingRect'', the other block will also be redrawn.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L340-L343 grc/gui_qt/components/canvas/block.py#L340-L343]<br />
<syntaxhighlight lang="python" line="line"><br />
def boundingRect(self): # required to have<br />
return QtCore.QRectF( # TODO: Calculate comment box size<br />
-2.5, -2.5, self.width + 5, self.height + (5 if not self.comment else 50)<br />
) # margin to avoid artifacts<br />
</syntaxhighlight><br />
<br />
The movement also causes the block's ''itemChange'' slot to be triggered, which repositions the block if the '''Snap to grid''' setting has been enabled:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/block.py#L384-L391 grc/gui_qt/components/canvas/block.py#L384-L391]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if change == QtWidgets.QGraphicsItem.ItemPositionChange and self.scene() and self.snap_to_grid:<br />
grid_size = 10<br />
value.setX(round(value.x()/grid_size)*grid_size)<br />
value.setY(round(value.y()/grid_size)*grid_size)<br />
return value<br />
else:<br />
return QtWidgets.QGraphicsItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Some blocks have ports, and they move with their parent block. This means that they will also notice the position change, and their ''itemChange'' slots make sure that the port's connections move accordingly:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/canvas/port.py#L60-L67 grc/gui_qt/components/canvas/port.py#L60-L67]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if self._dir == "sink":<br />
self.connection_point = self.scenePos() + QtCore.QPointF(0.0, self.height / 2.0)<br />
else:<br />
self.connection_point = self.scenePos() + QtCore.QPointF(self.width, self.height / 2.0)<br />
for conn in self.connections():<br />
conn.updateLine()<br />
return QtWidgets.QGraphicsLineItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Finally the user releases the mouse and drops the block in its new position. This leads to a ''mouseReleaseEvent'' in the Flowgraph, which emits an ''itemMoved'' signal.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/flowgraph.py#L343-L345 grc/gui_qt/components/flowgraph.py#L343-L345]<br />
<syntaxhighlight lang="python" line="line"><br />
if self.clickPos != event.scenePos():<br />
if self.moving_blocks:<br />
self.itemMoved.emit(event.scenePos() - self.clickPos)<br />
</syntaxhighlight><br />
<br />
The ''itemMoved'' signal is caught by the QMainWindow, where it has been connected to the ''registerMove'' slot. Note that the block is already in its new position, the ''registerMove'' just registers the move as a MoveAction and places it in the undo stack.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/18dd2e04edb58f6e1ebeb14d3bdfef70499d261b/grc/gui_qt/components/window.py#L210-L215 grc/gui_qt/components/window.py#L210-L215]<br />
<syntaxhighlight lang="python" line="line"><br />
@QtCore.Slot(QtCore.QPointF)<br />
def createMove(self, diff):<br />
self.currentFlowgraph.set_saved(False)<br />
action = MoveAction(self.currentFlowgraph, diff)<br />
self.currentFlowgraph.undoStack.push(action)<br />
self.updateActions()<br />
</syntaxhighlight><br />
<br />
=== What happens when a block's properties is changed? (coming) ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13721GRC Qt2023-12-30T19:59:35Z<p>Haakov: GRC Qt: Update code</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
=== Automatic block wiki loading ===<br />
<br />
When clicking a block (either in the flowgraph canvas or in the block library to the left), the wiki tab to the right will automatically load the page from wiki.gnuradio.org corresponding to the block.<br />
<br />
== Code structure ==<br />
<br />
WIP<br />
<br />
== Code tour ==<br />
<br />
The following sections are meant to give the reader an understanding of what happens in GRC under the hood when a user interacts with a flowgraph. This will hopefully make it easier for new contributors to familiarise themselves with the GRC code.<br />
<br />
=== What happens when a block is moved? ===<br />
<br />
Once the user clicks and drags a block, a ''mousePressEvent'' is issued. The event is passed down from the FlowgraphView (QGraphicsView subclass), which is the widget that displays the Flowgraph (which is a QGraphicsScene subclass). The event passes through the Flowgraph, which records the position of the click:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L270-L277 grc/gui_qt/components/flowgraph.py#L270-L277]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, event):<br />
item = self.itemAt(event.scenePos(), QtGui.QTransform())<br />
selected = self.selectedItems()<br />
self.moving_blocks = False<br />
if item:<br />
if item.is_block:<br />
self.moving_blocks = True<br />
self.clickPos = event.scenePos()<br />
</syntaxhighlight><br />
<br />
The click ends up in the block:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L359-L369 grc/gui_qt/components/canvas/block.py#L359-L369]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, e):<br />
super(self.__class__, self).mousePressEvent(e)<br />
log.debug(f"{self} clicked")<br />
url_prefix = str(self.parent.app.platform.config.wiki_block_docs_url_prefix)<br />
self.parent.app.WikiTab.setURL(QUrl(url_prefix + self.label.replace(" ", "_")))<br />
<br />
self.moveToTop()<br />
</syntaxhighlight><br />
<br />
<br />
A ''mouseMoveEvent'' is also issued, but the QGraphicsView framework's default handler does everything we need, so we don't need to modify it. The block (which is a QGraphicsItem) is being redrawn continuouslish as the block is dragged, using ''block.paint()'' (quite long):<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L228 grc/gui_qt/components/canvas/block.py#L228]<br />
<syntaxhighlight lang="python" line="line"><br />
def paint(self, painter, option, widget):<br />
(...)<br />
</syntaxhighlight><br />
<br />
If the block passes through another block's ''boundingRect'', the other block will also be redrawn.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/77fc296e81780fcb970ea8534725ac1858f08c12/grc/gui_qt/components/canvas/block.py#L340-L343 grc/gui_qt/components/canvas/block.py#L340-L343]<br />
<syntaxhighlight lang="python" line="line"><br />
def boundingRect(self): # required to have<br />
return QtCore.QRectF( # TODO: Calculate comment box size<br />
-2.5, -2.5, self.width + 5, self.height + (5 if not self.comment else 50)<br />
) # margin to avoid artifacts<br />
</syntaxhighlight><br />
<br />
The movement also causes the block's ''itemChange'' slot to be triggered, which repositions the block if the '''Snap to grid''' setting has been enabled:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L384-L391 grc/gui_qt/components/canvas/block.py#L384-L391]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if change == QtWidgets.QGraphicsItem.ItemPositionChange and self.scene() and self.snap_to_grid:<br />
grid_size = 10<br />
value.setX(round(value.x()/grid_size)*grid_size)<br />
value.setY(round(value.y()/grid_size)*grid_size)<br />
return value<br />
else:<br />
return QtWidgets.QGraphicsItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Some blocks have ports, and they move with their parent block. This means that they will also notice the position change, and their ''itemChange'' slots make sure that the port's connections move accordingly:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/port.py#L60-L67 grc/gui_qt/components/canvas/port.py#L60-L67]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if self._dir == "sink":<br />
self.connection_point = self.scenePos() + QtCore.QPointF(0.0, self.height / 2.0)<br />
else:<br />
self.connection_point = self.scenePos() + QtCore.QPointF(self.width, self.height / 2.0)<br />
for conn in self.connections():<br />
conn.updateLine()<br />
return QtWidgets.QGraphicsLineItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Finally the user releases the mouse and drops the block in its new position. This leads to a ''mouseReleaseEvent'' in the Flowgraph, which emits an ''itemMoved'' signal.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L343-L345 grc/gui_qt/components/flowgraph.py#L343-L345]<br />
<syntaxhighlight lang="python" line="line"><br />
if self.clickPos != event.scenePos():<br />
if self.moving_blocks:<br />
self.itemMoved.emit(event.scenePos() - self.clickPos)<br />
</syntaxhighlight><br />
<br />
The ''itemMoved'' signal is caught by the QMainWindow, where it has been connected to the ''registerMove'' slot. Note that the block is already in its new position, the ''registerMove'' just registers the move as a MoveAction and places it in the undo stack.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/window.py#L210-L215 grc/gui_qt/components/window.py#L210-L215]<br />
<syntaxhighlight lang="python" line="line"><br />
@QtCore.Slot(QtCore.QPointF)<br />
def createMove(self, diff):<br />
self.currentFlowgraph.set_saved(False)<br />
action = MoveAction(self.currentFlowgraph, diff)<br />
self.currentFlowgraph.undoStack.push(action)<br />
self.updateActions()<br />
</syntaxhighlight><br />
<br />
=== What happens when a block's properties is changed? (coming) ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13720GRC Qt2023-12-30T19:52:48Z<p>Haakov: GRC Qt: Italics</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
=== Automatic block wiki loading ===<br />
<br />
When clicking a block (either in the flowgraph canvas or in the block library to the left), the wiki tab to the right will automatically load the page from wiki.gnuradio.org corresponding to the block.<br />
<br />
== Code structure ==<br />
<br />
WIP<br />
<br />
== Code tour ==<br />
<br />
The following sections are meant to give the reader an understanding of what happens in GRC under the hood when a user interacts with a flowgraph. This will hopefully make it easier for new contributors to familiarise themselves with the GRC code.<br />
<br />
=== What happens when a block is moved? ===<br />
<br />
Once the user clicks and drags a block, a ''mousePressEvent'' is issued. The event is passed down from the FlowgraphView (QGraphicsView subclass), which is the widget that displays the Flowgraph (which is a QGraphicsScene subclass). The event passes through the Flowgraph, which records the position of the click:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L270-L277 grc/gui_qt/components/flowgraph.py#L270-L277]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, event):<br />
item = self.itemAt(event.scenePos(), QtGui.QTransform())<br />
selected = self.selectedItems()<br />
self.moving_blocks = False<br />
if item:<br />
if item.is_block:<br />
self.moving_blocks = True<br />
self.clickPos = event.scenePos()<br />
</syntaxhighlight><br />
<br />
The click ends up in the block:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L359-L369 grc/gui_qt/components/canvas/block.py#L359-L369]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, e):<br />
super(self.__class__, self).mousePressEvent(e)<br />
log.debug(f"{self} clicked")<br />
try:<br />
prefix = str(self.parent.app.platform.Config.wiki_block_docs_url_prefix)<br />
self.parent.app.WikiTab.setURL(QUrl(prefix + self.label.replace(" ", "_")))<br />
except KeyError:<br />
pass<br />
<br />
self.moveToTop()<br />
</syntaxhighlight><br />
<br />
<br />
A ''mouseMoveEvent'' is also issued, but the QGraphicsView framework's default handler does everything we need, so we don't need to modify it. The block (which is a QGraphicsItem) is being redrawn continuouslish as the block is dragged, using ''block.paint()'' (quite long):<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L228 grc/gui_qt/components/canvas/block.py#L228]<br />
<syntaxhighlight lang="python" line="line"><br />
def paint(self, painter, option, widget):<br />
(...)<br />
</syntaxhighlight><br />
<br />
If the block passes through another block's ''boundingRect'', the other block will also be redrawn.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/77fc296e81780fcb970ea8534725ac1858f08c12/grc/gui_qt/components/canvas/block.py#L340-L343 grc/gui_qt/components/canvas/block.py#L340-L343]<br />
<syntaxhighlight lang="python" line="line"><br />
def boundingRect(self): # required to have<br />
return QtCore.QRectF( # TODO: Calculate comment box size<br />
-2.5, -2.5, self.width + 5, self.height + (5 if not self.comment else 50)<br />
) # margin to avoid artifacts<br />
</syntaxhighlight><br />
<br />
The movement also causes the block's ''itemChange'' slot to be triggered, which repositions the block if the '''Snap to grid''' setting has been enabled:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L384-L391 grc/gui_qt/components/canvas/block.py#L384-L391]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if change == QtWidgets.QGraphicsItem.ItemPositionChange and self.scene() and self.snap_to_grid:<br />
grid_size = 10<br />
value.setX(round(value.x()/grid_size)*grid_size)<br />
value.setY(round(value.y()/grid_size)*grid_size)<br />
return value<br />
else:<br />
return QtWidgets.QGraphicsItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Some blocks have ports, and they move with their parent block. This means that they will also notice the position change, and their ''itemChange'' slots make sure that the port's connections move accordingly:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/port.py#L60-L67 grc/gui_qt/components/canvas/port.py#L60-L67]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if self._dir == "sink":<br />
self.connection_point = self.scenePos() + QtCore.QPointF(0.0, self.height / 2.0)<br />
else:<br />
self.connection_point = self.scenePos() + QtCore.QPointF(self.width, self.height / 2.0)<br />
for conn in self.connections():<br />
conn.updateLine()<br />
return QtWidgets.QGraphicsLineItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Finally the user releases the mouse and drops the block in its new position. This leads to a ''mouseReleaseEvent'' in the Flowgraph, which emits an ''itemMoved'' signal.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L343-L345 grc/gui_qt/components/flowgraph.py#L343-L345]<br />
<syntaxhighlight lang="python" line="line"><br />
if self.clickPos != event.scenePos():<br />
if self.moving_blocks:<br />
self.itemMoved.emit(event.scenePos() - self.clickPos)<br />
</syntaxhighlight><br />
<br />
The ''itemMoved'' signal is caught by the QMainWindow, where it has been connected to the ''registerMove'' slot. Note that the block is already in its new position, the ''registerMove'' just registers the move as a MoveAction and places it in the undo stack.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/window.py#L210-L215 grc/gui_qt/components/window.py#L210-L215]<br />
<syntaxhighlight lang="python" line="line"><br />
@QtCore.Slot(QtCore.QPointF)<br />
def createMove(self, diff):<br />
self.currentFlowgraph.set_saved(False)<br />
action = MoveAction(self.currentFlowgraph, diff)<br />
self.currentFlowgraph.undoStack.push(action)<br />
self.updateActions()<br />
</syntaxhighlight><br />
<br />
=== What happens when a block's properties is changed? (coming) ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13719GRC Qt2023-12-30T19:49:16Z<p>Haakov: GRC Qt: Resize images</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
=== Automatic block wiki loading ===<br />
<br />
When clicking a block (either in the flowgraph canvas or in the block library to the left), the wiki tab to the right will automatically load the page from wiki.gnuradio.org corresponding to the block.<br />
<br />
== Code structure ==<br />
<br />
WIP<br />
<br />
== Code tour ==<br />
<br />
The following sections are meant to give the reader an understanding of what happens in GRC under the hood when a user interacts with a flowgraph. This will hopefully make it easier for new contributors to familiarise themselves with the GRC code.<br />
<br />
=== What happens when a block is moved? ===<br />
<br />
Once the user clicks and drags a block, a `mousePressEvent` is issued. The event is passed down from the FlowgraphView (QGraphicsView subclass), which is the widget that displays the Flowgraph (which is a QGraphicsScene subclass). The event passes through the Flowgraph, which records the position of the click:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L270-L277 grc/gui_qt/components/flowgraph.py#L270-L277]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, event):<br />
item = self.itemAt(event.scenePos(), QtGui.QTransform())<br />
selected = self.selectedItems()<br />
self.moving_blocks = False<br />
if item:<br />
if item.is_block:<br />
self.moving_blocks = True<br />
self.clickPos = event.scenePos()<br />
</syntaxhighlight><br />
<br />
The click ends up in the block:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L359-L369 grc/gui_qt/components/canvas/block.py#L359-L369]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, e):<br />
super(self.__class__, self).mousePressEvent(e)<br />
log.debug(f"{self} clicked")<br />
try:<br />
prefix = str(self.parent.app.platform.Config.wiki_block_docs_url_prefix)<br />
self.parent.app.WikiTab.setURL(QUrl(prefix + self.label.replace(" ", "_")))<br />
except KeyError:<br />
pass<br />
<br />
self.moveToTop()<br />
</syntaxhighlight><br />
<br />
<br />
A `mouseMoveEvent` is also issued, but the QGraphicsView framework's default handler does everything we need, so we don't need to modify it. The block (which is a QGraphicsItem) is being redrawn continuouslish as the block is dragged, using `block.paint()` (quite long):<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L228 grc/gui_qt/components/canvas/block.py#L228]<br />
<syntaxhighlight lang="python" line="line"><br />
def paint(self, painter, option, widget):<br />
(...)<br />
</syntaxhighlight><br />
<br />
If the block passes through another block's `boundingRect`, the other block will also be redrawn.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/77fc296e81780fcb970ea8534725ac1858f08c12/grc/gui_qt/components/canvas/block.py#L340-L343 grc/gui_qt/components/canvas/block.py#L340-L343]<br />
<syntaxhighlight lang="python" line="line"><br />
def boundingRect(self): # required to have<br />
return QtCore.QRectF( # TODO: Calculate comment box size<br />
-2.5, -2.5, self.width + 5, self.height + (5 if not self.comment else 50)<br />
) # margin to avoid artifacts<br />
</syntaxhighlight><br />
<br />
The movement also causes the block's `itemChange` slot to be triggered, which repositions the block if the *Snap to grid* setting has been enabled:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L384-L391 grc/gui_qt/components/canvas/block.py#L384-L391]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if change == QtWidgets.QGraphicsItem.ItemPositionChange and self.scene() and self.snap_to_grid:<br />
grid_size = 10<br />
value.setX(round(value.x()/grid_size)*grid_size)<br />
value.setY(round(value.y()/grid_size)*grid_size)<br />
return value<br />
else:<br />
return QtWidgets.QGraphicsItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Some blocks have ports, and they move with their parent block. This means that they will also notice the position change, and their `itemChange` slots make sure that the port's connections move accordingly:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/port.py#L60-L67 grc/gui_qt/components/canvas/port.py#L60-L67]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if self._dir == "sink":<br />
self.connection_point = self.scenePos() + QtCore.QPointF(0.0, self.height / 2.0)<br />
else:<br />
self.connection_point = self.scenePos() + QtCore.QPointF(self.width, self.height / 2.0)<br />
for conn in self.connections():<br />
conn.updateLine()<br />
return QtWidgets.QGraphicsLineItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Finally the user releases the mouse and drops the block in its new position. This leads to a `mouseReleaseEvent` in the Flowgraph, which emits an `itemMoved` signal.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L343-L345 grc/gui_qt/components/flowgraph.py#L343-L345]<br />
<syntaxhighlight lang="python" line="line"><br />
if self.clickPos != event.scenePos():<br />
if self.moving_blocks:<br />
self.itemMoved.emit(event.scenePos() - self.clickPos)<br />
</syntaxhighlight><br />
<br />
The `itemMoved` signal is caught by the QMainWindow, where it has been connected to the `registerMove` slot. Note that the block is already in its new position, the `registerMove` just registers the move as a MoveAction and places it in the undo stack.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/window.py#L210-L215 grc/gui_qt/components/window.py#L210-L215]<br />
<syntaxhighlight lang="python" line="line"><br />
@QtCore.Slot(QtCore.QPointF)<br />
def createMove(self, diff):<br />
self.currentFlowgraph.set_saved(False)<br />
action = MoveAction(self.currentFlowgraph, diff)<br />
self.currentFlowgraph.undoStack.push(action)<br />
self.updateActions()<br />
</syntaxhighlight><br />
<br />
<br />
=== What happens when a block's properties is changed? (coming) ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13718GRC Qt2023-12-30T19:46:20Z<p>Haakov: GRC Qt: Start adding Code Tour</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1.8|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1.8|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1.8|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
=== Automatic block wiki loading ===<br />
<br />
When clicking a block (either in the flowgraph canvas or in the block library to the left), the wiki tab to the right will automatically load the page from wiki.gnuradio.org corresponding to the block.<br />
<br />
== Code structure ==<br />
<br />
WIP<br />
<br />
== Code tour ==<br />
<br />
The following sections are meant to give the reader an understanding of what happens in GRC under the hood when a user interacts with a flowgraph. This will hopefully make it easier for new contributors to familiarise themselves with the GRC code.<br />
<br />
=== What happens when a block is moved? ===<br />
<br />
Once the user clicks and drags a block, a `mousePressEvent` is issued. The event is passed down from the FlowgraphView (QGraphicsView subclass), which is the widget that displays the Flowgraph (which is a QGraphicsScene subclass). The event passes through the Flowgraph, which records the position of the click:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L270-L277 grc/gui_qt/components/flowgraph.py#L270-L277]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, event):<br />
item = self.itemAt(event.scenePos(), QtGui.QTransform())<br />
selected = self.selectedItems()<br />
self.moving_blocks = False<br />
if item:<br />
if item.is_block:<br />
self.moving_blocks = True<br />
self.clickPos = event.scenePos()<br />
</syntaxhighlight><br />
<br />
The click ends up in the block:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L359-L369 grc/gui_qt/components/canvas/block.py#L359-L369]<br />
<syntaxhighlight lang="python" line="line"><br />
def mousePressEvent(self, e):<br />
super(self.__class__, self).mousePressEvent(e)<br />
log.debug(f"{self} clicked")<br />
try:<br />
prefix = str(self.parent.app.platform.Config.wiki_block_docs_url_prefix)<br />
self.parent.app.WikiTab.setURL(QUrl(prefix + self.label.replace(" ", "_")))<br />
except KeyError:<br />
pass<br />
<br />
self.moveToTop()<br />
</syntaxhighlight><br />
<br />
<br />
A `mouseMoveEvent` is also issued, but the QGraphicsView framework's default handler does everything we need, so we don't need to modify it. The block (which is a QGraphicsItem) is being redrawn continuouslish as the block is dragged, using `block.paint()` (quite long):<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L228 grc/gui_qt/components/canvas/block.py#L228]<br />
<syntaxhighlight lang="python" line="line"><br />
def paint(self, painter, option, widget):<br />
(...)<br />
</syntaxhighlight><br />
<br />
If the block passes through another block's `boundingRect`, the other block will also be redrawn.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/77fc296e81780fcb970ea8534725ac1858f08c12/grc/gui_qt/components/canvas/block.py#L340-L343 grc/gui_qt/components/canvas/block.py#L340-L343]<br />
<syntaxhighlight lang="python" line="line"><br />
def boundingRect(self): # required to have<br />
return QtCore.QRectF( # TODO: Calculate comment box size<br />
-2.5, -2.5, self.width + 5, self.height + (5 if not self.comment else 50)<br />
) # margin to avoid artifacts<br />
</syntaxhighlight><br />
<br />
The movement also causes the block's `itemChange` slot to be triggered, which repositions the block if the *Snap to grid* setting has been enabled:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/block.py#L384-L391 grc/gui_qt/components/canvas/block.py#L384-L391]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if change == QtWidgets.QGraphicsItem.ItemPositionChange and self.scene() and self.snap_to_grid:<br />
grid_size = 10<br />
value.setX(round(value.x()/grid_size)*grid_size)<br />
value.setY(round(value.y()/grid_size)*grid_size)<br />
return value<br />
else:<br />
return QtWidgets.QGraphicsItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Some blocks have ports, and they move with their parent block. This means that they will also notice the position change, and their `itemChange` slots make sure that the port's connections move accordingly:<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/canvas/port.py#L60-L67 grc/gui_qt/components/canvas/port.py#L60-L67]<br />
<syntaxhighlight lang="python" line="line"><br />
def itemChange(self, change, value):<br />
if self._dir == "sink":<br />
self.connection_point = self.scenePos() + QtCore.QPointF(0.0, self.height / 2.0)<br />
else:<br />
self.connection_point = self.scenePos() + QtCore.QPointF(self.width, self.height / 2.0)<br />
for conn in self.connections():<br />
conn.updateLine()<br />
return QtWidgets.QGraphicsLineItem.itemChange(self, change, value)<br />
</syntaxhighlight><br />
<br />
Finally the user releases the mouse and drops the block in its new position. This leads to a `mouseReleaseEvent` in the Flowgraph, which emits an `itemMoved` signal.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/flowgraph.py#L343-L345 grc/gui_qt/components/flowgraph.py#L343-L345]<br />
<syntaxhighlight lang="python" line="line"><br />
if self.clickPos != event.scenePos():<br />
if self.moving_blocks:<br />
self.itemMoved.emit(event.scenePos() - self.clickPos)<br />
</syntaxhighlight><br />
<br />
The `itemMoved` signal is caught by the QMainWindow, where it has been connected to the `registerMove` slot. Note that the block is already in its new position, the `registerMove` just registers the move as a MoveAction and places it in the undo stack.<br />
<br />
[https://github.com/gnuradio/gnuradio/blob/ad92582a7709e8b12ca65900b1bffe27b97293bd/grc/gui_qt/components/window.py#L210-L215 grc/gui_qt/components/window.py#L210-L215]<br />
<syntaxhighlight lang="python" line="line"><br />
@QtCore.Slot(QtCore.QPointF)<br />
def createMove(self, diff):<br />
self.currentFlowgraph.set_saved(False)<br />
action = MoveAction(self.currentFlowgraph, diff)<br />
self.currentFlowgraph.undoStack.push(action)<br />
self.updateActions()<br />
</syntaxhighlight><br />
<br />
<br />
=== What happens when a block's properties is changed? (coming) ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13717GRC Qt2023-12-30T16:56:57Z<p>Haakov: Updated the GRC Qt page</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1.8|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1.8|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1.8|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
=== Automatic block wiki loading ===<br />
<br />
When clicking a block (either in the flowgraph canvas or in the block library to the left), the wiki tab to the right will automatically load the page from wiki.gnuradio.org corresponding to the block.<br />
<br />
== Code structure ==<br />
<br />
WIP</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13716GRC Qt2023-12-30T15:57:40Z<p>Haakov: Updated the GRC Qt page (log file)</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1.8|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1.8|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1.8|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default. Run GRC with ''--log debug'' to enable DEBUG level log messages too.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
== Code structure ==</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13715GRC Qt2023-12-30T15:55:23Z<p>Haakov: Updated the GRC Qt page</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1.8|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1.8|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1.8|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== Undo stack ===<br />
<br />
GRC Qt uses Qt's Undo framework, which comes with a built-in Undo stack viewer. You can find it at Edit->Undo stack.<br />
<br />
=== Log file ===<br />
<br />
GRC Qt writes logs (levels INFO and higher) to ~/.gnuradio/grc.log by default.<br />
<br />
=== GUI testing ===<br />
<br />
The file grc/tests/test_qtbot.py uses Pytest-qt and PyAutoGUI to test various GUI features. Warning: The script will use your mouse and keyboard for ~30 seconds!<br />
<br />
== Code structure ==</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13714GRC Qt2023-12-28T11:55:02Z<p>Haakov: </p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
Go to File->Examples to open the example browser. You can also open a block's properties dialog (double-click) and click the Examples tab to see which examples contain the block.<br />
<br />
[[File:grcqt_examples.png|upright=1.8|thumb|GRC Examples browser (December 2023)]]<br />
<br />
=== OOT browser ===<br />
<br />
You can find the OOT browser at Tools->OOT Module Browser. It lists the installed OOTs and displays information about it from MANIFEST.md.<br />
<br />
[[File:grcqt_oot_browser.png|upright=1.8|thumb|GRC OOT browser (December 2023)]]<br />
<br />
=== Preferences ===<br />
<br />
Go to File->Preferences to open the preferences menu.<br />
<br />
[[File:grcqt_prefs.png|upright=1.8|thumb|GRC Qt preferences (December 2023)]]<br />
<br />
=== GUI testing ===<br />
<br />
== Code structure ==</div>Haakovhttps://wiki.gnuradio.org/index.php?title=File:Grcqt_examples.png&diff=13713File:Grcqt examples.png2023-12-28T11:54:05Z<p>Haakov: </p>
<hr />
<div></div>Haakovhttps://wiki.gnuradio.org/index.php?title=File:Grcqt_oot_browser.png&diff=13712File:Grcqt oot browser.png2023-12-28T11:53:01Z<p>Haakov: </p>
<hr />
<div></div>Haakovhttps://wiki.gnuradio.org/index.php?title=File:Grcqt_prefs.png&diff=13711File:Grcqt prefs.png2023-12-28T11:40:15Z<p>Haakov: </p>
<hr />
<div></div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13591GRC Qt2023-11-13T17:16:11Z<p>Haakov: Added screenshot of GRC Qt</p>
<hr />
<div>[[File:Grcqt.png|upright=1.8|thumb|right|GRC Qt (November 2023)]]<br />
<br />
GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
=== OOT browser ===<br />
<br />
=== Preferences ===<br />
<br />
=== GUI testing ===<br />
<br />
== Code structure ==</div>Haakovhttps://wiki.gnuradio.org/index.php?title=File:Grcqt.png&diff=13590File:Grcqt.png2023-11-13T17:14:22Z<p>Haakov: </p>
<hr />
<div></div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_Qt&diff=13589GRC Qt2023-11-13T17:11:36Z<p>Haakov: Created GRC Qt page</p>
<hr />
<div>GRC Qt is a work-in-progress port of GRC from Gtk to Qt. GRC Qt aims to provide better cross-platform support, both across different OSes, but also across different versions of Qt/PyQt (PyQt and PySide, version 5 and 6). GRC Qt can be tried out at https://github.com/gnuradio/gnuradio/tree/feature-grc-qt.<br />
<br />
== New features ==<br />
<br />
=== Example integration ===<br />
<br />
=== OOT browser ===<br />
<br />
=== Preferences ===<br />
<br />
=== GUI testing ===<br />
<br />
== Code structure ==</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=12939GSoCIdeas2023-02-07T19:21:21Z<p>Haakov: /* GRC: Standalone application and pluggable workflows */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2023: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize old modules ===<br />
<br />
Some of the in-tree modules are in need of attention. For example, gr-wavelet does not have any examples, and several of the tests in gr-trellis are failing. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=12938GSoCIdeas2023-02-07T19:20:11Z<p>Haakov: /* Summer of Code 2023: Project ideas list */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2023: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
** Support multiple domains' workflows. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
<br />
=== Revitalize old modules ===<br />
<br />
Some of the in-tree modules are in need of attention. For example, gr-wavelet does not have any examples, and several of the tests in gr-trellis are failing. <br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++, Python and DSP.<br />
<br />
'''Outcome'''<br />
<br />
* More example code, tests and flowgraphs for various in-tree modules<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
<br />
=== CI for maintenance branches and select OOT modules ===<br />
<br />
It would be useful to have nightly builds for GNU Radio's maintenance branches (3.8, 3.9, 3.10) and some select OOTs. <br />
<br />
'''Prerequisites'''<br />
<br />
* Experience with Docker?<br />
* ?<br />
<br />
'''Outcome'''<br />
<br />
* Automated PPAs, Snaps, Flatpak apps<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether, ?<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=12937GSoCIdeas2023-02-07T18:05:26Z<p>Haakov: /* Summer of Code 2023: Project ideas list */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2023: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== GRC: Standalone application and pluggable workflows ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has hierarchical blocks as a way to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Mentor(s)'''<br />
<br />
Håkon Vågsether<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=12936GSoCIdeas2023-02-07T17:42:09Z<p>Haakov: Move old ideas from current ideas page</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2023: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
== Old Ideas ==<br />
<br />
Feel free to browse [https://wiki.gnuradio.org/index.php?title=OldGSoCIdeas old ideas] from previous years for inspiration.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=OldGSoCIdeas&diff=12935OldGSoCIdeas2023-02-07T17:39:35Z<p>Haakov: Create Old GSoC Ideas page</p>
<hr />
<div><br />
== Summer of Code 2022: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2022 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GNU Radio goes Browser: Web Assembly (WASM) port ===<br />
<br />
<br />
[[File:WASM-preview.jpg|thumb|link=https://mobile.twitter.com/marcnewlin/status/1490577402086313984/photo/1|A view of GRC running on WASM-compiled Python]]<br />
<br />
The main goal of WebAssembly is to enable high-performance applications on web pages. Originally quite restricted to single-threaded applications, only interacting with the browser's notion of the world through a JavaScript interaction layer, today it has become quite capable, with support for threads, exceptions, SIMD and a lot of other performance-critical features.<br />
<br />
Obviously, that's great news! GNU Radio in the Browser means zero-installation, fully portable SDR for the masses. This GSoC project strives to take Marc Newlin's current work and make something functional, with the big goal of having a fully functional GNU Radio on WASM.<br />
<br />
This project has subprojects, from which the student is to pick '''one''':<br />
<br />
* porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted set of intrinsics<br />
* working to bring GRC in the feature-grc-qt branch to parity with GRC in main<br />
* WebUSB driver porting (I have prototyped standalone drivers for UHD, HackRF and PlutoSDR which haven't get been integrated, and then porting gr-osmosdr would be awesome). <br />
* creating blocks for ZMQ over websockets<br />
<br />
in addition to making a (minimal) web page to which the current development state can be tested on, updated automatically from Github.<br />
<br />
'''Steps'''<br />
<br />
* Make (and test!) Marc Newlin's WASM build locally<br />
* Add a CI step to build a WASM binary<br />
* Implement one of the points above<br />
* Implement a suitable demonstration for it and deploy<br />
<br />
'''Prerequisites'''<br />
<br />
* Basic knowledge of Python<br />
* Working (especially, reading) knowledge of C++<br />
* Basic knowledge of WASM <br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marc Newlin<br />
* Marcus Müller<br />
* Depending on topic: further member of the GNU Radio community<br />
<br />
<br />
== Summer of Code 2021: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2021 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
'''The time a student can spend on a GSoC project has been reduced by 50% for 2021 - keep this in mind when submitting your ideas'''<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
=== Standardized High Throughput FEC Codes ===<br />
<br />
Channel coding is essential to modern communications. Also, it is computationally very heavy. As of now, there exist implementations in GNU Radio which are too slow to be integrated into high throughput applications. GNU Radio would benefit from integration of standardized decoders for Turbo and LDPC codes. These codes would only support a certain subset of the whole code class but would be well optimized. <br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.<br />
<br />
'''Outcome'''<br />
<br />
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.<br />
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Johannes Demel<br />
<br />
<br />
=== GRC: View-Only Mode (Secure) ===<br />
<br />
When a flowgraph from an untrusted source is opened if GRC, arbitrary Python code can be executed. This poses a potential security risk. Storing the all evaluated values of all parameters within a flow graph (.grc) file would allow us to open such flow graphs without compromising security. No code would be have to executed to draw the flow graph and block parameters can be viewed safely. Only if the flow graph is modified the user would have to choose to trust the flow graph thus enabling normal eval operations.<br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is implemented using Python. So, Python should be known pretty well.<br />
<br />
'''Outcome'''<br />
<br />
* Safely view other people's flowgraphs without putting your PC at risk.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===<br />
<br />
Even though the 8b10b line coding is primarily used for byte-level synchronization and spectral shaping, it adds some redundancy to the data, so it can be used as a forward error correction method to fix some bit errors in the received data. From the perspective of the decoder there is one bit of hidden state, so 8b10b line coding is amenable to Viterbi decoding, as hinted in [http://www.bigideatrouble.com/AMSAT%202013%20FOX1%20Paper.pdf this document about the AMSAT FOX satellites]. One goal of this project is to create Viterbi decoder block(s) for 8b10b and possibly other similar line codes, so that these blocks can be eventually upstreamed in-tree. The error correction performance of this method will be studied using simulations with these blocks. The second goal is to use the Viterbi decoder and gr-satellites to create a full decoder for the FOX satellites from AMSAT.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python. Some basic understanding about FEC in general.<br />
<br />
'''Outcome'''<br />
<br />
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites<br />
<br />
'''Mentor(s)'''<br />
<br />
* Daniel Estévez<br />
<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput). This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our server, allowing us to crowdsource data. (Similar to our online stats for SIMD performance.)<br />
<br />
'''Outcome'''<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Set up automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web server.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
*Bastian Bloessl<br />
<br />
<br />
== Summer of Code 2020: Project ideas list ==<br />
This is the list of project ideas for the summer of code 2020 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has the hierarchical blocks to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
<br />
=== Qt5 GUI Integrations ===<br />
<br />
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization<br />
<br />
'''Prerequisites'''<br />
<br />
* C++, Python proficiency<br />
* Qt experienced<br />
<br />
'''Outcome'''<br />
<br />
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)<br />
* Possible to import generate Qt GUI description file (UIC) into GRC<br />
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph<br />
* Integration of that into GRC-generated Python code<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Müller & Sebastian "GRC-Man" Koslowski<br />
<br />
<br />
<br />
=== Extending and Updating gr-radar ===<br />
<br />
gr-radar (https://github.com/kit-cel/gr-radar/) was a great and successful GSoC project that provided a few methods of radar in GNU Radio. This module is heavily used by academics, researchers, cybersecurity folks, and hobbyists. This project would work to improve upon the concepts already in there as well as add more radar techniques.<br />
<br />
There are uncountable methods and techniques that could be added to this project, such as:<br />
<br />
* SAR / InSAR methods<br />
* Better passive radar support<br />
* Speed camera applications<br />
* Multi-antenna radar techniques<br />
<br />
'''Prerequisites'''<br />
<br />
* Signal processing and some radar basics are required.<br />
* Code is written in C++ with some Python on the side, so the student must be able to handle these languages at the least.<br />
<br />
'''Outcome'''<br />
<br />
* Based on the student's interest, a subset of the radar techniques listed above (or others) are chosen as milestones for this project. <br />
* All code must be merged back into gr-radar by the end of the summer.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Stefan Wunsch, Martin Braun<br />
<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add new widgets<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C+'', so some C''+ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Tim O'Shea<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Android ===<br />
<br />
One effort of the past years was to improve Android support for GNU Radio. We're getting to a point where we've figured out '''how''' to do it, so the next step is to make it more accessible to users and developers.<br />
<br />
The Android ecosystem is an entirely different beast from the rest of GNU Radio. To make writing Android/GR apps easy, the following needs to happen (and shall be part of this project):<br />
<br />
* Improve support for development environment<br />
** Create Dockers for easy start of development<br />
* Visualization classes for PSD, spectrogram and oscilloscope<br />
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs<br />
* Interactivity concepts<br />
** Gestures and config for radio parameters (e.g., freq, gain, bandwidth)<br />
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures<br />
<br />
You can find a summary of the work that has been done on this (years ago) here: [[Android]]<br />
<br />
'''Prerequisites'''<br />
<br />
* Some Android experience<br />
* Enjoy writing GUI widgets<br />
* C++/Java experience<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput).<br />
This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our sever, allowing us to crowdsource data. (Similar to our [http://stats.gnuradio.org/ online stats] for SIMD performance.)<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Setup automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web sever.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl, Marcus Mueller<br />
<br />
=== Filter Design Tool Enhancements ===<br />
<br />
GNU Radio provides many tools to design and use digital filters. Using these tools requires both some expertise in these areas as well as an understanding of the performance on the given platform. One example is the selection between FIR (convolution-based) and FFT (fast convolution-based) filters for different resampling rates. Another example is doing stages of filter decomposition when doing large down-sampling. Included in this is the polyphase filterbanks, which again are provided as primitive blocks that need tweaking to work.<br />
<br />
This project is to improve our uses of these tools and blocks to make it more obvious to the users as well as automate some of the decisions for optimally using them. Some pointers:<br />
<br />
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.<br />
* It still currently runs on PyQWT, which is obsolete and needs to be updated to Qt5<br />
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui<br />
* Add more support for filter design concepts and other filters.<br />
** Cascaded filters<br />
** Better support for creating PFB filters<br />
<br />
'''Prerequisites'''<br />
<br />
* Strong DSP background required.<br />
* Python and QT knowledge highly useful (at least one of those is a must).<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Leech<br />
<br />
<br />
<br />
=== Implement SigMF functionality for the GNU Radio Ecosystem ===<br />
<br />
SigMF is the "Signal Metadata Format" that was defined during the 2017 DARPA Hackfest in Brussels. Its purpose is to annotate raw binary dumps of signals with metadata, thus giving meaning to a raw mass of samples.<br /><br />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf<br />
There is an out-of-tree module providing SigMF functionality for GNU Radio as well: https://github.com/skysafe/gr-sigmf<br />
<br />
However, SigMF is not represented well in the GNU Radio tooling landscape. Therefore, a subset of tools can be extended by SigMF support. Incomplete lists of possible tools benefitting from SigMF support:<br />
<br />
* qgrx (https://github.com/csete/gqrx)<br />
* inspectrum (https://github.com/miek/inspectrum)<br />
* ...<br />
<br />
Any additional tools are welcome in a proposal.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of the programming language of the covered tools.<br />
* Hands-on experience with the respective tools.<br />
* Familiarity with the SigMF specification.<br />
<br />
'''Outcome'''<br />
<br />
* The tools worked on have capability to load and save files in the SigMF format.<br />
* Depending on the specific tool, SigMF meta data is displayed within the tool.<br />
* The number of tools worked on needs to be determined by the student, depending on his/her experience.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Müller, Andrej Rode<br />
<br />
<br />
<br />
=== Statistical Toolbox for GRC ===<br />
<br />
A statistical toolbox for GRC would enable GUI-based statistical analysis. Currently, such analysis can be done by writing an independent program (e.g., with SciPy), but there is no actual integration with GNU Radio. By developing the statistical toolbox, we provide blocks for probability distribution fitting, hypothesis testing, extracting statistical parameters for one-dimensional as well as multi-dimensional data. This would significantly expand GNU Radio users' ability to perform data-science analysis and modeling on signal data.<br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.<br />
<br />
'''Outcome'''<br />
<br />
* An OOT module that provides statistical analysis capabilities for GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Ben Hilburn<br />
<br />
</div><br />
</div><br />
== Application process ==<br />
<br />
Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].<br />
* Please introduce yourself on the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]<br />
* Fill in the formal application for GNU Radio<br />
* Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=12921GSoCIdeas2023-01-29T19:22:18Z<p>Haakov: Update GSoCIdeas for 2023</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
<br />
== Summer of Code 2023: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2023 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed"><br />
<br />
== Summer of Code 2022: Project ideas list ==<br />
<div class="mw-collapsible-content"><br />
<br />
This is the list of project ideas for the summer of code 2022 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
Sebastian Koslowski,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GNU Radio goes Browser: Web Assembly (WASM) port ===<br />
<br />
<br />
[[File:WASM-preview.jpg|thumb|link=https://mobile.twitter.com/marcnewlin/status/1490577402086313984/photo/1|A view of GRC running on WASM-compiled Python]]<br />
<br />
The main goal of WebAssembly is to enable high-performance applications on web pages. Originally quite restricted to single-threaded applications, only interacting with the browser's notion of the world through a JavaScript interaction layer, today it has become quite capable, with support for threads, exceptions, SIMD and a lot of other performance-critical features.<br />
<br />
Obviously, that's great news! GNU Radio in the Browser means zero-installation, fully portable SDR for the masses. This GSoC project strives to take Marc Newlin's current work and make something functional, with the big goal of having a fully functional GNU Radio on WASM.<br />
<br />
This project has subprojects, from which the student is to pick '''one''':<br />
<br />
* porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted set of intrinsics<br />
* working to bring GRC in the feature-grc-qt branch to parity with GRC in main<br />
* WebUSB driver porting (I have prototyped standalone drivers for UHD, HackRF and PlutoSDR which haven't get been integrated, and then porting gr-osmosdr would be awesome). <br />
* creating blocks for ZMQ over websockets<br />
<br />
in addition to making a (minimal) web page to which the current development state can be tested on, updated automatically from Github.<br />
<br />
'''Steps'''<br />
<br />
* Make (and test!) Marc Newlin's WASM build locally<br />
* Add a CI step to build a WASM binary<br />
* Implement one of the points above<br />
* Implement a suitable demonstration for it and deploy<br />
<br />
'''Prerequisites'''<br />
<br />
* Basic knowledge of Python<br />
* Working (especially, reading) knowledge of C++<br />
* Basic knowledge of WASM <br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marc Newlin<br />
* Marcus Müller<br />
* Depending on topic: further member of the GNU Radio community<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed"><br />
<br />
== Summer of Code 2021: Project ideas list ==<br />
<div class="mw-collapsible-content"><br />
<br />
This is the list of project ideas for the summer of code 2021 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
'''The time a student can spend on a GSoC project has been reduced by 50% for 2021 - keep this in mind when submitting your ideas'''<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
=== Standardized High Throughput FEC Codes ===<br />
<br />
Channel coding is essential to modern communications. Also, it is computationally very heavy. As of now, there exist implementations in GNU Radio which are too slow to be integrated into high throughput applications. GNU Radio would benefit from integration of standardized decoders for Turbo and LDPC codes. These codes would only support a certain subset of the whole code class but would be well optimized. <br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.<br />
<br />
'''Outcome'''<br />
<br />
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.<br />
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Johannes Demel<br />
<br />
<br />
=== GRC: View-Only Mode (Secure) ===<br />
<br />
When a flowgraph from an untrusted source is opened if GRC, arbitrary Python code can be executed. This poses a potential security risk. Storing the all evaluated values of all parameters within a flow graph (.grc) file would allow us to open such flow graphs without compromising security. No code would be have to executed to draw the flow graph and block parameters can be viewed safely. Only if the flow graph is modified the user would have to choose to trust the flow graph thus enabling normal eval operations.<br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is implemented using Python. So, Python should be known pretty well.<br />
<br />
'''Outcome'''<br />
<br />
* Safely view other people's flowgraphs without putting your PC at risk.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===<br />
<br />
Even though the 8b10b line coding is primarily used for byte-level synchronization and spectral shaping, it adds some redundancy to the data, so it can be used as a forward error correction method to fix some bit errors in the received data. From the perspective of the decoder there is one bit of hidden state, so 8b10b line coding is amenable to Viterbi decoding, as hinted in [http://www.bigideatrouble.com/AMSAT%202013%20FOX1%20Paper.pdf this document about the AMSAT FOX satellites]. One goal of this project is to create Viterbi decoder block(s) for 8b10b and possibly other similar line codes, so that these blocks can be eventually upstreamed in-tree. The error correction performance of this method will be studied using simulations with these blocks. The second goal is to use the Viterbi decoder and gr-satellites to create a full decoder for the FOX satellites from AMSAT.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python. Some basic understanding about FEC in general.<br />
<br />
'''Outcome'''<br />
<br />
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites<br />
<br />
'''Mentor(s)'''<br />
<br />
* Daniel Estévez<br />
<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput). This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our server, allowing us to crowdsource data. (Similar to our online stats for SIMD performance.)<br />
<br />
'''Outcome'''<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Set up automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web server.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
*Bastian Bloessl<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed"><br />
<br />
== Summer of Code 2020: Project ideas list ==<br />
<div class="mw-collapsible-content"><br />
This is the list of project ideas for the summer of code 2020 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has the hierarchical blocks to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
<br />
=== Qt5 GUI Integrations ===<br />
<br />
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization<br />
<br />
'''Prerequisites'''<br />
<br />
* C++, Python proficiency<br />
* Qt experienced<br />
<br />
'''Outcome'''<br />
<br />
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)<br />
* Possible to import generate Qt GUI description file (UIC) into GRC<br />
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph<br />
* Integration of that into GRC-generated Python code<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Müller & Sebastian "GRC-Man" Koslowski<br />
<br />
<br />
<br />
=== Extending and Updating gr-radar ===<br />
<br />
gr-radar (https://github.com/kit-cel/gr-radar/) was a great and successful GSoC project that provided a few methods of radar in GNU Radio. This module is heavily used by academics, researchers, cybersecurity folks, and hobbyists. This project would work to improve upon the concepts already in there as well as add more radar techniques.<br />
<br />
There are uncountable methods and techniques that could be added to this project, such as:<br />
<br />
* SAR / InSAR methods<br />
* Better passive radar support<br />
* Speed camera applications<br />
* Multi-antenna radar techniques<br />
<br />
'''Prerequisites'''<br />
<br />
* Signal processing and some radar basics are required.<br />
* Code is written in C++ with some Python on the side, so the student must be able to handle these languages at the least.<br />
<br />
'''Outcome'''<br />
<br />
* Based on the student's interest, a subset of the radar techniques listed above (or others) are chosen as milestones for this project. <br />
* All code must be merged back into gr-radar by the end of the summer.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Stefan Wunsch, Martin Braun<br />
<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add new widgets<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C+'', so some C''+ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Tim O'Shea<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Android ===<br />
<br />
One effort of the past years was to improve Android support for GNU Radio. We're getting to a point where we've figured out '''how''' to do it, so the next step is to make it more accessible to users and developers.<br />
<br />
The Android ecosystem is an entirely different beast from the rest of GNU Radio. To make writing Android/GR apps easy, the following needs to happen (and shall be part of this project):<br />
<br />
* Improve support for development environment<br />
** Create Dockers for easy start of development<br />
* Visualization classes for PSD, spectrogram and oscilloscope<br />
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs<br />
* Interactivity concepts<br />
** Gestures and config for radio parameters (e.g., freq, gain, bandwidth)<br />
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures<br />
<br />
You can find a summary of the work that has been done on this (years ago) here: [[Android]]<br />
<br />
'''Prerequisites'''<br />
<br />
* Some Android experience<br />
* Enjoy writing GUI widgets<br />
* C++/Java experience<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput).<br />
This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our sever, allowing us to crowdsource data. (Similar to our [http://stats.gnuradio.org/ online stats] for SIMD performance.)<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Setup automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web sever.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl, Marcus Mueller<br />
<br />
=== Filter Design Tool Enhancements ===<br />
<br />
GNU Radio provides many tools to design and use digital filters. Using these tools requires both some expertise in these areas as well as an understanding of the performance on the given platform. One example is the selection between FIR (convolution-based) and FFT (fast convolution-based) filters for different resampling rates. Another example is doing stages of filter decomposition when doing large down-sampling. Included in this is the polyphase filterbanks, which again are provided as primitive blocks that need tweaking to work.<br />
<br />
This project is to improve our uses of these tools and blocks to make it more obvious to the users as well as automate some of the decisions for optimally using them. Some pointers:<br />
<br />
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.<br />
* It still currently runs on PyQWT, which is obsolete and needs to be updated to Qt5<br />
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui<br />
* Add more support for filter design concepts and other filters.<br />
** Cascaded filters<br />
** Better support for creating PFB filters<br />
<br />
'''Prerequisites'''<br />
<br />
* Strong DSP background required.<br />
* Python and QT knowledge highly useful (at least one of those is a must).<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Leech<br />
<br />
<br />
<br />
=== Implement SigMF functionality for the GNU Radio Ecosystem ===<br />
<br />
SigMF is the "Signal Metadata Format" that was defined during the 2017 DARPA Hackfest in Brussels. Its purpose is to annotate raw binary dumps of signals with metadata, thus giving meaning to a raw mass of samples.<br /><br />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf<br />
There is an out-of-tree module providing SigMF functionality for GNU Radio as well: https://github.com/skysafe/gr-sigmf<br />
<br />
However, SigMF is not represented well in the GNU Radio tooling landscape. Therefore, a subset of tools can be extended by SigMF support. Incomplete lists of possible tools benefitting from SigMF support:<br />
<br />
* qgrx (https://github.com/csete/gqrx)<br />
* inspectrum (https://github.com/miek/inspectrum)<br />
* ...<br />
<br />
Any additional tools are welcome in a proposal.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of the programming language of the covered tools.<br />
* Hands-on experience with the respective tools.<br />
* Familiarity with the SigMF specification.<br />
<br />
'''Outcome'''<br />
<br />
* The tools worked on have capability to load and save files in the SigMF format.<br />
* Depending on the specific tool, SigMF meta data is displayed within the tool.<br />
* The number of tools worked on needs to be determined by the student, depending on his/her experience.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Müller, Andrej Rode<br />
<br />
<br />
<br />
=== Statistical Toolbox for GRC ===<br />
<br />
A statistical toolbox for GRC would enable GUI-based statistical analysis. Currently, such analysis can be done by writing an independent program (e.g., with SciPy), but there is no actual integration with GNU Radio. By developing the statistical toolbox, we provide blocks for probability distribution fitting, hypothesis testing, extracting statistical parameters for one-dimensional as well as multi-dimensional data. This would significantly expand GNU Radio users' ability to perform data-science analysis and modeling on signal data.<br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.<br />
<br />
'''Outcome'''<br />
<br />
* An OOT module that provides statistical analysis capabilities for GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Ben Hilburn<br />
<br />
</div><br />
</div><br />
== Application process ==<br />
<br />
Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].<br />
* Please introduce yourself on the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]<br />
* Fill in the formal application for GNU Radio<br />
* Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12435GRC C++ Generation2022-08-16T21:56:08Z<p>Haakov: /* Enabling C++ Output */</p>
<hr />
<div>Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call CMake and Make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal, in case you need to examine error messages or make some manual adjustments to the generated files. <br />
<br />
== Enabling C++ Output ==<br />
<br />
C++ output for a flowgraph can be enabled by changing the Output Language parameter of the Options block from Python to C++ and pressing OK. <br />
<br />
[[File:Grc_cpp.png|upright=2.0|The Options block parameters]]<br />
<br />
That's all, given that the blocks in your flowgraph support C++ output. If they don't, please see the next section about adding C++ templates. Note that two new parameters are visible, namely Generate CMakeLists.txt and CMake Options. The first one is useful if you've written your own CMakeLists.txt (and don't want GRC to overwrite it), while the second parameter is used to pass command line arguments to CMake. For example, if you want to compile your app with the debug flag set, write <syntaxhighlight inline>"-DCMAKE_BUILD_TYPE=Debug"</syntaxhighlight>. This ends up as the following line in the resulting CMakeLists.txt:<br />
<br />
<syntaxhighlight><br />
set(CMAKE_BUILD_TYPE Debug)<br />
</syntaxhighlight><br />
<br />
Once you've generated your C++ flowgraph, you can navigate to the generated files, enter the build directory, run <syntaxhighlight inline>cmake ..</syntaxhighlight> and then <syntaxhighlight inline>make</syntaxhighlight>. If all goes well, your flowgraph will show up in executable form in your build directory.<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
'''Note:''' C++ generation requires that the block's implementation is written in C++, which most blocks are. However, some blocks are purely written in Python, and these can't produce C++ code. You might want to use a different block.<br />
<br />
Some blocks don't have C++ templates yet. However, adding C++ templates is often quite simple. This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-17"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
The translations field might not be necessary for your block, it is used here to de-capitalize the boolean selector parameter. Next, you can follow the C++ OOT guide (e.g. cmake, make, make install) to compile the module. Once this has been done, you can load the updated block information into GRC by pressing the Reload Blocks button or restarting GRC.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
==== Generate Error: (NameError("(...) is not defined") ====<br />
<br />
This error is actually not C++-specific. It appears if you use a variable that is not defined, this is usually caused by typos. In the context of the multDivSelect block, the following line would cause a NameError:<br />
<br />
<syntaxhighlight lang="c++"><br />
cpp_templates:<br />
(...)<br />
make: 'this->${id} = customModule::multDivSelect::make(${selllector});'<br />
(...)<br />
</syntaxhighlight><br />
<br />
==== This block does not support C++ output ====<br />
<br />
The block does not have the cpp flag set, which can be found near the start of the YAML file (line 4 in the example above). This usually means that the block does not have C++ templates either. You can try writing the templates yourself, or create an issue on Github and ask for someone else to do it.<br />
<br />
=== Compilation Issues ===<br />
<br />
==== ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
==== undefined reference to (...) ====<br />
<br />
There is something missing in the target_link_libraries() call in your flowgraph's CMakeLists.txt, which means that there is a problem with your block YAML's link field. Try gnuradio::gnuradio-qtgui (in-tree blocks) or gnuradio-customModule (OOT blocks). Replace qtgui or customModule with the actual module's name.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12434GRC C++ Generation2022-08-16T21:55:15Z<p>Haakov: /* Switching Between Python and C++ Output */</p>
<hr />
<div>Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call CMake and Make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal, in case you need to examine error messages or make some manual adjustments to the generated files. <br />
<br />
== Enabling C++ Output ==<br />
<br />
C++ output for a flowgraph can be enabled by changing the Output Language parameter of the Options block from Python to C++ and pressing OK. <br />
<br />
[[File:Grc_cpp.png|upright=2.0|The Options block parameters]]<br />
<br />
That's all, given that the blocks in your flowgraph support C++ output. If they don't, please see the next section about adding C++ templates. Note that two new parameters are visible, namely Generate CMakeLists.txt and CMake Options. The first one is useful if you've written your own CMakeLists.txt (and don't want GRC to overwrite it), while the second parameter is used to pass command line arguments to CMake. For example, if you want to compile your app with the debug flag set, write "-DCMAKE_BUILD_TYPE=Debug". This ends up as the following line in the resulting CMakeLists.txt:<br />
<br />
<syntaxhighlight><br />
set(CMAKE_BUILD_TYPE Debug)<br />
</syntaxhighlight><br />
<br />
Once you've generated your C++ flowgraph, you can navigate to the generated files, enter the build directory, run <syntaxhighlight inline>cmake ..</syntaxhighlight> and then <syntaxhighlight inline>make</syntaxhighlight>. If all goes well, your flowgraph will show up in executable form in your build directory.<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
'''Note:''' C++ generation requires that the block's implementation is written in C++, which most blocks are. However, some blocks are purely written in Python, and these can't produce C++ code. You might want to use a different block.<br />
<br />
Some blocks don't have C++ templates yet. However, adding C++ templates is often quite simple. This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-17"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
The translations field might not be necessary for your block, it is used here to de-capitalize the boolean selector parameter. Next, you can follow the C++ OOT guide (e.g. cmake, make, make install) to compile the module. Once this has been done, you can load the updated block information into GRC by pressing the Reload Blocks button or restarting GRC.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
==== Generate Error: (NameError("(...) is not defined") ====<br />
<br />
This error is actually not C++-specific. It appears if you use a variable that is not defined, this is usually caused by typos. In the context of the multDivSelect block, the following line would cause a NameError:<br />
<br />
<syntaxhighlight lang="c++"><br />
cpp_templates:<br />
(...)<br />
make: 'this->${id} = customModule::multDivSelect::make(${selllector});'<br />
(...)<br />
</syntaxhighlight><br />
<br />
==== This block does not support C++ output ====<br />
<br />
The block does not have the cpp flag set, which can be found near the start of the YAML file (line 4 in the example above). This usually means that the block does not have C++ templates either. You can try writing the templates yourself, or create an issue on Github and ask for someone else to do it.<br />
<br />
=== Compilation Issues ===<br />
<br />
==== ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
==== undefined reference to (...) ====<br />
<br />
There is something missing in the target_link_libraries() call in your flowgraph's CMakeLists.txt, which means that there is a problem with your block YAML's link field. Try gnuradio::gnuradio-qtgui (in-tree blocks) or gnuradio-customModule (OOT blocks). Replace qtgui or customModule with the actual module's name.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12433GRC C++ Generation2022-08-16T21:46:09Z<p>Haakov: </p>
<hr />
<div>Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call CMake and Make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal, in case you need to examine error messages or make some manual adjustments to the generated files. <br />
<br />
== Switching Between Python and C++ Output ==<br />
<br />
C++ output for a flowgraph can be enabled by changing the Output Language parameter of the Options block from Python to C++ and pressing OK. <br />
<br />
[[File:Grc_cpp.png|upright=2.0|The Options block parameters]]<br />
<br />
That's all, given that the blocks in your flowgraph support C++ output. Note that two new parameters are visible, namely Generate CMakeLists.txt and CMake Options. The first one is useful if you've written your own CMakeLists.txt (and don't want GRC to overwrite it), while the second parameter is used to pass command line arguments to CMake. For example, if you want to compile your app with the debug flag set, write "-DCMAKE_BUILD_TYPE=Debug". This ends up as the following line in the resulting CMakeLists.txt:<br />
<br />
<syntaxhighlight><br />
set(CMAKE_BUILD_TYPE Debug)<br />
</syntaxhighlight><br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
'''Note:''' C++ generation requires that the block's implementation is written in C++, which most blocks are. However, some blocks are purely written in Python, and these can't produce C++ code. You might want to use a different block.<br />
<br />
Some blocks don't have C++ templates yet. However, adding C++ templates is often quite simple. This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-17"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
The translations field might not be necessary for your block, it is used here to de-capitalize the boolean selector parameter. Next, you can follow the C++ OOT guide (e.g. cmake, make, make install) to compile the module. Once this has been done, you can load the updated block information into GRC by pressing the Reload Blocks button or restarting GRC.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
==== Generate Error: (NameError("(...) is not defined") ====<br />
<br />
This error is actually not C++-specific. It appears if you use a variable that is not defined, this is usually caused by typos. In the context of the multDivSelect block, the following line would cause a NameError:<br />
<br />
<syntaxhighlight lang="c++"><br />
cpp_templates:<br />
(...)<br />
make: 'this->${id} = customModule::multDivSelect::make(${selllector});'<br />
(...)<br />
</syntaxhighlight><br />
<br />
==== This block does not support C++ output ====<br />
<br />
The block does not have the cpp flag set, which can be found near the start of the YAML file (line 4 in the example above). This usually means that the block does not have C++ templates either. You can try writing the templates yourself, or create an issue on Github and ask for someone else to do it.<br />
<br />
=== Compilation Issues ===<br />
<br />
==== ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
==== undefined reference to (...) ====<br />
<br />
There is something missing in the target_link_libraries() call in your flowgraph's CMakeLists.txt, which means that there is a problem with your block YAML's link field. Try gnuradio::gnuradio-qtgui (in-tree blocks) or gnuradio-customModule (OOT blocks). Replace qtgui or customModule with the actual module's name.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=File:Grc_cpp.png&diff=12432File:Grc cpp.png2022-08-16T21:19:53Z<p>Haakov: The Options block with parameter dialog. Zoomed in on the C++ generation parameters.</p>
<hr />
<div>== Summary ==<br />
The Options block with parameter dialog. Zoomed in on the C++ generation parameters.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12430GRC C++ Generation2022-08-14T21:15:46Z<p>Haakov: </p>
<hr />
<div>Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal. C++ output for a flowgraph can be enabled by changing the Output Language parameter of the Options block from Python to C++ and pressing OK. That's all, given that the blocks in your flowgraph support C++ output. <br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
'''Note:''' C++ generation requires that the block's implementation is written in C++, which most blocks are. However, some blocks are purely written in Python, and these can't produce C++ code. You might want to use a different block.<br />
<br />
Some blocks don't have C++ templates yet. However, adding C++ templates is often quite simple. This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-17"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
The translations field might not be necessary for your block, it is used here to de-capitalize the boolean selector parameter. Next, you can follow the C++ OOT guide (e.g. cmake, make, make install) to compile the module. Once this has been done, you can load the updated block information into GRC by pressing the Reload Blocks button or restarting GRC.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
==== Generate Error: (NameError("(...) is not defined") ====<br />
<br />
This error is actually not C++-specific. It appears if you use a variable that is not defined, this is usually caused by typos. In the context of the multDiv block, the following line would cause a NameError:<br />
<br />
<syntaxhighlight lang="c++"><br />
cpp_templates:<br />
(...)<br />
make: 'this->${id} = customModule::multDivSelect::make(${selllector});'<br />
(...)<br />
</syntaxhighlight><br />
<br />
==== This block does not support C++ output ====<br />
<br />
The block does not have the cpp flag set, which can be found near the start of the YAML file (line 4 in the example above). This usually means that the block does not have C++ templates either. You can try writing the templates yourself, or create an issue on Github and ask for someone else to do it.<br />
<br />
=== Compilation Issues ===<br />
<br />
==== ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
==== undefined reference to (...) ====<br />
<br />
There is something missing in the target_link_libraries() call in your flowgraph's CMakeLists.txt. Your block YAML's link field is probably incorrect. Try gnuradio::gnuradio-qtgui (in-tree blocks) or gnuradio-customModule (OOT blocks). Replace qtgui or customModule with the actual module's name.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12429GRC C++ Generation2022-08-14T17:59:11Z<p>Haakov: /* This block does not support C++ output */</p>
<hr />
<div>Note: This page is a work in progress.<br />
<br />
Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal.<br />
<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-17"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
The translations field might not be necessary for your block, it is used here to de-capitalize the boolean selector parameter. Next, you can follow the C++ OOT guide (e.g. cmake, make, make install) to compile the module. Once this has been done, you can load the updated block information into GRC by pressing the Reload Blocks button or restarting GRC.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
==== This block does not support C++ output ====<br />
<br />
The block does not have the cpp flag set, which can be found near the start of the YAML file (line 4 in the example above). This usually means that the block does not have C++ templates either. You can try writing the templates yourself, or create an issue on Github and ask for someone else to do it.<br />
<br />
=== Compilation Issues ===<br />
<br />
==== ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12428GRC C++ Generation2022-08-14T15:16:57Z<p>Haakov: </p>
<hr />
<div>Note: This page is a work in progress.<br />
<br />
Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal.<br />
<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-17"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
The translations field might not be necessary for your block, it is used here to de-capitalize the boolean selector parameter. Next, you can follow the C++ OOT guide (e.g. cmake, make, make install) to compile the module. Once this has been done, you can load the updated block information into GRC by pressing the Reload Blocks button or restarting GRC.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
==== This block does not support C++ output ====<br />
<br />
The block does not have the cpp flag set, which can be found near the start of the YAML file. This usually means that the block does not have C++ templates either. You can try writing the templates yourself, or create an issue on Github and ask for someone else to do it.<br />
<br />
=== Compilation Issues ===<br />
<br />
==== ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12427GRC C++ Generation2022-08-14T15:11:58Z<p>Haakov: /* Adding C++ Templates to a Block */</p>
<hr />
<div>Note: This page is a work in progress.<br />
<br />
Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal.<br />
<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-17"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
The translations field might not be necessary for your block, it is used here to de-capitalize the boolean selector parameter. Next, you can follow the C++ OOT guide (e.g. cmake, make, make install) to compile the module. Once this has been done, you can load the updated block information into GRC by pressing the Reload Blocks button or restarting GRC.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
=== Compilation Issues ===<br />
<br />
==== error: ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12426GRC C++ Generation2022-08-14T09:06:11Z<p>Haakov: /* Adding C++ Templates to a Block */</p>
<hr />
<div>Note: This page is a work in progress.<br />
<br />
Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal.<br />
<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-14"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
=== Compilation Issues ===<br />
<br />
==== error: ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12425GRC C++ Generation2022-08-14T09:02:47Z<p>Haakov: /* Compilation Issues */</p>
<hr />
<div>Note: This page is a work in progress.<br />
<br />
Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal.<br />
<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-14"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
=== Compilation Issues ===<br />
<br />
==== error: ‘True’ was not declared in this scope ====<br />
<br />
<syntaxhighlight lang="c++"><br />
Consolidate compiler generated dependencies of target cpptest<br />
[ 50%] Building CXX object CMakeFiles/cpptest.dir/cpptest.cpp.o<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp: In constructor ‘cpptest::cpptest()’:<br />
/home/hkon/oot/gr-customModule/build/cpptest/cpptest.cpp:37:80: error: ‘True’ was not declared in this scope<br />
37 | this->customModule_multDivSelect_0 = customModule::multDivSelect::make(True);<br />
| ^~~~<br />
make[2]: *** [CMakeFiles/cpptest.dir/build.make:90: CMakeFiles/cpptest.dir/cpptest.cpp.o] Error 1<br />
</syntaxhighlight><br />
<br />
In C++, the boolean type is either true or false (lowercase), while the corresponding Python type is True or False. Try adding a translations field to the cpp_templates:<br />
<br />
<syntaxhighlight lang="yaml"><br />
cpp_templates:<br />
(...)<br />
translations:<br />
'True': 'true'<br />
'False': 'false'<br />
</syntaxhighlight><br />
<br />
GRC will do a search and replace operation on your block's generated code, replacing all instances of True and False with true and false, respectively.<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12424GRC C++ Generation2022-08-14T08:33:03Z<p>Haakov: </p>
<hr />
<div>Note: This page is a work in progress.<br />
<br />
Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. However, it is often convenient to compile and run your flowgraph in a separate terminal.<br />
<br />
<br />
== Adding C++ Templates to a Block ==<br />
<br />
This guide builds on the [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool C++ OOT guide]. The steps listed here will fall between [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Modifying_the_YAML_.yml_File Modifying the YAML file] and [https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool#Compiling_and_Installing_the_Block Compiling_and_Installing_the_Block]. <br />
<br />
In order to enable C++ generation for our multDivSelect block, we need to add some additional lines to the YAML file (comments have been removed for brevity):<br />
<br />
<syntaxhighlight lang="yaml" line="line" highlight="4, 10-14"><br />
id: customModule_multDivSelect<br />
label: multDivSelect<br />
category: '[customModule]'<br />
flags: [cpp]<br />
<br />
templates:<br />
imports: from gnuradio import customModule<br />
make: customModule.multDivSelect(${selector})<br />
<br />
cpp_templates:<br />
includes: ['#include <gnuradio/customModule/multDivSelect.h>']<br />
declarations: 'customModule::multDivSelect::sptr ${id};'<br />
link: ['gnuradio-customModule']<br />
make: 'this->${id} = customModule::multDivSelect::make(${selector});'<br />
<br />
parameters:<br />
- id: selector<br />
label: Selector, Multiply (true) or Divide (false)<br />
dtype: bool<br />
default: true<br />
<br />
inputs:<br />
- label: in0<br />
domain: stream<br />
dtype: complex<br />
- label: in1<br />
domain: stream<br />
dtype: complex<br />
outputs:<br />
- label: out0<br />
domain: stream<br />
dtype: complex<br />
<br />
file_format: 1</syntaxhighlight><br />
<br />
<br />
<br />
== Troubleshooting ==<br />
<br />
=== Generation Issues ===<br />
<br />
=== Compilation Issues ===<br />
<br />
=== Runtime Issues ===</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GRC_C%2B%2B_Generation&diff=12423GRC C++ Generation2022-08-14T08:10:34Z<p>Haakov: Created page with "Note: This page is a work in progress. Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C..."</p>
<hr />
<div>Note: This page is a work in progress.<br />
<br />
Starting from GNU Radio 3.8, GRC allows you to generate C++ code (not just Python) from your flowgraph. This feature was a SOCIS (ESA Summer of Code in Space) project in 2017. The C++ generation mode is significantly less stable and feature-rich than the default Python mode, since Python is a far more flexible language (and since GRC was created to generate Python code). About 50% of the in-tree blocks support C++ generation. The C++ generation templates have to be written on a per-block basis, which is a considerable amount of work. This also means that it is a considerable amount of work to keep the C++ templates updated, which is why some blocks' templates may be outdated and produce errors. The good news is that these errors often have trivial fixes.<br />
<br />
GRC generates C++ code by creating a new directory with three files:<br />
<br />
* top_block.cpp<br />
* top_block.hpp<br />
* CMakeLists.txt<br />
<br />
All of these files are generated from templates, and changes in your flowgraph will be reflected in them. Additionally, GRC creates a build directory which you can call cmake and make from. Pressing the execute button in GRC will generate, compile and run your flowgraph. <br />
<br />
https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool<br />
<br />
= Adding C++ Templates to a Block =<br />
<br />
lorem ipsum<br />
<br />
= Troubleshooting =<br />
<br />
== Generation Issues ==<br />
<br />
== Compilation Issues ==<br />
<br />
== Runtime Issues ==</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCStudentInfo&diff=11859GSoCStudentInfo2022-03-12T11:00:23Z<p>Haakov: /* GSoC - Information for students */</p>
<hr />
<div>= GSoC - Information for students =<br />
<br />
Here's the most important steps of applying for GSoC with GNU Radio:<br />
<br />
* Read this '''entire''' page before submitting applications. We will not consider your application otherwise.<br />
* Read Google's [https://developers.google.com/open-source/gsoc/faq FAQ]<br />
* Take a look at our [[GSoCIdeas|list of ideas]]<br />
* Come up with project that you're interested in (be it on the list or not!)<br />
* Write a first draft proposal and get someone to review it for you (perhaps one of the mentors)<br />
* Submit it using Google's web interface<br />
* '''Important: Make sure you have followed all the instructions on this page. Failing to do so will cause us to ignore your proposal, as we usually have many more applicants than we have slots!'''<br />
<br />
For accepted students, we have guidelines in place for during GSoC, see our [[GSoCManifest|rules of conduct]] page.<br />
<br />
== Student/Contributor Eligibility ==<br />
<br />
'''This year (2022), students no longer need to be enrolled at a university to be eligible for GSoC.'''<br />
<br />
The formal requirements are that you:<br />
<br />
* must be at least 18 years old at time of registration.<br />
* must be an open source beginner.<br />
* must be eligible to work in your country of residence during the duration of program.<br />
* must be a resident of a country not currently embargoed by the United States. <br />
<br />
== The Project ==<br />
<br />
Choose a project that suits you. We have project ideas on our GSoC page you can choose from, but you can also submit your own ideas. If you do so, tell us early enough about that! It is also OK to use the ideas as a rough guideline for your project, but to vary from that.<br />
<br />
Note that if you submit your own idea, even if it's awesome, there might be no mentor who has the technical know-how to supervise that, or simply no-one who want to supervise that specific project. If you post your idea early enough, this is usually not a problem, though.<br />
<br />
Whatever you do, it is very important that you understand the project you'll be working on. Proving that you understand the problem is basically the first hurdle for you to get our attention.<br />
<br />
You can submit several applications for GNU Radio, so if there are several projects you feel like doing, submit one for each project. Time has shown that it's usually better to eventually focus on one proposal, because it's already quite some work to get one excellent proposal finished.<br />
<br />
== The Proposal ==<br />
<br />
The proposal, which you submit to the GSoC page, is the single most important part of your application.<br /><br />
In the time before the proposal submission, you should contact the GNU Radio mailing list.<br /><br />
The mentors (and other community members) will give you some feedback on your proposal, but that does mean you have to have to actually write a proposal on which you can get feedback.<br />
<br />
It might seem odd to publically announce an unfinished proposal. You might be concerned that other students will read and copy your proposal. However, in the past, that has never happened. Students who submit early, and gather feedback, have always been the most successful students. We recommend having a proposal e.g. as a Google doc, or on an site like github, and treat it like open source software. Experience has shown that your chances are better if you start early with a '''publicly available proposal''' than developing your proposal trying to do it in private.<br />
<br />
An example of a successful proposal from 2012 can be [https://github.com/zeroXzero/gsoc_proposals/blob/master/filter_enhancements.pdf?raw=true found here (filter design)].<br />
<br />
The following things '''must''' be in the proposal, or it is considered incomplete and will not be considered for acceptance! We will simply mark your proposal as 'incomplete' and ignore communications from you.<br />
<br />
=== Topic background ===<br />
<br />
If there's any theory necessary for your project, include some pointers and explain the basics. Prove to us that you know what you're talking about.<br />
<br />
Something like this is good:<br />
<br />
> Herring-Codes were initially proposed in the seminal paper "Herring-Codes in a fishy radio environment" [1]. They are based on the mathematical theory that...<br />
<br />
Also, you should start getting a good idea about what's available in GNU Radio and other projects. This means you should have a look at the source code of GNU Radio. Here's an idea:<br />
<br />
> In GNU Radio, there are codes available in the component <code>gr-fec</code>. Having looked at the available blocks, it is clear that the available blocks in <code>gr-fec</code>, such as the ccsds_27_bb blocks, cannot trivially be modified to include Herring-Codes. It therefore makes sense to add these to GNU Radio.<br />
<br />
One major difference between some free software projects and GNU Radio is that the required technical background can be quite daunting, up to a point where some GSoC projects can't possibly be worked upon by people without a communications engineering background. However, we try to make GSoC accessible to all clever students, and have a variety of topics available.<br />
<br />
Important: This is the summer of code, '''not the summer of research'''! Your first goal must be coded deliverables. If it is possible to get some research done at the same time, or even write a paper on the subject, that's fantastic. But don't forget the code!<br />
<br />
=== The Deliverables ===<br />
<br />
Inside the proposal, your deliverables are the most important thing.<br /><br />
Clearly outline what you are planning to code, including the platform (host or USRP?) and the programming language (VHDL, C++, Python?).<br /><br />
Don't be vague! The following is not a good deliverable:<br />
<br />
* Deliverable 1: Include Herring-Codes in GNU Radio<br />
<br />
Rather, write it like this:<br />
<br />
* Deliverable 0: Create on out-of-tree module for Herring codes (<code>gr-herring</code>), using gr-modtool.<br />
* Deliverable 1: Add blocks for Herring codes (written in C++). This will require two blocks (<code>herring_X</code> and <code>herring_Y</code>), with the specs shown in Fig Z.<br />
<br />
Also, write what you're not doing if it's not explicitly clear. Something like this would be OK:<br />
<br />
* Often, Herring-Codes are mentioned in connection with Trout-Codes. These will not be included in <code>gr-herring</code>.<br />
<br />
=== License ===<br />
<br />
In most cases, the code submitted must be GPLv3 licensed. In most cases, there is no choice about this (e.g., if you are adding to the GNU Radio main tree, or writing typical OOT-modules). If you want to use another license, do tell us and lay out the reasons. In any case, specify the licence you will be using. This also shows us you care about free software licences and know a bit about them.<br />
<br />
=== Schedule ===<br />
<br />
Check the schedule on the GSoC website. Then figure out how you want to spend the time allocated to coding. Again, be specific - this shows us that you've put some thought into planning your summer. Of course we are aware that plans often need to be changed, so the schedule is of course changeable during the course of GSoC (in coordination with your mentor!).<br />
<br />
Don't forget to include time to write documentation, add QA codes and, most importantly, fix bugs! Don't leave docs etc. for the end.<br />
<br />
Other things to include:<br />
<br />
* How many hours per week are you planning to code? Be honest, and don't forget: we expect you to work full-time on this.<br />
* Is there a period where you won't be coding? During 3 months, it is not unreasonable to have a week 'off' for whatever reason, be it exams or other issues. Just be honest about this, and tell us beforehand.<br />
* Do you have other commitments during the summer that will take time away from coding? Tell us about that!<br />
* How many hours in total (175 or 350) is your project?<br />
* How long is your coding period? It can be anywhere from 10 to 22 weeks. This number can be changed during the coding period, so don't worry too much about it, but you still need to include an estimate in your proposal.<br />
<br />
=== Proof of your coding capabilities / prerequisite capabilities ===<br />
<br />
Despite having close contact with your mentor, it will not be possible to work on a project if you're not already capable of writing code. Depending on the project, you will need different skills, typically C++ and/or Python to a good degree, and sometimes other skills, such as DSP, wireless communication, low-level processor architecture, or something like that.<br />
<br />
Make sure your proposal gives us a way of knowing you're capable of doing these things. For code, the best way is to show us to previous projects of yours (e.g., your github page, contributions to other projects, something like that). For more theoretical subjects, a good way is to explain something in your proposal, in your own words.<br />
<br />
=== Formalities ===<br />
<br />
Include these things (again, these are not optional!):<br />
<br />
* Your name, place of residence<br />
* Your university and students status (are you a grad, undergrad... Note that university enrollment is no longer a requirement!)<br />
* Tell us if your GSoC work is in connection with your university work. Are you getting credit for your GSoC project? (None of this affects whether or not you're selected, we're just curious. It still needs to be in your application).<br />
<br />
Of course, check what Google requires you to reveal about yourself.<br />
<br />
Note that the layout, language etc. of the proposal matter. Make it look good, both content-wise and literally.<br />
<br />
=== Background on yourself ===<br />
<br />
Tell us about yourself. In particular we're interested in your coding history. Also, remember that you will be working closely with one of our mentors for three months, so we want to know what it's like working with you. Show us that you're used to working with other people!<br />
<br />
Also, remember that your mentor might be on another continent, speak another language, live in another time zone. How do you propose working with us? Are you on Skype, G+...?<br />
<br />
Most of the time, you will be speaking English with your mentor (you might get lucky and get a mentor that speaks your language, but be prepared to end up with a mentor of another nationality). Is your English good enough? Tell us about that.<br />
<br />
Proof of your technical proficiency is also required. Point us to your github, or '''show us any code you've produced in the past'''! Don't omit any of these questions:<br />
<br />
* Have you participated in an open source project before? If yes, which one? (If not, explicitly say so! A lot of our previous participants have had little experience in the free software world. Be honest!)<br />
* If you have, we'd like to see specific commits and contributions to those projects, please.<br />
* What code have you written? Upload as much as possible to github before applying, so we can have a look. If there's no code at all, we assume you can't code (and won't consider your application).<br />
* Which languages have you mastered so far?<br />
<br />
Finally, we want to know about your relationship to the GNU Radio community, such as<br />
<br />
* Have you participated in GNU Radio before?<br />
* How are you planning to contribute to GNU Radio after GSoC?<br />
<br />
A neat idea on how to present yourself is to upload a video of yourself explaining something.<br />
<br />
=== Acknowledge the three strikes rule ===<br />
<br />
On our [[GSoCManifest|rules of conduct]] page, we have outlined some rules including the three strikes rule. In your application, make a note that you have acknowledged and understood this rule.<br />
<br />
=== The secret code word ===<br />
<br />
Somewhere in your application, include the secret code word: "Cyberspectrum is the best spectrum". We will scan for this code word and simply not read the rest of your application if we can't find it.<br />
<br />
== Being a community member ==<br />
<br />
First of all: You do '''not''' have to be an active developer of GNU Radio to participate! For us, it's just as important to get new people into the project as it is to actually see the projects being coded, maybe more so. Perhaps you just heard about GNU Radio through GSoC? That's fine!<br />
<br />
However, we '''do''' want to get to know you, and see you integrate into our community. So, once you've decided you want to participate in GSoC, definetely sign up to the mailing list (which is the most important hub for the GNU Radio community).<br /><br />
Introduce yourself, tell us you want to participate and tell us about what you want to do.<br />
<br />
Earlier is better than later. The more time you spend on the list, discussing your and other projects, the more familiar you will be with how the community ticks, and we will get to know you better, as well. We try to be objective when grading proposals, but if someone's already made a good impression and we all know she or he writes good code, that definitely counts in your favour.<br />
<br />
== Working with a mentor (before and during GSoC) ==<br />
<br />
Mentors have the biggest say (next to Google) who participates in GSoC, so be nice to them. Also, mentors are volunteers, and don't get paid for GSoC, unlike you (if you're selected). This means they '''won't''' be working full-time mentoring you, so don't expect them to micro-manage your project.<br />
<br />
For this reason, it is important you prove that you're able to work independently and autonomously (if you and your mentor live in different time zones, you might have a call once a week and some chats/emails in between).<br />
<br />
=== Before the summer of code ===<br />
<br />
* Contact the mailing list, ask for feedback on your proposal, become engaged in the community. Don't spam us, that doesn't look good.<br />
* Make sure they know you're serious about GSoC by asking good questions.<br />
* If necessary, brush up your coding skills and play around with GNU Radio.<br />
<br />
=== During GSoC ===<br />
<br />
* Make sure you have regular contact with your mentor.<br />
* We require weekly updates that are publically visible for the entire community. A blog etc. is a good way to do this.<br />
<br />
== How we grade proposals ==<br />
<br />
The following points are considered when grading proposals:<br />
<br />
* How well do we understand what the student exactly is going to do?<br />
* How likely is success with this project?<br />
* How much does GNU Radio benefit from this project?<br />
* What are the chances of the student becoming an active member of the community after GSoC?<br />
<br />
Of course, all the other things on this page must also be considered.<br />
<br />
== GSoC is good for your education! ==<br />
<br />
[[File:gsoc.jpg|250px]]<br />
<br />
To be very clear here: GSoC is '''not''' part of your degree. If you want to apply in order to "clear GSoC" for your curriculum or whatever, go elsewhere. We want people who are actually passionate about this project, and free software. Sure, it will look good on your CV. But that's not a good motivation to apply here.<br />
<br />
That said, GSoC '''will''' make you smarter. And if your university is cooperative, there's no reason for GSoC and your university education to be mutually exclusive. In the past, universities have often supported GSoC students by giving them access to their labs, or even awarding credit for the project. Being a student is no longer a prerequisite to joining GSoC, but if you are, feel free to talk to us about collaborating, and talk to your university advisor if they are willing to give some support.<br />
<br />
== Hints ==<br />
<br />
There are some good hints on some of these pages from other projects:<br />
<br />
* [http://community.kde.org/GSoC#Hints KDE GSoC page]<br />
* [http://www.postgresql.org/developer/summerofcodeadvice/ PostgreSQL GSoC]<br />
* [http://danielpocock.com/getting-selected-for-google-summer-of-code-2015 Want to be selected for GSoC?] (a generic but very thorough guide, not specific to any one organization)<br />
<br />
Some more hints which have come up over the years:<br />
<br />
* People tend to want to do signal processing stuff. We also like project diversity, and your chances will increase if you apply to work in other areas, such as improving user interfaces (if you do that, a lot of people will be affected by your work; they might buy you beers)<br />
* The more we know about you, the better your chances. Make the proposal a personal matter<br />
* Don't forget the secret code word.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCStudentInfo&diff=11858GSoCStudentInfo2022-03-12T10:55:26Z<p>Haakov: /* Schedule */</p>
<hr />
<div>= GSoC - Information for students =<br />
<br />
Here's the most important steps of applying for GSoC with GNU Radio:<br />
<br />
* Read this '''entire''' page before submitting applications. We will not consider your application otherwise.<br />
* Read Google's [https://developers.google.com/open-source/gsoc/faq FAQ]<br />
* Take a look at our [[GSoCIdeas|list of ideas]]<br />
* Come up with project that you're interested in (be it on the list or not!)<br />
* Write a first draft proposal and get someone to review it for you (perhaps one of the mentors)<br />
* Submit it using Google's web interface<br />
* '''Important: Make sure you have followed all the instructions on this page. Failing to do so will cause us to ignore your proposal, as we usually have many more applicants than we have slots!'''<br />
<br />
For accepted students, we have guidelines in place for during GSoC, see our [[GSoCManifest|rules of conduct]] page.<br />
<br />
== The Project ==<br />
<br />
Choose a project that suits you. We have project ideas on our GSoC page you can choose from, but you can also submit your own ideas. If you do so, tell us early enough about that! It is also OK to use the ideas as a rough guideline for your project, but to vary from that.<br />
<br />
Note that if you submit your own idea, even if it's awesome, there might be no mentor who has the technical know-how to supervise that, or simply no-one who want to supervise that specific project. If you post your idea early enough, this is usually not a problem, though.<br />
<br />
Whatever you do, it is very important that you understand the project you'll be working on. Proving that you understand the problem is basically the first hurdle for you to get our attention.<br />
<br />
You can submit several applications for GNU Radio, so if there are several projects you feel like doing, submit one for each project. Time has shown that it's usually better to eventually focus on one proposal, because it's already quite some work to get one excellent proposal finished.<br />
<br />
== The Proposal ==<br />
<br />
The proposal, which you submit to the GSoC page, is the single most important part of your application.<br /><br />
In the time before the proposal submission, you should contact the GNU Radio mailing list.<br /><br />
The mentors (and other community members) will give you some feedback on your proposal, but that does mean you have to have to actually write a proposal on which you can get feedback.<br />
<br />
It might seem odd to publically announce an unfinished proposal. You might be concerned that other students will read and copy your proposal. However, in the past, that has never happened. Students who submit early, and gather feedback, have always been the most successful students. We recommend having a proposal e.g. as a Google doc, or on an site like github, and treat it like open source software. Experience has shown that your chances are better if you start early with a '''publicly available proposal''' than developing your proposal trying to do it in private.<br />
<br />
An example of a successful proposal from 2012 can be [https://github.com/zeroXzero/gsoc_proposals/blob/master/filter_enhancements.pdf?raw=true found here (filter design)].<br />
<br />
The following things '''must''' be in the proposal, or it is considered incomplete and will not be considered for acceptance! We will simply mark your proposal as 'incomplete' and ignore communications from you.<br />
<br />
=== Topic background ===<br />
<br />
If there's any theory necessary for your project, include some pointers and explain the basics. Prove to us that you know what you're talking about.<br />
<br />
Something like this is good:<br />
<br />
> Herring-Codes were initially proposed in the seminal paper "Herring-Codes in a fishy radio environment" [1]. They are based on the mathematical theory that...<br />
<br />
Also, you should start getting a good idea about what's available in GNU Radio and other projects. This means you should have a look at the source code of GNU Radio. Here's an idea:<br />
<br />
> In GNU Radio, there are codes available in the component <code>gr-fec</code>. Having looked at the available blocks, it is clear that the available blocks in <code>gr-fec</code>, such as the ccsds_27_bb blocks, cannot trivially be modified to include Herring-Codes. It therefore makes sense to add these to GNU Radio.<br />
<br />
One major difference between some free software projects and GNU Radio is that the required technical background can be quite daunting, up to a point where some GSoC projects can't possibly be worked upon by people without a communications engineering background. However, we try to make GSoC accessible to all clever students, and have a variety of topics available.<br />
<br />
Important: This is the summer of code, '''not the summer of research'''! Your first goal must be coded deliverables. If it is possible to get some research done at the same time, or even write a paper on the subject, that's fantastic. But don't forget the code!<br />
<br />
=== The Deliverables ===<br />
<br />
Inside the proposal, your deliverables are the most important thing.<br /><br />
Clearly outline what you are planning to code, including the platform (host or USRP?) and the programming language (VHDL, C++, Python?).<br /><br />
Don't be vague! The following is not a good deliverable:<br />
<br />
* Deliverable 1: Include Herring-Codes in GNU Radio<br />
<br />
Rather, write it like this:<br />
<br />
* Deliverable 0: Create on out-of-tree module for Herring codes (<code>gr-herring</code>), using gr-modtool.<br />
* Deliverable 1: Add blocks for Herring codes (written in C++). This will require two blocks (<code>herring_X</code> and <code>herring_Y</code>), with the specs shown in Fig Z.<br />
<br />
Also, write what you're not doing if it's not explicitly clear. Something like this would be OK:<br />
<br />
* Often, Herring-Codes are mentioned in connection with Trout-Codes. These will not be included in <code>gr-herring</code>.<br />
<br />
=== License ===<br />
<br />
In most cases, the code submitted must be GPLv3 licensed. In most cases, there is no choice about this (e.g., if you are adding to the GNU Radio main tree, or writing typical OOT-modules). If you want to use another license, do tell us and lay out the reasons. In any case, specify the licence you will be using. This also shows us you care about free software licences and know a bit about them.<br />
<br />
=== Schedule ===<br />
<br />
Check the schedule on the GSoC website. Then figure out how you want to spend the time allocated to coding. Again, be specific - this shows us that you've put some thought into planning your summer. Of course we are aware that plans often need to be changed, so the schedule is of course changeable during the course of GSoC (in coordination with your mentor!).<br />
<br />
Don't forget to include time to write documentation, add QA codes and, most importantly, fix bugs! Don't leave docs etc. for the end.<br />
<br />
Other things to include:<br />
<br />
* How many hours per week are you planning to code? Be honest, and don't forget: we expect you to work full-time on this.<br />
* Is there a period where you won't be coding? During 3 months, it is not unreasonable to have a week 'off' for whatever reason, be it exams or other issues. Just be honest about this, and tell us beforehand.<br />
* Do you have other commitments during the summer that will take time away from coding? Tell us about that!<br />
* How many hours in total (175 or 350) is your project?<br />
* How long is your coding period? It can be anywhere from 10 to 22 weeks. This number can be changed during the coding period, so don't worry too much about it, but you still need to include an estimate in your proposal.<br />
<br />
=== Proof of your coding capabilities / prerequisite capabilities ===<br />
<br />
Despite having close contact with your mentor, it will not be possible to work on a project if you're not already capable of writing code. Depending on the project, you will need different skills, typically C++ and/or Python to a good degree, and sometimes other skills, such as DSP, wireless communication, low-level processor architecture, or something like that.<br />
<br />
Make sure your proposal gives us a way of knowing you're capable of doing these things. For code, the best way is to show us to previous projects of yours (e.g., your github page, contributions to other projects, something like that). For more theoretical subjects, a good way is to explain something in your proposal, in your own words.<br />
<br />
=== Formalities ===<br />
<br />
Include these things (again, these are not optional!):<br />
<br />
* Your name, place of residence<br />
* Your university and students status (are you a grad, undergrad... Note that university enrollment is no longer a requirement!)<br />
* Tell us if your GSoC work is in connection with your university work. Are you getting credit for your GSoC project? (None of this affects whether or not you're selected, we're just curious. It still needs to be in your application).<br />
<br />
Of course, check what Google requires you to reveal about yourself.<br />
<br />
Note that the layout, language etc. of the proposal matter. Make it look good, both content-wise and literally.<br />
<br />
=== Background on yourself ===<br />
<br />
Tell us about yourself. In particular we're interested in your coding history. Also, remember that you will be working closely with one of our mentors for three months, so we want to know what it's like working with you. Show us that you're used to working with other people!<br />
<br />
Also, remember that your mentor might be on another continent, speak another language, live in another time zone. How do you propose working with us? Are you on Skype, G+...?<br />
<br />
Most of the time, you will be speaking English with your mentor (you might get lucky and get a mentor that speaks your language, but be prepared to end up with a mentor of another nationality). Is your English good enough? Tell us about that.<br />
<br />
Proof of your technical proficiency is also required. Point us to your github, or '''show us any code you've produced in the past'''! Don't omit any of these questions:<br />
<br />
* Have you participated in an open source project before? If yes, which one? (If not, explicitly say so! A lot of our previous participants have had little experience in the free software world. Be honest!)<br />
* If you have, we'd like to see specific commits and contributions to those projects, please.<br />
* What code have you written? Upload as much as possible to github before applying, so we can have a look. If there's no code at all, we assume you can't code (and won't consider your application).<br />
* Which languages have you mastered so far?<br />
<br />
Finally, we want to know about your relationship to the GNU Radio community, such as<br />
<br />
* Have you participated in GNU Radio before?<br />
* How are you planning to contribute to GNU Radio after GSoC?<br />
<br />
A neat idea on how to present yourself is to upload a video of yourself explaining something.<br />
<br />
=== Acknowledge the three strikes rule ===<br />
<br />
On our [[GSoCManifest|rules of conduct]] page, we have outlined some rules including the three strikes rule. In your application, make a note that you have acknowledged and understood this rule.<br />
<br />
=== The secret code word ===<br />
<br />
Somewhere in your application, include the secret code word: "Cyberspectrum is the best spectrum". We will scan for this code word and simply not read the rest of your application if we can't find it.<br />
<br />
== Being a community member ==<br />
<br />
First of all: You do '''not''' have to be an active developer of GNU Radio to participate! For us, it's just as important to get new people into the project as it is to actually see the projects being coded, maybe more so. Perhaps you just heard about GNU Radio through GSoC? That's fine!<br />
<br />
However, we '''do''' want to get to know you, and see you integrate into our community. So, once you've decided you want to participate in GSoC, definetely sign up to the mailing list (which is the most important hub for the GNU Radio community).<br /><br />
Introduce yourself, tell us you want to participate and tell us about what you want to do.<br />
<br />
Earlier is better than later. The more time you spend on the list, discussing your and other projects, the more familiar you will be with how the community ticks, and we will get to know you better, as well. We try to be objective when grading proposals, but if someone's already made a good impression and we all know she or he writes good code, that definitely counts in your favour.<br />
<br />
== Working with a mentor (before and during GSoC) ==<br />
<br />
Mentors have the biggest say (next to Google) who participates in GSoC, so be nice to them. Also, mentors are volunteers, and don't get paid for GSoC, unlike you (if you're selected). This means they '''won't''' be working full-time mentoring you, so don't expect them to micro-manage your project.<br />
<br />
For this reason, it is important you prove that you're able to work independently and autonomously (if you and your mentor live in different time zones, you might have a call once a week and some chats/emails in between).<br />
<br />
=== Before the summer of code ===<br />
<br />
* Contact the mailing list, ask for feedback on your proposal, become engaged in the community. Don't spam us, that doesn't look good.<br />
* Make sure they know you're serious about GSoC by asking good questions.<br />
* If necessary, brush up your coding skills and play around with GNU Radio.<br />
<br />
=== During GSoC ===<br />
<br />
* Make sure you have regular contact with your mentor.<br />
* We require weekly updates that are publically visible for the entire community. A blog etc. is a good way to do this.<br />
<br />
== How we grade proposals ==<br />
<br />
The following points are considered when grading proposals:<br />
<br />
* How well do we understand what the student exactly is going to do?<br />
* How likely is success with this project?<br />
* How much does GNU Radio benefit from this project?<br />
* What are the chances of the student becoming an active member of the community after GSoC?<br />
<br />
Of course, all the other things on this page must also be considered.<br />
<br />
== GSoC is good for your education! ==<br />
<br />
[[File:gsoc.jpg|250px]]<br />
<br />
To be very clear here: GSoC is '''not''' part of your degree. If you want to apply in order to "clear GSoC" for your curriculum or whatever, go elsewhere. We want people who are actually passionate about this project, and free software. Sure, it will look good on your CV. But that's not a good motivation to apply here.<br />
<br />
That said, GSoC '''will''' make you smarter. And if your university is cooperative, there's no reason for GSoC and your university education to be mutually exclusive. In the past, universities have often supported GSoC students by giving them access to their labs, or even awarding credit for the project. Being a student is no longer a prerequisite to joining GSoC, but if you are, feel free to talk to us about collaborating, and talk to your university advisor if they are willing to give some support.<br />
<br />
== Hints ==<br />
<br />
There are some good hints on some of these pages from other projects:<br />
<br />
* [http://community.kde.org/GSoC#Hints KDE GSoC page]<br />
* [http://www.postgresql.org/developer/summerofcodeadvice/ PostgreSQL GSoC]<br />
* [http://danielpocock.com/getting-selected-for-google-summer-of-code-2015 Want to be selected for GSoC?] (a generic but very thorough guide, not specific to any one organization)<br />
<br />
Some more hints which have come up over the years:<br />
<br />
* People tend to want to do signal processing stuff. We also like project diversity, and your chances will increase if you apply to work in other areas, such as improving user interfaces (if you do that, a lot of people will be affected by your work; they might buy you beers)<br />
* The more we know about you, the better your chances. Make the proposal a personal matter<br />
* Don't forget the secret code word.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCStudentInfo&diff=11857GSoCStudentInfo2022-03-12T10:40:27Z<p>Haakov: /* Formalities */</p>
<hr />
<div>= GSoC - Information for students =<br />
<br />
Here's the most important steps of applying for GSoC with GNU Radio:<br />
<br />
* Read this '''entire''' page before submitting applications. We will not consider your application otherwise.<br />
* Read Google's [https://developers.google.com/open-source/gsoc/faq FAQ]<br />
* Take a look at our [[GSoCIdeas|list of ideas]]<br />
* Come up with project that you're interested in (be it on the list or not!)<br />
* Write a first draft proposal and get someone to review it for you (perhaps one of the mentors)<br />
* Submit it using Google's web interface<br />
* '''Important: Make sure you have followed all the instructions on this page. Failing to do so will cause us to ignore your proposal, as we usually have many more applicants than we have slots!'''<br />
<br />
For accepted students, we have guidelines in place for during GSoC, see our [[GSoCManifest|rules of conduct]] page.<br />
<br />
== The Project ==<br />
<br />
Choose a project that suits you. We have project ideas on our GSoC page you can choose from, but you can also submit your own ideas. If you do so, tell us early enough about that! It is also OK to use the ideas as a rough guideline for your project, but to vary from that.<br />
<br />
Note that if you submit your own idea, even if it's awesome, there might be no mentor who has the technical know-how to supervise that, or simply no-one who want to supervise that specific project. If you post your idea early enough, this is usually not a problem, though.<br />
<br />
Whatever you do, it is very important that you understand the project you'll be working on. Proving that you understand the problem is basically the first hurdle for you to get our attention.<br />
<br />
You can submit several applications for GNU Radio, so if there are several projects you feel like doing, submit one for each project. Time has shown that it's usually better to eventually focus on one proposal, because it's already quite some work to get one excellent proposal finished.<br />
<br />
== The Proposal ==<br />
<br />
The proposal, which you submit to the GSoC page, is the single most important part of your application.<br /><br />
In the time before the proposal submission, you should contact the GNU Radio mailing list.<br /><br />
The mentors (and other community members) will give you some feedback on your proposal, but that does mean you have to have to actually write a proposal on which you can get feedback.<br />
<br />
It might seem odd to publically announce an unfinished proposal. You might be concerned that other students will read and copy your proposal. However, in the past, that has never happened. Students who submit early, and gather feedback, have always been the most successful students. We recommend having a proposal e.g. as a Google doc, or on an site like github, and treat it like open source software. Experience has shown that your chances are better if you start early with a '''publicly available proposal''' than developing your proposal trying to do it in private.<br />
<br />
An example of a successful proposal from 2012 can be [https://github.com/zeroXzero/gsoc_proposals/blob/master/filter_enhancements.pdf?raw=true found here (filter design)].<br />
<br />
The following things '''must''' be in the proposal, or it is considered incomplete and will not be considered for acceptance! We will simply mark your proposal as 'incomplete' and ignore communications from you.<br />
<br />
=== Topic background ===<br />
<br />
If there's any theory necessary for your project, include some pointers and explain the basics. Prove to us that you know what you're talking about.<br />
<br />
Something like this is good:<br />
<br />
> Herring-Codes were initially proposed in the seminal paper "Herring-Codes in a fishy radio environment" [1]. They are based on the mathematical theory that...<br />
<br />
Also, you should start getting a good idea about what's available in GNU Radio and other projects. This means you should have a look at the source code of GNU Radio. Here's an idea:<br />
<br />
> In GNU Radio, there are codes available in the component <code>gr-fec</code>. Having looked at the available blocks, it is clear that the available blocks in <code>gr-fec</code>, such as the ccsds_27_bb blocks, cannot trivially be modified to include Herring-Codes. It therefore makes sense to add these to GNU Radio.<br />
<br />
One major difference between some free software projects and GNU Radio is that the required technical background can be quite daunting, up to a point where some GSoC projects can't possibly be worked upon by people without a communications engineering background. However, we try to make GSoC accessible to all clever students, and have a variety of topics available.<br />
<br />
Important: This is the summer of code, '''not the summer of research'''! Your first goal must be coded deliverables. If it is possible to get some research done at the same time, or even write a paper on the subject, that's fantastic. But don't forget the code!<br />
<br />
=== The Deliverables ===<br />
<br />
Inside the proposal, your deliverables are the most important thing.<br /><br />
Clearly outline what you are planning to code, including the platform (host or USRP?) and the programming language (VHDL, C++, Python?).<br /><br />
Don't be vague! The following is not a good deliverable:<br />
<br />
* Deliverable 1: Include Herring-Codes in GNU Radio<br />
<br />
Rather, write it like this:<br />
<br />
* Deliverable 0: Create on out-of-tree module for Herring codes (<code>gr-herring</code>), using gr-modtool.<br />
* Deliverable 1: Add blocks for Herring codes (written in C++). This will require two blocks (<code>herring_X</code> and <code>herring_Y</code>), with the specs shown in Fig Z.<br />
<br />
Also, write what you're not doing if it's not explicitly clear. Something like this would be OK:<br />
<br />
* Often, Herring-Codes are mentioned in connection with Trout-Codes. These will not be included in <code>gr-herring</code>.<br />
<br />
=== License ===<br />
<br />
In most cases, the code submitted must be GPLv3 licensed. In most cases, there is no choice about this (e.g., if you are adding to the GNU Radio main tree, or writing typical OOT-modules). If you want to use another license, do tell us and lay out the reasons. In any case, specify the licence you will be using. This also shows us you care about free software licences and know a bit about them.<br />
<br />
=== Schedule ===<br />
<br />
Check the schedule for GSoC on the Google Melange website. Then figure out how you want to spend the time allocated to coding. Again, be specific - this shows us that you've put some thought into planning your summer. Of course we are aware that plans often need to be changed, so the schedule is of course changable during the course of GSoC (in coordination with your mentor!).<br />
<br />
Don't forget to include time to write documentation, add QA codes and, most importantly, fix bugs! Don't leave docs etc. for the end.<br />
<br />
Other things to include:<br />
<br />
* How many hours per week are you planning to code? Be honest, and don't forget: we expect you to work full-time on this.<br />
* Is there a period where you won't be coding? During 3 months, it is not unreasonable to have a week 'off' for whatever reason, be it exams or other issues. Just be honest about this, and tell us beforehand.<br />
* Do you have other commitments during the summer that will take time away from coding? Tell us about that!<br />
<br />
=== Proof of your coding capabilities / prerequisite capabilities ===<br />
<br />
Despite having close contact with your mentor, it will not be possible to work on a project if you're not already capable of writing code. Depending on the project, you will need different skills, typically C++ and/or Python to a good degree, and sometimes other skills, such as DSP, wireless communication, low-level processor architecture, or something like that.<br />
<br />
Make sure your proposal gives us a way of knowing you're capable of doing these things. For code, the best way is to show us to previous projects of yours (e.g., your github page, contributions to other projects, something like that). For more theoretical subjects, a good way is to explain something in your proposal, in your own words.<br />
<br />
=== Formalities ===<br />
<br />
Include these things (again, these are not optional!):<br />
<br />
* Your name, place of residence<br />
* Your university and students status (are you a grad, undergrad... Note that university enrollment is no longer a requirement!)<br />
* Tell us if your GSoC work is in connection with your university work. Are you getting credit for your GSoC project? (None of this affects whether or not you're selected, we're just curious. It still needs to be in your application).<br />
<br />
Of course, check what Google requires you to reveal about yourself.<br />
<br />
Note that the layout, language etc. of the proposal matter. Make it look good, both content-wise and literally.<br />
<br />
=== Background on yourself ===<br />
<br />
Tell us about yourself. In particular we're interested in your coding history. Also, remember that you will be working closely with one of our mentors for three months, so we want to know what it's like working with you. Show us that you're used to working with other people!<br />
<br />
Also, remember that your mentor might be on another continent, speak another language, live in another time zone. How do you propose working with us? Are you on Skype, G+...?<br />
<br />
Most of the time, you will be speaking English with your mentor (you might get lucky and get a mentor that speaks your language, but be prepared to end up with a mentor of another nationality). Is your English good enough? Tell us about that.<br />
<br />
Proof of your technical proficiency is also required. Point us to your github, or '''show us any code you've produced in the past'''! Don't omit any of these questions:<br />
<br />
* Have you participated in an open source project before? If yes, which one? (If not, explicitly say so! A lot of our previous participants have had little experience in the free software world. Be honest!)<br />
* If you have, we'd like to see specific commits and contributions to those projects, please.<br />
* What code have you written? Upload as much as possible to github before applying, so we can have a look. If there's no code at all, we assume you can't code (and won't consider your application).<br />
* Which languages have you mastered so far?<br />
<br />
Finally, we want to know about your relationship to the GNU Radio community, such as<br />
<br />
* Have you participated in GNU Radio before?<br />
* How are you planning to contribute to GNU Radio after GSoC?<br />
<br />
A neat idea on how to present yourself is to upload a video of yourself explaining something.<br />
<br />
=== Acknowledge the three strikes rule ===<br />
<br />
On our [[GSoCManifest|rules of conduct]] page, we have outlined some rules including the three strikes rule. In your application, make a note that you have acknowledged and understood this rule.<br />
<br />
=== The secret code word ===<br />
<br />
Somewhere in your application, include the secret code word: "Cyberspectrum is the best spectrum". We will scan for this code word and simply not read the rest of your application if we can't find it.<br />
<br />
== Being a community member ==<br />
<br />
First of all: You do '''not''' have to be an active developer of GNU Radio to participate! For us, it's just as important to get new people into the project as it is to actually see the projects being coded, maybe more so. Perhaps you just heard about GNU Radio through GSoC? That's fine!<br />
<br />
However, we '''do''' want to get to know you, and see you integrate into our community. So, once you've decided you want to participate in GSoC, definetely sign up to the mailing list (which is the most important hub for the GNU Radio community).<br /><br />
Introduce yourself, tell us you want to participate and tell us about what you want to do.<br />
<br />
Earlier is better than later. The more time you spend on the list, discussing your and other projects, the more familiar you will be with how the community ticks, and we will get to know you better, as well. We try to be objective when grading proposals, but if someone's already made a good impression and we all know she or he writes good code, that definitely counts in your favour.<br />
<br />
== Working with a mentor (before and during GSoC) ==<br />
<br />
Mentors have the biggest say (next to Google) who participates in GSoC, so be nice to them. Also, mentors are volunteers, and don't get paid for GSoC, unlike you (if you're selected). This means they '''won't''' be working full-time mentoring you, so don't expect them to micro-manage your project.<br />
<br />
For this reason, it is important you prove that you're able to work independently and autonomously (if you and your mentor live in different time zones, you might have a call once a week and some chats/emails in between).<br />
<br />
=== Before the summer of code ===<br />
<br />
* Contact the mailing list, ask for feedback on your proposal, become engaged in the community. Don't spam us, that doesn't look good.<br />
* Make sure they know you're serious about GSoC by asking good questions.<br />
* If necessary, brush up your coding skills and play around with GNU Radio.<br />
<br />
=== During GSoC ===<br />
<br />
* Make sure you have regular contact with your mentor.<br />
* We require weekly updates that are publically visible for the entire community. A blog etc. is a good way to do this.<br />
<br />
== How we grade proposals ==<br />
<br />
The following points are considered when grading proposals:<br />
<br />
* How well do we understand what the student exactly is going to do?<br />
* How likely is success with this project?<br />
* How much does GNU Radio benefit from this project?<br />
* What are the chances of the student becoming an active member of the community after GSoC?<br />
<br />
Of course, all the other things on this page must also be considered.<br />
<br />
== GSoC is good for your education! ==<br />
<br />
[[File:gsoc.jpg|250px]]<br />
<br />
To be very clear here: GSoC is '''not''' part of your degree. If you want to apply in order to "clear GSoC" for your curriculum or whatever, go elsewhere. We want people who are actually passionate about this project, and free software. Sure, it will look good on your CV. But that's not a good motivation to apply here.<br />
<br />
That said, GSoC '''will''' make you smarter. And if your university is cooperative, there's no reason for GSoC and your university education to be mutually exclusive. In the past, universities have often supported GSoC students by giving them access to their labs, or even awarding credit for the project. Being a student is no longer a prerequisite to joining GSoC, but if you are, feel free to talk to us about collaborating, and talk to your university advisor if they are willing to give some support.<br />
<br />
== Hints ==<br />
<br />
There are some good hints on some of these pages from other projects:<br />
<br />
* [http://community.kde.org/GSoC#Hints KDE GSoC page]<br />
* [http://www.postgresql.org/developer/summerofcodeadvice/ PostgreSQL GSoC]<br />
* [http://danielpocock.com/getting-selected-for-google-summer-of-code-2015 Want to be selected for GSoC?] (a generic but very thorough guide, not specific to any one organization)<br />
<br />
Some more hints which have come up over the years:<br />
<br />
* People tend to want to do signal processing stuff. We also like project diversity, and your chances will increase if you apply to work in other areas, such as improving user interfaces (if you do that, a lot of people will be affected by your work; they might buy you beers)<br />
* The more we know about you, the better your chances. Make the proposal a personal matter<br />
* Don't forget the secret code word.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCStudentInfo&diff=11856GSoCStudentInfo2022-03-12T10:38:49Z<p>Haakov: /* GSoC is good for your education! */</p>
<hr />
<div>= GSoC - Information for students =<br />
<br />
Here's the most important steps of applying for GSoC with GNU Radio:<br />
<br />
* Read this '''entire''' page before submitting applications. We will not consider your application otherwise.<br />
* Read Google's [https://developers.google.com/open-source/gsoc/faq FAQ]<br />
* Take a look at our [[GSoCIdeas|list of ideas]]<br />
* Come up with project that you're interested in (be it on the list or not!)<br />
* Write a first draft proposal and get someone to review it for you (perhaps one of the mentors)<br />
* Submit it using Google's web interface<br />
* '''Important: Make sure you have followed all the instructions on this page. Failing to do so will cause us to ignore your proposal, as we usually have many more applicants than we have slots!'''<br />
<br />
For accepted students, we have guidelines in place for during GSoC, see our [[GSoCManifest|rules of conduct]] page.<br />
<br />
== The Project ==<br />
<br />
Choose a project that suits you. We have project ideas on our GSoC page you can choose from, but you can also submit your own ideas. If you do so, tell us early enough about that! It is also OK to use the ideas as a rough guideline for your project, but to vary from that.<br />
<br />
Note that if you submit your own idea, even if it's awesome, there might be no mentor who has the technical know-how to supervise that, or simply no-one who want to supervise that specific project. If you post your idea early enough, this is usually not a problem, though.<br />
<br />
Whatever you do, it is very important that you understand the project you'll be working on. Proving that you understand the problem is basically the first hurdle for you to get our attention.<br />
<br />
You can submit several applications for GNU Radio, so if there are several projects you feel like doing, submit one for each project. Time has shown that it's usually better to eventually focus on one proposal, because it's already quite some work to get one excellent proposal finished.<br />
<br />
== The Proposal ==<br />
<br />
The proposal, which you submit to the GSoC page, is the single most important part of your application.<br /><br />
In the time before the proposal submission, you should contact the GNU Radio mailing list.<br /><br />
The mentors (and other community members) will give you some feedback on your proposal, but that does mean you have to have to actually write a proposal on which you can get feedback.<br />
<br />
It might seem odd to publically announce an unfinished proposal. You might be concerned that other students will read and copy your proposal. However, in the past, that has never happened. Students who submit early, and gather feedback, have always been the most successful students. We recommend having a proposal e.g. as a Google doc, or on an site like github, and treat it like open source software. Experience has shown that your chances are better if you start early with a '''publicly available proposal''' than developing your proposal trying to do it in private.<br />
<br />
An example of a successful proposal from 2012 can be [https://github.com/zeroXzero/gsoc_proposals/blob/master/filter_enhancements.pdf?raw=true found here (filter design)].<br />
<br />
The following things '''must''' be in the proposal, or it is considered incomplete and will not be considered for acceptance! We will simply mark your proposal as 'incomplete' and ignore communications from you.<br />
<br />
=== Topic background ===<br />
<br />
If there's any theory necessary for your project, include some pointers and explain the basics. Prove to us that you know what you're talking about.<br />
<br />
Something like this is good:<br />
<br />
> Herring-Codes were initially proposed in the seminal paper "Herring-Codes in a fishy radio environment" [1]. They are based on the mathematical theory that...<br />
<br />
Also, you should start getting a good idea about what's available in GNU Radio and other projects. This means you should have a look at the source code of GNU Radio. Here's an idea:<br />
<br />
> In GNU Radio, there are codes available in the component <code>gr-fec</code>. Having looked at the available blocks, it is clear that the available blocks in <code>gr-fec</code>, such as the ccsds_27_bb blocks, cannot trivially be modified to include Herring-Codes. It therefore makes sense to add these to GNU Radio.<br />
<br />
One major difference between some free software projects and GNU Radio is that the required technical background can be quite daunting, up to a point where some GSoC projects can't possibly be worked upon by people without a communications engineering background. However, we try to make GSoC accessible to all clever students, and have a variety of topics available.<br />
<br />
Important: This is the summer of code, '''not the summer of research'''! Your first goal must be coded deliverables. If it is possible to get some research done at the same time, or even write a paper on the subject, that's fantastic. But don't forget the code!<br />
<br />
=== The Deliverables ===<br />
<br />
Inside the proposal, your deliverables are the most important thing.<br /><br />
Clearly outline what you are planning to code, including the platform (host or USRP?) and the programming language (VHDL, C++, Python?).<br /><br />
Don't be vague! The following is not a good deliverable:<br />
<br />
* Deliverable 1: Include Herring-Codes in GNU Radio<br />
<br />
Rather, write it like this:<br />
<br />
* Deliverable 0: Create on out-of-tree module for Herring codes (<code>gr-herring</code>), using gr-modtool.<br />
* Deliverable 1: Add blocks for Herring codes (written in C++). This will require two blocks (<code>herring_X</code> and <code>herring_Y</code>), with the specs shown in Fig Z.<br />
<br />
Also, write what you're not doing if it's not explicitly clear. Something like this would be OK:<br />
<br />
* Often, Herring-Codes are mentioned in connection with Trout-Codes. These will not be included in <code>gr-herring</code>.<br />
<br />
=== License ===<br />
<br />
In most cases, the code submitted must be GPLv3 licensed. In most cases, there is no choice about this (e.g., if you are adding to the GNU Radio main tree, or writing typical OOT-modules). If you want to use another license, do tell us and lay out the reasons. In any case, specify the licence you will be using. This also shows us you care about free software licences and know a bit about them.<br />
<br />
=== Schedule ===<br />
<br />
Check the schedule for GSoC on the Google Melange website. Then figure out how you want to spend the time allocated to coding. Again, be specific - this shows us that you've put some thought into planning your summer. Of course we are aware that plans often need to be changed, so the schedule is of course changable during the course of GSoC (in coordination with your mentor!).<br />
<br />
Don't forget to include time to write documentation, add QA codes and, most importantly, fix bugs! Don't leave docs etc. for the end.<br />
<br />
Other things to include:<br />
<br />
* How many hours per week are you planning to code? Be honest, and don't forget: we expect you to work full-time on this.<br />
* Is there a period where you won't be coding? During 3 months, it is not unreasonable to have a week 'off' for whatever reason, be it exams or other issues. Just be honest about this, and tell us beforehand.<br />
* Do you have other commitments during the summer that will take time away from coding? Tell us about that!<br />
<br />
=== Proof of your coding capabilities / prerequisite capabilities ===<br />
<br />
Despite having close contact with your mentor, it will not be possible to work on a project if you're not already capable of writing code. Depending on the project, you will need different skills, typically C++ and/or Python to a good degree, and sometimes other skills, such as DSP, wireless communication, low-level processor architecture, or something like that.<br />
<br />
Make sure your proposal gives us a way of knowing you're capable of doing these things. For code, the best way is to show us to previous projects of yours (e.g., your github page, contributions to other projects, something like that). For more theoretical subjects, a good way is to explain something in your proposal, in your own words.<br />
<br />
=== Formalities ===<br />
<br />
Include these things (again, these are not optional!):<br />
<br />
* Your name, place of residence<br />
* Your university and students status (are you a grad, undergrad...)<br />
* Tell us if your GSoC work is in connection with your university work. Are you getting credit for your GSoC project? (None of this affects whether or not you're selected, we're just curious. It still needs to be in your application).<br />
<br />
Of course, check what Google requires you to reveal about yourself.<br />
<br />
Note that the layout, language etc. of the proposal matter. Make it look good, both content-wise and literally.<br />
<br />
=== Background on yourself ===<br />
<br />
Tell us about yourself. In particular we're interested in your coding history. Also, remember that you will be working closely with one of our mentors for three months, so we want to know what it's like working with you. Show us that you're used to working with other people!<br />
<br />
Also, remember that your mentor might be on another continent, speak another language, live in another time zone. How do you propose working with us? Are you on Skype, G+...?<br />
<br />
Most of the time, you will be speaking English with your mentor (you might get lucky and get a mentor that speaks your language, but be prepared to end up with a mentor of another nationality). Is your English good enough? Tell us about that.<br />
<br />
Proof of your technical proficiency is also required. Point us to your github, or '''show us any code you've produced in the past'''! Don't omit any of these questions:<br />
<br />
* Have you participated in an open source project before? If yes, which one? (If not, explicitly say so! A lot of our previous participants have had little experience in the free software world. Be honest!)<br />
* If you have, we'd like to see specific commits and contributions to those projects, please.<br />
* What code have you written? Upload as much as possible to github before applying, so we can have a look. If there's no code at all, we assume you can't code (and won't consider your application).<br />
* Which languages have you mastered so far?<br />
<br />
Finally, we want to know about your relationship to the GNU Radio community, such as<br />
<br />
* Have you participated in GNU Radio before?<br />
* How are you planning to contribute to GNU Radio after GSoC?<br />
<br />
A neat idea on how to present yourself is to upload a video of yourself explaining something.<br />
<br />
=== Acknowledge the three strikes rule ===<br />
<br />
On our [[GSoCManifest|rules of conduct]] page, we have outlined some rules including the three strikes rule. In your application, make a note that you have acknowledged and understood this rule.<br />
<br />
=== The secret code word ===<br />
<br />
Somewhere in your application, include the secret code word: "Cyberspectrum is the best spectrum". We will scan for this code word and simply not read the rest of your application if we can't find it.<br />
<br />
== Being a community member ==<br />
<br />
First of all: You do '''not''' have to be an active developer of GNU Radio to participate! For us, it's just as important to get new people into the project as it is to actually see the projects being coded, maybe more so. Perhaps you just heard about GNU Radio through GSoC? That's fine!<br />
<br />
However, we '''do''' want to get to know you, and see you integrate into our community. So, once you've decided you want to participate in GSoC, definetely sign up to the mailing list (which is the most important hub for the GNU Radio community).<br /><br />
Introduce yourself, tell us you want to participate and tell us about what you want to do.<br />
<br />
Earlier is better than later. The more time you spend on the list, discussing your and other projects, the more familiar you will be with how the community ticks, and we will get to know you better, as well. We try to be objective when grading proposals, but if someone's already made a good impression and we all know she or he writes good code, that definitely counts in your favour.<br />
<br />
== Working with a mentor (before and during GSoC) ==<br />
<br />
Mentors have the biggest say (next to Google) who participates in GSoC, so be nice to them. Also, mentors are volunteers, and don't get paid for GSoC, unlike you (if you're selected). This means they '''won't''' be working full-time mentoring you, so don't expect them to micro-manage your project.<br />
<br />
For this reason, it is important you prove that you're able to work independently and autonomously (if you and your mentor live in different time zones, you might have a call once a week and some chats/emails in between).<br />
<br />
=== Before the summer of code ===<br />
<br />
* Contact the mailing list, ask for feedback on your proposal, become engaged in the community. Don't spam us, that doesn't look good.<br />
* Make sure they know you're serious about GSoC by asking good questions.<br />
* If necessary, brush up your coding skills and play around with GNU Radio.<br />
<br />
=== During GSoC ===<br />
<br />
* Make sure you have regular contact with your mentor.<br />
* We require weekly updates that are publically visible for the entire community. A blog etc. is a good way to do this.<br />
<br />
== How we grade proposals ==<br />
<br />
The following points are considered when grading proposals:<br />
<br />
* How well do we understand what the student exactly is going to do?<br />
* How likely is success with this project?<br />
* How much does GNU Radio benefit from this project?<br />
* What are the chances of the student becoming an active member of the community after GSoC?<br />
<br />
Of course, all the other things on this page must also be considered.<br />
<br />
== GSoC is good for your education! ==<br />
<br />
[[File:gsoc.jpg|250px]]<br />
<br />
To be very clear here: GSoC is '''not''' part of your degree. If you want to apply in order to "clear GSoC" for your curriculum or whatever, go elsewhere. We want people who are actually passionate about this project, and free software. Sure, it will look good on your CV. But that's not a good motivation to apply here.<br />
<br />
That said, GSoC '''will''' make you smarter. And if your university is cooperative, there's no reason for GSoC and your university education to be mutually exclusive. In the past, universities have often supported GSoC students by giving them access to their labs, or even awarding credit for the project. Being a student is no longer a prerequisite to joining GSoC, but if you are, feel free to talk to us about collaborating, and talk to your university advisor if they are willing to give some support.<br />
<br />
== Hints ==<br />
<br />
There are some good hints on some of these pages from other projects:<br />
<br />
* [http://community.kde.org/GSoC#Hints KDE GSoC page]<br />
* [http://www.postgresql.org/developer/summerofcodeadvice/ PostgreSQL GSoC]<br />
* [http://danielpocock.com/getting-selected-for-google-summer-of-code-2015 Want to be selected for GSoC?] (a generic but very thorough guide, not specific to any one organization)<br />
<br />
Some more hints which have come up over the years:<br />
<br />
* People tend to want to do signal processing stuff. We also like project diversity, and your chances will increase if you apply to work in other areas, such as improving user interfaces (if you do that, a lot of people will be affected by your work; they might buy you beers)<br />
* The more we know about you, the better your chances. Make the proposal a personal matter<br />
* Don't forget the secret code word.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=11550GSoCIdeas2022-02-25T12:25:36Z<p>Haakov: /* Summer of Code 2022: Project ideas list */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
== Summer of Code 2022: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2022 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Hard<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Project length'''<br />
<br />
350 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GNU Radio goes Browser: Web Assembly (WASM) port ===<br />
<br />
<br />
[[File:WASM-preview.jpg|thumb|link=https://mobile.twitter.com/marcnewlin/status/1490577402086313984/photo/1|A view of GRC running on WASM-compiled Python]]<br />
<br />
The main goal of WebAssembly is to enable high-performance applications on web pages. Originally quite restricted to single-threaded applications, only interacting with the browser's notion of the world through a JavaScript interaction layer, today it has become quite capable, with support for threads, exceptions, SIMD and a lot of other performance-critical features.<br />
<br />
Obviously, that's great news! GNU Radio in the Browser means zero-installation, fully portable SDR for the masses. This GSoC project strives to take Marc Newlin's current work and make something functional, with the big goal of having a fully functional GNU Radio on WASM.<br />
<br />
This project has subprojects, from which the student is to pick '''one''':<br />
<br />
* porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted set of intrinsics<br />
* working to bring GRC in the feature-grc-qt branch to parity with GRC in main<br />
* WebUSB driver porting (I have prototyped standalone drivers for UHD, HackRF and PlutoSDR which haven't get been integrated, and then porting gr-osmosdr would be awesome). <br />
* creating blocks for ZMQ over websockets<br />
<br />
in addition to making a (minimal) web page to which the current development state can be tested on, updated automatically from Github.<br />
<br />
'''Steps'''<br />
<br />
* Make (and test!) Marc Newlin's WASM build locally<br />
* Add a CI step to build a WASM binary<br />
* Implement one of the points above<br />
* Implement a suitable demonstration for it and deploy<br />
<br />
'''Prerequisites'''<br />
<br />
* Basic knowledge of Python<br />
* Working (especially, reading) knowledge of C++<br />
* Basic knowledge of WASM <br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Medium<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marc Newlin<br />
* Marcus Müller<br />
* Depending on topic: further member of the GNU Radio community<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed"><br />
<br />
== Summer of Code 2021: Project ideas list ==<br />
<div class="mw-collapsible-content"><br />
<br />
This is the list of project ideas for the summer of code 2021 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
'''The time a student can spend on a GSoC project has been reduced by 50% for 2021 - keep this in mind when submitting your ideas'''<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
=== Standardized High Throughput FEC Codes ===<br />
<br />
Channel coding is essential to modern communications. Also, it is computationally very heavy. As of now, there exist implementations in GNU Radio which are too slow to be integrated into high throughput applications. GNU Radio would benefit from integration of standardized decoders for Turbo and LDPC codes. These codes would only support a certain subset of the whole code class but would be well optimized. <br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.<br />
<br />
'''Outcome'''<br />
<br />
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.<br />
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Johannes Demel<br />
<br />
<br />
=== GRC: View-Only Mode (Secure) ===<br />
<br />
When a flowgraph from an untrusted source is opened if GRC, arbitrary Python code can be executed. This poses a potential security risk. Storing the all evaluated values of all parameters within a flow graph (.grc) file would allow us to open such flow graphs without compromising security. No code would be have to executed to draw the flow graph and block parameters can be viewed safely. Only if the flow graph is modified the user would have to choose to trust the flow graph thus enabling normal eval operations.<br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is implemented using Python. So, Python should be known pretty well.<br />
<br />
'''Outcome'''<br />
<br />
* Safely view other people's flowgraphs without putting your PC at risk.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===<br />
<br />
Even though the 8b10b line coding is primarily used for byte-level synchronization and spectral shaping, it adds some redundancy to the data, so it can be used as a forward error correction method to fix some bit errors in the received data. From the perspective of the decoder there is one bit of hidden state, so 8b10b line coding is amenable to Viterbi decoding, as hinted in [http://www.bigideatrouble.com/AMSAT%202013%20FOX1%20Paper.pdf this document about the AMSAT FOX satellites]. One goal of this project is to create Viterbi decoder block(s) for 8b10b and possibly other similar line codes, so that these blocks can be eventually upstreamed in-tree. The error correction performance of this method will be studied using simulations with these blocks. The second goal is to use the Viterbi decoder and gr-satellites to create a full decoder for the FOX satellites from AMSAT.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python. Some basic understanding about FEC in general.<br />
<br />
'''Outcome'''<br />
<br />
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites<br />
<br />
'''Mentor(s)'''<br />
<br />
* Daniel Estévez<br />
<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput). This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our server, allowing us to crowdsource data. (Similar to our online stats for SIMD performance.)<br />
<br />
'''Outcome'''<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Set up automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web server.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
*Bastian Bloessl<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed"><br />
<br />
== Summer of Code 2020: Project ideas list ==<br />
<div class="mw-collapsible-content"><br />
This is the list of project ideas for the summer of code 2020 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has the hierarchical blocks to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
<br />
=== Qt5 GUI Integrations ===<br />
<br />
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization<br />
<br />
'''Prerequisites'''<br />
<br />
* C++, Python proficiency<br />
* Qt experienced<br />
<br />
'''Outcome'''<br />
<br />
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)<br />
* Possible to import generate Qt GUI description file (UIC) into GRC<br />
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph<br />
* Integration of that into GRC-generated Python code<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Müller & Sebastian "GRC-Man" Koslowski<br />
<br />
<br />
<br />
=== Extending and Updating gr-radar ===<br />
<br />
gr-radar (https://github.com/kit-cel/gr-radar/) was a great and successful GSoC project that provided a few methods of radar in GNU Radio. This module is heavily used by academics, researchers, cybersecurity folks, and hobbyists. This project would work to improve upon the concepts already in there as well as add more radar techniques.<br />
<br />
There are uncountable methods and techniques that could be added to this project, such as:<br />
<br />
* SAR / InSAR methods<br />
* Better passive radar support<br />
* Speed camera applications<br />
* Multi-antenna radar techniques<br />
<br />
'''Prerequisites'''<br />
<br />
* Signal processing and some radar basics are required.<br />
* Code is written in C++ with some Python on the side, so the student must be able to handle these languages at the least.<br />
<br />
'''Outcome'''<br />
<br />
* Based on the student's interest, a subset of the radar techniques listed above (or others) are chosen as milestones for this project. <br />
* All code must be merged back into gr-radar by the end of the summer.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Stefan Wunsch, Martin Braun<br />
<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add new widgets<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C+'', so some C''+ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Tim O'Shea<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Android ===<br />
<br />
One effort of the past years was to improve Android support for GNU Radio. We're getting to a point where we've figured out '''how''' to do it, so the next step is to make it more accessible to users and developers.<br />
<br />
The Android ecosystem is an entirely different beast from the rest of GNU Radio. To make writing Android/GR apps easy, the following needs to happen (and shall be part of this project):<br />
<br />
* Improve support for development environment<br />
** Create Dockers for easy start of development<br />
* Visualization classes for PSD, spectrogram and oscilloscope<br />
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs<br />
* Interactivity concepts<br />
** Gestures and config for radio parameters (e.g., freq, gain, bandwidth)<br />
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures<br />
<br />
You can find a summary of the work that has been done on this (years ago) here: [[Android]]<br />
<br />
'''Prerequisites'''<br />
<br />
* Some Android experience<br />
* Enjoy writing GUI widgets<br />
* C++/Java experience<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput).<br />
This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our sever, allowing us to crowdsource data. (Similar to our [http://stats.gnuradio.org/ online stats] for SIMD performance.)<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Setup automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web sever.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl, Marcus Mueller<br />
<br />
=== Filter Design Tool Enhancements ===<br />
<br />
GNU Radio provides many tools to design and use digital filters. Using these tools requires both some expertise in these areas as well as an understanding of the performance on the given platform. One example is the selection between FIR (convolution-based) and FFT (fast convolution-based) filters for different resampling rates. Another example is doing stages of filter decomposition when doing large down-sampling. Included in this is the polyphase filterbanks, which again are provided as primitive blocks that need tweaking to work.<br />
<br />
This project is to improve our uses of these tools and blocks to make it more obvious to the users as well as automate some of the decisions for optimally using them. Some pointers:<br />
<br />
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.<br />
* It still currently runs on PyQWT, which is obsolete and needs to be updated to Qt5<br />
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui<br />
* Add more support for filter design concepts and other filters.<br />
** Cascaded filters<br />
** Better support for creating PFB filters<br />
<br />
'''Prerequisites'''<br />
<br />
* Strong DSP background required.<br />
* Python and QT knowledge highly useful (at least one of those is a must).<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Leech<br />
<br />
<br />
<br />
=== Implement SigMF functionality for the GNU Radio Ecosystem ===<br />
<br />
SigMF is the "Signal Metadata Format" that was defined during the 2017 DARPA Hackfest in Brussels. Its purpose is to annotate raw binary dumps of signals with metadata, thus giving meaning to a raw mass of samples.<br /><br />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf<br />
There is an out-of-tree module providing SigMF functionality for GNU Radio as well: https://github.com/skysafe/gr-sigmf<br />
<br />
However, SigMF is not represented well in the GNU Radio tooling landscape. Therefore, a subset of tools can be extended by SigMF support. Incomplete lists of possible tools benefitting from SigMF support:<br />
<br />
* qgrx (https://github.com/csete/gqrx)<br />
* inspectrum (https://github.com/miek/inspectrum)<br />
* ...<br />
<br />
Any additional tools are welcome in a proposal.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of the programming language of the covered tools.<br />
* Hands-on experience with the respective tools.<br />
* Familiarity with the SigMF specification.<br />
<br />
'''Outcome'''<br />
<br />
* The tools worked on have capability to load and save files in the SigMF format.<br />
* Depending on the specific tool, SigMF meta data is displayed within the tool.<br />
* The number of tools worked on needs to be determined by the student, depending on his/her experience.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Müller, Andrej Rode<br />
<br />
<br />
<br />
=== Statistical Toolbox for GRC ===<br />
<br />
A statistical toolbox for GRC would enable GUI-based statistical analysis. Currently, such analysis can be done by writing an independent program (e.g., with SciPy), but there is no actual integration with GNU Radio. By developing the statistical toolbox, we provide blocks for probability distribution fitting, hypothesis testing, extracting statistical parameters for one-dimensional as well as multi-dimensional data. This would significantly expand GNU Radio users' ability to perform data-science analysis and modeling on signal data.<br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.<br />
<br />
'''Outcome'''<br />
<br />
* An OOT module that provides statistical analysis capabilities for GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Ben Hilburn<br />
<br />
</div><br />
</div><br />
== Application process ==<br />
<br />
Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].<br />
* Please introduce yourself on the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]<br />
* Fill in the formal application for GNU Radio<br />
* Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.</div>Haakovhttps://wiki.gnuradio.org/index.php?title=GSoCIdeas&diff=11549GSoCIdeas2022-02-25T07:15:43Z<p>Haakov: /* Standalone GRC */</p>
<hr />
<div>Note- also check out [[Grant Ideas]] for additional ideas that are more suited towards grant money than GSoC.<br />
<br />
== Summer of Code 2022: Project ideas list ==<br />
<br />
This is the list of project ideas for the summer of code 2022 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
<br />
=== GPU Accelerated Signal Processing Blocks ===<br />
<br />
GPUs offer incredible capability for accelerating a number of signal processing routines when the calculations can be done in parallel. Also, GNU Radio 3.10 brought in a "custom buffers" feature which provides support generally for accelerator devices by allowing blocks to have direct access to device memory, finally making accelerator processing feasible through a flowgraph (see [https://fosdem.org/2022/schedule/event/radio_gr3_10/ FOSDEM 2022 Presentation].<br />
<br />
One piece that is missing for GNU Radio is a library of blocks that accelerate common DSP routines. There are several interesting libraries of GPU accelerated signal processing - primarily using CUDA because of its accessible programming paradigm and the ubiquity of NVIDIA hardware:<br />
<br />
* [https://github.com/NVIDIA/MatX Matx]<br />
* [https://github.com/rapidsai/cusignal cuSignal] (Python signal processing)<br />
* [https://github.com/gnuradio/cusp CUSP]<br />
<br />
Integration of any of this functionality, along with additional kernels for signal processing would need to be predicated on using [https://github.com/gnuradio/gr-cuda gr-cuda] custom buffers, and expanding this module as needed<br />
<br />
This project can be broken into several subprojects:<br />
<br />
* Create gr-matx OOT<br />
** Add Matx Custom Buffer Type (after gr-cuda)<br />
** Create blocks wrapping Matx operations<br />
* Expand gr-cuda<br />
** Additional custom buffer types - pinned, unified<br />
** Create python custom buffers allowing zero copy into python blocks<br />
* Create gr-cuSignal<br />
** Wrap cuSignal functionality (dependent on python zero copy)<br />
* Replicate existing GR blocks as CUDA accelerated (things not in cuSignal or Matx)<br />
** Target for extensions to Matx, cuSignal, or CUSP (within our control)<br />
** FIR Filters<br />
** Polyphase Resampler<br />
** Signal Source<br />
** Moving Average<br />
** Polyphase Clock Sync<br />
** Stream Operators<br />
** ...<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python.<br />
* Familiarity with CUDA programming<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman<br />
<br />
<br />
=== Standalone GRC ===<br />
<br />
GNU Radio Companion (GRC) has become useful outside of just GNU Radio, and several projects have forked and maintained their own versions. Even within GRC, there are different workflows (QT GUI, C++, Bokeh-gui) with different options in the path to render a working flowgraph see [https://github.com/gnuradio/greps/blob/main/grep-0025-grc-out-of-tree.md GREP 0025]. In its most basic form, GRC does the following:<br />
<br />
* User sets high level options (type of flowgraph)<br />
* User draws flowgraph graphically with blocks and connections<br />
* Flowgraph uses templates (Mako) to render to a python script<br />
<br />
The goal of this project is to pull GRC out of the GNU Radio codebase and make the workflow modular. There should be a high level selection of the workflow that defines the options block. In our current usage these workflows could be:<br />
<br />
* Python QT GUI<br />
* C++ QT GUI<br />
* Python No GUI<br />
* C++ No GUI<br />
* Bokeh GUI<br />
<br />
The workflow should map to a set of templates that are used to render the output script. The definition of the workflow options and the associated templates should be defined in some pluggable manner (files dropped into a directory that GRC sees at runtime), so that "out of tree" workflows can be added easily - because we don't know all the use cases of GRC.<br />
<br />
'''Steps'''<br />
* Move GRC as a separate repository (while maintaining git history)<br />
* Remove dependence of GRC on gnuradio<br />
* Modularized options block<br />
* Modularized templates<br />
* Allow templating with jinja as well<br />
* If time allows:<br />
** Modularize gr-modtool templates as well per [https://github.com/gnuradio/greps/blob/main/grep-0026-modtool-template-rework.md GREP 0026]<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of Python.<br />
<br />
'''Project length'''<br />
<br />
175 hours<br />
<br />
'''Difficulty'''<br />
<br />
Easy<br />
<br />
'''Mentor(s)'''<br />
<br />
Josh Morman,<br />
Håkon Vågsether,<br />
?? Someone else that is a GRC Wizard<br />
<br />
=== GNU Radio goes Browser: Web Assembly (WASM) port ===<br />
<br />
<br />
[[File:WASM-preview.jpg|thumb|link=https://mobile.twitter.com/marcnewlin/status/1490577402086313984/photo/1|A view of GRC running on WASM-compiled Python]]<br />
<br />
The main goal of WebAssembly is to enable high-performance applications on web pages. Originally quite restricted to single-threaded applications, only interacting with the browser's notion of the world through a JavaScript interaction layer, today it has become quite capable, with support for threads, exceptions, SIMD and a lot of other performance-critical features.<br />
<br />
Obviously, that's great news! GNU Radio in the Browser means zero-installation, fully portable SDR for the masses. This GSoC project strives to take Marc Newlin's current work and make something functional, with the big goal of having a fully functional GNU Radio on WASM.<br />
<br />
This project has subprojects, from which the student is to pick '''one''':<br />
<br />
* porting SIMD-heavy code (eg. volk, fftw3, etc) to use the Wasm-suppprted set of intrinsics<br />
* working to bring GRC in the feature-grc-qt branch to parity with GRC in main<br />
* WebUSB driver porting (I have prototyped standalone drivers for UHD, HackRF and PlutoSDR which haven't get been integrated, and then porting gr-osmosdr would be awesome). <br />
* creating blocks for ZMQ over websockets<br />
<br />
in addition to making a (minimal) web page to which the current development state can be tested on, updated automatically from Github.<br />
<br />
'''Steps'''<br />
<br />
* Make (and test!) Marc Newlin's WASM build locally<br />
* Add a CI step to build a WASM binary<br />
* Implement one of the points above<br />
* Implement a suitable demonstration for it and deploy<br />
<br />
'''Prerequisites'''<br />
<br />
* Basic knowledge of Python<br />
* Working (especially, reading) knowledge of C++<br />
* Basic knowledge of WASM <br />
<br />
'''Mentor(s)'''<br />
<br />
* Marc Newlin<br />
* Marcus Müller<br />
* Depending on topic: further member of the GNU Radio community<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed"><br />
<br />
== Summer of Code 2021: Project ideas list ==<br />
<div class="mw-collapsible-content"><br />
<br />
This is the list of project ideas for the summer of code 2021 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months at 50% capacity<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
'''The time a student can spend on a GSoC project has been reduced by 50% for 2021 - keep this in mind when submitting your ideas'''<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add a new widget<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C++, so some C++ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Andrej Rode<br />
<br />
=== Standardized High Throughput FEC Codes ===<br />
<br />
Channel coding is essential to modern communications. Also, it is computationally very heavy. As of now, there exist implementations in GNU Radio which are too slow to be integrated into high throughput applications. GNU Radio would benefit from integration of standardized decoders for Turbo and LDPC codes. These codes would only support a certain subset of the whole code class but would be well optimized. <br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of ''gr-fec'' API. Knowledge on channel coding. Understanding of C++.<br />
<br />
'''Outcome'''<br />
<br />
* Standardized Codes, e.g. LTE Turbo Codes, 5G Polar Codes, 5G LDPC Codes, CCITT Convolutional Codes etc. are available in ''gr-fec''.<br />
* The preferred goal is to find a highly optimized implementation and integrate these into GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Johannes Demel<br />
<br />
<br />
=== GRC: View-Only Mode (Secure) ===<br />
<br />
When a flowgraph from an untrusted source is opened if GRC, arbitrary Python code can be executed. This poses a potential security risk. Storing the all evaluated values of all parameters within a flow graph (.grc) file would allow us to open such flow graphs without compromising security. No code would be have to executed to draw the flow graph and block parameters can be viewed safely. Only if the flow graph is modified the user would have to choose to trust the flow graph thus enabling normal eval operations.<br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is implemented using Python. So, Python should be known pretty well.<br />
<br />
'''Outcome'''<br />
<br />
* Safely view other people's flowgraphs without putting your PC at risk.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
=== gr-satellites: Viterbi decoder for 8b10b and FOX satellite decoder ===<br />
<br />
Even though the 8b10b line coding is primarily used for byte-level synchronization and spectral shaping, it adds some redundancy to the data, so it can be used as a forward error correction method to fix some bit errors in the received data. From the perspective of the decoder there is one bit of hidden state, so 8b10b line coding is amenable to Viterbi decoding, as hinted in [http://www.bigideatrouble.com/AMSAT%202013%20FOX1%20Paper.pdf this document about the AMSAT FOX satellites]. One goal of this project is to create Viterbi decoder block(s) for 8b10b and possibly other similar line codes, so that these blocks can be eventually upstreamed in-tree. The error correction performance of this method will be studied using simulations with these blocks. The second goal is to use the Viterbi decoder and gr-satellites to create a full decoder for the FOX satellites from AMSAT.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of C++ and Python. Some basic understanding about FEC in general.<br />
<br />
'''Outcome'''<br />
<br />
* Viterbi decoder block(s) for 8b10b and similar line codes, FOX satellite decoder added to gr-satellites<br />
<br />
'''Mentor(s)'''<br />
<br />
* Daniel Estévez<br />
<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput). This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our server, allowing us to crowdsource data. (Similar to our online stats for SIMD performance.)<br />
<br />
'''Outcome'''<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Set up automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web server.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
*Bastian Bloessl<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed"><br />
<br />
== Summer of Code 2020: Project ideas list ==<br />
<div class="mw-collapsible-content"><br />
This is the list of project ideas for the summer of code 2020 within GNU Radio.<br /><br />
Remember that these are '''ideas''' and are merely meant as an inspiration for you to write your own proposal.<br />
<br />
Students who do not find a fit among these projects are encouraged to engage with us and suggest new ones. The [[MailingLists|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 the summer of code, unless you're contacting a mentor listed here to get feedback on a proposal.<br />
<br />
Reviewing the [https://developers.google.com/open-source/gsoc/faq Google GSoC FAQ] page for a broader understanding of project, mentor, and student responsibilities is recommended.<br />
<br />
If you need a USRP or other radio hardware to complete the project, we will be able to arrange something.<br />
<br />
Please add ideas to this list (you may cannibalize old ideas, of course!).<br />
<br />
Guidelines for good projects (when suggesting projects, please consider these):<br />
<br />
* Clearly defined scope, with a main target that can be done in 3 months<br />
* Clear benefits for the GNU Radio project<br />
* Not specific to a certain hardware. No specific embedded devices, either, please.<br />
* Both OOTs and in-tree improvements are welcome<br />
<br />
<br />
<br />
=== GRC: Build-in sub flowgraphs ===<br />
<br />
GNU Radio has the hierarchical blocks to build reuseable sub flowgraphs. These hier_blocks can be designed in GRC, however, they have to be compiled to code and GRC bindings, before they can be used in other GRC files. While this is great for reuseablity across flowgraphs, it is quite cumbersome when the main use is to structure a single (larger) flowgraph. The goal of this project is to ease this use-case by embedding sub flowgraphs directly in the main GRC file. Instead of creating bindings and code and then parsing them back again, this process shall be done in-place to allow quickly editing sub flowgraphs on-the-fly. <br />
<br />
'''Prerequisites'''<br />
<br />
* GRC is written in Python which is (almost) all you need to know for this project.<br />
<br />
'''Outcome'''<br />
<br />
* A vastly improved workflow for structuring flowgraphs<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Koslowski<br />
<br />
<br />
<br />
=== Qt5 GUI Integrations ===<br />
<br />
Idea: Wrap the Qt GUI sinks to appear in QtCreator, including the GUI aspects of their parameterization<br />
<br />
'''Prerequisites'''<br />
<br />
* C++, Python proficiency<br />
* Qt experienced<br />
<br />
'''Outcome'''<br />
<br />
* Qt GUI Sinks usable as widgets in QtCreator (not necessarily already showing an "empty" GUI, just placeholders)<br />
* Possible to import generate Qt GUI description file (UIC) into GRC<br />
* Interface to map placeholders from GUI design to Qt GUI sinks in Flow graph<br />
* Integration of that into GRC-generated Python code<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Müller & Sebastian "GRC-Man" Koslowski<br />
<br />
<br />
<br />
=== Extending and Updating gr-radar ===<br />
<br />
gr-radar (https://github.com/kit-cel/gr-radar/) was a great and successful GSoC project that provided a few methods of radar in GNU Radio. This module is heavily used by academics, researchers, cybersecurity folks, and hobbyists. This project would work to improve upon the concepts already in there as well as add more radar techniques.<br />
<br />
There are uncountable methods and techniques that could be added to this project, such as:<br />
<br />
* SAR / InSAR methods<br />
* Better passive radar support<br />
* Speed camera applications<br />
* Multi-antenna radar techniques<br />
<br />
'''Prerequisites'''<br />
<br />
* Signal processing and some radar basics are required.<br />
* Code is written in C++ with some Python on the side, so the student must be able to handle these languages at the least.<br />
<br />
'''Outcome'''<br />
<br />
* Based on the student's interest, a subset of the radar techniques listed above (or others) are chosen as milestones for this project. <br />
* All code must be merged back into gr-radar by the end of the summer.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Stefan Wunsch, Martin Braun<br />
<br />
<br />
<br />
=== QT Widgets Improvements ===<br />
<br />
The gr-qtgui in-tree component provides some QT widgets for signal visualization. This component needs some improvement to become more useful.<br /><br />
This project is cleanly divided into several sub-projects:<br />
<br />
* Add new widgets<br />
** Compass display (e.g. for direction-finding applications)<br />
** MPEG display (e.g. for video demod output)<br />
** Matrix sink (e.g. for radar Doppler/range plane visualization, or 2D-equalizer taps visualization)<br />
<br />
* Improve current widgets<br />
** Better code structure to make the current widgets more manageable, extensible and remove code duplication between widgets<br />
** More Control Panels on other widgets (follow lead on the frequency sink)<br />
** Improve UI, make more intuitive, more power to mouse users<br />
** Set trigger point with mouse<br />
<br />
* Integration / Support for QT Creator<br />
** QML design<br />
** Allow to build full GUI applications from, say, GRC<br />
<br />
'''Prerequisites'''<br />
<br />
* Familiarity with QT is essential.<br />
* Widgets are written in C+'', so some C''+ knowledge is also required.<br />
* Python skills are highly useful.<br />
<br />
'''Mentor(s)'''<br />
<br />
Tim O'Shea<br />
<br />
<br />
<br />
<br />
<br />
<br />
=== Android ===<br />
<br />
One effort of the past years was to improve Android support for GNU Radio. We're getting to a point where we've figured out '''how''' to do it, so the next step is to make it more accessible to users and developers.<br />
<br />
The Android ecosystem is an entirely different beast from the rest of GNU Radio. To make writing Android/GR apps easy, the following needs to happen (and shall be part of this project):<br />
<br />
* Improve support for development environment<br />
** Create Dockers for easy start of development<br />
* Visualization classes for PSD, spectrogram and oscilloscope<br />
** Easy reuse in other apps, like the gr-qtgui widgets, but for Android SDKs<br />
* Interactivity concepts<br />
** Gestures and config for radio parameters (e.g., freq, gain, bandwidth)<br />
** Create an example FM receiver app that allows easy channel selection etc. through motions and gestures<br />
<br />
You can find a summary of the work that has been done on this (years ago) here: [[Android]]<br />
<br />
'''Prerequisites'''<br />
<br />
* Some Android experience<br />
* Enjoy writing GUI widgets<br />
* C++/Java experience<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl<br />
<br />
=== Runtime Benchmarks ===<br />
<br />
To facilitate development of a more modern GNU Radio runtime and scheduler, we need a tool to measure its performance (in terms of delay and throughput).<br />
This data is required to compare alternate approaches and to become aware of performance regressions early in the process.<br />
<br />
The goal of the project is to provide a tool to benchmark the GNU Radio runtime. Since we are interested in the performance on many platforms and architectures, it should provide an option to submit performance data to our sever, allowing us to crowdsource data. (Similar to our [http://stats.gnuradio.org/ online stats] for SIMD performance.)<br />
<br />
* Come up with interesting metrics and, if needed, implement blocks to extract them.<br />
* Come up with interesting flowgraph topologies that should be benchmarked.<br />
* Setup automated experiments that iterate over a given parameter space (repetitions, number of samples, size of the flowgraph).<br />
* Parse, evaluate, and visualize the data.<br />
* Add an option to upload the performance data to our web sever.<br />
<br />
'''Prerequisites'''<br />
<br />
* C++ programming<br />
* Data evaluation and visualization<br />
* Automation tools (like GNU Make to run benchmarks)<br />
<br />
'''Mentor(s)'''<br />
<br />
* Bastian Bloessl, Marcus Mueller<br />
<br />
=== Filter Design Tool Enhancements ===<br />
<br />
GNU Radio provides many tools to design and use digital filters. Using these tools requires both some expertise in these areas as well as an understanding of the performance on the given platform. One example is the selection between FIR (convolution-based) and FFT (fast convolution-based) filters for different resampling rates. Another example is doing stages of filter decomposition when doing large down-sampling. Included in this is the polyphase filterbanks, which again are provided as primitive blocks that need tweaking to work.<br />
<br />
This project is to improve our uses of these tools and blocks to make it more obvious to the users as well as automate some of the decisions for optimally using them. Some pointers:<br />
<br />
* When used in GRC, we want to save the results of the tool in a local file or for use in actual blocks.<br />
* It still currently runs on PyQWT, which is obsolete and needs to be updated to Qt5<br />
** See https://github.com/trondeau/gnuradio/tree/filter/design_tool_newgui<br />
* Add more support for filter design concepts and other filters.<br />
** Cascaded filters<br />
** Better support for creating PFB filters<br />
<br />
'''Prerequisites'''<br />
<br />
* Strong DSP background required.<br />
* Python and QT knowledge highly useful (at least one of those is a must).<br />
<br />
'''Mentor(s)'''<br />
<br />
* Marcus Leech<br />
<br />
<br />
<br />
=== Implement SigMF functionality for the GNU Radio Ecosystem ===<br />
<br />
SigMF is the "Signal Metadata Format" that was defined during the 2017 DARPA Hackfest in Brussels. Its purpose is to annotate raw binary dumps of signals with metadata, thus giving meaning to a raw mass of samples.<br /><br />
SigMF is specified and has a minimal reference implementation here: https://github.com/gnuradio/sigmf<br />
There is an out-of-tree module providing SigMF functionality for GNU Radio as well: https://github.com/skysafe/gr-sigmf<br />
<br />
However, SigMF is not represented well in the GNU Radio tooling landscape. Therefore, a subset of tools can be extended by SigMF support. Incomplete lists of possible tools benefitting from SigMF support:<br />
<br />
* qgrx (https://github.com/csete/gqrx)<br />
* inspectrum (https://github.com/miek/inspectrum)<br />
* ...<br />
<br />
Any additional tools are welcome in a proposal.<br />
<br />
'''Prerequisites'''<br />
<br />
* Knowledge of the programming language of the covered tools.<br />
* Hands-on experience with the respective tools.<br />
* Familiarity with the SigMF specification.<br />
<br />
'''Outcome'''<br />
<br />
* The tools worked on have capability to load and save files in the SigMF format.<br />
* Depending on the specific tool, SigMF meta data is displayed within the tool.<br />
* The number of tools worked on needs to be determined by the student, depending on his/her experience.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Sebastian Müller, Andrej Rode<br />
<br />
<br />
<br />
=== Statistical Toolbox for GRC ===<br />
<br />
A statistical toolbox for GRC would enable GUI-based statistical analysis. Currently, such analysis can be done by writing an independent program (e.g., with SciPy), but there is no actual integration with GNU Radio. By developing the statistical toolbox, we provide blocks for probability distribution fitting, hypothesis testing, extracting statistical parameters for one-dimensional as well as multi-dimensional data. This would significantly expand GNU Radio users' ability to perform data-science analysis and modeling on signal data.<br />
<br />
'''Prerequisites'''<br />
<br />
* Understanding of existing GNU Radio tools (e.g., GRC), GNU Radio Out-of-Tree Modules, and statistics / data-science modeling.<br />
<br />
'''Outcome'''<br />
<br />
* An OOT module that provides statistical analysis capabilities for GNU Radio.<br />
<br />
'''Mentor(s)'''<br />
<br />
* Ben Hilburn<br />
<br />
</div><br />
</div><br />
== Application process ==<br />
<br />
Students interested in participating, read the [[GSoCStudentInfo|student instructions]] and the [[GSoCManifest|rules of conduct]].<br />
* Please introduce yourself on the [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio GNU Radio mailing list]<br />
* Fill in the formal application for GNU Radio<br />
* Pick some items from the list above or feel free to suggest another piece of work relevant to this theme. Give us a detailed, week-by-week plan for completing the task over the summer.</div>Haakov