Re: Why does the random input not match the output

Hi Maureen!
Great to have you here, welcome to the community!

> There is a chunk of data missing on the bottom
> left hand corner.

You had me scared there for a moment, but:

That's perfectly congruent with your choice of constellation points; attached output of
(roughly this code)

import numpy
from matplotlib import pyplot
# copy & pasted from your constellation object "qam"'s constellation points:
points = numpy.array([-0.9489 -0.3162j, -0.9489 +0.3162j, -0.9489 +0.9489j,
-0.3162-0.9489j, -0.3162-0.9489j, -0.3162-0.3162j, -0.3162+0.3162j, -0.3162+0.9489j,
0.3162-0.9489j, 0.3162-0.3162j, 0.3162+0.3162j, 0.3162+0.9489j, 0.9489 -0.9489j, 0.9489
-0.3162j, 0.9489 -0.3162j, 0.9489 +0.9489j])
pyplot.scatter(points.real, points.imag)
pyplot.savefig("/tmp/figure.png")

why you might not have seen the same "missing" constellation points in your channel
model's output is the frequency offset (0.01), which rotates the whole thing by 1/100 of a
full rotation per sample, so one "quarterrotation" every 25 samples; the synchronization
after might be doing its best, but might not be able to counter that. I haven't actually
looked deeper into that!

There's a few things to discuss here, like whether the constellation points are
intentionally like they are (they might be – you might be doing an experiment where you
intentionally confuse multiple points), and how an "unbalanced" (and hence not white)
transmission might affect carrier recovery.

Best regards,
Marcus

CGRAN website SSL certificate is expired.

Hello.

I just thought you should know that the SSL certificate for cgran.org is expired.

Re: [VOLK] Release 3.3.0

Marcus Müller <mmueller@gnuradio.org> writes:

> would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?

I commented in the PR, but it applies to 3.3.0, builds under pkgsrc with
gcc 10, and passes tests. Looks good to merge from my viewpoint.

Re: [VOLK] Release 3.3.0

Hello Greg,

would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?

Hello Johannes,

sadly I could not find a way that both introduces no random new includes in volk_common.h
that causes functional changes in consumers of the header, while still addressing the
issue Greg describes; the cleanest seems to be moving the mostly-internal math functions
out of volk_common.h to a new header.
That of course means API breakage; sorry.

Best regards,
Marcus

On 2026-02-09 5:39 PM, Marcus Müller wrote:
> hm that volk_common.h is generally not that well-structured; I'd advocate for having
> something like `volk_cos_poly` in a different file than basic type and attribute
> declarations that get used all over the place. I'll make a PR to that end; if you could
> test that, Greg, it'd be much appreciated.
>
> Best regards,
> Marcus
>
> On 2026-02-08 8:57 PM, Greg Troxel wrote:
>> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>>
>>> Hey Greg,
>>>
>>> thanks for picking up the release so quickly. I haven't seen this issue
>>> with any of the CI compilers.
>>> Would there be a way to reproduce that in a docker container?
>>
>> You could add NetBSD 10 the CI farm.  (I am not clear on how docker
>> works.)
>>
>>
>> It seems this is pretty hard:
>>
>>    https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
>>    https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
>>    https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-
>> you-might-think
>>      (section "absolute mess")
>>
>> another possibility is to use __builtin_isnan, which works
>> on gcc and clang but that's not portable to other compilers that comply
>> with standards.
>>
>>  From reading lots of things, I have taken away that in C++ code isnan
>> should always be written std::isnan(), have not found anything
>> indicating that writing it that way is at all bad, and that it's
>> unspecified if abs without std:: works or not.
>>
>>
>>
>

Re: [VOLK] Release 3.3.0

Marcus Müller <mmueller@gnuradio.org> writes:

> place. I'll make a PR to that end; if you could test that, Greg, it'd
> be much appreciated.

Sure, please feel free to @gdt (github and codeberg) or email me a link
and I'll try it.

Johannes: I realize that having bougght into github CI that it's not a
great portability situation as the set of available runners is very
limited. I am struggling with this myself on an unrelated project, but
so far more inclined to put energy into leaving github and some
beyond-github future CI more than improving CI on github, even if it's
not so much either way :-(


Someone else updated volk to 3.3.0 and here's the patch they arrived at.
I'm not a fan of doing it this way (upstream), but it does more or less
show the issue well.



--- include/volk/volk_common.h.orig 2026-02-09 12:27:43.544508041 +0000
+++ include/volk/volk_common.h
@@ -150,7 +150,12 @@ union bit256 {
////////////////////////////////////////////////////////////////////////
// log2f
////////////////////////////////////////////////////////////////////////
+#ifdef __cplusplus
+#include <cmath>
+using std::isinf, std::isnan;
+#else
#include <math.h>
+

Re: [VOLK] Release 3.3.0

Hey Greg,

Our CI consists of the GitHub runners that are available through this channel. If there's a service to add netbsd runners, please let me know. That'd be a great addition. 

Besides, Marcus suggestion to fix things sounds good either way. 

Cheers

Johannes 

On Mon, 9 Feb 2026, 17:39 Marcus Müller, <mmueller@gnuradio.org> wrote:

hm that volk_common.h is generally not that well-structured; I'd advocate for having
something like `volk_cos_poly` in a different file than basic type and attribute
declarations that get used all over the place. I'll make a PR to that end; if you could
test that, Greg, it'd be much appreciated.

Best regards,
Marcus

On 2026-02-08 8:57 PM, Greg Troxel wrote:
> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>
>> Hey Greg,
>>
>> thanks for picking up the release so quickly. I haven't seen this issue
>> with any of the CI compilers.
>> Would there be a way to reproduce that in a docker container?
>
> You could add NetBSD 10 the CI farm.  (I am not clear on how docker
> works.)
>
>
> It seems this is pretty hard:
>
>    https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
>    https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
>    https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think
>      (section "absolute mess")
>
> another possibility is to use __builtin_isnan, which works
> on gcc and clang but that's not portable to other compilers that comply
> with standards.
>
>  From reading lots of things, I have taken away that in C++ code isnan
> should always be written std::isnan(), have not found anything
> indicating that writing it that way is at all bad, and that it's
> unspecified if abs without std:: works or not.
>
>
>

Re: [VOLK] Release 3.3.0

hm that volk_common.h is generally not that well-structured; I'd advocate for having
something like `volk_cos_poly` in a different file than basic type and attribute
declarations that get used all over the place. I'll make a PR to that end; if you could
test that, Greg, it'd be much appreciated.

Best regards,
Marcus

On 2026-02-08 8:57 PM, Greg Troxel wrote:
> Johannes Sterz Demel <jdemel@gnuradio.org> writes:
>
>> Hey Greg,
>>
>> thanks for picking up the release so quickly. I haven't seen this issue
>> with any of the CI compilers.
>> Would there be a way to reproduce that in a docker container?
>
> You could add NetBSD 10 the CI farm. (I am not clear on how docker
> works.)
>
>
> It seems this is pretty hard:
>
> https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
> https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
> https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think
> (section "absolute mess")
>
> another possibility is to use __builtin_isnan, which works
> on gcc and clang but that's not portable to other compilers that comply
> with standards.
>
> From reading lots of things, I have taken away that in C++ code isnan
> should always be written std::isnan(), have not found anything
> indicating that writing it that way is at all bad, and that it's
> unspecified if abs without std:: works or not.
>
>
>