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