Hi Rafik,
I should have been a little more constructive in my last email:
It's not inherently impossible to correct phase of a QAM reception using
a costas loop – it's just that the GNU Radio costas loop block makes
assumptions that break down for 16QAM:
* The Costas loop is a phase-only correction mechanism. Now, there's
12 different phases in a 16QAM:
Phases of QAM
Thus, all the Phase-locking Costas could do is correct things so
that you find the 12 possible phase values again
* Problem: While after a PSK-correcting Costas loop, you only have to
correct the phase ambiguity by rotating until the right symbol shows
up at the right position, now there's possibly one or two symbols,
so your ambiguity resolution gets a whole lot less fun
* The angles (¼π, ¾π, 5̸4π and 7̸4π [blue and green lines], ±atan(±⅓)
[orange and red] and π/2±atan(±⅓) [violet and brown]) aren't equally
distributed around the circle – which means that the costas-typical
assumption of linear, uniform error-over-angle function breaks down.
This is per se not catastrophical, but will actively break your
system in low-SNR situation. You'd have to build a costas loop with
a phase error detector (PED) that has a feeling for whether the
current symbol is on a diagonal or not, and adjusts the error
estimate appropriately
* The ¼π, ¾π, 5̸4π and 7̸4π angles each are twice as likely to occur
than any of the other 8 phases (simply because there's two
constellation points on each of these phases, vs one for the rest).
That means that you might want to adjust your decision regions for a
self-built PED accordingly.
The GNU Radio Costas Loop supports none of that. It's really meant for
lower-order PSK constellations, and doesn't have the flexibility to
address inequal phase decision boundaries etc. Really, Costas Loops are
usually *not* used to recover phase of non-PSK modulations, as far as I
(limited experience with QAM receivers) can tell.
So, generally, if you can do timing recovery (and that might be
possible, e.g. with a Polyphase Filterbank Clock Recovery approach), you
should be able to see the constellation diagram. However, that will be
rotated, and possibly also still slowly continue to rotate, depending on
how good your timing recovery works. As I tried to hint at above, it's
not trivial to design a phase recovery for true QAM modulations – in
fact, the need to do that is, in practice, often avoided by having
sufficient channel state info from somewhere else – e.g. by having a
known preamble that can be used to derotate.
Phase sync, like any sync, is always pretty application-specific, and
it's not inherently easy to say, "yeah, that's the optimal algorithm"
for any given case. You'll often find something like a receiver getting
the initial phase estimate by correlating the post-timing-recovery
stream to a known sequence, and then either using a phase error loop
with a small bandwidth, assuming that phase jumps will never be large
enough that you end up jumping the minimum phase distance between
constellation points, or looking for periodically inserted pilot symbols
and updating their internal phase tracking from these.
Personally, I kind of still consider the Costas Loop a concept rooted in
analog signal processing (though it definitely works good in digital
domain, too) with the error signals etc actually being analog voltages
being fed back to analog summing amplifiers and so on. That makes it
easy (ok, easier) for me to visualize how phase stabilization for
PSK-type modulations works. If I have to imagine I'd have to synchronize
a quantized QAM with such a thing optimally, I'd have a hard time
describing what the analog error estimator and analog loop filter should
look like. In digital domain, we get all the "logic" coming cheap, so,
yeah, why not have a few % of symbols being used for phase recovery and
skip the phase error loop – we can double-use them to estimate more of
the channel than just the phase, so that's not such a bad deal, usually.
Again, this is all very application-specific!
Best regards,
Marcus
On 07/17/2017 12:56 PM, Rafik ZITOUNI wrote:
Thanks Marcus,
So, how can I see my constellation points with 16 QAM receiver ?
Regards,
2017-07-17 12:26 GMT+02:00 Marcus Müller <muel...@kit.edu
<mailto:muel...@kit.edu>>:
No.
That's not going to work out, mathematically.
Best regards,
Marcus
On 07/17/2017 10:29 AM, Rafik ZITOUNI wrote:
Dear Cinaed,
The costas loop works only with BPSK, QPSK and 8PSK.
Is it possible to change the actual costas loop and add the 16 QAM.
Best regards,
2017-07-14 0:46 GMT+02:00 Cinaed Simson <cinaed.sim...@gmail.com
<mailto:cinaed.sim...@gmail.com>>:
On 07/13/2017 06:16 AM, Rafik ZITOUNI wrote:
> Dear Cinaed,
>
> But how to see the constellations of my received symbols since
> constellation receiver and constellation decoder have a
byte as an output.
>
> Is it possible to have a costas loop for QAM 16?
I use the Polyphase Clock Sync.
In the tutorial 7, they use a channel model
Const. Demod -> Channel Model-> Polyphase Clock -> CMA
Equalizer ->
Costa Loop -> Demodulator
and put the Constellation Sink on the output of the Costa Loop.
-- Cinaed
>
> Thanks,
>
> 2017-07-13 1:30 GMT+02:00 Cinaed Simson
<cinaed.sim...@gmail.com <mailto:cinaed.sim...@gmail.com>
> <mailto:cinaed.sim...@gmail.com
<mailto:cinaed.sim...@gmail.com>>>:
>
> On 07/12/2017 09:55 AM, Rafik ZITOUNI wrote:
> > Dear Cinaed,
> >
> > Thanks for your answer.
> >
> > I tried with my Tx and it works fine with a
constellation, but with my
> > receiver symbols or constellation_decoder,
digital.qam_16()[1] gives me
> > an error.
>
> I'm using the Constellation Modulator/Constellation
Decoder pair and the
> Constellation Object with Type=Variable Constellation.
>
> The same object is used for both the Constellation
Modulator and the
> Constellation Decoder.
>
> When I look inside the Constellation Decoder there's
nothing to
> configure.
>
> Maybe you're doing things differently.
>
> -- Cinaed
>
> >
> > line 164, in __init__
> > self.digital_constellation_decoder_cb_0_0 =
> > digital.constellation_decoder_cb(digital.qam_16()[1])
> >
> > Best,
> >
> >
> >
> >
> > 2017-07-12 2:26 GMT+02:00 Cinaed Simson
<cinaed.sim...@gmail.com <mailto:cinaed.sim...@gmail.com>
<mailto:cinaed.sim...@gmail.com <mailto:cinaed.sim...@gmail.com>>
> > <mailto:cinaed.sim...@gmail.com
<mailto:cinaed.sim...@gmail.com>
<mailto:cinaed.sim...@gmail.com
<mailto:cinaed.sim...@gmail.com>>>>:
> >
> > On 07/11/2017 05:13 AM, Rafik ZITOUNI wrote:
> > > Dear gnuradio users,
> > >
> > > I am trying to use digital_chunks_to_symbols to
reconstruct block by
> > > block my QAM modulator.
> > >
> > > Please could you give me an idea how to set the
constellation points in
> > > Symbol Table field? I can do it with BPSK, QPSK
and 8PSK using
> > > constellation[0].points,
constellation[1].points and
> > > constellation[2].points, but how can I do it
with 16 QAM ?
> >
> > Try
> >
> > Symbols: digital.qam_16()[1]
> > Constellations: digital.qam_16()[0]
> >
> > -- Cinaed
> >
> >
> > >
> > > For my 16 QAM receiver, could you please tell
me if it's possible to
> > > have a constellation points view?
> > >
> > > Best,
> > >
> > > --
> > > **<http://www.ece.fr/>Rafik
> > >
> > >
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
<mailto:Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>>
> <mailto:Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
<mailto:Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>>>
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
> >
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>
> > >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
<mailto:Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>>
> <mailto:Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
<mailto:Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>>>
> >
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
> > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>
> >
> >
> >
> >
> > --
> > **<http://www.ece.fr/>Rafik
> >
>
>
>
>
> --
> **<http://www.ece.fr/>Rafik
>
--
**<http://www.ece.fr/>Rafik
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
--
**<http://www.ece.fr/>Rafik
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio