GSoC proposal review

Hey,

So, right now I am in a bit of a pickle. Due to personal reasons I wasn't able to interact with the community and properly convey my idea and also I am a bit behind on my proposal. I am confident that I can complete it within April 8 - 18:00 UTC but a lot of the details that I initially wanted to present in the proposal wouldn't be there, I really hope this wouldn't be a problem.

Here's the link to my proposal https://github.com/Ashborn-SM/GSoC-Proposal, the document is located at latex>main.pdf. Please note that the proposal is still a work in progress. However, the first two chapters are complete (have to be proof-read), hopefully they will give a clear idea on what i am trying to accomplish. There's also a .ipynb file to prove my coding capabilities in this domain. 

Regards,

Rahul

WANTED: Flowgraphs for our Block Doc pages

**WANTED: Flowgraphs for our Block Doc pages**

Part of the value of our Block Doc pages is having an Example Flowgraph to show how that block can be used. In a recent review of our 555 current blocks, 214 of them do not have an Example Flowgraph!

Look at https://wiki.gnuradio.org/index.php?title=Category:Pages_with_no_Example_Flowgraph and https://wiki.gnuradio.org/index.php?title=Category:Stub_Docs for the lists.

So, we are appealing to you to help supply those flowgraphs. There are three sources which come to mind:

- find an example flowgraph in our repo https://github.com/gnuradio/gnuradio

- use a flowgraph from your applications of GNU Radio

- create a flowgraph to illustrate the block

If you have any questions on how to work with our documentation, you're most welcome to contact our documentation team on #docs:gnuradio.org. We appreciate your help!

---

Barry Duggan

Re: Change gain in running gloegraph

Hi Robin,

I'm still not sure what you mean with "without programming"; what you describe is doing a
specific sequence of operations as described by you in written terms. That *is*
programming already :)

But I really can't make out what you're hoping for here: under which conditions should the
frequency change?

Best regards,
Marcus

On 4/5/25 11:50 PM, robin ivetic wrote:
> Hello Marcus;
>
> I know that with variable block, but I like to run script headless, which will change
> automatically gain when reaches certain frequency, can I do that without programming, I
> look with in gnuradio-history collection, and couldn't find similar case. Sorry that I
> didn't be more precise Marcus;
>
> Robin
>
>
> ------------------------------------------------------------------------------------------
> *From:* discuss-gnuradio-bounces+otpisani1=hotmail.com@gnu.org <discuss-gnuradio-
> bounces+otpisani1=hotmail.com@gnu.org> on behalf of Marcus Müller <mmueller@gnuradio.org>
> *Sent:* Saturday, April 5, 2025 9:52 PM
> *To:* discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
> *Subject:* Re: Change gain in running gloegraph
> Hi Robin,
>
> our tutorials on https://tutorials.gnuradio.org <https://tutorials.gnuradio.org> show how
> you can use a slider to effect
> change at runtime without programming. It's one of the very first tutorial chapters!
>
> Best regards,
> Marcus
>
> On 4/5/25 11:57 AM, robin ivetic wrote:
>> Hello,
>>
>> Can I somehow change automatically gain with certain fequrncy in running script or
>> flowgraph, using soapy or osmocom block, or adding other block to existing one, mention
>> before, without additional knowledge of python language;
>>
>> Robin
>
>

Re: Change gain in running gloegraph

Hi Robin,

our tutorials on https://tutorials.gnuradio.org show how you can use a slider to effect
change at runtime without programming. It's one of the very first tutorial chapters!

Best regards,
Marcus

On 4/5/25 11:57 AM, robin ivetic wrote:
> Hello,
>
> Can I somehow change automatically gain with certain fequrncy in running script or
> flowgraph, using soapy or osmocom block, or adding other block to existing one, mention
> before, without additional knowledge of python language;
>
> Robin

Change gain in running gloegraph

Hello,

Can I somehow change automatically gain with certain fequrncy in running script or flowgraph, using soapy or osmocom block, or adding other block to existing one, mention before, without additional knowledge of python language;

Robin

Re: GSoc'25 Proposal

Hello Sliverfish,

I spotted your proposal for GPU-accelerated signal processing (gr-cuda + MatX) and wanted to say great work on outlining your approach! I've also explored gr-cuda before but couldn't pursue it deeply due to hardware constraints. However, I did have some helpful discussions with Josh Morman – one of the main contributors to gr-cuda – and he pointed me to a resource that might interest you:
https://github.com/luigifcruz/CyberEther?tab=readme-ov-file#compatibility

Here are a few suggestions you might find useful:

1. Scoping and Timeline:

   • Adding a MatX-specific buffer type plus writing specialized blocks (e.g., kernel wrappers, file I/O) can get tricky quickly. Make sure you have a strong plan for incremental testing. Wrapping entire sets of MatX capabilities might be too big for a single GSoC. You could consider focusing on a smaller, high-impact set of operations (e.g., FFTs and FIR filters) and mark the rest as stretch goals.

2. Integration with gr-cuda Memory Model:

   • gr-cuda provides a zero-copy approach for device memory. Ensure that layering higher-level MatX buffers on top of that doesn't cause redundant data transfers or overhead. A quick proof-of-concept verifying you can maintain zero-copy usage with MatX is a good first step.

3. Testing Strategy:

   • GPU debugging is often more involved than CPU-based code. Set aside extra time to build robust test harnesses, especially for performance comparisons. Mentors typically appreciate seeing a clear plan to measure throughput gains vs. CPU-based blocks under practical scenarios (large chunk sizes, typical sample rates).

4. Documentation & Examples:

   • In addition to developer docs, consider example flowgraphs that compare CPU vs. GPU blocks. Demonstrating real performance improvements for something like FFT or FIR filtering will highlight the immediate community value.

Your plan looks thorough, and it's exciting to see further GPU integration in GNURadio. I'll be following your progress—best of luck, and feel free to reach out if you want to compare notes on GPU aspects!

All the best,
Krish Gupta

On Sat, Apr 5, 2025 at 6:42 AM Shen Yu <jiayu.sjy@gmail.com> wrote:

Hello!

  My name's Silverfish, I'm a master's student studying wireless communications, and I use GNURadio for my work. I would like to contribute to the gnuradio community through GSoC.
   I've written an early version of my proposal and would love some feedback to improve it. I look forward to hearing your thoughts. Thank you for your time!

Best Wishes,

Sliverfish

GSoc'25 Proposal

Hello!

  My name's Silverfish, I'm a master's student studying wireless communications, and I use GNURadio for my work. I would like to contribute to the gnuradio community through GSoC.
   I've written an early version of my proposal and would love some feedback to improve it. I look forward to hearing your thoughts. Thank you for your time!

Best Wishes,

Sliverfish