GSoC (2026) - Hardware in the loop CI

Subject: Introduction and Interest in GSoC Hardware-in-the-Loop CI Project

Hello GNU Radio community,

My name is Naima Hassan, and I am a Telecommunications Engineer currently doing a PhD in space system engineering. My focus is on digital communications and signal processing. My research interests include wireless communication systems, software-defined radio (SDR), and practical DSP implementations for RF systems.

I recently started exploring the Google Summer of Code projects proposed by the GNU Radio community, and I am particularly interested in the Hardware-in-the-Loop CI project. The idea of introducing automated testing with real radio hardware is very exciting to me, especially since real-world wireless systems often behave quite differently from purely simulated environments.

From my background in DSP and telecommunications, I have experience with communication system designand signal analysis. I am very interested in contributing to the development of hardware-based testing scenarios, defining appropriate performance metrics (such as BER or detection accuracy), and integrating these experiments into a CI workflow.

I would love to learn more about the expectations for this project and how I could best prepare a strong proposal. If there are existing resources, repositories, or prior work related to hardware testing or the CorteXlab platform that I should study, I would greatly appreciate any pointers.

Thank you for maintaining such an impressive open-source project. I look forward to learning from the community and hopefully contributing during GSoC.

Best regards,
Naima Hassan

Re: Pybind11 ver 3.0.2 errors

Hey everyone!

Thanks! That solved an issue for me:

Lately, the GNU Radio MinGW CI has been failing, but I have had a terrible time figuring
out why. (I'm really not a fan of the Github runners, which make introspection of
something failing basically impossible before it fails, local reproduction hard, and
pairing that with rolling-release nature of Msys2 made it impossible to just look into
what changed.

So, without Ryan pointing at this, and Gisle asking about it, I wouldn't have been able to
figure this one out!

Should have asked, myself, it seems! Glad someone did :) Even more glad some answered!

Best regards,
Marcus

On 2026-03-06 11:26 PM, Gisle Vanem wrote:
> Ryan Volz wrote:
>
>>> So I ended up with:
>>>    pip3 uninstall pybind11
>>>    pip3 install pybind11==3.0.1
>>>
>>> Has anybody else seen such issues with pybind11 3.0.2?
>>>
>>>
>>
>> Hi,
>>
>> I have seen the same recently in building the `gnuradio` package for conda-forge. It
>> seems to be an upstream bug:
>> https://github.com/pybind/pybind11/issues/5989
>
> Good to know I'm not the only one. Thanks for the link.
>
>
>> For now I have also fallen back to building with pybind11 3.0.1 and hope the pybind11
>> developers will address it in the next release.
>

GSoC (2026) - CyberEther and GNU Radio

Hi Everyone! I'm Malek Hossam. I'm a fresh computer engineering graduate from Cairo University, Egypt. I have a great passion for open source projects, specifically GNU Radio, as I believe they mostly fit my background very well. I have a solid background in cpp, I also have a background with game engines as I worked on a game engine with openGL and c++. Lastly, I made a c-like language custom compiler using cpp, yacc and lex. In addition, I want to confirm that I have no experience with QT but I'am willing to learn!. I'm heavily interested in your projects but what caught my eyes the most was Graphical interoperability between CyberEther and GNU Radio (link) I was drawn to this project because enabling CyberEther visualizations inside GNU Radio would significantly improve how developers explore and debug SDR systems, and I would be excited to contribute my C++ and graphics programming experience toward that goal. I would be very grateful to receive help to start contributing and learning more about this project!

Re: Introduction and GSoC Questions - Ziad Haithem

Hi Ziad,

Welcome! You are using the mailing list perfectly.

Our ideas list includes projects that are currently available. You are welcome to propose your own idea; however, as you noted, that would require finding a mentor for the project.

Regarding the 5G scanner, I believe this has already been implemented. We have several other exciting projects listed for this year that may interest you.

Cheers,

Johannes

On Fri, 6 Mar 2026, 18:50 Ziad Haithem 202201027, <s-ziad.fahmy@zewailcity.edu.eg> wrote:

Dear GNU Radio Community,

My name is Ziad Haithem, and I am a Communication and Information Engineering student from Egypt. I am writing to introduce myself and ask a few questions regarding GSoC.

I have a strong interest in communication systems and DSP, so I was quite excited to see GNU Radio participating in GSoC this year.

I wanted to share a quick story about my experience with SDR last semester in my Digital & Wireless Communication course. Our project was to transmit audio or images wirelessly. We used LabVIEW and two NI USRPs. My teammates and I decided to be ambitious and build an OFDM-based system. Creating the OFDM system in LabVIEW, debugging the issues, and finally transmitting audio over a distance of just a few centimeters was one of the most painfully educational experiences I've had in college.

