On Fri, 2015-01-02 at 09:56 -0800, Nick F. wrote:
problem
> Nick F. has thoughts on this, too, with his work on GMSK
picked the two large positive correlation peaks and ignores
mid-corr.png"
with any candidate vector you want (although I hadn’t considered the
…with set_history(d_filter->ntaps()) in the constructor, we should
probably be running the filter against the entire input vector
including history, and copying to the output the part relevant to the
current work call. Or, only running the work function up to
(noutput_items - d_filter->ntaps()) items. Right?
–n
Hi Nick,
Here’s what I just got working for me. In my block’s constructor I do
this:
// Correlation filter
d_filter = new filter::kernel::fft_filter_fff(1, d_symbols);
// Per comments in
gr-filter/include/gnuradio/filter/fft_filter.h,
// set the block output multiple to the FFT filter kernel’s
internal,
// assumed “nsamples”, to ensure the scheduler always passes a
// proper number of samples.
int nsamples;
nsamples = d_filter->set_taps(d_symbols);
set_output_multiple(nsamples);
// It looks like the kernel::fft_filter_fff stashes a tail
between
// calls, so that contains our history maybe? The
fft_filter_fff
// block (which calls the kernel::fft_filter_fff) sets the
history
// to 1, so let’s follow its lead. I’m not sure if this is
right
// though.
set_history(1);
//set_history(d_filter->ntaps());
// Setting the alignment multiple for volk causes problems with
the
// expected behavior of setting the output multiple for the FFT
filter.
// Don’t set the alignment multiple for now, until we figure out
// another way to ensure the output multiple provided by the
// scheduler.
//const int alignment_multiple =
// volk_get_alignment() / sizeof(float);
//set_alignment(std::max(1,alignment_multiple));
See the attached “Correlator end of work OK.png” to see the correlator
output looking reasonable across calls to work.
Nick and Tom,
Unfortunately there is still the problem of correlation tags that cannot
be set back on the beginning of a preamble that spans 2 consecutive
calls to work(). Compare the left (good) and right (bad) baseband pulse
tagging in “Correlater cant set tag back in previous work call.png”.
Energy detection of the pulse might be one way to deal with this
problem. Another might be to stash the last d_symbols.size() samples in
each call to work(), so the next call to work() can look back upon them,
if needed. There are probably more graceful things to do.
-Andy
