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
Friday, March 6, 2026
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
> 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
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
Introduction and GSoC Questions - Ziad Haithem
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:
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?
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
0120 205 7175
Whatsapp number - 0109 479 1824
Monday, March 2, 2026
Re: Save-the-Date: NEWSDR 2026 at WPI on June 4-5
We've created a landing page for the event:
https://newsdr.org/workshops/newsdr-2026/
More details to come soon!
On Sat, 28 Feb 2026 at 15:38, Neel Pandeya <neel.pandeya@ettus.com> wrote:
Save-the-Date: NEWSDR 2026 at WPI on June 4-5
We would like to announce the 16th annual New England Workshop on Software Defined Radio (NEWSDR) event on Friday June 5, to be hosted in-person at Worcester Polytechnic Institute (WPI), in Worcester, Massachusetts, USA. There will also be a set of tutorials and workshops on Thursday June 4.
Registration and the Call for Participation will open soon.
We will post the event page on our website soon.
We will be looking for poster presentations, exhibitors, and sponsors.
We look forward to seeing you all at the event!
https://newsdr.org/
Re: Your thoughts on attached simulation?
No, really, I wouldn't squelch at all, but simply integrate the "is this high enough"
logic into a block at the output of your moving average, which only sends a *message* only
on detection of the burst to a Qt compass sink (and anything else that cares).
That is, unless your mental physical model of what you're simulating here says the nature
of it matches well to the nature of our Squelches (which, tbh, are rather um, strange).
Best regards,
Marcus
On 2026-03-02 10:25 AM, Marcus Müller wrote:
> Hi Robert, my thoughts:
>
> You really need to describe where these signals are coming from and what they physically
> are! I'd, for example, argue you would in general need frequency recovery first – but that
> might be a given (or not a problem) in your specific system.
>
> Generally, yes, the argument of the signal is the phase. I'd frankly do the squelching, if
> at all, only after the moving average that reduces the noise variance.
>
> Best regards,
> Marcus
>
> On 2026-03-02 7:41 AM, Robert Heerekop wrote:
>> The objective is to measure the phase difference between a noisy burst of 200ms
>> containing 500Hz and a reference 500Hz.
>> Attached grc runs without hardware, contains the signal sources and works as follows:
>>
>> 1. A noisy 200ms burst signal of 500Hz is generated based on a 500Hz sine.
>> 2. A squelch block its sob-Tag triggers a python block which diverts the stream (during
>> the active pulse) from the default null sink to a detector.
>> 3. The detector is a conjugate multiplication which transfers the difference of both
>> signals to DC.
>> The noise is averaged out and the resulting phase difference is extracted.
>> 4. A compass and constallation sink show the phase difference
>>
>> 20260302.png
>> Thanks for sharing your thoughts what to improve in the phase shift detection of this
>> simulation.
>>
>> Robert
>>
>> https://github.com/rrrRbert360/GR_Burst_PHdetection <https://github.com/rrrRbert360/
>> GR_Burst_PHdetection>
>
logic into a block at the output of your moving average, which only sends a *message* only
on detection of the burst to a Qt compass sink (and anything else that cares).
That is, unless your mental physical model of what you're simulating here says the nature
of it matches well to the nature of our Squelches (which, tbh, are rather um, strange).
Best regards,
Marcus
On 2026-03-02 10:25 AM, Marcus Müller wrote:
> Hi Robert, my thoughts:
>
> You really need to describe where these signals are coming from and what they physically
> are! I'd, for example, argue you would in general need frequency recovery first – but that
> might be a given (or not a problem) in your specific system.
>
> Generally, yes, the argument of the signal is the phase. I'd frankly do the squelching, if
> at all, only after the moving average that reduces the noise variance.
>
> Best regards,
> Marcus
>
> On 2026-03-02 7:41 AM, Robert Heerekop wrote:
>> The objective is to measure the phase difference between a noisy burst of 200ms
>> containing 500Hz and a reference 500Hz.
>> Attached grc runs without hardware, contains the signal sources and works as follows:
>>
>> 1. A noisy 200ms burst signal of 500Hz is generated based on a 500Hz sine.
>> 2. A squelch block its sob-Tag triggers a python block which diverts the stream (during
>> the active pulse) from the default null sink to a detector.
>> 3. The detector is a conjugate multiplication which transfers the difference of both
>> signals to DC.
>> The noise is averaged out and the resulting phase difference is extracted.
>> 4. A compass and constallation sink show the phase difference
>>
>> 20260302.png
>> Thanks for sharing your thoughts what to improve in the phase shift detection of this
>> simulation.
>>
>> Robert
>>
>> https://github.com/rrrRbert360/GR_Burst_PHdetection <https://github.com/rrrRbert360/
>> GR_Burst_PHdetection>
>
Re: Your thoughts on attached simulation?
Hi Robert, my thoughts:
You really need to describe where these signals are coming from and what they physically
are! I'd, for example, argue you would in general need frequency recovery first – but that
might be a given (or not a problem) in your specific system.
Generally, yes, the argument of the signal is the phase. I'd frankly do the squelching, if
at all, only after the moving average that reduces the noise variance.
Best regards,
Marcus
On 2026-03-02 7:41 AM, Robert Heerekop wrote:
> The objective is to measure the phase difference between a noisy burst of 200ms containing
> 500Hz and a reference 500Hz.
> Attached grc runs without hardware, contains the signal sources and works as follows:
>
> 1. A noisy 200ms burst signal of 500Hz is generated based on a 500Hz sine.
> 2. A squelch block its sob-Tag triggers a python block which diverts the stream (during
> the active pulse) from the default null sink to a detector.
> 3. The detector is a conjugate multiplication which transfers the difference of both
> signals to DC.
> The noise is averaged out and the resulting phase difference is extracted.
> 4. A compass and constallation sink show the phase difference
>
> 20260302.png
> Thanks for sharing your thoughts what to improve in the phase shift detection of this
> simulation.
>
> Robert
>
> https://github.com/rrrRbert360/GR_Burst_PHdetection <https://github.com/rrrRbert360/
> GR_Burst_PHdetection>
You really need to describe where these signals are coming from and what they physically
are! I'd, for example, argue you would in general need frequency recovery first – but that
might be a given (or not a problem) in your specific system.
Generally, yes, the argument of the signal is the phase. I'd frankly do the squelching, if
at all, only after the moving average that reduces the noise variance.
Best regards,
Marcus
On 2026-03-02 7:41 AM, Robert Heerekop wrote:
> The objective is to measure the phase difference between a noisy burst of 200ms containing
> 500Hz and a reference 500Hz.
> Attached grc runs without hardware, contains the signal sources and works as follows:
>
> 1. A noisy 200ms burst signal of 500Hz is generated based on a 500Hz sine.
> 2. A squelch block its sob-Tag triggers a python block which diverts the stream (during
> the active pulse) from the default null sink to a detector.
> 3. The detector is a conjugate multiplication which transfers the difference of both
> signals to DC.
> The noise is averaged out and the resulting phase difference is extracted.
> 4. A compass and constallation sink show the phase difference
>
> 20260302.png
> Thanks for sharing your thoughts what to improve in the phase shift detection of this
> simulation.
>
> Robert
>
> https://github.com/rrrRbert360/GR_Burst_PHdetection <https://github.com/rrrRbert360/
> GR_Burst_PHdetection>
Subscribe to:
Comments (Atom)