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:CorOn 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/rational_resampler.py On 29.05.2017 19:01, Cor Legemaat wrote:filter/python 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_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment