GNU Radio has been accepted to the Google Summer of Code 2026

Hey everyone,

The GNU Radio project has been accepted for GSoC 2026. This could be
your opportunity to create something great with and for GNU Radio. 🎉🎉

We have a longer announcement with more details:
https://www.gnuradio.org/news/2026-02-22-gsoc26-announcement/

Cheers
Johannes

Re: Discuss-gnuradio Digest, Vol 280, Issue 9

Marcus,

Thank you for your helpful corrections.  We changed the constellation to fix the missing point and we had a duplicate point.  This was by mistake.

We updated the attached .grc to fix that and also changed it to be QAM-16 modules instead of QPSK.

Our next question is:

We want to prove that the random input matches the final output.

Where do we put the file sync module to prove that the random input matches the final output?

Thanks again.

Maureen

On Sat, Feb 21, 2026 at 11:02 AM <discuss-gnuradio-request@gnu.org> wrote:

Send Discuss-gnuradio mailing list submissions to
        discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
        discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
        discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Re: Why does the random input not match the output
      (Marcus Müller)


----------------------------------------------------------------------

Message: 1
Date: Sat, 21 Feb 2026 08:59:39 +0100
From: Marcus Müller <mmueller@gnuradio.org>
To: discuss-gnuradio@gnu.org
Subject: Re: Why does the random input not match the output
Message-ID: <21a44bc5-7578-465d-b047-5e57030029f8@gnuradio.org>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constellation points.png
Type: image/png
Size: 14880 bytes
Desc: not available
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20260221/4a6ab333/attachment.png>

------------------------------

Subject: Digest Footer

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


------------------------------

End of Discuss-gnuradio Digest, Vol 280, Issue 9
************************************************

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.