[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
>
>
>
>
>
>