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
