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
bad frame: Dropbox - Error - Simplify your life
Thank you all in advance for the help,
Michael B.
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.
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
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 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
