>
>
>
> 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
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
