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

[Marcus Müller]

Hi Andy,

yeah, that should work well, too.
In fact, it's pretty common to use IIRs for DC killing -- maybe even the 
single-tap IIR GNU Radio has is sufficient. I just wanted to come up 
with something that is signal-wise as good as the CPU hungry DC blocker.
By the way, the theory behind that DC blocker is simply that of a low 
pass, being subtracted from the correctly delayed original signal, 
yielding the inverse filter -- if you look at the pictures in that 
paper, it kind of comes down to implementing the low pass as a 
combination of FIR and IIR (which seems to perform bad).

Best regards,
Marcus

On 21.07.2015 22:27, Andy Walls wrote:
> 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.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio