discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Rational Resampler no output.


From: Cor Legemaat
Subject: Re: [Discuss-gnuradio] Rational Resampler no output.
Date: Tue, 27 Jun 2017 19:01:51 +0200

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" <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]