[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 +
(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
- Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block, Andy Walls, 2015/01/02
- Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block, Tom Rondeau, 2015/01/02
- Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block, Andy Walls, 2015/01/02
- Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block, Nick Foster, 2015/01/02
- Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block,
Andy Walls <=
- Re: [Discuss-gnuradio] Question on threshold mathematics in correlate_and_sync block, Andy Walls, 2015/01/03
- [Discuss-gnuradio] Correlate and sync matched filter: pitfall and another bug (Re: Question on threshold mathematics in correlate_and_sync block), Andy Walls, 2015/01/05
- Re: [Discuss-gnuradio] Correlate and sync matched filter: pitfall and another bug (Re: Question on threshold mathematics in correlate_and_sync block), Tom Rondeau, 2015/01/05
- Re: [Discuss-gnuradio] Correlate and sync matched filter: pitfall and another bug (Re: Question on threshold mathematics in correlate_and_sync block), Nick Foster, 2015/01/05
- Re: [Discuss-gnuradio] Correlate and sync matched filter: pitfall and another bug (Re: Question on threshold mathematics in correlate_and_sync block), Andy Walls, 2015/01/06