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

[Cor Legemaat]

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.002 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 's on
the AMD
> > > > >   pc.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > > > > > Tried to debug with "nemiver /usr/bin/python2.7
-u
> > > > >   /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" 
> > > > > > > > > > > > 
> > > > > >   wrote:
> > > > > > 
> > > > > >   
> > > > > > 
> > > > > >   Hi Cor,
> > > > > > 
> > > > > >   
> > > > > > > > > > > >  

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

[Marcus Müller]

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.002 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 's on the AMD pc.

 Tried to debug with "nemiver /usr/bin/python2.7 -u
 /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"  > wrote:
>
> Hi Cor,
>
> Excuse the language, but frk. 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 

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

[Cor Legemaat]

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.002 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 's on the AMD
pc.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Tried to debug with "nemiver /usr/bin/python2.7 -u
> > >   /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" 
> > > >   wrote:
> > > > 
> > > >   
> > > > 
> > > >   Hi Cor,
> > > > 
> > > >   
> > > > > > > >   Excuse the language, but frk. 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!!
> 

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

[Marcus Müller]

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.002 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
>> 's on the AMD pc.
>>
>> Tried to debug with "nemiver /usr/bin/python2.7 -u
>> /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" >> > wrote:
>>>
>>> Hi Cor,
>>>
>>> Excuse the language, but frk. 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
> 

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

[Cor Legemaat]

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.002
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
's on the AMD pc.
> 
> > > > > > > Tried to debug with "nemiver /usr/bin/python2.7 -u
/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" 
wrote:
> > 
> >   
> > 
> >   
> >   
> > Hi Cor,
> > 
> > 
> > > > Excuse the language, but frk. 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
> > > > 

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

[Cor Legemaat]

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
's on the AMD pc.

Tried to debug with "nemiver /usr/bin/python2.7 -u
/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" 
wrote:
> 
>   
> 
>   
>   
> Hi Cor,
> 
> 
> Excuse the language, but frk. 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.
> > > > 
> > > > 

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

[Anon Lister]

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"  wrote:

Hi Cor,

Excuse the language, but frk. 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 

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

[Marcus Müller]

Hi Cor,

Excuse the language, but frk. 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

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

[Cor Legemaat]

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 

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

[Marcus Müller]

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-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

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

[Cor Legemaat]

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
>  


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

[Discuss-gnuradio] Rational Resampler no output.

[Cor Legemaat]

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

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