Re: [Discuss-gnuradio] oprofile callgraph question

[Eric Blossom]

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 <address@hidden>
> Subject: Re: [Discuss-gnuradio] atsc_cpll finally works
> To: Eric Blossom <address@hidden>
> Cc: address@hidden, gnuradio mailing list <address@hidden>
> 
> 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