Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block

[Andy Walls]

On Fri, 2015-01-02 at 09:56 -0800, Nick Foster wrote:
>         
>         
>         
>         Hi Tom,
>         
>         
>         > Andy,
>         >
>         >
>         > Thanks for the reports and details. I can definitely see the
>         problem
>         > with the situation you're describing. We obviously weren't
>         considering
>         > that case when we designed the block. We were really
>         expecting any
>         > preamble/access code that we were using would have good
>         > autocorrelation statistics. From that perspective, the
>         10101...
>         > pattern is pretty silly, but hey, it is used.
>         
>         Yeah.
>         
>         > Right now, you're probably best off redoing your own block
>         as you say
>         > to deal with the specifics of your case. However, I'd like
>         us to think
>         > about how we can abstract this concept within the current
>         block so
>         > that we can more easily provide the behavior we'd like to
>         see, such as
>         > the correlation and detection logic, and the filter design.
>         I know
>         > Nick Foster has thoughts on this, too, with his work on GMSK
>         signals.
>         
>         Yes, I leveraged Nick's msk_correlate_and_sync as well. :)
>         
>         For visualizing the scenario I mentioned, see the attached
>         "Clock
>         pattern correlation.png".  I took the "corr" output of my
>         custom block
>         and plotted its abs() along with the baseband input. My custom
>         block
>         picked the two large positive correlation peaks and ignores
>         the nearby
>         negative ones.  With my particular real, baseband input, I'm
>         guaranteed
>         not to have any sign ambiguity in the baseband input; so I
>         could ignore
>         that wrinkle.
>         
>         There is another problem which prevents proper correlation:
>         the end of
>         work coming mid-burst.  See the attached "End of work
>         mid-corr.png"
>         which shows an end of work tag with the value of
>         noutput_items.  I'm not
>         sure how to handle this is the general case, except for burst
>         energy
>         detection.  But burst energy detection won't work for
>         CDMA-like things,
>         where the signal might be buried in the noise.
> 
> 
> I'm in the middle of generalizing correlate_and_sync_cc to allow use
> with any candidate vector you want (although I hadn't considered the
> real-only case). It's working now, and just this morning I encountered
> the same thing you're seeing. Of interest to me is the loop:
> 
> 
> <...>
> d_filter->filter(noutput_items, in, corr);
> <...>
> int i = d_sps;
> while(i<noutput_items) {
> <...>
> 
> 
> ...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

Correlater end of work OK.png
Description: PNG image

Correlater cant set tag back in previous work call.png
Description: PNG image