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
