[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] oprofile callgraph question
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] oprofile callgraph question |
Date: |
Sat, 21 Jun 2008 11:07:01 -0700 |
User-agent: |
Mutt/1.5.17 (2007-11-01) |
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
- [Discuss-gnuradio] oprofile callgraph question, Mikyung Han, 2008/06/20
- Re: [Discuss-gnuradio] oprofile callgraph question, Eric Blossom, 2008/06/20
- Re: [Discuss-gnuradio] oprofile callgraph question, Eric Blossom, 2008/06/23
- Re: [Discuss-gnuradio] oprofile callgraph question, Mikyung Han, 2008/06/23
- Re: [Discuss-gnuradio] oprofile callgraph question, Mikyung Han, 2008/06/23
- Re: [Discuss-gnuradio] oprofile callgraph question, Eric Blossom, 2008/06/23
- Re: [Discuss-gnuradio] oprofile callgraph question, Mikyung Han, 2008/06/23
- Re: [Discuss-gnuradio] oprofile callgraph question, Eric Blossom, 2008/06/23
- Re: [Discuss-gnuradio] oprofile callgraph question, Eric Blossom, 2008/06/23