GSoC 2026 Interest: BokehGUI in GNU Radio 4

Hello GNU Radio Team,

My name is Kiran Dharmar, a second-year Computer Science student from Vijayapura, Karnataka, India. I recently went through the GSoC 2026 ideas page and carefully read your organization's policies and expectations.

I am highly interested in contributing to the "BokehGUI in GNU Radio 4" project. The idea of building a remote, browser-based GUI module for GNU Radio 4 strongly aligns with my interests in backend systems, visualization pipelines, and open-source development.

Technical Background:

I have experience working with Python and foundational C++. My primary focus areas include machine learning systems, inference pipelines, and backend integration. I have worked with PyTorch, TensorFlow, and NumPy, and I am currently learning ONNX for model export and optimization workflows. I am comfortable working in Linux environments and collaborating through Git and GitHub.

Open Source Contributions:

I am actively contributing to open-source projects:

• Kornia:

  - PR #3520 (under review)

  - PR #3565 (under review)

• FOSSASIA Visdom:

  - Fixed an incorrect wildcard routing issue that affected static asset handling.

  - Implemented support for explicit X/Y axis values in heatmaps.

• Biopython:

  - Fixed URL construction logic in PDBList for non-RCSB mirror compatibility.

These contributions strengthened my understanding of backend logic, routing systems, compatibility improvements, and clean integration practices.

Projects:

I have built projects involving data pipelines, neural network training workflows, and backend-driven AI systems, including:

- Instagram User Data Analysis (Python, Pandas)

- VidSnap AI (Flask-based AI reel generator system)

- MNIST Classification using TensorFlow/Keras

I am particularly excited about BokehGUI because it combines backend processing with interactive visualization — an area where I want to grow deeply. I am committed to contributing consistently and would appreciate guidance on how I can begin preparing or contributing toward this project.

Thank you for your time and consideration.

Best regards,  

Kiran Dharmar  

Email: kirandharmar867@gmail.com  

GitHub: https://github.com/kirandharmar867-maker  

LinkedIn: https://www.linkedin.com/in/kiran-dharmar-73718437a  

Location: Vijayapura, Karnataka, India

GSoC 2026 — Student introduction and guidance on CyberEther visualization proposal

Hello GNU Radio community,

