Hi Tom, what you are writing is completely right. Simply increasing the sampling frequency will result in a more complex filter.
Nevertheless the firdes.low_pass function does NOT want to calculate the 101-tap-filter. But it DOES calculate the 100001-tap-filter. Really strange. So this might not be a memory problem. The "magic border" I described is at 1MHz. Not at 1GHz as I wrote accidentally. Do you have another idea what the problem could be? Frederik Am 17.11.2013 17:48, schrieb Tom Rondeau: > On Sun, Nov 17, 2013 at 9:39 AM, Frederik Wing <freddy.15-...@freenet.de> > wrote: >> Hello again, >> >> meanwhile I got some more information about the error. >> It occurs when returning the taps from the firdes::low_pass function. >> But ONLY under some conditions. >> I wrote a simple script which is NOT working and giving the error >> mentioned earlier: >>> from gnuradio.filter import firdes >>> >>> f_s = 1e3 >>> f_c = 0.2e3 >>> transition_width = 100 >>> low_pass1 = >>> firdes.low_pass(1,f_s,f_c,transition_width,firdes.WIN_KAISER, 5.0) >>> print len(low_pass1) >> But it does work if I change f_s to 1e6 or higher. There seems to be a >> "magic border" at 1GHz. >> >> Can anyone help me? >> >> Frederik > Not sure if you really meant 1e6 or 1 GHz (1e9). > > The complexity of a filter like this is inversely proportional to the > width of the transition band. As you increase f_s, you're normalized > transition band is transition_width/f_s, which is getting smaller and > smaller. > > At a sampling rate of 1 ksps, this filter you describe here is 101 > taps. At 1e6 sps, you have 100001 taps. That's a gigantic filter > already. At 1e9 sps, that creates a filter with 100000001 taps. That > is, one hundred million taps. > > My i7 processor with 8 GB of RAM took 30 seconds to calculate that > filter. Your RaspberryPi isn't quite that powerful. Most likely, your > running out of RAM and probably writing out of bounds, so strange > things are happening that's causing that double free. > > There is absolutely no way that you need that complex of a filter. > Make sure to scale your transition width with your sampling rate. > > Tom > > > >> Am 15.11.2013 12:53, schrieb Marcus Müller: >>> Hi Frederik, hi rest, >>> >>> this is an interesting error. You might want to report it. >>> The interesting part of your backtrace is >>> #8 ~vector (this=0xbee7c59c, __in_chrg=<optimized out>) >>> at /usr/include/c++/4.6/bits/stl_vector.h:350 >>> #9 gr::filter::firdes::low_pass (gain=<optimized out>, >>> sampling_freq=<optimized out>, cutoff_freq=0.45000000000000001, >>> transition_width=<optimized out>, window_type=<optimized out>, >>> beta=<optimized out>) at >>> /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 >>> >>> firdes.cc:136 is the closing bracket of the for loop that iterates >>> over both the taps vector and the window vector. >>> sadly, gdb doesn't tell us whether the w or the taps vector's >>> destructor is being called. >>> As a wild guess, the compiler realised w is not being used after the >>> last iteration of the loop in the low_pass function. >>> Proposal: >>> do a >>> >>> gdb --args python top_block.py #or whatever your file is called >>> gdb>break /home/pi/gnuradio/gr-filter/lib/firdes.cc:136 >>> gdb>run >>> ##at some point, the breakpoint will be reached. >>> >>> and check if it crashes on the first run, on the last or whenever. >>> >>> Basically: It's a curious thing that this happens. I do not rule out >>> strange and wilde and generally untame things happening in memory here! >>> >>> Greetings, and look out for memory grues, >>> >>> Marcus >>> >>> On 15.11.2013 12:13, Frederik Wing wrote: >>>> Hi everyone, >>>> >>>> I am using the latest GNU Radio version compiled and running on a >>>> Raspberry Pi with Raspbian Wheezy. >>>> Most of the blocks seem to work. But the Rational Resampler makes >>>> problems. >>>> >>>> Here is my sample python script generated by GNU Radio Companion: >>>> http://pastebin.com/R0Z21MfU >>>> >>>> Running it throws the error: >>>> *** glibc detected *** /usr/bin/python2: double free or corruption >>>> (!prev): 0x02bee190 *** >>>> >>>> Debugging it with gdb gives the output here: >>>> http://pastebin.com/rXqtkZVG >>>> >>>> Any ideas how to solve this? >>>> >>>> Yours, >>>> Frederik >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> _______________________________________________ >> 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
