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
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
>
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
>
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
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
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
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++
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
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
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:
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.
12 matches
Mail list logo