Question about carrier syncronization for demodulating QPSK/

Hi, all

The problem is HOWTO do carrier syncronization.
I am using two USRP with FLEX 2400, one for Tx, the other for Rx. The RF
of
both Tx and Rx are tuned to 2.45GHz.
I generate and transmit a QPSK signal. At the receiver, an obvious
frequency
deviation can be observed from the fft sink. And of course, nothing can
be
demodulated. (using simple correlator to deframing, no seqno outputs).
So I
adjust Tx RF a little bit, and I realy get some seqno from
simple_correlator, but they are uncontinuous and snatchy, which means
the
manual freq adjustment is not so accuracy.
I think the linear bidimention mouduation such as BPSK/QPSK/16QAM
requires
much more accurate syncronization of carrier than FSK does.

There are already some discusses on the archive about BPSK demod, but I
still have no idea about that.
http://aphex.media.mit.edu/wiki/tiki-index.php?page=BPSK
I read the code and find that the author wrote a costas loop which
require
sinusoid input. This scheme will produce higher speed baseband signal,
which
cost much USB bandwidth. I wonder if only pure IQ complex at the speed
of
QPSK symbol rate can do carrier sync and demodulation.

Thanks!

The following are the key src code of my QPSK mod/demod.

qpsk_tx.py:
src = gr.file_source (gr.sizeof_char, filename, options.repeat)
framer = gr.simple_framer (payload_size)
bytes_to_syms = gr.bytes_to_syms ()
qpsk_mod = gr.float_to_complex()
interp = gr.interp_fir_filter_ccf (8, interp_taps)
…# usrp init
self.connect (src, framer, bytes_to_syms, qpsk_mod, interp, gain, u)

qpsk_rx.py:
filter = gr.fir_filter_ccf (1, rx_taps)
c2f = gr.complex_to_float()
corr = gr.simple_correlator (payload_size)
filesink = gr.file_sink (gr.sizeof_char, options.filename)
self.connect (u, filter, c2f, corr, filesink)

Eric and my team at Virginia Tech just got done creating a full
differentially encoded QPSK transceiver. There’s still a bit left to be
done
on it, but the basic building blocks should all be checked in by now.
For
carrier synchronization of a QPSK waveform, we use the classic fourth
order
Costas loop approach, a block you can find as gr_costas_loop_cc. Set the
alpha value somewhere around 0.005 - 0.05 to get started (and play with
it
from there). The beta value should be about an order of magnitude
smaller
(it’s been set to 0.25*alpha^2; I’m not sure where that comes from,
though).
The next two arguments are the max and min frequency deviation in terms
of
scaled frequency, so 0.05 and -0.05 work well. The final value of the
reference phase can just be set to 0. This block’s been around for a bit
of
time and used in BPSK.

From here, you’ll need to worry about symbol synchronization. We build a
complex modified Mueller and Muller clock recovery circuit for this
called
gr_clock_recovery_mm_cc (this file existed already, but we modified it
some). Set mu=0.05, omega is approximately the samples per baud,
gain_mu=0.05, gain_omega=0.25*mu^2, and omega_rel_limit=0.5. These
values
will get you started.

There are other blocks available now to do differential encoding and
decoding to handle the phase ambiguity generated by the Costas loop (the
final constellation can be in any one of 4 rotations). In the GMSK2
examples, I know the benchmark_xpsk_tx.py generates the differentially
encoded QPSK signal. If not there yet, soon the benchmark_xpsk_rx.py
should
do the synchronization and differential demodulation once a few more
things
are worked out.

Tom


From: discuss-gnuradio-bounces+trondeau=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+trondeau=removed_email_address@domain.invalid] On Behalf Of 2
1
Sent: Thursday, June 01, 2006 6:16 AM
To: [email protected]
Subject: [Discuss-gnuradio] Question about carrier syncronization
fordemodulating QPSK/BPSK signal.

Hi, all

The problem is HOWTO do carrier syncronization.

I am using two USRP with FLEX 2400, one for Tx, the other for Rx. The RF
of
both Tx and Rx are tuned to 2.45GHz.

I generate and transmit a QPSK signal. At the receiver, an obvious
frequency
deviation can be observed from the fft sink. And of course, nothing can
be
demodulated. (using simple correlator to deframing, no seqno outputs).
So I
adjust Tx RF a little bit, and I realy get some seqno from
simple_correlator, but they are uncontinuous and snatchy, which means
the
manual freq adjustment is not so accuracy.

I think the linear bidimention mouduation such as BPSK/QPSK/16QAM
requires
much more accurate syncronization of carrier than FSK does.

There are already some discusses on the archive about BPSK demod, but I
still have no idea about that.

http://aphex.media.mit.edu/wiki/tiki-index.php?page=BPSK

I read the code and find that the author wrote a costas loop which
require
sinusoid input. This scheme will produce higher speed baseband signal,
which
cost much USB bandwidth. I wonder if only pure IQ complex at the speed
of
QPSK symbol rate can do carrier sync and demodulation.

Thanks!

The following are the key src code of my QPSK mod/demod.

qpsk_tx.py:
src = gr.file_source (gr.sizeof_char, filename, options.repeat)
framer = gr.simple_framer (payload_size)
bytes_to_syms = gr.bytes_to_syms ()
qpsk_mod = gr.float_to_complex()
interp = gr.interp_fir_filter_ccf (8, interp_taps)
…# usrp init
self.connect (src, framer, bytes_to_syms, qpsk_mod, interp, gain, u)

qpsk_rx.py:
filter = gr.fir_filter_ccf (1, rx_taps)
c2f = gr.complex_to_float()
corr = gr.simple_correlator (payload_size)
filesink = gr.file_sink (gr.sizeof_char, options.filename)
self.connect (u, filter, c2f, corr, filesink)

Eric B. wrote:

time and used in BPSK.

beta = alpha^2/4 gives a critically damped loop.

From here, you’ll need to worry about symbol synchronization. We build a
complex modified Mueller and Muller clock recovery circuit for this called
gr_clock_recovery_mm_cc (this file existed already, but we modified it
some). Set mu=0.05, omega is approximately the samples per baud,
gain_mu=0.05, gain_omega=0.25*mu^2, and omega_rel_limit=0.5. These values
will get you started.

Same way of setting beta here.

Matt

On Thu, Jun 01, 2006 at 08:54:28AM -0400, Tom R. wrote:

reference phase can just be set to 0. This block’s been around for a bit of

There are other blocks available now to do differential encoding and
decoding to handle the phase ambiguity generated by the Costas loop (the
final constellation can be in any one of 4 rotations). In the GMSK2
examples, I know the benchmark_xpsk_tx.py generates the differentially
encoded QPSK signal. If not there yet, soon the benchmark_xpsk_rx.py should
do the synchronization and differential demodulation once a few more things
are worked out.

Tom

There are still a few things to finish rearranging, then we should
have a good QPSK (and most likely BPSK) implementation.

I’ve refactored the GMSK code to use (and test) some of the new
ideas. Stay tuned…

Eric

Thanks for your working.

I wonder if 1.28Msymbol/s (2.56Mbps for qpsk) is possible to be
archieved
through costas loop.
I’m worry about the 32Mbyte/s of USB 2.0 interface may not be enough.
I’ve read the code from
http://aphex.media.mit.edu/wiki/tiki-index.php?page=BPSK (using costas
loop)
and found that 8 samples are used to build a sinusoid wave at the
baseband
level. Consindering complex sampling (4 bytes for one samle), the
maximum symbol rate is only 1M. If filter with over sampling is
employed,
the data rate may be much lower.

Right now, I’m thinking about using pilot seqence for doing carrier sync
and
symbol sync together. I hope it works, but more experiments are needed.

2006/6/2, Matt E. [email protected]:

On Sat, Jun 03, 2006 at 02:49:16PM +0800, 2 1 wrote:

the data rate may be much lower.

Right now, I’m thinking about using pilot seqence for doing carrier sync and
symbol sync together. I hope it works, but more experiments are needed.

The QPSK code works fine at 2 or more samples/baud.
2 Mbaud (4 Mbit/sec) should be doable, modulo CPU consumption.
[We haven’t measured the performance, or tried to do anything to make
it run faster. Lots of room for improvement.]

We’re currently using a Costas loop to track the carrier followed by a
complex M&M symbol timing block. Seems to work fine. We do whiten
the transmitted signal to ensure lots of transitions.

I’m giving a talk at USENIX today, and will get the rest of the QPSK
code checked in by Monday.

Eric