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
out.
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.
Tom
Tom R. wrote:
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
Using the old versions of the code, I noticed that the SNR performance
is MUCH MUCH MUCH MUCH better when 64M/bitrate is a power of 2. E.G.
125k (decim 512), 250k (decim 256), 500k (decim 128) work great but 200k
does not. Is the above why?
Thanks,
-Dan
Using the old versions of the code, I noticed that the SNR performance
is MUCH MUCH MUCH MUCH better when 64M/bitrate is a power of 2. E.G.
125k (decim 512), 250k (decim 256), 500k (decim 128) work great but 200k
does not. Is the above why?
Thanks,
-Dan
Yes, I’m sure these are related. It has a lot to do with how much the
phase
rotates between samples, and the Costas Loop corrects the phase for
every
sample; if the SNR is high and you have many samples per symbol, many of
those samples are going to have lower amplitude (not the maximum SNR
you’d
see when just sampling at the symbol peak); the noise can easily push
these
around, which would cause the Costas Loop phase detector to mis-trigger,
and
the phase correction for this sample would be wrong.
The new method makes a decision on the sampling time to maximize the
SNR,
then the Costas loop part uses this to make the phase and frequency
adjustments.
At least, I think this is what is happening.
Tom
Tom R. wrote:
The new method makes a decision on the sampling time to maximize the SNR,
then the Costas loop part uses this to make the phase and frequency
adjustments.
At least, I think this is what is happening.
This is what SHOULD happen. You make phase/frequency estimates only at
the proper sampling instant where the SNR is maximum in most cases.
Tom
–
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest.” - Piet Hine