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

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, discuss-gnuradio-request@gnu.org
> wrote:
>> Message: 11
>> Date: Tue, 21 Jul 2015 11:47:40 +0200
>> From: Marcus M?ller <marcus.mueller@ettus.com>
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] Run graph/ scheduler overhead
>> Message-ID: <55AE153C.9050503@ettus.com>
>> 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio