Hi Cor, Excuse the language, but faaaark. Ok, looks like we have a bug in low_pass. Or in GCC. Or SWIG (which does the python-wrapping of the code in firdes.cc). yay.
So, let's narrow this down: on intel and amd64, same number of taps, right? Then: If I asked you to use GDB to verify the C++ low_pass function in gr::filter::firdes::low_pass actually returned the right float values, would you feel that, with a few hints, be able to do that? Best regards, Marcus On 01.06.2017 07:20, Cor Legemaat wrote: > Hi: > > filter.firdes.low_pass get called with: > * fractional_bw = 0.4 > * trans_width = 0.1 > * mid_transition_band = 0.45 > * interpolation = 24 > > But return: (nan, <788 times nan>) > > Regards: > Cor > > On Tue, 2017-05-30 at 00:06 +0200, Marcus Müller wrote: >> Hi Cor, >>> * When using 1 as "taps" there is output. >> Aha!! >> So, here's the thing: something might be going wrong in the python >> code that sets up the taps automatically if you don't set them >> explicitly. >> Maybe you can figure out where things go wrong; the interesting part >> (maybe add some `print`s here?) from [1]: >> >> # If we don't have user-provided taps, reduce the interp and >> # decim values by the GCD (if there is one) and then define >> # the taps from these new values. >> if taps is None: >> interpolation = interpolation // d >> decimation = decimation // d >> taps = design_filter(interpolation, decimation, >> fractional_bw) >> >> and >> >> >> def design_filter(interpolation, decimation, fractional_bw): >> """ >> Given the interpolation rate, decimation rate and a fractional >> bandwidth, >> design a set of taps. >> >> Args: >> interpolation: interpolation factor (integer > 0) >> decimation: decimation factor (integer > 0) >> fractional_bw: fractional bandwidth in (0, 0.5) 0.4 works >> well. (float) >> Returns: >> : sequence of numbers >> """ >> >> if fractional_bw >= 0.5 or fractional_bw <= 0: >> raise ValueError, "Invalid fractional_bandwidth, must be in >> (0, 0.5)" >> >> beta = 7.0 >> halfband = 0.5 >> rate = float(interpolation)/float(decimation) >> if(rate >= 1.0): >> trans_width = halfband - fractional_bw >> mid_transition_band = halfband - trans_width/2.0 >> else: >> trans_width = rate*(halfband - fractional_bw) >> mid_transition_band = rate*halfband - trans_width/2.0 >> >> taps = filter.firdes.low_pass(interpolation, >> # gain >> interpolation, >> # Fs >> mid_transition_band, >> # trans mid point >> trans_width, >> # transition width >> filter.firdes.WIN_KAISER, >> beta) >> # beta >> >> return taps >> >> >> >> Best regards, >> Marcus >> >> [1] https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python >> /filter/rational_resampler.py >> >> On 29.05.2017 19:01, Cor Legemaat wrote: >>> Hi: >>> >>> * The only warning is about the thread priority but that's on >>> both. >>> * Type "Complex->Complex (Complex Taps)" >>> * When using 1 as "taps" there is output. >>> >>> I can open it in Nemiver if I know where to put the break point... >>> >>> Regards: >>> Cor >>> >>> On Mon, 2017-05-29 at 11:36 +0200, Marcus Müller wrote: >>>> Hi Cor, >>>> that's kind of surprising¹. My first bet is that your AMD system >>>> is >>>> missing some dependency that the intel system has, so that >>>> something >>>> goes wrong during build. But then again, you shouldn't be seeing >>>> the >>>> rational resampler block at all in that case. Let's head straight >>>> to >>>> debugging: >>>> * Do you get any warning/console output during the execution of >>>> that >>>> flow graph? >>>> * Which is the input/output type (float or complex, orange or >>>> blue >>>> connector in GRC, if using that) >>>> * If in GRC: when explicitly using [1,] as "taps", do you get >>>> output? >>>> Best regards, >>>> Marcus >>>> >>>> ¹ "wat?!" >>>> >>>> On 29.05.2017 06:35, Cor Legemaat wrote: >>>>> Hi: >>>>> >>>>> I have 2 different hardware setup's with funtoo/gentoo and >>>>> gnuradio >>>>> installed. On the Intel system the "Rational Resampler" is >>>>> working >>>>> correctly but on the AMD system there is no output. This is on >>>>> a >>>>> flow >>>>> graph for an basic wide band fm receiver based on the USPR >>>>> 10min fm >>>>> receiver tutorial. >>>>> >>>>> AMD system: >>>>> * AMD FX(tm)-8150 Eight-Core Processor >>>>> * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt sse sse2 sse3 >>>>> sse4_1 sse4_2 sse4a ssse3 xop" >>>>> >>>>> Intel system: >>>>> * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz >>>>> * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 >>>>> sse4_1 >>>>> sse4_2 >>>>> ssse3" >>>>> >>>>> Tried with different versions of GNURadio and gcc but the same >>>>> symptoms, both systems is compiled with CFLAGS="-march=native >>>>> -O2 >>>>> -pipe". At the moment it is gcc:6.3.0 and net- >>>>> wireless/gnuradio- >>>>> 3.7.11:0/3.7.11 USE="alsa analog atsc audio channels digital >>>>> doc >>>>> dtv >>>>> examples fec filter grc noaa pager performance-counters >>>>> portaudio >>>>> qt4 >>>>> uhd utils vocoder wavelet wxwidgets zeromq -fcd -jack -log -oss >>>>> -sdl {- >>>>> test} -trellis" PYTHON_TARGETS="python2_7" >>>>> >>>>> Where do I start to search? >>>>> >>>>> Regards: >>>>> Cor >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
