Re: [Discuss-gnuradio] Run graph/ scheduler overhead

[Andy Walls]

On Tue, 2015-07-21 at 12:01 -0400, address@hidden
wrote:
> Message: 11
> Date: Tue, 21 Jul 2015 11:47:40 +0200
> From: Marcus M?ller <address@hidden>
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Run graph/ scheduler overhead
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> Hi Dennis,
> 
> if I read Fig 4 of [1] correctly, then you 32-delay DC blocker has a 
> passband starting at let's say 0.025 * f_sample.
> I've gone ahead and clicked together a FIR filter that theoretically 
> should perform as well; its CPU consumption is... tolerable :)
> Compare [2]; taps are in the PNG comment. Because this is so quick
> and 
> dirt, I didn't bother to verify I really see 10MS/s throughput -- but 
> considering the most-used CPU core is tasked 40% of its time only, I 
> think that's a feasible assumption; plus, you can probably go
> further, 
> if the filter performance doesn't match your needs -- I found that
> for 
> filters > 100taps numerical accuracy of single precision floating
> point 
> arithmetics starts taking its toll, so your amplitude response will
> not 
> 100% be what gr_filter_design shows. Verify with a long averaging Qt 
> frequency sink or so.
> 
> Best regards,
> Marcus
> 
> [1]
> http://www.ingelec.uns.edu.ar/pds2803/materiales/articulos/04472252.pdf
> [2] http://i.imgur.com/Qmx9q96.png

Hmmm.

Since this is ADS-B and phase doesn't matter, how about a differentiator
followed by a leaky integrator:

IIR filter:
Feedforward taps: [1.0 -1.0]
Feedback taps: [1.0 -0.99]

4-taps.  I have no idea how computationally efficient GnuRadio is at IIR
filters.

Need a steeper notch at DC, change the -0.99 to -0.9999 or whatever.

Regards,
Andy

> On 21.07.2015 09:02, Dennis Glatting wrote:
> > On Mon, 2015-07-13 at 21:43 -0400, Tom Rondeau wrote:
> >> On Mon, Jul 13, 2015 at 12:30 AM, West, Nathan
> > FYI and following up.
> >
> > I simplified my graph (below). According to gr-perf-monitorx, and
> > gr-ctrlport-monitor agrees, 95% of the the time is spent in
> > dc_blocker_cc.
> >
> > I haven't look at why but clearly that's a problem.