|Subject:||Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block|
|Date:||Fri, 2 Jan 2015 09:56:11 -0800|
> 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.
> 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
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.
Discuss-gnuradio mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|