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

[Nick Foster]

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

Regards,
Andy



_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio