|Subject:||[Discuss-gnuradio] New digital modulation implementations|
|Date:||Tue, 16 Mar 2010 09:10:31 -0400|
|User-agent:||Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:220.127.116.11) Gecko/20100227 Thunderbird/3.0.3|
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|