discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sync Problem with 256-QAM with USRP B2xx in GRC


From: Marcus Müller
Subject: Re: Sync Problem with 256-QAM with USRP B2xx in GRC
Date: Mon, 20 Sep 2021 14:39:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Hi Leonhard,

a really short reply because I'm stuck with a lot of other things, but:

256-QAM is indeed not trivial to phase synchronize, and you're right - your 
usual Costas
loop will have a hard time! Remember that the Costas loop tries to "lock onto" 
the limited
amount of phases that exist in the "correct" constellation. For BPSK, QPSK, 
that's simple.
For 256-QAM, there's 32 constellation points in each of the eight symmetric (0, 
pi/4],
(pi/4, pi/2]... sectors... you end up with 192 different phases (python code 
[1]).

Now, there's still some *adaptive blind phase estimation* algorithms that you 
could look
into, but in all honesty: Things are hard!

You typically go for some data/preamble-aided method with higher-order QAMs: 
For example,
just send a known preamble, and correlate against that. If you send the same 
L-length
preamble twice with a known distance D between their beginnings (often, just 
one right
after the first), you can employ a fixed-lag correlation (i.e. just a 
dot-product between
a vector of L samples with another vector of L samples, taken D later). The 
phase of that
will depend on how much the phase of the second preamble has rotated compared 
to the first
– and a phase rotation that always happens over a fixed time, that's a 
frequency, so you
got your frequency estimation done that way.

>From the correlation of the received preamble with the known transmit 
>preamble, you get an
absolute phase.

Note that in wireless communications, there's not that many cases where you 
have 256-QAM,
but not some external structure that needs synchronization, anyway. Most 
commonly (LTE,
WiFi, DTV, DSL, …) you'll find QAM within OFDM – and for OFDM, there's clever
synchronization. Schmidl&Cox is an all-time favorite ;)

Cheers,
Marcus



[1]
#!/usr/bin/env python
from fractions import Fraction as ratio
import itertools

# Number of bits in QAM, N = 8 -> 256-QAM
N = 8

# make the inphase points; sqrt(2**N) of them, centered on 0, spaced 2
inphase_component = range(-(2**(N//2))+1, 2**(N//2), 2)

#Make all combinations of inphase and quadrature components.
const_points = itertools.product(inphase_component, inphase_component)

# Fraction "auto-cancels",
# so that we get a deduplicated set of slopes, equivalent to angles
# Notice that {...} is Python's way of building a set from a generator
slopes = { ratio(*point) for point in const_points }

# Need to double the length, because (-3/-2) = (3/2), but these have
# different phases
print(f"Number of different angles in {2**N}-QAM: {2 * len(slopes)}")


On 20.09.21 09:10, Röpfl, Leonhard wrote:
> Dear GNU Radio Community,
> 
> 
> since a couple of months i try to get a 256-QAM Transmission over Air to work.
> 
> 
> Now i reached a dead point, because i could not get the receiver locked on 
> the phase of
> the QAM.
> 
> 
> 4-QAM is not a Problem, it works fine like it is described in the Tutorial.
> 
> 
> I have tried Polyphase Clock Sync, Costas Loop ect. (what ever i found under
> Synchronizers) in quite various combination,
> 
> but this leads to nothing. 
> 
> 
> My guess is that Costas Loop is not working for higher QAM anyway.
> 
> 
> I did not find any description, how this could be done right, neither in the
> Internet (Google, Youtube) nor in the library of our
> 
> University.
> 
> 
> Helpful would be:
> 
> 
> - a generic description or example how this is done
> 
> 
> - a reference one a book or paper which describe that (even if this book is 
> expensive)  
> 
> 
> - link to an online-resource 
> 
> 
> Thanks in advance
> 
> 
> Best regards
> 
> 
> Leonhard
> 
> 
> 
> 
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]