|
From: | Michael Berman |
Subject: | Re: [Discuss-gnuradio] OOT Decimation Module dropping data samples |
Date: | Wed, 26 Feb 2014 17:06:19 -0800 |
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?MichaelOn Wed, Feb 26, 2014 at 1:42 AM, Martin Braun <address@hidden> wrote:
On 02/26/2014 01:31 AM, Michael Berman wrote:Agreed this is weird. No immediate solution pops to my mind, but can you
> 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?
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
There's no reason not to do that, but it would be a big surprise if that
> 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?
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
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |