New GNU Radio contributor introduction

Hello GNU Radio community,

My name is Mididoddi Sai Poojith, and I'm currently a Dual Degree (BTech + MS by Research) student at IIIT Hyderabad, specializing in Electronics and Communication Engineering.

I'm highly interested in signal processing, communication systems, and open-source development, and I would like to start contributing to GNU Radio. I'm also preparing early for GSoC 2026. I want to build a solid understanding of the ecosystem.

As part of my academic background, I've completed relevant coursework, including Signal Processing, Communication Theory, Introduction to 5G, and Architecture of Cellular Systems. I'm also comfortable working with Python, C++, Git, and Linux.

Currently, I'm learning through the GNU Radio tutorials to become comfortable with GNU Radio concepts and workflow.

I would appreciate your guidance on how I can start contributing effectively as a newcomer.

Thank you for your time and guidance.

Regards,
Mididoddi Sai Poojith

Re: Question about custom buffer handling with fanout (possible bug + fix)

Hey Marcus,

Happy to be back in the mix!

Thanks for the feedback! I went ahead and made a PR with a fix that reuses the output buffer for multiple

downstream edges, so the fanout hang is gone. I forked from main (wasn't sure if main-3.10 was the right 

branch), and tested on 3.10.12.0 and main, and it seems solid.

Please feel free to try it. I totally agree, if a use-case comes up for multiple replacements, we can revisit with

a config option, but this seems save for now.

Thanks again for the guidance!

— Wael

On Jan 27, 2026, at 2:27 AM, Marcus Müller <mmueller@gnuradio.org> wrote:

Hi Wael!

Great to see you here again :)!

I'm honestly not too deep into the implementation side of the custom buffers, but reading your email, I'd say, yes, that's a bug; I'd hence love to have that as an issue on our issue tracker, unless you directly have a fix (which you seem to do).

I could technically see why in the presence of different accelerators and if our dynamic flowgraph reconfiguration worked flawlessly, you might want to exchange buffers multiple times – but not in practice. So, I'd say, go for it. Worst case, someone says "no!! You can't do that, we need…", then you rightfully say "But we need …", and then (and only then, I'd propose) we add a configuration option to switch between behaviours.

In the meantime, I'm trying to get the right eyes on this. Thank you so much!

Best regards,
Marcus

On 2026-01-26 8:08 PM, Wael Farah wrote:

Hi all,
I ran into something that looks like a bug in GNU Radio runtime related to custom buffers and fanout, and I wanted to sanity-check it with the list before opening an issue or PR.
The scenario is roughly:
 *
   An upstream block with a default (host) output buffer
 *
   That output fans out to multiple downstream blocks
 *
   Each downstream block requires a custom buffer (e.g., CUDA buffers)
In this case, it looks like |flat_flowgraph::connect_block_inputs()| <https://github.com/ gnuradio/gnuradio/blob/ec7a3239645162ffea1925e6f1e6e62bf1349d03/gnuradio-runtime/lib/ flat_flowgraph.cc%23L160> ends up calling |replace_buffer()| <https://github.com/gnuradio/ gnuradio/blob/ec7a3239645162ffea1925e6f1e6e62bf1349d03/gnuradio-runtime/lib/ flat_flowgraph.cc%23L220> once per downstream edge. This results in multiple custom buffers being allocated for the same output port, but only the last one actually remains connected to the upstream block. The earlier buffers become orphaned, and the corresponding downstream blocks stall waiting for data that never arrives.
From what I can tell, the root cause is that the buffer type comparison uses the upstream block's |output_signature()|, which is static and doesn't reflect that |replace_buffer()|   may already have been called by a previous fanout edge. So every subsequent edge still thinks it's dealing with a default buffer and tries to replace it again.
I put together a small fix that:
 *
   Checks whether an output buffer already exists
 *
   Compares the /actual buffer type/ against the signature
 *
   Reuses the existing custom buffer if it was already replaced by an earlier fanout edge
With this change, all downstream custom-buffer blocks share the same buffer created by the first edge, and the flowgraph no longer hangs. I've tested this with flowgraphs where a host block (e.g., |analog.sig_source|) fans out to multiple custom blocks; before the fix it would hang, after it works as expected.
I'm currently seeing this on GNURadio _v.3.10.12.0_ release, but I also checked the maint-3.10 branch where the same behavior still appears to be present.
Before I go any further:
Does this match others' understanding of how buffer replacement is supposed to work in fanout scenarios? Is there a reason GNU Radio intentionally allows multiple | replace_buffer()| calls on the same output port?
Happy to open an issue or PR if this is indeed unintended behavior.
Thanks!
Wael

GNU Radio at FOSDEM!

Dear most socializable SDR community to have ever been observed from orbit,

GNU Radio will be present at FOSDEM! Hope we'll see each other:

1. at the GNU Radio booth (organized by Cyrille!) in building AW
2. at the GNU Radio beards-of-a-feather on room H.3242, Saturday 14:00–14:55
3. at various talks at the Software Defined Radio(SDR)/Digital Signal Processing(DSP)
devroom on Sunday, Room K.3.601

Booth
—————

Just a table, stickers, clever people, a screen and demos! Come and ask questions.
If you feel like you could explain a thing or two about GNU Radio (you don't need to be an
expert), we might need your help. Reach out to Cyrille or me to see if there's still booth
shifts left! You will not inherently need to do a shift alone, but experience tells me if
the same person stands alone at a booth and has to talk to everyone who comes along, their
voice gets no chance to recuperate, and that's bad.

Birds-of-a-feather Room
———————————————————————

BoF is half an English proverb ("BoF flock together") meaning "people who share interests
or style like to occur and hang out together". So, since you, reading this mailing list,
obviously have great style and share interesting interests: Say hi! Share a story about
how you are using or developing GNU Radio, or just come around to meet other users. Ask
in-depth questions!

I've not structured this room very much. There's a few things I can kick off a discussion
about, but I'd let the actual group that forms decide the topics we'll cover!

SDR / DSP Devroom
—————————————————

GNU Radio is not the only SDR project out there, but it is present in several of the talks:
https://fosdem.org/2026/schedule/track/sdr-dsp/
The room organizer is a Jean-Michel Friedt, who people in the European GR community could
(and maybe should) know. People regularly tell me they'd pay good money for "the JM Friedt
show", that is, his entertaining, fast-paced presentations, so this is really anything but
a secret gem of FOSDEM :)

Anyways,
See you around at FOSDEM (and on the livestreams, chat rooms),
Marcus

Re: Question about custom buffer handling with fanout (possible bug + fix)

Hi Wael!

Great to see you here again :)!

I'm honestly not too deep into the implementation side of the custom buffers, but reading
your email, I'd say, yes, that's a bug; I'd hence love to have that as an issue on our
issue tracker, unless you directly have a fix (which you seem to do).

I could technically see why in the presence of different accelerators and if our dynamic
flowgraph reconfiguration worked flawlessly, you might want to exchange buffers multiple
times – but not in practice. So, I'd say, go for it. Worst case, someone says "no!! You
can't do that, we need…", then you rightfully say "But we need …", and then (and only
then, I'd propose) we add a configuration option to switch between behaviours.

In the meantime, I'm trying to get the right eyes on this. Thank you so much!

Best regards,
Marcus

On 2026-01-26 8:08 PM, Wael Farah wrote:
> Hi all,
>
> I ran into something that looks like a bug in GNU Radio runtime related to custom buffers
> and fanout, and I wanted to sanity-check it with the list before opening an issue or PR.
>
> The scenario is roughly:
>
> *
>
> An upstream block with a default (host) output buffer
>
> *
>
> That output fans out to multiple downstream blocks
>
> *
>
> Each downstream block requires a custom buffer (e.g., CUDA buffers)
>
> In this case, it looks like |flat_flowgraph::connect_block_inputs()| <https://github.com/
> gnuradio/gnuradio/blob/ec7a3239645162ffea1925e6f1e6e62bf1349d03/gnuradio-runtime/lib/
> flat_flowgraph.cc%23L160> ends up calling |replace_buffer()| <https://github.com/gnuradio/
> gnuradio/blob/ec7a3239645162ffea1925e6f1e6e62bf1349d03/gnuradio-runtime/lib/
> flat_flowgraph.cc%23L220> once per downstream edge. This results in multiple custom
> buffers being allocated for the same output port, but only the last one actually remains
> connected to the upstream block. The earlier buffers become orphaned, and the
> corresponding downstream blocks stall waiting for data that never arrives.
>
> From what I can tell, the root cause is that the buffer type comparison uses the upstream
> block's |output_signature()|, which is static and doesn't reflect that |replace_buffer()|
>  may already have been called by a previous fanout edge. So every subsequent edge still
> thinks it's dealing with a default buffer and tries to replace it again.
>
> I put together a small fix that:
>
> *
>
> Checks whether an output buffer already exists
>
> *
>
> Compares the /actual buffer type/ against the signature
>
> *
>
> Reuses the existing custom buffer if it was already replaced by an earlier fanout edge
>
> With this change, all downstream custom-buffer blocks share the same buffer created by the
> first edge, and the flowgraph no longer hangs. I've tested this with flowgraphs where a
> host block (e.g., |analog.sig_source|) fans out to multiple custom blocks; before the fix
> it would hang, after it works as expected.
>
> I'm currently seeing this on GNURadio _v.3.10.12.0_ release, but I also checked the
> maint-3.10 branch where the same behavior still appears to be present.
>
> Before I go any further:
>
> Does this match others' understanding of how buffer replacement is supposed to work in
> fanout scenarios? Is there a reason GNU Radio intentionally allows multiple |
> replace_buffer()| calls on the same output port?
>
> Happy to open an issue or PR if this is indeed unintended behavior.
>
> Thanks!
> Wael
>

