On Sat, Jul 3, 2010 at 8:17 PM, Marcus D. Leech <[email protected]> wrote:
> Environment: 3 different computers, all running F12 with all latest updates
> Both USRP2 and USRP1
>
> Latest GIT
>
> A segfault is provoked in gr_sync_decimator.cc:64 when you have an
> FFT filter, and change its size
> at runtime.
>
> Doesn't matter which circbuf factory I'm using, or which of my 3 systems
> (two are x86_64 and one is x86).
>
> Doesn't matter whether the FFT filter is "big" or little. Increasing
> one from 2 taps to 128 taps was enough
> to cause a segmentation fault.
>
> Doesn't seem to matter whether you're increasing the size, or decreasing it.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
Marcus,
I can't seem to replicate this problem on my Ubuntu 10.04 64-bit machine.
I created a signal, fft filter (ccc), and a file sink with a
threshold, connected them, and ran the flow graph. To run it, I used
this, where mytb is the top_block class.
def main():
taps0 = gr.firdes.low_pass_2(1, 1, 0.1, 0.1, 60)
taps1 = gr.firdes.low_pass_2(1, 1, 0.01, 0.01, 60)
print "Setting start taps (ntaps = %d)" % (len(taps0))
tb = mytb(taps0)
tb.start()
time.sleep(0.5)
print "Setting new taps (ntaps = %d)" % (len(taps1))
tb.fftfilt.set_taps(taps1)
time.sleep(0.5)
tb.stop()
tb.wait()
The initial taps have length 27 and the new taps (taps1) have length
273. I also tried it with both complex in/out/taps and float
in/out/taps.
Is there something else that I'm missing?
Tom
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
