Re: [Discuss-gnuradio] Lock-Up Time for 2PSK Demodulation

[Tom Rondeau]

On Mon, Nov 16, 2015 at 10:08 PM, Kevin McQuiggin <address@hidden> wrote:

Hi All:

I have a .grc 2PSK demodulator working for the RDS subcarriers on FM radio signals.  I note however that it takes a couple of minutes for the PSK demod hierarchical block to settle and give me consistent good data.

I tried fiddling with the three timing parameters in the block but lock-up time is only marginally affected.  All work fine at default 2*pi/100.0, just that stabilization takes about 2 minutes.

I also looked into the code for the hierarchical block as well as the generic mod demod, but I found no real insight there. Obviously my lack of theoretical foundation.

Perhaps this related to the low data rate of RDS, 1187.5 bps.  I have the PSK demod running at 2 sps, i.e. 2375 bps.  My original sample rate is about 600k.  I decimate through the chain before the demod block.

gnuradio version 3.8.7.1 (from memory), Ubuntu 14.04, USRP B200, 16 GB ram, i5 processor.  USB3 connection.

Any advice would be appreciated!

Kevin

Good problem. First, have you looked to see how Bastian does it in gr-rds (http://cgran.org/pages/gr-rds.html)?

Second, yes, the problem is with the slow bit rate. The timing lock is delay is mostly based on the number of samples, not time in seconds. Still, 2 minutes is a long time... This is a large part of the motivation for corr_est, but you need known data to correlate against in order to get the right information out of this block.

My presentation from GRCon14 might be useful here:

http://www.trondeau.com/grcon14-presentations#tut-rondeau-mpsk

But I focus more on the phase locking speed in this one.

For the timing block, off the top of my head, you might be able to reduce the size of the matched filter to get some improvements in speed by reducing the group delay of the filter paths. I think we default to an extra long filter for some reason.

Tom