On Mon, 2015-07-13 at 21:43 -0400, Tom Rondeau wrote:
> On Mon, Jul 13, 2015 at 12:30 AM, West, Nathan
> <n...@ostatemail.okstate.edu> wrote:
> This is a lot of information, and I'm just going to pick out
> one statement to comment on.
>
> On Sun, Jul 12, 2015 at 6:13 PM, Dennis Glatting
> <gnura...@pki2.com> wrote:
>
> If I remove most of the blocks from my graph with the
> result:
>
> source --> dc block --> Preamble --> null
>
> with the statement:
>
> return noutput_items;
>
> at the beginning of general_work() in Preamble, I have
> overflows and
> gr-perf-monitorx shows a thick red line from:
>
> optimize_c0 -> hack_rf_source_c0 -> dc_blocker_cc0
> --> Preamble
>
> with dc_blocker_cc0 depicted as a large blue square.
>
>
>
>
> Hi Dennis,
>
>
> The size (area) of the blue boxes is proportional to the
> amount of CPU a block is using. The "darkness" and thickenss
> of lines are how full buffers are. That indicates that DC
> blocker is using a lot of CPU and the buffers in front of it
> are full because the blocks have done all of their work and
> have filled their buffers before dc blocker can work on them.
>
>
> 1.6ms is a long time to be working on samples when your
> incoming rate is 10Msps.
>
>
> There's a number of ways to proceed. You can use offset tuning
> to remove the DC spike (I can't remember hackrf's input
> bandwidth so this may or may not be realistic), use some other
> method for DC removal, or try to optimize whatever might be
> taking a while in the dc_blocker. (I suggest a dynamic
> analysis tool like kcachegrind, AMD Code Analyst, or Intel
> vTune)
>
>
> A quick glance at the code makes me suspicious off the deque
> that is used in a for loop in work. Time for my wild
> speculation: it's possible there is some dynamic
> allocation/dellocation gone wild with the way this deque is
> implemented combined with this usgae. It seems like a fixed
> length buffer (or a deque/vector with overwriting/manual
> pointer management) would be sufficient as long as you're
> willing to do the pointer math. It's worth looking at how
> other blocks might be keeping internal vectors of samples and
> possibly doing the dynamic code analysis to confirm it is the
> deque.
>
>
> -Nathan
>
>
> Yeah, that DC blocker turned out to be an interesting lesson in DSP.
> That's based on a paper claiming it to be a very fast algorithm for
> removing DC from a system. But like a lot of implementations in DSP,
> it was really geared towards being a hardware implementation and turns
> out to not be so great in software. It's there because it provides
> good control over the shape of the DC rejection profile in frequency,
> but computationally, there are better ways to go about this.
>
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.
#!/usr/bin/env python
#
# Copyright (c) 2015 Dennis Glatting
#
# Build a receiver, minus all of the fancy GUI stuff, for debug/test.
#
#
# $Log: test.py,v $
# Revision 1.1 2015/07/12 08:37:29 dennisg
# Initial revision
#
#
import math
import sys
from gnuradio import gr,blocks,filter
import osmosdr
import adsb
# A bunch of constants.
#
rx_rate = 10000000.0
rx_freq = 1090000000.0
rx_gain = 47.57
rx_thr = 4.8
rx_bits = 12
# Allocate a bunch of blocks.
#
tb = gr.top_block()
src = blocks.file_source(gr.sizeof_gr_complex,"samp.bin",True)
dc = filter.dc_blocker_cc( 32, True )
rxcvr = osmosdr.source( "hackrf" )
pream = adsb.Preamble(rx_rate, rx_thr, rx_bits, rx_freq, rx_gain)
null = blocks.null_sink(gr.sizeof_float)
# Do a bunch of sets.
#
rxcvr.set_sample_rate( rx_rate )
rxcvr.set_center_freq( rx_freq )
rxcvr.set_gain( rx_gain )
# Connect things up.
#
tb.connect( rxcvr, dc )
tb.connect( dc, pream ),
tb.connect(( pream, 0 ), null )
tb.run()
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
