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

[Andy Walls]

On Fri, 2015-01-02 at 09:57 -0500, Tom Rondeau wrote:
> On Fri, Jan 2, 2015 at 8:57 AM, Andy Walls
> <address@hidden> wrote:
>         On Wed, 2014-12-31 at 15:48 -0500, Andy Walls wrote:
>         > On Wed, 2014-12-31 at 14:00 -0500, Andy Walls wrote:
>         > > Hi.
>         > >
>         > > Can someone give me a brief clue about the threshold testing in 
> the
>         > > correlate_and_sync block?
>         
>         I found my answer in this post:
>         
>         https://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1310
>         
>         "The correlation peak is tested by first observing that the width of 
> the
>         correlation peak will be sps number of samples wide. So we look at
>         sample i and sample (i-sps). If the difference between these two 
> symbols
>         is greater than the threashold we calculated in the constructor, we
>         declare a correlation."
>         
>         That probably works for most preambles.
>         
>         Unfortunately it becomes a problem with the data sequence
>         "101010101010..." and a rectangular pulse filter, as the absolute 
> value
>         (magnitude) peaks of the correlation increase somewhat linearly as the
>         sequences align, and there will be a peak at every sps samples.  Thus
>         the threshold test won't trigger as expected.
>         
>         The correlation absolute value peak happens every sps samples because,
>         using NRZ bit mapping (0 => -1, 1 => 1), the positive correlation is
>         about as strong as the neighboring negative correlation that is sps
>         samples away.
>         
>         I'm not sure if I should file a bug report for this corner case or 
> not.
>         
>         I'm writing my own correlator block based on the correlate_and_sync
>         block; except that it works on real, not complex, input samples.   For
>         myself, I just use the unmodified output of the real valued 
> correlation
>         filter and just set the threshold test to be relative to 0.
> 

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.


Regards,
Andy

End of work mid-correlation.png
Description: PNG image

Clock pattern correlation.png
Description: PNG image