Hi Marcus: Not working, don't have time to debug now, will look at it this weekend.
But the bug got triggered at i == ntaps - 1 and not i == 0? Regards: Cor On Tue, 2017-06-27 at 12:03 +0200, Marcus Müller wrote: > > Hi Cor, > hopefully, I have a fix: Could you try > git pull https://github.com/marcusmueller/gnuradio > window_fix_floating_point_math > > > (or, alternatively, attached patch, cd gnuradio; git apply > /path/to/patchfile.patch ) > > > > Thank you!! > > > > Marcus > > > > On 27.06.2017 07:09, Cor Legemaat wrote: > > > > > > > https://github.com/gnuradio/gnuradio/issues/1348 > > > > > > > > > > > > Regards: > > > > Cor > > > > > > > > > > > > On Mon, 2017-06-26 at 14:11 +0200, Marcus Müller wrote: > > > > > > > > That's mightily interesting! I feel like we should be doing > > > bug reports, but I'm not sure where. > > > > > > > > > > > > > > > On 26.06.2017 06:42, Cor Legemaat > > > wrote: > > > > > > > > > > > > > Found it: > > > > > > > > > > > > > > > > > > > > > > > > Created an C++ app that called that function with the > > > > > > > > same parameter values as with python for this flow graph. > > > > Witch I was able to debug normally. > > > > > > > > > > > > > > > > > > > > > > > > In window.cc line 265, with i = ntaps - 1, temp = > > > > > > > > 1.0000000000000000002 that cause sqrt (0) witch return > > > > > > > > "-nan" on the next line and screw all the rest of the > > > > calculations. > > > > > > > > > > > > > > > > > > > > > > > > This only happens when compiled with > > > > > > > > "CFLAGS=-march=native -O2", if I don't specify the march > > > > > > > > it's working correctly. The function is called on my system > > > > with taps=787 and beta = 7. > > > > > > > > > > > > > > > > > > > > > > > > Regards: > > > > > > > > Cor > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2017-06-21 at 15:13 +0200, Cor Legemaat wrote: > > > > > > > > > Hi: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry for the late replay... The intel pc call > > > > > > > > > > filter.firdes.low_pass with the same values > > > > > > > > > > but return 768 > > > > > > > > > > proper float values, not like the <nan>'s on the AMD > > > > > pc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tried to debug with "nemiver /usr/bin/python2.7 -u > > > > > <path>/fm_receiver.py" and the breakpoint at > > > > > > > > > > firdes.cc line 100 witch get triggered and I can read the > > > > > > > > > > function parameters but when I try to step > > > > > > > > > > true the > > > > > > > > > > function it jumps to the assembly of pthread. If I put > > > > > > > > > > more breakpoints in firdes.cc I get back to > > > > > > > > > > the function > > > > > > > > > > but cant read any variables any more. Also tried exporting > > > > > > > > > > "export GR_SCHEDULER=STS" but the same symptoms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Don't know if Ubuntu will trigger the bug it's probably > > > > > compiled more generic... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards: > > > > > > > > > > Cor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2017-06-07 at 04:26 -0400, Anon Lister wrote: > > > > > > > > > > > > > > > > > > > > > > > I have an AMD system with the same chip running > > > > > > > > > > > > Ubuntu 16.xx. I can probably try to duplicate this > > > > > > > > > > > > weekend, if Cor doesn't get to it, as another data > > > > > > point. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Jun 5, 2017 3:14 PM, > > > > > > > > > > > > "Marcus Müller" > > > > > > > > > > > > <marcus.mueller@ettus .com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > 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-gn uradio > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Discuss-gnuradio mailing list > > > > > > > > > > Discuss-gnuradio@gnu.org > > > > > > > > > > > > > > > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnur adio > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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/listi nfo/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 > > > > > > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
