discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] DSSS sync question


From: Ed Criscuolo
Subject: Re: [Discuss-gnuradio] DSSS sync question
Date: Fri, 05 Feb 2016 19:24:59 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 2/5/16 6:46 PM, Richard Bell wrote:
No it wouldn't work. You have to synchronize before you start de-spreading.

I disagree.  Mathematically, its the same result if you synchronize,
then despread, or despread then synchronize.  In the real world,
however, its a different ballgame!

DSSS spread spectrum signals are usually spread out over enough
bandwidth that the energy per spread bit is BELOW the noise
floor.  This makes it impossible to do anything with the spread
bits directly.  You have to despread them first so that the
energy per bit gets up above the noise floor. What you end up
having to do is starting out _close_ to your chip rate, and try
correlating with your PN sequence over enough chips to cover
just one bit, and see if you get a correlation, if you don't,
you have to add an offset of one chip time  to the PN sequence
and try again.  When you reach the point that the average of
all of N despread chips you're looking at peaks, then you've got
the correct offset.

In addition, in order to allow for chip rate mismatch between the transmitter and receiver, you will have to actually work at twice
the chip rate so you can check -1/2, 0, and +1/2 offsets on each
try.  This guarantees that you will find the correct offset within
one chip time.

Once you have roughly acquired the chip clock and offset, you can
use a PLL in your despreader to lock onto it and track it, so you
can reliably despread the bits.

Note that, at this point, you still just have a _bitstream_,
with no idea where the byte or packet boundaries are.  For that,
you'll need some kind of packet structure, with a known header
or sync pattern, to find the byte and PDU boundaries.

This type of despreading is called unassisted despreading, in that
does not depend on knowing any data content.  Its weakness is that
it requires a largish number of chips per bit to work well.

There are also data-assisted despreaders that depend on knowing
something in advance about the data content, such as a fixed
sync word or preamble.  The algorithm for those is roughly the same,
except that you're looking for a correlation over a bigger chunk
of data (ie - a whole sync word) instead of over just one bit.

@(^.^)@  Ed



reply via email to

[Prev in Thread] Current Thread [Next in Thread]