[Top][All Lists]

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

[Discuss-gnuradio] New digital modulation receiver in trunk

From: Tom Rondeau
Subject: [Discuss-gnuradio] New digital modulation receiver in trunk
Date: Wed, 7 Mar 2007 00:10:02 -0500

I've just merged the new digital modulation receiver work into the trunk.
This was long overdue, but there were a lot of picky issues I had to work

This is a replacement for what was formerly a separate Costas Loop and M&M
symbol sync loop done in the DBPSK and DQPSK blocks. It is now a
decision-directed loop that combines the two.

The problems with this are that the performance is now a bit more picky
about the settings of --costas-alpha and --gain-mu. This is what I've spent
so much time optimizing. They are now set to values that, by default, should
work with most bitrates. I've tested from 75 kbps to 500 kbps in many,
random step sizes, with DQPSK and can say that there is less than 0.1%
packet loss in an AWGN channel with decent SNR. For lower values of the data
rate (<125 kbps), you might start to see a bit of loss, which requires a
small increase in --costas-alpha. The main issue with these gains is the
different samples per symbol, which is corrected for mostly by changes in
the mu gain in the M&M loop. To keep the logic simple, I set costas-alpha
and choose gain-mu from a list, depending on the samples per symbol. As I
said, this works for all of the tests cases I ran (which, I guarantee you,
was a lot).

The good news, though, is that this receiver has much better SNR
performance. Of course, we don't yet have a way of getting a BER vs. EbNo
(hint, hint). I had the transmitter and receiver in separate rooms,
separated by about 10 m and a few obstruction. I kept my transmitter running
in burst mode and switched out the receivers. While the old receiver missed
packets and got almost all Falses with the CRC check, the new receiver got
over 99% of the packets properly.

This receiver should also be useful for 8PSK and pi/4 DQPSK, possibly with
some performance enhancements.

In general, there is a LOT of optimization to be done where we can hopefully
get rid of some of the branching statements.


reply via email to

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