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
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.c
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
> n
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 a bug in low_pass.
Or in G
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
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 ou
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 her
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.
A
Hi Jason,
so talking about the GNU Radio rational resampler:
> Under the hood, is GNURadio basically creating a FIR
> decimator?
Yeah! Multirate processing!
So what happens in the block that's called "rational resampler" in GRC
is that if you leave "taps" empty, the Python block [1] designs a FIR
I think I am overthinking something with the rational resampler. I am
working on an RFNoC block to incorporate a working gnuradio script we
have, and am somehow being silly about the rational resampler.
I am decimating by 4 (and not interpolating at all), to reduce the
sample rate by 4. Under th
Thank you, Tom!
I will try it on my Raspi soon.
Frederik
Am 19.11.2013 04:38, schrieb Tom Rondeau:
> On Mon, Nov 18, 2013 at 9:48 AM, Tom Rondeau wrote:
>> On Mon, Nov 18, 2013 at 8:41 AM, Frederik Wing
>> wrote:
>>> As I said, I cannot design a filter with a sampling frequency below 1e6.
>>>
On Mon, Nov 18, 2013 at 9:48 AM, Tom Rondeau wrote:
> On Mon, Nov 18, 2013 at 8:41 AM, Frederik Wing
> wrote:
>> As I said, I cannot design a filter with a sampling frequency below 1e6.
>> The Python script I posted (where f_s = 1e3) does NOT work! But if I
>> change f_s to 1e6 it works and give
On Mon, Nov 18, 2013 at 8:41 AM, Frederik Wing wrote:
> As I said, I cannot design a filter with a sampling frequency below 1e6.
> The Python script I posted (where f_s = 1e3) does NOT work! But if I
> change f_s to 1e6 it works and gives me the gigantic filter.
>
> Frederik
I think I see the pro
As I said, I cannot design a filter with a sampling frequency below 1e6.
The Python script I posted (where f_s = 1e3) does NOT work! But if I
change f_s to 1e6 it works and gives me the gigantic filter.
Frederik
Am 18.11.2013 14:35, schrieb Tom Rondeau:
> On Mon, Nov 18, 2013 at 8:31 AM, Martin B
You can find my sample Python script two posts earlier.
Frederik
Am 18.11.2013 14:31, schrieb Martin
Braun (CEL):
On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote:
Hi Tom,
what you are writing is completely right. Sim
On Mon, Nov 18, 2013 at 8:31 AM, Martin Braun (CEL)
wrote:
> On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote:
>> Hi Tom,
>>
>> what you are writing is completely right. Simply increasing the sampling
>> frequency will result in a more complex filter.
>>
>> Nevertheless the firdes.low
On Mon, Nov 18, 2013 at 02:19:55PM +0100, Frederik Wing wrote:
> Hi Tom,
>
> what you are writing is completely right. Simply increasing the sampling
> frequency will result in a more complex filter.
>
> Nevertheless the firdes.low_pass function does NOT want to calculate the
> 101-tap-filter. Bu
Hi Tom,
what you are writing is completely right. Simply increasing the sampling
frequency will result in a more complex filter.
Nevertheless the firdes.low_pass function does NOT want to calculate the
101-tap-filter. But it DOES calculate the 11-tap-filter. Really
strange. So this might not
On Sun, Nov 17, 2013 at 9:39 AM, Frederik Wing wrote:
> Hello again,
>
> meanwhile I got some more information about the error.
> It occurs when returning the taps from the firdes::low_pass function.
> But ONLY under some conditions.
> I wrote a simple script which is NOT working and giving the er
Hello again,
meanwhile I got some more information about the error.
It occurs when returning the taps from the firdes::low_pass function.
But ONLY under some conditions.
I wrote a simple script which is NOT working and giving the error
mentioned earlier:
> from gnuradio.filter import firdes
>
> f_
Good evening Marcus,
thanks for your fast response.
In my sources firdes.cc:136 is
> return taps;
I cloned them from the git repository. Here is the source of the
trouble-making file:
http://gnuradio.org/redmine/projects/gnuradio/repository/entry/gr-filter/lib/firdes.cc?rev=master
Maybe you have
I pulled and compiled the latest gnuradio yesterday on an intel machine.
My project uses the rational resampler as well and I am having no problems.
Mark
On 15/11/13 11:13, Frederik Wing wrote:
> Hi everyone,
>
> I am using the latest GNU Radio version compiled and running on a
> Raspberry Pi with
Hi Frederik, hi rest,
this is an interesting error. You might want to report it.
The interesting part of your backtrace is
#8 ~vector (this=0xbee7c59c, __in_chrg=)
at /usr/include/c++/4.6/bits/stl_vector.h:350
#9 gr::filter::firdes::low_pass (gain=,
sampling_freq=, cutoff_freq=0.450
Hi everyone,
I am using the latest GNU Radio version compiled and running on a
Raspberry Pi with Raspbian Wheezy.
Most of the blocks seem to work. But the Rational Resampler makes problems.
Here is my sample python script generated by GNU Radio Companion:
http://pastebin.com/R0Z21MfU
Running it
>So I suppose if I do the same thing it would work right?
Only one way to find out, try it.
On Wed, Jun 20, 2012 at 11:02 PM, Stephen wrote:
>
>
> On 6/19/2012 11:50 PM, Andrew Davis wrote:
>> The rational resampler is part of BLKS2 which is python only. I'm
>
> thanks for reminding me. I keep f
The rational resampler is part of BLKS2 which is python only. I'm
currently working on porting blks2 over to C++ so the API will not be
python only, but there is a lot of python code it is built on that
needs to be converted first so it could be a bit. You could just do it
yourself, all the rationa
Hi,
I'm trying to convert a flowgraph from grc to c++. In grc there is a
rational resampler block and a rational resampler base block. I could
not find a c++ version of the rational resampler block. Does a c++
version exist? I don't much about either but I tried to use the rational
resampler base
On Wed, Apr 30, 2008 at 3:10 PM, Wireless Monster
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Does anybody know how to calculate the delay introduced by the filter used
> by the rational_resampler_ccc block (formula or a way to measure it, as the
> parameters are fixed)
>
> Thanks for your help!
The
Hi all,
Does anybody know how to calculate the delay introduced by the filter used
by the rational_resampler_ccc block (formula or a way to measure it, as the
parameters are fixed)
Thanks for your help!
___
Discuss-gnuradio mailing list
Discuss-gnuradi
On Wed, Mar 08, 2006 at 07:56:11AM -0500, Marcus Leech wrote:
> I'm trying to re-sample signals, ranging from 0.5Hz up to about 40Hz,
> sampling them at some small
> integer multiple of their frequency. Simple decimation isn't getting
> close enough, in many circumstances,
> leaving a significa
I'm trying to re-sample signals, ranging from 0.5Hz up to about 40Hz,
sampling them at some small
integer multiple of their frequency. Simple decimation isn't getting
close enough, in many circumstances,
leaving a significant phase erorr.
I'm thinking that I can get closer using the rationa
The rational resampler is functional and has been checked in by Eric. I
learned a valuable lesson which I will pass on. Like everyone who does
a lot of different coding these days, the first place to go is to
Google for the time saving code. Julius O. Smith of CCRMA did a very
good study of
36 matches
Mail list logo
