Grant Ideas

Similar to the GSoC Ideas page, this is a list of things we could potentially ask for grant money to accomplish, or even just volunteers who want something specific to dive into:

Documentation Related

Doxygen Cleanup

We recently moved all usage-style docs to the wiki, including the one-page-per-block docs, and it's been going great, but one problem is that the Doxygen still contains the block usage docs that we used as a starting point for the wiki, and I (Marc) think we should strip all of that out of the Doxygen and only leave stuff that is developer-centric, like useful for anyone looking at (or modifying) the code. Now one question that would need to be answered is how deep we go with the list of params for each block, like do we just list the params with no description in Doxygen and refer to the wiki page for the block? We want to avoid information living in two places.

More Tutorials!

Barry has been rocking it with the tutorials but we can always use more, or have more advanced ones cleaned up

Matt C's ideas for future tutorials:

• Custom Blocks / Advanced Coding
  • how to include custom python libraries (import x) into Python OOT or embedded python block
  • Profiling flowgraph performance with htop
  • Strategies for debugging errors in GNU Radio
  • Building blocks with mixed data types (ex: 1 port float, 1 port complex)
  • Building interp (gr_sync_interp) and decimation (gr_sync_decim) blocks
• Over-the-air / Advanced DSP:
  • How to transmit/receive with various receivers (RTL-SDR, HackRF, ettus line, etc.)
  • Building an FM receiver as a way to explain real DSP concepts (tuning, filtering, demodulation, etc.)
  • Transmit FM using Laptop + B200 and listen to it on a car radio? or clock radio?
  • Using RTL-SDR with GNU Radio
  • Building a simple data-link
  • Analyze a RF indoor/outdoor thermometer, then build a receiver for it
    • Digital Mod (FSK? QAM?)
    • One-way link, then incorporate the reverse link
    • Symbol sync, carrier recov, CRC, FEC, etc.
  • How to do sample rate change to match RX/TX sample rates
  • Efficient resampling in GNU Radio
  • Why/how to use irrational rate resampler
• Additional beginner tutorials
  • Using file sink/source
  • Raw fileformats (float, complex, etc.)
  • Page for how to solve common errors in GNU Radio
  • Install gnuradio inside a VM for testing
• Video-based Tutorials (complementing text-based wiki tutorials)
• External links to DSP-based websites and/or YouTube videos
  • Help fill in the RF/DSP knowledge gaps in tutorials
  • Linking externally allows the wiki to retain tight focus on GNU radio
  • Reduces burden of explaining detailed technical knowledge inside wiki itself

Matt C: I would like to make tutorials that the community wants/needs. One idea would be to generate a list of 10 ideas and then put them in a poll and have the community rank them. Then create tutorials for the most popular ones.

Filling out Block Docs

There are still plenty of blocks without proper documentation, whether that's the description of each param, or examples, although one problem is we dont all have expert knowledge about every block, so there might need to be some reaching out to experts to try to data mine info that can be put into the docs. People tend to be more willing to write an email explaining how some block or param works, if it means they dont have to actually write the docs themselves.

Coming up with a system for exporting and versioning wiki

Now that tons of our docs live on the wiki, it opens up the question of how we can tie docs to versions of GR, and what people who dont have internet access do. These two problems can probably be solved together, because if there was a nice export of the wiki (e.g. block docs, tutorials, usage manual) then we can do an export each time a release is created, and host it somewhere. But it brings up the issue of all the changes we back-port into the older releases... So we need to decide how big an issue that is. There might also be a wiki plugin/extension that can help us do better versioning. Brainstorming is needed, and whatever approach we decide needs to be agreed on by the majority.

Training Materials Related (Not including tutorials in our docs)

In the past GNU Radio training sessions were provided by the project leads, both in-person and remote, which usually includes powerpoints and exercises. Derek is currently working on creating beginner level training materials, but we could always use more money/effort to create more advanced or specific to some area like radio astronomy or spectrum sensing or something. This one would be pretty easy to explain in a grant proposal, because the deliverable is very straightforward and its easy to explain why creating such training material is so important for the scientific/research community, GNU Radio has such a high learning curve after all.

Packaging

Windows & OS X Packaging

Pay someone to maintain Windows or macOS packaging, e.g. 20 hours a month or something and ideally it would be long term, 1+ years.

CI-generated Packages

Maintaining a Linux (e.g. Ubuntu) package repository is a lot of work, and ideally, we'd do it for more than one distro. We might pay someone who sets everything up, so that CI triggers (automatically) a regular generation of packages, and can be instructed to generate new release packages. In a perfect world, that person would accompany the project for the duration of ~2 releases, so that the kinks are worked out with a high probability.

Maintainer Assistance

Pay someone to assist the lead maintainer, by going through issues and PRs to try to label and weed out stuff, and just do whatever they can manage to help reduce the lead maintainers work load. Martin had some good words to describe this kind of role, and it's extremely valuable and would be worth paying for if we found the right person.

De-boostification

https://github.com/gnuradio/gnuradio/issues/5891

Boost as a dependency is significantly reduced in 3.10/3.11, but there are few major pieces still in there that are harder to remove. Namely, the boost threads that are integral to the runtime and scheduler. The biggest task here would be to replace boost::thread with std::thread, and ensure the same shutdown conditions that exist with the interuption_point that is available in boost.

3.11 would be a good point to have no Boost dependencies (except for maybe boost::test and boost::program_options)

GNU Radio 4.0 and Beyond

There is amazing work going on in the newsched working group, its really paving the way for the next generation GNU Radio, and if we were to find the right person and pay them with a grant, they could really dive in and help move things along, perhaps spend time benchmarking and creating QA code, or creating documentation, etc. Just to try to take some of the load off the folks already working on it. We just need to be tactful about what we pay someone to do, we don't want the volunteers to feel weird about it, so the best bet is to carve out a very specific piece of work that no one else is currently working on.

Porting Modules and Blocks

Once the structure of GR 4.0 is finalized to the extent that the block API is settled and there is minimal risk to major overhaul, migrating modules from GR 3.x to GR 4.0 will be a valuable task

Adding Unit Tests

Increasing our coverage of tests at the block level including tests that run the work method of the block without going through the scheduler will greatly ensure the robustness of the codebase

GNU Radio Companion

Enhancements to GNU Radio companion including pushing it to be a more general purpose tool