# OOT Decimation Module dropping data samples **URL:** \ **Category:** GNU Radio\ **Created:** [February 26, 2014, 1:32am UTC](https://www.ruby-forum.com/t/oot-decimation-module-dropping-data-samples/239430 "2014-02-26T01:32:59Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [February 26, 2014, 1:32am UTC](https://www.ruby-forum.com/t/oot-decimation-module-dropping-data-samples/239430/1 "2014-02-26T01:32:59Z")
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? 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? good frame: [Dropbox - Error - Simplify your life](https://www.dropbox.com/s/tma3qn5byismgha/good_frame.png) bad frame: [Dropbox - Error - Simplify your life](https://www.dropbox.com/s/xgvcmlbgma14k0i/bad_frame.jpg) Thank you all in advance for the help, Michael B. ---
**Author:** ![michaelb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b19c9b/32.png) [@michaelb](https://www.ruby-forum.com/u/michaelb)\ **Post date:** [February 26, 2014, 10:43am UTC](https://www.ruby-forum.com/t/oot-decimation-module-dropping-data-samples/239430/2 "2014-02-26T10:43:18Z")
On 02/26/2014 01:31 AM, Michael B. wrote: > 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. ---
**Author:** ![michaelb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b19c9b/32.png) [@michaelb](https://www.ruby-forum.com/u/michaelb)\ **Post date:** [February 26, 2014, 8:51pm UTC](https://www.ruby-forum.com/t/oot-decimation-module-dropping-data-samples/239430/3 "2014-02-26T20:51:53Z")
Martin, Thank you for the quick response to my issue! I cannot release the source code as is, however I can describe what I am doing, and possibly if need be I can release a deprecated version that still exhibits this behavior. I am taking 1 MHz of spectrum and putting this through a 50 channel channelizer to obtain 20 kHz channels. The signals I am interested in are all at +/- 5 kHz of 12 of the original 50 channels; the channels I am not using are fed into NULL sinks. I then take my channels of interest and feed them through a mixer by multiplying the signals by a +/- 4950 Hz complex sinusoid to shift my signals of interest to +/- 50 Hz in each channel. Each channel is then ran through an FIR filter and into an instance of the blocks at question. I have set this up to run with just one channel instead of the 12 as described above and everything works fine, so I believe this may be an issue with having multiple instances of a block alive at the same time. Are the input and output buffers thread safe against multiple instances of the same block running? Michael ---
**Author:** ![michaelb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b19c9b/32.png) [@michaelb](https://www.ruby-forum.com/u/michaelb)\ **Post date:** [February 27, 2014, 2:08am UTC](https://www.ruby-forum.com/t/oot-decimation-module-dropping-data-samples/239430/4 "2014-02-27T02:08:25Z")
I have figured out what was happening for me. As I was deprecating the source code to put out publicly, I noticed something that looking at now was a glaring red flag. Inside my OOT, I was copying the GNURadio buffered data into a vector for computation on the large set of data. I knew that it was going to be large, and trying to save space on the stack, I made the local variable static. This, of course, made all instances of the object have the same local buffer in memory, and I truly did have a classic multi-threaded problem on my hands. In my case, Instead of dealing with the overhead needed to guard the common resource, I simply removed the static keyword and allowed the memory to allocated on the stack. Michael ---
**Author:** ![michaelb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/b19c9b/32.png) [@michaelb](https://www.ruby-forum.com/u/michaelb)\ **Post date:** [February 27, 2014, 2:11pm UTC](https://www.ruby-forum.com/t/oot-decimation-module-dropping-data-samples/239430/5 "2014-02-27T14:11:17Z")
On 02/27/2014 02:06 AM, Michael B. wrote: > allocated on the stack. > Hah, a classic case of premature optimization 🙂 > Glad you figured it out. Martin