Re: GSoC 2026 Proposal - Hardware in the loop CI

Hi Joseph,

Welcome!

Feel free to share your draft here on the mailing list, for feedback by members of the community, that's the right place

I don't have a specific format for the tests scenarios, choose what you think is best/more readable/most relevant.
But do look at the GSoC Student info on the wiki if you haven't already: https://wiki.gnuradio.org/index.php?title=GSoCStudentInfo

Cyrille MORIN

Le 26/03/2026 à 15:56, Joseph George a écrit :

Hi Cyrille, 

I'm Joseph, an ECE student and the Chair of the IEEE Signal Processing Society at my college. I'm putting together a GSoC proposal for the "Hardware in the loop CI" project and wanted to quickly say hello. 

I have a strong background in bridging DSP theory with physical hardware. I recently placed 7th globally in the ICASSP 2026 ALS challenge by building domain-driven acoustic biomarker pipelines, and I regularly build hardware projects (like ESP32 navigation systems using Kalman filtering for sensor fusion). I'd love to help bring GNU Radio's CI tests out of software only simulation and onto the physical CorteXlab hardware. 

I am drafting my 12-week timeline right now. Is there a specific format you prefer for the test scenarios, or a good place to drop a link to my draft for a quick sanity check before Tuesday's deadline?

Re: GSoC 2026 Proposal - Hardware in the loop CI

Thanks, John! That exact transition from pure theory to physical reliability is what drew me to the project. 

I'm finalizing my 12-week timeline draft  to share with the group!

On Thu, 26 Mar, 2026, 21:52 John Malsbury, <john@anysignal.com> wrote:

+1

It's not glamorous to most DSP academics, but HITL CI is vital and why things like SpaceX could scale.  

On Thu, Mar 26, 2026 at 7:58 AM Joseph George <josephgeorge28360@gmail.com> wrote:

Hi Cyrille, 

I'm Joseph, an ECE student and the Chair of the IEEE Signal Processing Society at my college. I'm putting together a GSoC proposal for the "Hardware in the loop CI" project and wanted to quickly say hello. 

I have a strong background in bridging DSP theory with physical hardware. I recently placed 7th globally in the ICASSP 2026 ALS challenge by building domain-driven acoustic biomarker pipelines, and I regularly build hardware projects (like ESP32 navigation systems using Kalman filtering for sensor fusion). I'd love to help bring GNU Radio's CI tests out of software only simulation and onto the physical CorteXlab hardware. 

I am drafting my 12-week timeline right now. Is there a specific format you prefer for the test scenarios, or a good place to drop a link to my draft for a quick sanity check before Tuesday's deadline?

Re: GSoC 2026 Proposal - Hardware in the loop CI

+1

It's not glamorous to most DSP academics, but HITL CI is vital and why things like SpaceX could scale.  

On Thu, Mar 26, 2026 at 7:58 AM Joseph George <josephgeorge28360@gmail.com> wrote:

Hi Cyrille, 

I'm Joseph, an ECE student and the Chair of the IEEE Signal Processing Society at my college. I'm putting together a GSoC proposal for the "Hardware in the loop CI" project and wanted to quickly say hello. 

I have a strong background in bridging DSP theory with physical hardware. I recently placed 7th globally in the ICASSP 2026 ALS challenge by building domain-driven acoustic biomarker pipelines, and I regularly build hardware projects (like ESP32 navigation systems using Kalman filtering for sensor fusion). I'd love to help bring GNU Radio's CI tests out of software only simulation and onto the physical CorteXlab hardware. 

I am drafting my 12-week timeline right now. Is there a specific format you prefer for the test scenarios, or a good place to drop a link to my draft for a quick sanity check before Tuesday's deadline?

GSoC 2026 Proposal - Hardware in the loop CI

Hi Cyrille, 

I'm Joseph, an ECE student and the Chair of the IEEE Signal Processing Society at my college. I'm putting together a GSoC proposal for the "Hardware in the loop CI" project and wanted to quickly say hello. 

I have a strong background in bridging DSP theory with physical hardware. I recently placed 7th globally in the ICASSP 2026 ALS challenge by building domain-driven acoustic biomarker pipelines, and I regularly build hardware projects (like ESP32 navigation systems using Kalman filtering for sensor fusion). I'd love to help bring GNU Radio's CI tests out of software only simulation and onto the physical CorteXlab hardware. 

I am drafting my 12-week timeline right now. Is there a specific format you prefer for the test scenarios, or a good place to drop a link to my draft for a quick sanity check before Tuesday's deadline?

GSoC 2026 Proposal Feedback Request- CyberEther Integration with GNU Radio

Dear GNU Radio Community,

I hope you are all doing well.

My name is Nandini MP, and I am currently pursuing an MSc in Nanoscience and Nanotechnology at the University of Siegen. I am planning to apply for GSoC 2026 with a project titled "Graphical Interoperability between CyberEther and GNU Radio," and I would greatly appreciate feedback from the community.

The proposal focuses on developing an Out-Of-Tree (OOT) module to integrate CyberEther as a hardware accelerated visualization backend for GNU Radio. This aims to provide a modern alternative to the current QT/GTK based GUI by enabling faster, real-time visualization, remote interaction, and improved user experience. The module will support common plots (waterfall, spectrogram, constellation, time-domain) along with interactive widgets such as sliders and text inputs.

I have already built an initial prototype and have some prior contribution experience with GNU Radio (PR #8118). I would be grateful for any feedback on the design, feasibility, or potential improvements to the approach.

Thank you for your time and support.

Best regards,
Nandini MP

Feedback on GSoC Proposal Submission: GRC Sub-flowgraphs and Minimap Navigation

Dear GNU Radio Community,

I hope you are doing well.

My name is Suryasaradhi, and I am currently pursuing an MSc in Electronics Design and Technology at the University of Siegen. I am writing to share my GSoC 2026 proposal titled:

"Enhancing GRC: Built-in Sub-flowgraphs and Minimap Navigation"

This proposal focuses on improving the usability and scalability of GNU Radio Companion (GRC), especially for large and complex flowgraphs. The key contributions include:

- A built-in sub-flowgraph system to enable modular design without requiring external Python bindings or recompilation

- A minimap navigation system for intuitive visualization and navigation of large flowgraphs

- Improvements to workflow efficiency, design scalability, and overall user experience

I have already developed working prototypes for both the sub-flowgraph system and the minimap (GTK), and I am currently extending support to Qt. The proposal also includes detailed system design, implementation strategy, and a structured timeline.

I would greatly appreciate your feedback and suggestions to further refine the proposal. I am particularly interested in aligning the design with the current GRC architecture and community expectations.

Please find the detailed proposal attached as a PDF.

Thank you for your time and consideration.

Best regards,

Suryasaradhi

MSc Electronics Design and Technology

University of Siegen

GitHub: https://github.com/thesunRider/gnuradio

Re: BokehGUI in GNU Radio 4 (GSOC)

Hi Ziad,

Having a running GR 4.0 with a custom OOT is certainly a good start, well done!

I'm definitely not in the best position to give advice on GR4 code philosophy as I still need to start playing with it before GSoc starts.
But I believe you'll find the best and most up to date info in the gnuradio4 repo itself, including the readmes in the /docs folder, and also the 4.0.0-RC1 tag description which covers a lot of the current state

I mention Bokeh in the project description because it's the dependency we use for the current (GR3) version of the remote monitoring system, so we know it can cover the main use case.
But it is far from perfect so we are open to using an other library providing that same core use case of remote monitoring with plots and interaction with widgets, with the added bonus of not requiring anything installed on the remote computer.
So ImGUI, with its many flavours could be an interesting option with better performance, nice plots... as long as it shows an efficient way for remote operation outside of the local browser.

I hope it helps with some of your questions,

Best

Cyrille MORIN

Ingénieur SED
Équipe MARACAS

Centre Inria de Lyon

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

https://team.inria.fr/maracas/

Le 24/03/2026 à 04:40, Ziad Haithem 202201027 a écrit :

Dear GNU Radio Community,

I have decided that my gsoc proposal/project will be on the "BokehGUI in GNU radio 4.0" idea

1. Proof of Concept & Progress

To get comfortable with the GR 4.0 , I've developed a small PoC . It uses a signal generator block into a custom OOT module that publishes data to a socket via ZMQ. A Python script then subscribes to that socket and plots the sine wave in the browser in real-time using Bokeh.

Main goal is to just show i was able to take something generated by GR4 and get it displayed in the browser 

• Repo: [https://github.com/ZiadFahmyZewailCity/gr4.0-bokehgui/tree/gettingFamiliarWithDevelopment]

• Video Demo: [Link to Video]

I've also worked through the GR3 beginner and OOT tutorials, and spent time playing with ZMQ/Bokeh to ensure I can handle plotting and the data flow between processes.

2. Seeking Guidance on GR 4.0 

While I'm thrilled I got the PoC running, this is my first time working with a codebase of this scale. My main concern is moving from "making it work" to "making it right." What are some resources that'll help me design and write code that "fits" with the design philosophy behind OOT modules for GR4. I feel like this will be very important for my proposal 

3. Use of bokeh  

I wrote the POC in bokeh and focused on it when experimenting because its what was mentioned in the project description and there are plenty of resources for it. However while researching I found that in European GNU Radio Days in the next generation remote GUI section. "Imgui"  was considered a good candidate to be used for wireless plotting for GNU Radio 4.0. Has the community moved away from this opinion ? is it still present ? Should I write my proposal with only one library in mind or be flexible and have this been decided later on in development ?  

4. Why This Project?

I initially looked for something with a bit more DSP and communications concepts. However this project feels important, and I decided to go with something which would have an impact instead of wasting time thinking of a custom project to propose that had me playing with some of the concepts i was most interested in. 

I am really looking forward to the possibility of contributing to GNU Radio this summer as part of GSOC. Thank you for your time and for any pointers you can provide!

cyberspectrum is best spectrum (I think the code word is for the proposal only but one can never be too safe lol)

Sincerely,

Ziad 

--

Ziad Haithem Fahmy

ID:202201027

 

Communications and Information Engineering Student

Zewail City of Science, Technology and Innovation  

Ahmed Zewail Road, October Gardens, Giza 12578, Egypt

www.zewailcity.edu.eg

0120 205 7175

Whatsapp number - 0109 479 1824