I came out of it with one big realization: theory is great, but the things that were a nightmare to deal with were the practical issues you rarely think about in a classroom—managing buffers and limited memory, synchronizing everything so your demodulation isn't ruined by being off by a single sample, and getting creative with debugging techniques just to figure out what was breaking.

I feel like developing the skills to tackle these exact issues can only come from actually building and contributing to real-world communication systems, which is why I am so eager to get involved with GNU Radio.

Regarding GSoC, I had a few questions I was hoping the community could help clarify:

1. When it comes to the list of projects from previous years, are all the projects mentioned still available to be proposed this year, or are the ones that had a student attached to them already considered complete?

2. I wanted to get in contact with the mentors of one of last year's projects (the 5G cell scanner). Their names are listed; however, I don't see any actual contact info for them.

Lastly, this is the first time I have used a mailing list. I apologize if I have broken any etiquette; please let me know if I have, and where an email like this one would be more appropriate to send.

Thank you for your time, and I look forward to contributing.

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

Virus-free.www.avast.com

Re: Pybind11 ver 3.0.2 errors

Ryan Volz wrote:

>> So I ended up with:
>>    pip3 uninstall pybind11
>>    pip3 install pybind11==3.0.1
>>
>> Has anybody else seen such issues with pybind11 3.0.2?
>>
>>
>
> Hi,
>
> I have seen the same recently in building the `gnuradio` package for conda-forge. It seems to be an upstream bug:
> https://github.com/pybind/pybind11/issues/5989

Good to know I'm not the only one. Thanks for the link.


> For now I have also fallen back to building with pybind11 3.0.1 and hope the pybind11 developers will address it in the
> next release.

--
--gv

Re: Pybind11 ver 3.0.2 errors

