Marcus,

Thank you for your helpful corrections.  We changed the constellation to
fix the missing point and we had a duplicate point.  This was by mistake.
We updated the attached .grc to fix that and also changed it to be QAM-16
modules instead of QPSK.

Our next question is:
We want to prove that the random input matches the final output.
Where do we put the file sync module to prove that the random input matches
the final output?

Thanks again.

Maureen

On Sat, Feb 21, 2026 at 11:02 AM <[email protected]> wrote:

> Send Discuss-gnuradio mailing list submissions to
>         [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
>         [email protected]
>
> You can reach the person managing the list at
>         [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>    1. Re: Why does the random input not match the output
>       (Marcus Müller)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 21 Feb 2026 08:59:39 +0100
> From: Marcus Müller <[email protected]>
> To: [email protected]
> Subject: Re: Why does the random input not match the output
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: constellation points.png
> Type: image/png
> Size: 14880 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20260221/4a6ab333/attachment.png
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ------------------------------
>
> End of Discuss-gnuradio Digest, Vol 280, Issue 9
> ************************************************
>

Attachment: QAM16 2-25-2026.grc
Description: Binary data

Reply via email to