Question about custom buffer handling with fanout (possible bug + fix)

Hi all,

I ran into something that looks like a bug in GNU Radio runtime related to custom buffers and fanout, and I wanted to sanity-check it with the list before opening an issue or PR.

The scenario is roughly:

• An upstream block with a default (host) output buffer

• That output fans out to multiple downstream blocks

• Each downstream block requires a custom buffer (e.g., CUDA buffers)

In this case, it looks like flat_flowgraph::connect_block_inputs() ends up calling replace_buffer() once per downstream edge. This results in multiple custom buffers being allocated for the same output port, but only the last one actually remains connected to the upstream block. The earlier buffers become orphaned, and the corresponding downstream blocks stall waiting for data that never arrives.

From what I can tell, the root cause is that the buffer type comparison uses the upstream block's output_signature(), which is static and doesn't reflect that replace_buffer() may already have been called by a previous fanout edge. So every subsequent edge still thinks it's dealing with a default buffer and tries to replace it again.

I put together a small fix that:

• Checks whether an output buffer already exists

• Compares the actual buffer type against the signature

• Reuses the existing custom buffer if it was already replaced by an earlier fanout edge

With this change, all downstream custom-buffer blocks share the same buffer created by the first edge, and the flowgraph no longer hangs. I've tested this with flowgraphs where a host block (e.g., analog.sig_source) fans out to multiple custom blocks; before the fix it would hang, after it works as expected.

I'm currently seeing this on GNURadio v.3.10.12.0 release, but I also checked the maint-3.10 branch where the same behavior still appears to be present.

Before I go any further:

Does this match others' understanding of how buffer replacement is supposed to work in fanout scenarios? Is there a reason GNU Radio intentionally allows multiple replace_buffer() calls on the same output port?

Happy to open an issue or PR if this is indeed unintended behavior.

Thanks!
Wael

BLUE support now in sigmf-python v1.6+

As some of the SDR community are still using MIDAS/PLATINUM Blue recordings (commonly .cdif) we have just added support to sigmf-python to read and/or convert these files.

After installing sigmf-python v1.6+ (pip install sigmf) you can now do:

import sigmf

meta = sigmf.fromfile('record.cdif')

# access samples

meta[0:100]

# access metadata

meta.sample_rate

# access BLUE fields

Meta.get_global_field("blue:fixed")

There is also a command-line converter:

sigmf_convert record.cdif converted.sigmf

For more information see the GitHub release page or our API documentation.

If you are interested in contributing to the SigMF specification or language-specific implementation send me an email.

Kyle Logue

⚝ The Aerospace Corporation

Re: CCSDS Outreach Initiative & Potential GNU Radio Collaboration

Dear Hamza,

as I mentioned (with a bit of time diversity) on said call, GNU Radio, as an organization,
is happy to help e.g. in shape of a GNU Radio workshop, or as a continuously helpful
community.

It's a great idea to form a team where everyone contributes their strengths!
I'd caution that prior to forming a team, you'd really want to sit down with the two
standards and identify what you think a team should achieve, and what you can contribute
to within that! It's two separate standards, and identifying the chunks you actually want
to work on will certainly be helpful.

Best regards,
Marcus

On 2026-01-19 1:29 PM, Hamza Mohammed wrote:
> Hi everyone,
>
> I hope you're doing well.
>
> I recently attended a webinar on the CCSDS Outreach Initiative and Competition <https://
> amsat-uk.org/2025/12/08/ccsds-outreach-initiative-and-competition/>, and I noticed that
> GNU Radio was mentioned during the session. This made me curious whether there are any
> plans or interest within the GNU Radio community to collaborate on or contribute to this
> initiative.
>
> I'd personally be very interested in getting involved, but I don't have a team.
>
> If there are any discussions, plans, or people to talk to, I'd really appreciate a pointer.
>
> Thanks a lot,
> Hamza
>