[Top][All Lists]

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

Re: [Discuss-gnuradio] atsc_cpll finally works

From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] atsc_cpll finally works
Date: Fri, 23 May 2008 09:00:31 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

OK, I see.

I have two comments:

1) Usually in fractional interpolators the trade-off is: more taps vs finer sampling. It might be possible to increase the number of taps and still be able to work with only a 12.8 (or 16) real-Msps. Having said that, I have to admit I haven't looked at exactly what this particular timing loop is doing.

2) naive question: do we pass the signal x(t) (RRC-Nyquist filtered original 8-PAM) through a matched filter?


Charles Swiger wrote:
Yes, 12.8 or 16Msps would be perfect for the pll - however the next
stage is a 'bit timing loop' (atsc.bit_timing_loop) which uses
'atsci_sssr' (symbol sync and segment recovery) which uses an
interpolator (gri_mmse_fir_interpolator - 'minimal mean square error')
which, for reason unknown to me, requires the
nominal_raio_of_rx_clock_to_symbol_freq (~10.76M) to be greater than
1.8.  I relaxed that just a bit to get by with a slightly lower sample
rate of 19.2  (19.2/10.76 ~= 1.7844) which was easy to get from 6.4Msps
which is easy to get from the usrp. It would be nice to be able to
cheaply upsample from 12.8(16) to 19.2(24)Msps somehow.   The mmse
interpolator notes says:

 * This implements a Mininum Mean Squared Error interpolator with 8
 * It is suitable for signals where the bandwidth of interest B =
 * Where Ts is the time between samples.

That looks like your fsym/4. B = 3.2Mhz at 12.8Msps, and 4.8Mhz at
19.2Msps - I'm not sure what that means ;)   Will the bit_timing_loop
work at 12.8(16)Msps input to recover the 10.76M symbols-per-second?
It's magic to me.


reply via email to

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