On 3/6/26 2:22 PM, Gisle Vanem wrote:
> Hi folks.
>
> I upgraded my Python from 3.10.5 with a pybind11
> version 3.0.1 that has worked fine with GnuRadio
> for years.
>
> Then yesterday I upgraded my Python to 3.14.2 with
> a fresh 'py -3 -m pip install pybind11' which is
> version 3.0.2.
>
> This has causes a lot of troubles in building some
> GnuRadio .PYDs. Like when compiling
> gr-digital/python/digital/bindings/ofdm_serializer_vcc_python.cc:
>
> In file included from ofdm_serializer_vcc_python.cc:20:
> In file included from F:/gv/Python314/Lib/site-packages/pybind11/
> include\pybind11/complex.h:12:
> In file included from F:/gv/Python314/Lib/site-packages/pybind11/
> include\pybind11\pybind11.h:12:
> In file included from F:/gv/Python314/Lib/site-packages/pybind11/
> include\pybind11\detail/class.h:12:
> In file included from F:/gv/Python314/Lib/site-packages/pybind11/
> include\pybind11/attr.h:13:
> In file included from F:/gv/Python314/Lib/site-packages/pybind11/
> include\pybind11\detail/common.h:225:
> f:\gv\VC_2026\VC\Tools\MSVC\14.50.35717\include\memory(2028,23): error:
> cannot cast 'gr::basic_block *' to 'typename
> shared_ptr<gr::digital::ofdm_carrier_allocator_cvc>::element_type *'
> (aka 'gr::digital::ofdm_carrier_allocator_cvc *') via virtual base
> 'gr::tagged_stream_block'
>  2028 |     const auto _Ptr = static_cast<typename
> shared_ptr<_Ty1>::element_type*>(_Other.get());
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> F:/gv/Python314/Lib/site-packages/pybind11/include\pybind11\detail/
> holder_caster_foreign_helpers.h(40,32): note: in instantiation of
>       function template specialization
> 'std::static_pointer_cast<gr::digital::ofdm_carrier_allocator_cvc,
> gr::basic_block>' requested here
>    40 |             *holder_out =
> std::static_pointer_cast<type>(existing);
>       |                                ^
> ...
>
> ofdm_serializer_vcc_python.cc(57,10): note: in instantiation of function
> template specialization
>       'pybind11::class_<gr::digital::ofdm_serializer_vcc,
> gr::tagged_stream_block,
>
> std::shared_ptr<gr::digital::ofdm_serializer_vcc>>::def<std::shared_ptr<gr::digital::ofdm_serializer_vcc> (*)(const std::shared_ptr<gr::digital::ofdm_carrier_allocator_cvc> &, const std::basic_string<char> &,
>    int, const std::basic_string<char> &, bool),
>    pybind11::detail::void_type (*)(),
> std::shared_ptr<gr::digital::ofdm_serializer_vcc> (
>    const std::shared_ptr<gr::digital::ofdm_carrier_allocator_cvc> &,
> const std::basic_string<char> &,
>    int, const std::basic_string<char> &, bool),
> pybind11::detail::void_type (), pybind11::arg,
>    pybind11::arg_v, pybind11::arg_v, pybind11::arg_v, pybind11::arg_v,
> const char *>'
> requested here
>    57 |         .def(py::init((std::shared_ptr<ofdm_serializer_vcc>(*)(
>       |          ^
> 1 error generated.
>
> ------------------------
>
> So I ended up with:
>   pip3 uninstall pybind11
>   pip3 install pybind11==3.0.1
>
> Has anybody else seen such issues with pybind11 3.0.2?
>
>

Hi,

I have seen the same recently in building the `gnuradio` package for
conda-forge. It seems to be an upstream bug:
https://github.com/pybind/pybind11/issues/5989

For now I have also fallen back to building with pybind11 3.0.1 and hope
the pybind11 developers will address it in the next release.

Cheers,
Ryan

Pybind11 ver 3.0.2 errors

Hi folks.

I upgraded my Python from 3.10.5 with a pybind11
version 3.0.1 that has worked fine with GnuRadio
for years.

Then yesterday I upgraded my Python to 3.14.2 with
a fresh 'py -3 -m pip install pybind11' which is
version 3.0.2.

This has causes a lot of troubles in building some
GnuRadio .PYDs. Like when compiling
gr-digital/python/digital/bindings/ofdm_serializer_vcc_python.cc:

In file included from ofdm_serializer_vcc_python.cc:20:
In file included from F:/gv/Python314/Lib/site-packages/pybind11/include\pybind11/complex.h:12:
In file included from F:/gv/Python314/Lib/site-packages/pybind11/include\pybind11\pybind11.h:12:
In file included from F:/gv/Python314/Lib/site-packages/pybind11/include\pybind11\detail/class.h:12:
In file included from F:/gv/Python314/Lib/site-packages/pybind11/include\pybind11/attr.h:13:
In file included from F:/gv/Python314/Lib/site-packages/pybind11/include\pybind11\detail/common.h:225:
f:\gv\VC_2026\VC\Tools\MSVC\14.50.35717\include\memory(2028,23): error: cannot cast 'gr::basic_block *' to 'typename
shared_ptr<gr::digital::ofdm_carrier_allocator_cvc>::element_type *'
(aka 'gr::digital::ofdm_carrier_allocator_cvc *') via virtual base 'gr::tagged_stream_block'
2028 | const auto _Ptr = static_cast<typename shared_ptr<_Ty1>::element_type*>(_Other.get());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
F:/gv/Python314/Lib/site-packages/pybind11/include\pybind11\detail/holder_caster_foreign_helpers.h(40,32): note: in
instantiation of
function template specialization 'std::static_pointer_cast<gr::digital::ofdm_carrier_allocator_cvc,
gr::basic_block>' requested here
40 | *holder_out = std::static_pointer_cast<type>(existing);
| ^
...

ofdm_serializer_vcc_python.cc(57,10): note: in instantiation of function template specialization
'pybind11::class_<gr::digital::ofdm_serializer_vcc, gr::tagged_stream_block,
std::shared_ptr<gr::digital::ofdm_serializer_vcc>>::def<std::shared_ptr<gr::digital::ofdm_serializer_vcc>
(*)(const std::shared_ptr<gr::digital::ofdm_carrier_allocator_cvc> &, const std::basic_string<char> &,
int, const std::basic_string<char> &, bool),
pybind11::detail::void_type (*)(), std::shared_ptr<gr::digital::ofdm_serializer_vcc> (
const std::shared_ptr<gr::digital::ofdm_carrier_allocator_cvc> &, const std::basic_string<char> &,
int, const std::basic_string<char> &, bool), pybind11::detail::void_type (), pybind11::arg,
pybind11::arg_v, pybind11::arg_v, pybind11::arg_v, pybind11::arg_v, const char *>'
requested here
57 | .def(py::init((std::shared_ptr<ofdm_serializer_vcc>(*)(
| ^
1 error generated.

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

So I ended up with:
pip3 uninstall pybind11
pip3 install pybind11==3.0.1

Has anybody else seen such issues with pybind11 3.0.2?


--
--gv