[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andy Walls
Subject: Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block
Date: Fri, 02 Jan 2015 13:16:09 -0500

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 + 

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]