Re: [Discuss-gnuradio] Lock onto QPSK signa

[Henry Barton]

My project isn’t meant to be 2-way or mobile. Even if my system was meant to be mobile, I think you’d have to be going 100's of miles per hour to notice any Doppler shift, right? A car going 60, I’m thinking, would only have to worry about multipath. My project aims to have multiple broadcasters operating their own transmitters while users provide the spreading code to pick out a broadcaster.

Sent from Windows Mail

From: Landsman, Arik
Sent: ‎Wednesday‎, ‎March‎ ‎16‎, ‎2016 ‎11‎:‎59‎ ‎AM
To: address@hidden
Cc: address@hidden, Marcus Müller

Hi Henry,

To add to Marcus's comments, there are two main methods in gnuradio for clock recovery of QPSK. in all cases you would need a costas loop block, and some way to recover symbol timing *before* costas (either a polyphase clock sync or an M&M). These are built into the psk demod block, along with a few others - a great starting point is to check the python for it.

Since CDMA I assume your radio would need to communicate while in motion, which implies a fast-moving channel - so doppler would need to be constantly corrected. An FLL would do this but it may need encoding to make the spectrum look uniform. I suppose the cmda spreading codes would do that as a freebie.

Marcus mentioned a few web resources - if he hasn't mentioned gr-digital/examples has good examples.

So two ways for clock/symbol recovery:

diff encoding - easiest to implement in general, but comes with a 2x BER penalty. psk mod/demod block are ready-to-go blocks Tom R had put together.
preamble (syncword) recovery - a bit more difficult, but in theory better BER at low SNR (that is when it works right.. debugging mine right now). I had no luck with QPSK so far, but there are examples of BPSK that work.

before jumping into CDMA (worth noting that 5G will be likely FDMA - turns out CDMA throughput in real systems is lower than estimated at first for 4G), you may want to have a single QPSK tx-rx pair working first. Adding "users" to your system requires resolving networking sync issues (as both you and Marcus noted), and operate under the assumption that each MS can reliably connect to the Basestation for a typical channel response. Lots of good papers on IEEE, including some review papers that give more of a summary.

MIT's open course offers their Digital Comm course online - great stuff if you endure 1hr videos :)
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-450-principles-of-digital-communications-i-fall-2006/video-lectures/lecture-21-doppler-spread/


diff encoding will get you started sooner, just use the psk mod/demod blocks. Should largely work out of the box.

Best Regards,
Arik 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20160316/a85c86a9/attachment.html>

------------------------------

Message: 28
Date: Wed, 16 Mar 2016 15:33:00 +0100
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Lock onto QPSK signal
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"

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: 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20160316/5c991ec1/attachment.html>

------------------------------