Wow, thanks for the comprehensive reply. You covered a lot of material and I like how simple you make it. >"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? >still "pretty" orthogonal when out of syncI 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? >frequency-selective channelsWhat's that? Is it like selective fading? 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. I use QPSK/4QAM because it has 1/2 the bandwidth >of BPSK while still being much more error-resistant than high-order QAM.
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
