discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] OOT Decimation Module dropping data samples


From: Martin Braun
Subject: Re: [Discuss-gnuradio] OOT Decimation Module dropping data samples
Date: Wed, 26 Feb 2014 10:42:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

On 02/26/2014 01:31 AM, Michael Berman wrote:
> I am seeing some odd behavior with an OOT decimation block.  What I am
> seeing is chunks of data are being dropped down to noise for random
> calls of the work function in my OOT.  To observe this happening, I
> tee'd off the connection going into my OOT module and went strait into a
> file sink and then from within the OOT module for each call of the work
> function I stored off the incoming data to a file; the results of a good
> and bad frame of data are provided in the below links.  Within this
> data, the top chart is the file sink tee'd off and you can see it
> tracking well for the most part with the data from within the module on
> the bottom.  Within the "bad frame" image however, a little over 1000
> samples in, the data drops down noise around 0 instead of being a nice
> (and slightly noisy...) sinusoid.  The OOT module has a decimation value
> of 4000 in this particular case.  I am running on Fedora 20 with a week
> old pull of GNURadio master branch.
> 
> Does anybody have any thoughts as to why this is happening, and what I
> could do to resolve it?

Agreed this is weird. No immediate solution pops to my mind, but can you
provide some more info:
- Is this block part of a larger flow graph, or does this occur also
when you isolate your block?
- Is this code you can share? If so, can we see the OOT

> The first resolution that is coming to mind would be to re-write my OOT
> module to run with general_work, and manage the input buffer myself.
>  Does anybody see any issues with doing this as a work around/solution?

There's no reason not to do that, but it would be a big surprise if that
helped. After all, a sync_decimator is just a very thin wrapper around a
gr::block.

> good frame: https://www.dropbox.com/s/tma3qn5byismgha/good_frame.png
> bad frame: https://www.dropbox.com/s/xgvcmlbgma14k0i/bad_frame.jpg
> 
> 
> Thank you all in advance for the help,
> 
> Michael Berman
> 
> 
> 
> _______________________________________________
> 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]