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:
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 <address@hidden>:
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 <address@hidden>:
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 <address@hidden
> <mailto:address@hiddenm >>:
>
> 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 = > > <mailto:address@hidden
> > digital.constellation_decoder_cb(digital.qam_16()[1])
> >
> > Best,
> >
> >
> >
> >
> > 2017-07-12 2:26 GMT+02:00 Cinaed Simson <address@hidden <mailto:address@hiddenm >
m <mailto:address@hiddenm >>>:
> >
> > 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
> > >
> > >
> > >
> > > _______________________________________________ > <mailto:address@hidden
> > > Discuss-gnuradio mailing list
> > > address@hidden <mailto:address@hiddenrg >
org <mailto:address@hiddenrg >>
> > > 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 >>
> > >
> >
> >
> > _______________________________________________ > <mailto:address@hidden
> > Discuss-gnuradio mailing list
> > address@hidden <mailto:address@hiddenrg >
org <mailto:address@hiddenrg >>
> > 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
>
--
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
