Hello Cyrille and community, i was putting the finishing touches on my proposal and was about to submit when to my surprise, the submission was closed, I looked in the timeline on the gsoc page and it shows that the deadline for my time is 8PM so i am unsure why it closedHere is my proposalI know i probably can no longer be accepted into the program, if an exception can be made that would be great, i thought i was submitting an 1 hour and 30 mins early but instead i am apparently 30 mins late, i have attached a screen shot of the timeline on my endOn Mon, Mar 30, 2026 at 1:45 PM Ziad Haithem 202201027 <s-ziad.fahmy@zewailcity.edu.eg> wrote:Thanks for the feedback this clears up quite a bit3,1) Ill explicitly state that the library is undecided and try to keep discussion on the core architecture library neutral, i'll add it as a deliverable to be done hopefully by the the first week of gsoc, it'll contain compiling a list of options, testing and final selection of the library.2) I'll incorporate more testing throughout the timeline instead of keeping all of it to the endill try to expand a bit on risks/risk mitigation & prioritization in the proposal
Virus-free.www.avast.com On Mon, Mar 30, 2026 at 11:46 AM Cyrille Morin <cyrille.morin@inria.fr> wrote:Hi Ziad,
To give you some feedback, I'll go out of order:
3) I believe deciding on the exact library to use is an important first step, and is part of the work to be done as it requires time to try out the different options. So having that decision as part of the gsoc itself is a good thing. It could even be thought of as a deliverable
1) The discussion of pros and cons is good, but the exact choice might be dependent on the specificities of the chosen library. For instance, ImGUI might be easier to integrate directly into C++ blocks than Bokeh's Python
2) In general, it's good practice to test as you go. Making all the sinks and widgets before starting to test them might leave you with nothing working, or having to rewrite everything if you find systemic bugs in your code or architecture.
Expanding on the topic of risks. It could be good to think about, and detail where you could have some wriggle room to tackle unexpected issues and/or plan B, prioritization in case time runs short.
Cyrille MORIN
Ingénieur SED
Équipe MARACAS
Centre Inria de Lyon
Laboratoire CITI
Campus La Doua - Villeurbanne
6 avenue des Arts
F-69621 Villeurbanne
Le 27/03/2026 à 18:52, Ziad Haithem 202201027 a écrit :
Sorry for the delay in my reply, things took a bit longer than i expectedThanks 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
Specifically what i would like feedback on is the following1) 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 help3) 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 stateI 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
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 FahmyID:202201027Communications and Information Engineering StudentZewail City of Science, Technology and Innovation
Ahmed Zewail Road, October Gardens, Giza 12578, Egypt
0120 205 7175
Whatsapp number - 0109 479 1824
Tuesday, March 31, 2026
Re: BokehGUI in GNU Radio 4 (GSOC)
Re: BokehGUI in GNU Radio 4 (GSOC)
Thanks for the feedback this clears up quite a bit3,1) Ill explicitly state that the library is undecided and try to keep discussion on the core architecture library neutral, i'll add it as a deliverable to be done hopefully by the the first week of gsoc, it'll contain compiling a list of options, testing and final selection of the library.2) I'll incorporate more testing throughout the timeline instead of keeping all of it to the endill try to expand a bit on risks/risk mitigation & prioritization in the proposal
Virus-free.www.avast.com On Mon, Mar 30, 2026 at 11:46 AM Cyrille Morin <cyrille.morin@inria.fr> wrote:Hi Ziad,
To give you some feedback, I'll go out of order:
3) I believe deciding on the exact library to use is an important first step, and is part of the work to be done as it requires time to try out the different options. So having that decision as part of the gsoc itself is a good thing. It could even be thought of as a deliverable
1) The discussion of pros and cons is good, but the exact choice might be dependent on the specificities of the chosen library. For instance, ImGUI might be easier to integrate directly into C++ blocks than Bokeh's Python
2) In general, it's good practice to test as you go. Making all the sinks and widgets before starting to test them might leave you with nothing working, or having to rewrite everything if you find systemic bugs in your code or architecture.
Expanding on the topic of risks. It could be good to think about, and detail where you could have some wriggle room to tackle unexpected issues and/or plan B, prioritization in case time runs short.
Cyrille MORIN
Ingénieur SED
Équipe MARACAS
Centre Inria de Lyon
Laboratoire CITI
Campus La Doua - Villeurbanne
6 avenue des Arts
F-69621 Villeurbanne
Le 27/03/2026 à 18:52, Ziad Haithem 202201027 a écrit :
Sorry for the delay in my reply, things took a bit longer than i expectedThanks 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
Specifically what i would like feedback on is the following1) 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 help3) 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 stateI 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
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 FahmyID:202201027Communications and Information Engineering StudentZewail City of Science, Technology and Innovation
Ahmed Zewail Road, October Gardens, Giza 12578, Egypt
0120 205 7175
Whatsapp number - 0109 479 1824
Late introduction: GSOC 2026 Proposal- GNU Radio 4 signal processing server for MaiaSDR
Hi GNU Radio community,
I'm Vinod Akshat, a 3rd-year undergraduate at NIT Srinagar (India) pursuing B.Tech in Computer Science and Engineering. I recently introduced myself on the GNU Radio Discord and have been following the project for the past few months.
I've submitted my GSoC 2026 proposal for "GNU Radio 4 signal processing server for MaiaSDR." The project aims to replace the existing maia-httpd backend with a GNU Radio 4–native server that streams IQ data and spectrum to the maia-wasm frontend via REST APIs and WebSocket, with support for multiple sources and SigMF recording.
I've shared both my exploratory work (notes on GR4, MaiaSDR, and gr-fosphor) and the full proposal here:
https://docs.google.com/document/d/1xVUhFP9l4fBUUJHGs4jldqGbMqGmVjlHrA6XcDIEngw/edit?usp=sharing
https://docs.google.com/document/d/1b8W-EbxvEXYdyMFyPwW-QYMaYjo0d21YeDsytCQGVQo/edit?usp=sharing
Although the submission deadline has passed, I would really appreciate any feedback or suggestions if you have time.
Thanks to the mentors and the GNU Radio community for the work you do.
Best regards,
Vinod Akshat
Discord: akshay
GitHub: akshayrivers
Re: GSoC 2026 Proposal - Hardware in the loop CI
Hi everyone,
(Apologies to Cyrille for the double email in your inbox—I accidentally hit 'Reply' instead of 'Reply All' on my first attempt! Posting my response here for the community.)
Thank you Cyrille for taking the time to read the proposal and for the specific, actionable feedback it made the revision much cleaner.
I have updated the proposal to address both points directly:
On the integration test complexity: The test scenarios are now structured as a three-tier progressive complexity ladder. Tier 1 (UHD streaming stability no RF link, no synchronisation blocks) enters CI first and independently. Tier 2 (BER loopback, FM) follows once Tier 1 is stable. Tier 3 (OFDM, multi-node, advanced sync) is explicitly scoped as stretch goals that do not block the project's core CI deliverable. The timeline milestones reflect this CI integration is never waiting on the most complex tests.
On labgrid vs. Minus: I have added a dedicated section that answers precisely where labgrid adds capability Minus does not natively provide for automated CI: (1) a blocking reservation queue so concurrent PR jobs don't collide, (2) crash-safe orphan detection via heartbeat so a killed runner doesn't hold a node locked indefinitely, and (3) hardware-agnostic YAML environment files so test scripts aren't coupled to CorteXlab node identifiers. The proposed architecture layers labgrid on top of Minus .Minus continues to handle CorteXlab's native scheduling, while labgrid handles the CI-side locking and queuing. I've also noted that I'll assess the exact Minus integration points during Community Bonding and will fall back to a thin custom shim if the labgrid exporter integration proves more complex than expected.
I'm attaching the revised proposal: Hardware in the Loop CI
Please let me know if there is anything else you'd like clarified before the deadline.
Best regards,
Joseph P George
Hello Joseph,
I read trough your document.
Overall, it looks good, it appears to have everything required of the proposal document.A couple of thoughts:
The proposed integrated tests look good and feel like what we would like to head towards, but being integration tests, they involve a lot of moving parts, so they might require a lot of tweaking and debugging time to work reliably, which might push back the integration into the CI pipeline.
I've never used Labgrid so I don't know much about what it can or cannot help with. But it does sound in your proposal to perform many task already done by the platform's systems (booking, health check, ...) You might want to detail where specifically Labgrid would offer new and required capabilities
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
Le 28/03/2026 à 14:49, Joseph George a écrit :
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=GSoCStudentInfoCyrille MORINLe 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
> Hello Joseph,
>
> I read trough your document.
> Overall, it looks good, it appears to have everything required of the
> proposal document.
>
> A couple of thoughts:
>
> The proposed integrated tests look good and feel like what we would like
> to head towards, but being integration tests, they involve a lot of
> moving parts, so they might require a lot of tweaking and debugging time
> to work reliably, which might push back the integration into the CI
> pipeline.
>
> I've never used Labgrid so I don't know much about what it can or cannot
> help with. But it does sound in your proposal to perform many task
> already done by the platform's systems (booking, health check, ...) You
> might want to detail where specifically Labgrid would offer new and
> required capabilities
Labgrid would offer a general API to the hardware so the work could
extend beyond CorteXlab. It is certainly worth a look to see if it is
straight forward to abstract the interface to the underlying hardware.
Philip
>
> Best
>
> *Cyrille MORIN*
> /Ingénieur SED/
> /Équipe MARACAS/
>
> Logo Inria
> Centre Inria de Lyon
>
> Laboratoire CITI
> Campus La Doua - Villeurbanne
> 6 avenue des Arts
> F-69621 Villeurbanne
>
> https://team.inria.fr/maracas/
> Le 28/03/2026 à 14:49, Joseph George a écrit :
>>
>> 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 <https://drive.google.com/file/
>> d/1ATLOxq_bvPpG7fizTQtZK-8w_BwadVeF/view?usp=drive_link>
>>
>> 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
>> <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 – GNU Radio RF Signal Scanner
Thank you for pointing that out.
I am attaching my GSoC 2026 proposal titled:
"Development of an Offline Automated RF Signal Scanning and Detection Tool for GNU Radio Using HackRF".
I would greatly appreciate any feedback or suggestions from the community.
Thank you for your time.
Best regards
Shreyansh Khandelwal
Hi!
Only the GSoC admins can see your submitted proposal, so please send it to the mailing
list, too, to get community feedback.
Best regards,
Marcus
On 2026-03-31 10:42 AM, Shreyansh Khandelwal wrote:
> Hello,
>
> I am Shreyansh , and I am an Electronics and Communication Engineering student interested
> in contributing to GNU Radio through Google Summer of Code 2026.
>
> I have submitted a proposal titled "Development of an Automated RF Signal Scanning and
> Detection Tool for GNU Radio Using HackRF".
>
> The project focuses on implementing:
> - Frequency sweep engine
> - FFT-based signal detection
> - Signal characterization
> - GUI integration
>
> I have experience using GNU Radio, HackRF One, and SDR experimentation. I would appreciate
> any feedback or suggestions regarding this proposal.
>
> Thank you for your time.
>
> Best regards
> Shreyansh Khandelwal
Re: GSoC 2026 Proposal – GNU Radio RF Signal Scanner
Only the GSoC admins can see your submitted proposal, so please send it to the mailing
list, too, to get community feedback.
Best regards,
Marcus
On 2026-03-31 10:42 AM, Shreyansh Khandelwal wrote:
> Hello,
>
> I am Shreyansh , and I am an Electronics and Communication Engineering student interested
> in contributing to GNU Radio through Google Summer of Code 2026.
>
> I have submitted a proposal titled "Development of an Automated RF Signal Scanning and
> Detection Tool for GNU Radio Using HackRF".
>
> The project focuses on implementing:
> - Frequency sweep engine
> - FFT-based signal detection
> - Signal characterization
> - GUI integration
>
> I have experience using GNU Radio, HackRF One, and SDR experimentation. I would appreciate
> any feedback or suggestions regarding this proposal.
>
> Thank you for your time.
>
> Best regards
> Shreyansh Khandelwal