Re: [Discuss-gnuradio] is there possible to have item drops?

[Mostafa Alizadeh]

Tx is an abbreviation of tx blocks! :)

I finally found the problem! I used heap memory but I never release it in different blocks! So during the runtime, the memory allocation get the error: "std::bad_alloc" after somewhile. Now this is fine. 

Thank you too much, 

Best, 

Mostafa

On Thu, Oct 16, 2014 at 4:16 PM, Marcus Müller <address@hidden> wrote:

I'm a bit confused. Your diagram

TX->FIR->...
   ->Filesink

Indicates that TX is a source, whereas TX usually is an information sink
in DSP. Maybe you want to fill us in about the type of block TX is?

Greetings,
Marcus

On 16.10.2014 13:47, Mostafa Alizadeh wrote:
> Hi Marcus,
>
> I tested again my problem with connecting a data file (file source) to the
> fir filter and read the output with the one resulted from Matlab. The error
> which appears due to the data precision is in acceptable order.
>
> However, when I directly connect my tx to the fir filter, it did something
> strange after sometime which causes a great error with respect to the
> Matlab one.
>
> *I think the problem is with my tx! I really confused!! I just wanna know
> how could I identify the problem and how could I fix it? *
>
> My scheme:
>
> *[image: Inline image 1]*

>
> Best,
> Mostafa
>
> On Wed, Oct 15, 2014 at 9:03 PM, Marcus Müller <address@hidden>
> wrote:
>
>>  Hello Mostafa,
>>
>> filtering is a inherently lossy operation: it's an operation that involves
>> multiplication and addition of floating point numbers.
>> Matlab internally uses double (float64) values, whereas GNU Radio,
>> usually, uses single precision (float32) numbers for performance reasons.
>> Now, without knowing what kind of signal you are filtering with what kind
>> of taps you are using with what kind of GNU Radio filters and what Matlab
>> functions, there's nothing to guess on how these differences occur.
>> What I *can* say though is that I've never seen an item drop in GNU
>> Radio's runtime, and we have strong tests against that. Now, it's entirely
>> possible that any of our filter implementations might have bugs, but I kind
>> of doubt that. It's most probably simply numeric accuracy that kills your
>> samples.
>>
>> Greetings,
>> Marcus
>>
>>
>>
>> On 15.10.2014 18:07, Mostafa Alizadeh wrote:
>>
>> Hi all,
>>
>> It seems this is a ridiculous question, however, I didn't find any solution
>> for my problem.
>>
>> I have already a bunch of custom blocks connected to each other which play
>> role as a transmitter (tx). I want to connect tx to a fir filter by using
>> fir_filter_ccc block. I set the filter taps with specific ones. I also have
>> this filter in Matlab. The output of the filter is connected to a sink file.
>>
>> When I see the output (tx) and filtering it by Matlab and comparing it with
>> the output of the gnuradio filter, I see both of the following:
>>
>> 1) Both matlab and gnuradio filtered output, have little difference in a
>> range of 0.01. (I'm using gr_complex data).
>>
>> 2) After a while, Matlab output and GNURadio's output will differ as high
>> as 1000 in magnitude!!
>>
>> I guess, there is item drops in this filtering. I know, the probability of
>> this event is so weak, anyway, item drop even can happen in GNURadio?
>>
>> Where is my problem?
>>
>> Best,
>> Mostafa
>>
>>
>>
>>
>> _______________________________________________

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

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

--

***********************************************************

Department of Electrical Engineering

Aboureyhan Building

MMWCL LAB

Amirkabir University Of Technology

Tehran

IRAN

Tel: +98 (919) 158-7730

LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411

Homepage: http://ele.aut.ac.ir/~alizadeh/

***********************************************************