I’ve been working on redoing the digital modulations in the background
for a little while now, and I just merged in a branch with newer
features. So that I didn’t interrupt the flow of anything, I just added
a version 2 for everything in the digital modulation path instead of
changing what was inside them. Hopefully, we will be able to switch over
to the new stuff and replace the old ones so we don’t have all of this
duplication lying around.
Here’s what’s new:
dbpsk2 and dqpsk2 - these run a couple of new algorithms for the
synchronization, including a frequency lock loop in the front
(gr_fll_band_edge), a filterbank clock synchronizer (gr_pfb_clock_sync)
for timing, and the standard Costas loop that is mainly used for phase
alignment. I also replaced the interpolation filter in the transmitter
with a resampling filter that can handle any real number for the number
of samples per symbol. This along with the new clock synchronizer allows
us to use (almost) any value for the bitrate we want instead of being
constrained to a set of discrete values like before. I say almost any
value because you can’t go too low as this would require a huge number
of samples per symbol, which has other problems.
To use these new modulations, you have to run benchmark_*2.py. In the
same examples digital folder you’ll find a version 2 of everything. You
can only access these modulations through them.
The reason for these changes is to make the digital modulations more
robust and tolerant of channel conditions. The old way was too dependent
on the receiver parameters. The new synchronization methods are much
more tolerant based on their parameters. The new frequency lock loop
will also make initial acquisition a lot better and the USRPs can be
farther off frequency than they could be in the old scheme. You still
have to be careful about this, because I have two USRPS with RFX2400s
that are so off frequency that the signal is getting hit by the filter
in the USRP before the FLL can get it. Since we don’t retune the USRP,
there’s not much we can do here except decrease the decimation rate and
alter the receiver samples per symbol. Just something to watch out for.
I’m interested to hear any input about how these new blocks work for
people. My biggest concern is the amount of lock-in time for the FLL,
which may have to be rethought to make this system practical for bursty
signals. Once we work out any major issues and if people find this works
better, then we can remove the old stuff.
Thanks,
Tom