To:
address@hidden
From:
address@hidden
Date: Wed, 16 Mar 2016 14:03:32 +0100
Subject: Re: [Discuss-gnuradio] Lock onto QPSK signal
Hi Henry,
Interesting questions!
On 16.03.2016 03:48, Henry
Barton wrote:
Hi, does anyone know of any good
tutorials that explain how to lock onto the clock of a
QPSK signal and/or correlate? I know this is all very
simple in GNUradio, but I hope someone knows of a
website or, preferably, a video series that will explain
this.
Have you read the GNU Radio Guided Tutorials[1]? Chapter 7
(you should really read 1-5 before) deals with PSK reception
and timing recovery.
A video series? Hm; to be honest, that does sound like you
want to attend a full course on the basics and some lectures
on advanced methods of digital communications. I do think
there's some good lecture recordings out there[2], but
inherently, they are pretty sequential, so although you'll
learn a lot, you'd still have to have the perseverance to
spend quite some hours till you come to the point of clock
sync for CDMA.
Personally: I'm not very much of a "I learn from videos"
person. I do like the kind of introduction where someone
stands in front and derives the methods and formulas "live" on
a blackboard, but somehow, my concentration suffers when
watching a video while mentally (and sometimes, on paper) take
notes, at least for complex mathematical stuff. I'd rather go
and loan a book from a local library. I
think Sklar's
Digital Communications would be the go-to ressource on
CDMA clock sync.
If I have 10 different QPSK users,
spreaded and on the same frequency, that would make
CDMA.
Assuming these 10 users used sufficiently orthogonal spreading
sequences!
Assuming no manufacturing
tolerance or frequency drift, all the clocks on the
transmitters would be perfectly the same.
aside from a phase offset
What I’m trying to understand is:
1. No two separate
transmitters can ever be perfectly in sync. Even if the
clocks were 100% accurate, User 1 might start his
transmitter at 10:00:00 AM while User 2 starts his at
10:00:00.250 AM. The signals would be a little out of
sync with each other. How would I pick one out in DSP?
OK, what I describe in the following is somewhat like a
textbook/naive/classical approach; in practice, devices
are
smarter.
Well, in CDMA, if you build the dot product of your received
signal and User A's spreading sequency, you'll get a large
magnitude as a result, if the signal actually contains A's TX.
On the other hand, the spreading sequences of A and any other
user are orthogonal, i.e. the dot product is zero. Assuming
interference is linear (i.e. RX signal after channel(signal
from A + signal from B) = RX signal after channel(signal from
A) + RX signal after channel(signal from B)), and assuming the
spreading sequences were chosen that they are not only
perfectly orthogonal when in sync, but still "pretty"
orthogonal when out of sync, this works reasonably well.
That's a property that a few known spreading sequences
fulfill.
Knowing that the "other" users' signals won't interfere with
the result much, you just correlate your RX signal (that you
think might contain User A's signal) with User A's spreading
sequence. That'll give you a function describing "amont of
similarity between the RX signal shifted in time by 𝜏 and the
right spreading sequence". Look for the peak. That's your
timing offset.
Note that correlation means "take signal A and multiply point
wise with signal B, sum up, note down, then shift first signal
a bit and repeat", which is "(<A[𝜏:𝜏+length(B)],B>),
𝜏=[0, N)" in DSP if you want so, and obviously has
length(B)*N multiplications and summations – not an overly fun
thing to do in real-time (N will roughly be length(B)). Hence,
fast correlation based on multiplying in frequency domain
(signal->FFT->multiplication->FFT) is often used.
2. I’ve heard of
“clock recovery”, which implies to me that you “look” at
a signal to find its clock, but surely you must have at
least a very close idea of the desired clock before you
can begin, right?
Well, yes. If you don't know the clock offset at all, you
wouldn't know how much bandwidth to observe, and then you
couldn't select a suitable sampling rate etc.
Often, sync procedures have multiple steps, e.g. a rough
frequency estimation (done by something like "let's look where
there's a ca X Hz wide occupied piece of spectrum and find its
center"), a fine frequency control and timing recovery.
For CDMA, you can rely on the symbol-duration periodicity of
the autocorrelation.
If you had 3 different CDMA signals but different chip
rates, they could probably coexist nicely, but how would
you pick out the faster signal or the slower one? (see
picture)
If your chip rates are actually somehow fixedly related and
you can make sure that the different chips still are mutually
orthogonal, yes.
In practice, the CDMA orthogonality breaks down for "bad"
combinations especially for frequency-selective channels
(which is probably one of the central reasons why CDMA was
abandoned after 3G and DSSS was only used in IEEE802.11b – you
can't apply it easily to wide channels, because they tend to
be frequency-selective, and you need those wide bandwidths for
higher data rates).
Best regards,
Marcus
[1]
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[2]
https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading#Digital-Comms
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio