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.muel...@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-fil ter/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-gnurad io > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > _______________________________________________ > > > 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
