discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] blks2.pfb_arb_resampler segfault


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] blks2.pfb_arb_resampler segfault
Date: Sun, 13 May 2012 20:40:12 -0400

On Sun, May 13, 2012 at 4:56 PM, Andrew Davis <address@hidden> wrote:
> I have a C++ port of optfir waiting to be merged you could look at:
> https://github.com/glneo/gnuradio-davisaf/tree/master/gnuradio-core/src/lib/general,
> it's in there, its the gr_optfir*. It has a few bug-fixes from the
> python code.

Yes, we'll hopefully be moving this in soon. I have to take another
look at the branch you've been working on. I've been working on
gr-filter, moving all filter related materials to a new top-level
component and converting to Volk for as much as possible. This might
just move right into there.

Hopefully, this will fix the problem Alex has been having. It would be
nice to know more about what's going on, though. It might just be
returning an empty vector or throwing an error that's not being
handled properly. We should try to fix/handle those errors properly
regardless of it being Python/C++.

Tom


> On Sun, May 13, 2012 at 4:15 PM, Alexandru Csete <address@hidden> wrote:
>> On Sun, May 13, 2012 at 5:52 PM, Tom Rondeau <address@hidden> wrote:
>>> On Sun, May 13, 2012 at 11:33 AM, Alexandru Csete <address@hidden> wrote:
>>>> I was implementing the two functions from blks2/pfb_arb_resampler.py
>>>> in C++ and I noticed that the python code crashes for some reason. I
>>>> was trying it using the attached GRC file.
>>>>
>>>> I think the C++ code itself is fine because it works with my C++
>>>> implementation of pfb_arb_resampler_ccf and pfb_arb_resampler_fff, so
>>>> the problem must be at the python level. One of the differences
>>>> between my C++ implementation and the python code is that I use
>>>> gr_firdes for generating the taps instead of optfir.
>>>>
>>>> Alex
>>>
>>> Yes, must be something with optfir producing badly formed taps in this
>>> case. Can you create your own taps in the GRC graph and pass them to
>>> the block?
>>
>> Hi Tom,
>>
>> Yes, using firdes to generate the taps works. So the problem must be
>> in the optfir package.
>>
>> Alex
>>
>> _______________________________________________
>> 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



reply via email to

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