Thursday, March 12, 2026

GSoC 2026 Intro: SDR Developer interested in the 5G Cell Scanner Project

Hi everyone,

I'm Mujtaba Ahmed, a final-year Electrical Engineering student specializing in Embedded Systems. I am planning to apply for GSoC 2026 and am highly interested in contributing to the 5G Cell Scanner project.

I'm actively working in this exact domain right now. I am currently building a distributed system to detect and localize radio transmitters using TDOA algorithms, working directly with HackRF One and ADALM-PLUTO SDRs. Because I spend my time in Ubuntu bridging physical radio hardware with software-level signal processing, I am very comfortable with the exact challenges of passively detecting and capturing RF signals, and I want to bring that hands-on experience to GNU Radio.

I am setting up my development environment this weekend to compile GNU Radio from source. Are there any specific "good first issues," existing flowgraphs, or 5G protocol parsers the mentors recommend I tackle to demonstrate my skills before the formal application period opens?

Looking forward to learning from you all!

Wednesday, March 11, 2026

Re: Releasing the next 3.10.x soon – complain, please

I would like it and think I would benefit from it.

John

On Wed, Mar 11, 2026, 6:44 PM Marcus Müller <mmueller@gnuradio.org> wrote:

Hi Wael,

because I'd like to be careful about changing buffer infra on the released branch, I can do that, but would only do it if someone definitely benefits from it more than it just being included in a GNU Radio 3.11.0.0 some ~1 month in the future.

Would backporting this specifically help you / cascade? Then, it's totally doable! 

Best,
Marcus

On 2026-03-10 11:49 PM, Wael Farah wrote:
Hey Marcus,

That's awesome!

Might there be a chance to include the subclassing buffer_double_mapped and the gr::buffer::on_transfer_type to the release?
They're not technically API-breaking, but I understand and respect if you have other criteria you usually follow.

Best,
Wael

On Mar 10, 2026, at 2:57 AM, Marcus Müller <mmueller@gnuradio.org> wrote:

Dear Community,

this weekend, I finally have gotten around to backport all (but one) of the changes made to `main` to `maint-3.10`, as far as I've been keeping track of them [1], or decide that they can't and/or shan't be backported.

I might have missed something! If there's some feature that doesn't need an API-breaking change to be backported that I'm missing which you'd really like to see in 3.10.13.0, let me know. I'm aiming for a release candidate coming weekend.

Best regards,
Marcus


[1] https://github.com/orgs/gnuradio/projects/12/views/1


Re: Releasing the next 3.10.x soon – complain, please

Hi Wael,

because I'd like to be careful about changing buffer infra on the released branch, I can do that, but would only do it if someone definitely benefits from it more than it just being included in a GNU Radio 3.11.0.0 some ~1 month in the future.

Would backporting this specifically help you / cascade? Then, it's totally doable! 

Best,
Marcus

On 2026-03-10 11:49 PM, Wael Farah wrote:
Hey Marcus,

That's awesome!

Might there be a chance to include the subclassing buffer_double_mapped and the gr::buffer::on_transfer_type to the release?
They're not technically API-breaking, but I understand and respect if you have other criteria you usually follow.

Best,
Wael

On Mar 10, 2026, at 2:57 AM, Marcus Müller <mmueller@gnuradio.org> wrote:

Dear Community,

this weekend, I finally have gotten around to backport all (but one) of the changes made to `main` to `maint-3.10`, as far as I've been keeping track of them [1], or decide that they can't and/or shan't be backported.

I might have missed something! If there's some feature that doesn't need an API-breaking change to be backported that I'm missing which you'd really like to see in 3.10.13.0, let me know. I'm aiming for a release candidate coming weekend.

Best regards,
Marcus


[1] https://github.com/orgs/gnuradio/projects/12/views/1


interp_resampler_pfb crashes with huge samples

Hi all!

