When I said “is it like selective fading” you wrote “That.” What does “That.”
mean?
>No way 24 MHz are going to be flat in frequency domain
Does that mean that the transmitted result will not be smooth in a waterfall,
but have high power and low power areas? I would expect a wideband SDR like the
bladeRF to be uneven over its frequency range. At least this is Phase-Shift
Keying and not QAM, since QAM depends on amplitude.
My project uses an x16 chip rate, because the base rate is exactly 1.5
Msymbols/sec with FEC and Reed-Solomon. That makes exactly 24 MHz which fits
nicely in the 26-MHz-wide 900 MHz ISM band.
Sent from Windows Mail
From: Marcus Müller
Sent: Wednesday, March 16, 2016 10:34 AM
To: [email protected]
Hi Henry,
On 16.03.2016 15:24, Henry Barton wrote:
Wow, thanks for the comprehensive reply. You covered a lot of material and I
like how simple you make it.
Did I? I pretty much went ahead and threw assumptions at you like "hey, that's
a dot product, and you'll know how to deal with that" :)
>"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.
I guess that means if I have an x16 chip rate, I try applying the spreading
code to the RX signal at different symbol shifts. So I might have a buffer of
received symbols and shift it 1 symbol each time as I try the spreading code on
it, then see which produces the strongest result?
Pretty much! You can also oversample to get a more fine-tuned result.
>still "pretty" orthogonal when out of sync
I hadn't even considered that. So turning on your transmitter by chance at just
the right time can make your orthogonal code ruin others' signals?
Nah, spreading codes used usually are pretty good, but yes, there's compromises
to be made when your code can't be infinitely long but you want to have a lot
of users etc.
>frequency-selective channels
What's that? Is it like selective fading?
That.
I don't need high throughput; my project aims to transmit 2.064 Mbit/sec in a
24 MHz channel in the 900 MHz band.
No way 24 MHz are going to be flat in frequency domain :)
I use QPSK/4QAM because it has 1/2 the bandwidth of BPSK while still being much
more error-resistant than high-order QAM.
Sounds like a good choice; so 2.064 Mb/s/(2b/S) = 1.032 MS/s, so I guess you're
aiming for a spreading factor > 10?
Cheers,
Marcus
To: [email protected]
From: [email protected]
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
[email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
