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:

>         
>         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

I haven't worked through all that yet, myself. :)

I do know with my differential input signal, I have to run the
subtraction through all the history and the output items to get the
proper baseband input vector.  Here's what I'm doing currently in that
start of work():

        memcpy(out_p, in_p, sizeof(float)*noutput_items);
        memcpy(out_n, in_n, sizeof(float)*noutput_items);

        // Compute the unequalized baseband input
        volk_32f_x2_subtract_32f(d_in, in_p, in_n, noutput_items + 
(history()-1));

        // Calculate the correlation with the known symbols
        d_filter->filter(noutput_items, d_in, corr);

I was *assuming* the d_filter->filter() call was sucking in the proper
amount of history it need for noutput_items based on d_filter->ntaps()
since it already knows ntaps().

My possibly flawed understanding of history() is that the actual size of
the incoming buffer is at least noutput_items + (history()-1), and that
in[0] points to the oldest sample in the history.

I thought the discontinuity in the output of the correlation at the
beginning of the next work call looked odd.   So maybe I've got
something wrong. 

-Andy