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 <discuss-gnuradio-request@gnu.org> wrote:
Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org
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
discuss-gnuradio-request@gnu.org
You can reach the person managing the list at
discuss-gnuradio-owner@gnu.org
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 <mmueller@gnuradio.org>
To: discuss-gnuradio@gnu.org
Subject: Re: Why does the random input not match the output
Message-ID: <21a44bc5-7578-465d-b047-5e57030029f8@gnuradio.org>
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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 280, Issue 9
************************************************
No comments:
Post a Comment