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


On Wed, Feb 26, 2014 at 11:50 AM, Michael Berman <mrberma...@gmail.com>wrote:

> 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
>
>
> On Wed, Feb 26, 2014 at 1:42 AM, Martin Braun <martin.br...@ettus.com>wrote:
>
>> 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
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to