Here you can see that when the polyphase interpolator computes an index out of bounds it throws a runtime error instead of just truncating or wrapping it around.

We've encountered a situation in which a normal stream coming from a SDR has a few huge samples (~ 1e28) and this block crashes the entire flowgraph.

From my understanding of polyphase filters (thanks fharris&trondeau!), wouldn't it be better to just wrap it?

Thanks!

Francisco.

Tuesday, March 10, 2026

Re: Releasing the next 3.10.x soon – complain, please

Hey Marcus,

That's awesome!

Might there be a chance to include the subclassing buffer_double_mapped and the gr::buffer::on_transfer_type to the release?
They're not technically API-breaking, but I understand and respect if you have other criteria you usually follow.

Best,
Wael

On Mar 10, 2026, at 2:57 AM, Marcus Müller <mmueller@gnuradio.org> wrote:

Dear Community,

this weekend, I finally have gotten around to backport all (but one) of the changes made to `main` to `maint-3.10`, as far as I've been keeping track of them [1], or decide that they can't and/or shan't be backported.

I might have missed something! If there's some feature that doesn't need an API-breaking change to be backported that I'm missing which you'd really like to see in 3.10.13.0, let me know. I'm aiming for a release candidate coming weekend.

Best regards,
Marcus


[1] https://github.com/orgs/gnuradio/projects/12/views/1


Re: GSoC (2026) - Hardware in the loop CI

Hello Naima,

Welcome!

You can find information on the CorteXlab platform in its wiki: https://www.cortexlab.fr, feel free to look into that, or even create an account.

If you haven't already, I would advise that you go through the tutorials on the GNU Radio wiki. Both because they are a good resource to get started with GNU Radio in general, but also because they are, with some of the example flowgraphs in the main repo, examples of true communication chains involving hardware, and they might be an interesting starting point for testing.

Best 

Cyrille MORIN @Notou
Ingénieur SED
Équipe MARACAS


Centre Inria de Lyon

Laboratoire CITI
Campus La Doua - Villeurbanne
6 avenue des Arts
F-69621 Villeurbanne

Le 09/03/2026 à 09:15, Naima Dimbil a écrit :

Subject: Introduction and Interest in GSoC Hardware-in-the-Loop CI Project

Hello GNU Radio community,

My name is Naima Hassan, and I am a Telecommunications Engineer currently doing a PhD in space system engineering. My focus is on digital communications and signal processing. My research interests include wireless communication systems, software-defined radio (SDR), and practical DSP implementations for RF systems.

I recently started exploring the Google Summer of Code projects proposed by the GNU Radio community, and I am particularly interested in the Hardware-in-the-Loop CI project. The idea of introducing automated testing with real radio hardware is very exciting to me, especially since real-world wireless systems often behave quite differently from purely simulated environments.

From my background in DSP and telecommunications, I have experience with communication system designand signal analysis. I am very interested in contributing to the development of hardware-based testing scenarios, defining appropriate performance metrics (such as BER or detection accuracy), and integrating these experiments into a CI workflow.

I would love to learn more about the expectations for this project and how I could best prepare a strong proposal. If there are existing resources, repositories, or prior work related to hardware testing or the CorteXlab platform that I should study, I would greatly appreciate any pointers.

Thank you for maintaining such an impressive open-source project. I look forward to learning from the community and hopefully contributing during GSoC.

Best regards,
Naima Hassan

Releasing the next 3.10.x soon – complain, please

Dear Community,

this weekend, I finally have gotten around to backport all (but one) of the changes made
to `main` to `maint-3.10`, as far as I've been keeping track of them [1], or decide that
they can't and/or shan't be backported.

I might have missed something! If there's some feature that doesn't need an API-breaking
change to be backported that I'm missing which you'd really like to see in 3.10.13.0, let
me know. I'm aiming for a release candidate coming weekend.

Best regards,
Marcus


[1] https://github.com/orgs/gnuradio/projects/12/views/1