My name is Amith Biju, and I am a second year Computer Science and Engineering student at Cochin University of Science and Technology, currently pursuing a minor in Electronics and Communication. I am proficient in C, C++, and Python. Through my academic projects, I developed an interest in real-time systems and signal processing, which led me to explore GNU Radio as part of my preparation for GSoC 2026

  So far, I have contributed to GNU Radio through three pull requests, two of which addressed beginner level issues( #7999 , #8047 ) and have been merged, while the third, involving a feature implementation ( #8028 ), is currently under review. This contribution process helped me understand how changes are made within the codebase and how different components interact internally. Through this journey, along with guidance from the community, I gained initial insight into GNU Radio's development workflow. In addition, I have built  flowgraphs and   conducted small experiments as part of my project , which helped me understand GNU Radio from a user perspective.  

My current proposal  for GSoC 2026 focuses on exploring CyberEther based visualization support within GRC. Since this workflow shares conceptual similarities with gr-bokehgui, I have been studying the original gr-bokehgui proposal and its implementation to understand how visualization workflows are designed and how I can approach a similar proposal for CyberEther integration. In parallel, I am also exploring the BokehGUI work for GNU Radio 4, as both efforts involve related visualization architectures and design considerations. These ideas were inspired by the project ideas shared on the GNU Radio GSoC wiki page.

As part of my preparation, I am studying sink implementation, OOT module structure, and existing visualization backends. I have also gone through the contributor guidelines, student instructions, and the code of conduct to better understand community expectations for GSoC. During the proposal period, I plan to continue learning, contributing, and demonstrating my ability to work effectively within the GNU Radio community. If time allows, I will also continue contributing by working on relevant issues

.
  I would appreciate any feedback on whether my current learning direction is appropriate and if there are specific areas of the GNU Radio codebase, design aspects, or resources I should focus on while preparing for CyberEther visualization support. Any guidance from the community would be very helpful.  

Best regards,

Amith Biju

Re: Why does the random input not match the output

Hi Maureen!
Great to have you here, welcome to the community!

> There is a chunk of data missing on the bottom
> left hand corner.

You had me scared there for a moment, but:

That's perfectly congruent with your choice of constellation points; attached output of
(roughly this code)

import numpy
from matplotlib import pyplot
# copy & pasted from your constellation object "qam"'s constellation points:
points = numpy.array([-0.9489 -0.3162j, -0.9489 +0.3162j, -0.9489 +0.9489j,
-0.3162-0.9489j, -0.3162-0.9489j, -0.3162-0.3162j, -0.3162+0.3162j, -0.3162+0.9489j,
0.3162-0.9489j, 0.3162-0.3162j, 0.3162+0.3162j, 0.3162+0.9489j, 0.9489 -0.9489j, 0.9489
-0.3162j, 0.9489 -0.3162j, 0.9489 +0.9489j])
pyplot.scatter(points.real, points.imag)
pyplot.savefig("/tmp/figure.png")

why you might not have seen the same "missing" constellation points in your channel
model's output is the frequency offset (0.01), which rotates the whole thing by 1/100 of a
full rotation per sample, so one "quarterrotation" every 25 samples; the synchronization
after might be doing its best, but might not be able to counter that. I haven't actually
looked deeper into that!

There's a few things to discuss here, like whether the constellation points are
intentionally like they are (they might be – you might be doing an experiment where you
intentionally confuse multiple points), and how an "unbalanced" (and hence not white)
transmission might affect carrier recovery.

Best regards,
Marcus

CGRAN website SSL certificate is expired.

Hello.

I just thought you should know that the SSL certificate for cgran.org is expired.

Re: [VOLK] Release 3.3.0

Marcus Müller <mmueller@gnuradio.org> writes:

> would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?

I commented in the PR, but it applies to 3.3.0, builds under pkgsrc with
gcc 10, and passes tests. Looks good to merge from my viewpoint.

Re: [VOLK] Release 3.3.0

Hello Greg,

would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?

Hello Johannes,

sadly I could not find a way that both introduces no random new includes in volk_common.h
that causes functional changes in consumers of the header, while still addressing the
issue Greg describes; the cleanest seems to be moving the mostly-internal math functions
out of volk_common.h to a new header.
That of course means API breakage; sorry.

Best regards,
Marcus

On 2026-02-09 5:39 PM, Marcus Müller wrote:
> hm that volk_common.h is generally not that well-structured; I'd advocate for having
> something like `volk_cos_poly` in a different file than basic type and attribute
> declarations that get used all over the place. I'll make a PR to that end; if you could
> test that, Greg, it'd be much appreciated.
>
> Best regards,
> Marcus
>
> On 2026-02-08 8:57 PM, Greg Troxel wrote:
>> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>>
>>> Hey Greg,
>>>
>>> thanks for picking up the release so quickly. I haven't seen this issue
>>> with any of the CI compilers.
>>> Would there be a way to reproduce that in a docker container?
>>
>> You could add NetBSD 10 the CI farm.  (I am not clear on how docker
>> works.)
>>
>>
>> It seems this is pretty hard:
>>
>>    https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
>>    https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
>>    https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-
>> you-might-think
>>      (section "absolute mess")
>>
>> another possibility is to use __builtin_isnan, which works
>> on gcc and clang but that's not portable to other compilers that comply
>> with standards.
>>
>>  From reading lots of things, I have taken away that in C++ code isnan
>> should always be written std::isnan(), have not found anything
>> indicating that writing it that way is at all bad, and that it's
>> unspecified if abs without std:: works or not.
>>
>>
>>
>

Re: [VOLK] Release 3.3.0

Marcus Müller <mmueller@gnuradio.org> writes:

> place. I'll make a PR to that end; if you could test that, Greg, it'd
> be much appreciated.

Sure, please feel free to @gdt (github and codeberg) or email me a link
and I'll try it.

Johannes: I realize that having bougght into github CI that it's not a
great portability situation as the set of available runners is very
limited. I am struggling with this myself on an unrelated project, but
so far more inclined to put energy into leaving github and some
beyond-github future CI more than improving CI on github, even if it's
not so much either way :-(


Someone else updated volk to 3.3.0 and here's the patch they arrived at.
I'm not a fan of doing it this way (upstream), but it does more or less
show the issue well.



--- include/volk/volk_common.h.orig 2026-02-09 12:27:43.544508041 +0000
+++ include/volk/volk_common.h
@@ -150,7 +150,12 @@ union bit256 {
////////////////////////////////////////////////////////////////////////
// log2f
////////////////////////////////////////////////////////////////////////
+#ifdef __cplusplus
+#include <cmath>
+using std::isinf, std::isnan;
+#else
#include <math.h>
+