Dear Marcus, Thanks for your answer and the precious complementary information. I conclude that an implementation of QAM16's costas loop is more complicated than the existing one, i.e MPK receiver.
I am trying to reuse some existing implementation with 16QAM in order to obtain something with my flowgraphs. Best regards, 2017-07-17 14:25 GMT+02:00 Marcus Müller <muel...@kit.edu>: > 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: > [image: 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>: > >> 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>: >> >>> 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>>: >>> > >>> > 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 >>> >>>: >>> > > >>> > > 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 >>> >> >>> > > > 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 >>> >> >>> > > 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 >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > <http://www.ece.fr/>Rafik > > > -- <http://www.ece.fr/>Rafik
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
