Re: GSoC 2026 Proposal Feedback Request -"Graphical interoperability between CyberEther and GNU Radio"

Yes, I'm aware of that.

Since I picked this idea from the GSoC idea page, I mainly focused on designing CyberEther-powered visualization sinks for GNU Radio, so I didn't go too deep into those limitations in the proposal.

From what I understand, existing solutions like gr-fosphor are highly optimized but mainly focused on  waterfall and frequency domain  plots. With this approach, the goal is to support multiple types of visualization sinks using CyberEther.

That said, I do recognize there are limitations in this approach, and I'm aiming to build a practical and extensible integration that makes CyberEther useful within the GNU Radio ecosystem.

And I also saw recent GNU Radio Conference talks (2021–2023) on CyberEther, where future plans to integrate CyberEther with Qt for use in GNU Radio were discussed, and with that consideration I made the proposal in this direction.

Also, regarding the MSVC/clang-cl compatibility issue, I understand this could be a limitation for full integration into GNU Radio. For now, I was mainly considering a Linux based environment where CyberEther is supported and focusing on building a working pipeline first. Cross platform support can be explored later depending on feasibility .

Would like to know if this approach is reasonable for the project scope.

Re: GSoC 2026 Proposal - Hardware in the loop CI

Hi Cyrille,

I have completed the first draft of my GSoC 2026 proposal for the "Hardware in the Loop CI" project.

Draft : Hardware in the Loop CI

A huge thank you to Larry and Philip for the insights. I have explicitly integrated the LBNL Node Health Check paradigm to isolate hardware failures from software regressions, and I've adopted Labgrid as the core hardware orchestration layer to manage the CorteXlab USRPs.

I would greatly appreciate any feedback from the community,

Thanks for your time and guidance!

Best, Joseph George

On Thu, 26 Mar 2026 at 22:23, Cyrille Morin <cyrille.morin@inria.fr> wrote:

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 Feedback Request -"Graphical interoperability between CyberEther and GNU Radio"

Amith Biju wrote:

> I have prepared my proposal for GSoC 2026 focused on Graphical interoperability between CyberEther and GNU Radio
>
> I would greatly appreciate any feedback or suggestions from the community. In particular, I would love input on:
>
> * the overall architecture and design
> * feasibility of the implementation plan
> * any potential issues or gaps I may have missed

I'm not sure you're aware that CyberEther currently
does NOT build with MSVC or clang-cl tools. That would
be a bit show-stopper for this integration into GNU-Radio.

I've tried; CyberEther is very GNU-C centric and on the bleeding
edge of the C++ standards. Even the use of ISO646 naming ('and', 'or')
breaks in clang-cl.

And WRT to use of GPU in GNU-Radio, this has been party done
in 'gr-fosphor'; https://www.youtube.com/watch?v=mjD-l3GAghU

--
--gv

GSoC 2026 Proposal Feedback Request -"Graphical interoperability between CyberEther and GNU Radio"

Hi GNU Radio Community,

I have prepared my proposal for GSoC 2026 focused on Graphical interoperability between CyberEther and GNU Radio

I would greatly appreciate any feedback or suggestions from the community. In particular, I would love input on:

• the overall architecture and design
• feasibility of the implementation plan
• any potential issues or gaps I may have missed

I have attached the proposal (PDF) and also included a Google Docs version 

• Google Docs:  https://docs.google.com/document/d/1Arw9rzifBS-8E1mr1PmRMjgZqMaKR0w1rD0NslaGFsw/edit?usp=sharing
•  PDF: attached 

Any feedback would be very helpful in improving the proposal. Thank you for your time and support.

Best regards,
Amith Biju

Re: BokehGUI in GNU Radio 4 (GSOC)

Sorry for the delay in my reply, things took a bit longer than i expected

Thanks for the answers 

I went ahead and looked up some developer tutorials for GR4 and i think i have a good enough of an understanding now to be able to write a good proposal,

Here is the google doc fo my proposal with the technical aspects complete and that's mainly what i would like to get feedback on

https://docs.google.com/document/d/18-Tik6fIwv6KZVvqpIYjX_cKrxYV9c4MihXhG65SPKg/edit?usp=sharing

Specifically what i would like feedback on is the following

1) My main design choice on the core infrastructure and if my rationalization behind it is sufficient (I detail 3 approaches in my proposal and compare them)

2) I lack quite a bit of experience with QA & documentation and so those parts of the proposal may be a bit lackluster any feedback on that would definitely help 

3) I have essentially pushed back the question of what library for browser plotting will be used (Bokeh, imgui, etc) to being part of the first week of work, as i feel i wont have enough time to do an actual good assessment before the proposal deadline, is that okay or do i need to specify the library which will be used ?

Obviously any feedback on anything else is welcome, I am sure I have so much to learn ! 

Since its a google doc, feedback via comments within the document would be easier than email i think, however whatever is preferable for you is fine

On Wed, Mar 25, 2026 at 5:34 PM Cyrille Morin <cyrille.morin@inria.fr> wrote:

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

Hi Cyrille,

I hope you're doing well.

I have completed a draft of my GSoC proposal titled "Hardware-in-the-Loop Continuous Integration for GNU Radio using CorteXlab." I have attached the proposal as a PDF for your review.

I would really appreciate it if you could take some time to review it and share your feedback, especially regarding the overall approach, feasibility, and any areas for improvement.

Thank you for your time and guidance.

Best regards,
Sayantan Maity
B.S. Electronics Systems, IIT Madras

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?