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-filter/py thon > > > /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 > > > > > > > > _______________________________________________ > 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
