On Sat, Jun 21, 2008 at 11:01:22AM -0400, Charles Swiger wrote: > On Fri, 2008-06-20 at 13:45 -0700, Eric Blossom wrote: > > considerably more up-to-date than that in 3.1.1. Chuck Swiger has > > been working on it. > > > > Eric > > Ah, I still need to check in the complex pll stuff that gets rid of > > > gr_freq_xlating_fir_filter_ccf 2.68% > > and allows the pll to run at 16MHz instead of 19.2MHz. An open question > (beyond me at the moment) is what are the optimal interpolator taps in > the bit_timing_loop for 16MHz? I'll check in what I have
Please do this on a branch. > and people can work with the taps since they are elsewhere in > gnuradio-core. I made some taps: > static const int NTAPS = 12; > static const int NSTEPS = 128; > static const double BANDWIDTH = 0.25; > > that work but that's just 'twiddling knobs and got a picture' , I can't > rigorously prove those are the best numbers ;) You're still basically hosed if you leave BANDWIDTH at 0.25. Our bandwidth of interest is 6MHz (TV channel) and you want to run at 16MHz, you'd need it to be 0.375. With regard to NTAPS, you'd want to look at the error between the ideal and actual transfer function over the frequency range of interest. IIRC the code in gen_interpolator_taps computes this as its metric. Keep NTAPS a a multiple of 4 since the SIMD code is going to round it up to that anyway (padding with zeros). Didn't you try the J.O. Smith resampler? How did that work out? Please also consider testing out Achilleas' suggestion: > Date: Sat, 24 May 2008 21:13:13 -0400 > From: Achilleas Anastasopoulos <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] atsc_cpll finally works > To: Eric Blossom <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], gnuradio mailing list <[email protected]> > > Chuck, Eric, > > I think there is a way to perform the cPLL at 8 complex Msps and upsample > to 16Msps only at the very end when you want to get the Real signal out for > further processing. I believe this works (i didn't see any point where > there is a possibility for aliasing) and it can result in some savings in > complexity without sacrifising performance. > Hopefully I didn't miss anything big... > > Take a look at the block diagram here: > > http://www.eecs.umich.edu/~anastas/gnuradio/pll.png > > Achilleas There's a simple modification that can be made to the EQ to drastically the CPU requirements. That would be to use the fast fir code in the body of the frame, and run the slow one (that's doing the adaptation) only on the training symbols. Please don't make this change until the basic architecture of the CPLL is sorted out and that the receiver is working well even on so-so signals. Also, we may actually want to drive up the EQ's CPU requirements by going to a decision feedback strategy. > Using cpll the oprofile top 10 looks like: > > samples % app name symbol name > 535275 24.5581 _atsc.so > atsci_equalizer_lms::filter1(float const*) > 467354 21.4419 libgnuradio-core.so.0.0.0 .loop1 > 277648 12.7383 _atsc.so > atsci_single_viterbi::decode(float) > 246879 11.3267 libgnuradio-core.so.0.0.0 .loop1 > 64547 2.9614 libgnuradio-core.so.0.0.0 gr_fast_atan2f(float, float) > 40527 1.8594 libgnuradio-core.so.0.0.0 decode_rs_char > 40256 1.8469 libgnuradio-core.so.0.0.0 > gr_single_pole_iir<std::complex<float>, std::complex<float>, > double>::filter(std::complex<float>) > 36013 1.6523 _atsc.so atsc_cpll::work(int, > std::vector<void const*, std::allocator<void const*> >&, > std::vector<void*, std::allocator<void*> >&) > 31789 1.4585 libm-2.6.so __ieee754_rem_pio2f > 29662 1.3609 libm-2.6.so sincosf > > --Chuck Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
