Re: [Discuss-gnuradio] Correlation Estimation Block Oddity

[Richard Bell]

I somehow attached the wrong correlation screenshot in my previous post. Here is the correct one.

Rich

On Mon, Apr 27, 2015 at 4:35 PM, Richard Bell <address@hidden> wrote:

Andy and all,

Sorry for the delay in reply, I've been working hard to figure things out on my end.

I use the polyphase clock recovery block for timing recovery.

I have essentially copied the test_corr_est.grc example that was included with the block in the examples directory. It seems that this might not be the appropriate way to use this block. Here is why I say this. If you look at the attached screenshot, you will see the correlation output has two peaks, somewhat close in amplitude to each other. The synchronization sequence that was used to generate those peaks was 64 bits long and composed of two 32 bit long PN sequences repeated. Therefore, one would expect the output of the correlation to generate 3 peaks, a center peak that is ~64 units high, and two side peaks spaced 32 samples apart that are ~32 units high.

Now, I believe the cause of this to be the use of the modulate vector block to generate the input mask for the correlation estimation block. I have attached a second screenshot of the output of the modulation vector block. You will see in this screen shot a large transient portion that is fed into the correlation estimation block. So, if we agree we should not use the modulate vector block to feed the correlation estimation block with its mask, then the question is how should I? An example what be most helpful.

This is difficult to discuss because things get wordy very quickly. Let me know if I can make anything more clear.

v/r,

Rich

On Fri, Apr 24, 2015 at 9:11 AM, Andy Walls <address@hidden> wrote:

Hi Richard,

>                              From:
> Richard Bell
>                           Subject:
> Re: [Discuss-gnuradio] Correlation
> Estimation Block Oddity
>                              Date:
> Thu, 23 Apr 2015 15:38:38 -0700
>
> ______________________________________________________________________
> I have another question on tag placement for the correlation
> estimation block. In the screenshot I've attached, you'll see that the
> corr_start tag is placed well before the preamble actually starts.

OK.  That's the first thing you should try to fix.  You are crossing the
correlation threshold too early.

Either

a. Get rid of leading 0's in the correlation sequence that you are
using,
b. Set the threshold on the corr_est block to something higher than the
default 0.9 (90%), or
c. make the correlation sequence "more unique" somehow, e.g. make it
longer.

As I mentioned in my previous email, the "corr_start" tags is placed at
the length of your matched filter samples before where the correlation
peak was detected.

You can eyeball how the correlation is going by plotting the Magnitude^2
of the "corr" output on top of the output signal (use a tag_gate block
to block the tags coming out of the "corr" output).  The output signal
is delayed by the length of the matched filter, so you can see the
correlation peak and the "corr_start" tag line up.

See the attached screen shot of an AIS preamble and the scaled magnitude
squared of the correlator output.


>  If I use the 'delay tag' field to move it to the end of the preamble
> where I need it, it stops delaying, no matter how big I make the
> delay,

Yup, the code forces a maximum delay.  You can delay it to the end of
your matched filter and no further:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/corr_est_cc_impl.cc#L65

The code does this because GnuRadio will not let us tag samples outside
of the window of samples passed to the current call to work.  By setting
the bound of the marking delay to the start and end of the matched
filter, with other mechanisms in the block, we are guaranteed to be able
to mark the sample.

>  before it reaches the end of the preamble.

Well as far as the block is concerned, you are able to mark to the end
of the matched filter where the correlation peak occurred (but no
further), which should be the end of your preamble.  Your problem is
that the block declared a correlation too early.


>  This is shown in the picture. I need this tag to denote the start of
> the header for the Header Payload Demux block.

Out of curiosity, what's doing timing recovery, i.e. finding the optimal
bit sampling times?  I use the tagging delay out of the corr_est block
to mark the center of the first bit in the preamble, to tell downstream
bit timing recovery blocks to reset/realign at that point.

Regards,
Andy

>
> My question is, given the situation in the screenshot, is there a way
> I can delay just the tag in grc using a block? I'm not sure how to get
> the tag positioned where I need it at this point.
>
>
> Help is greatly appreciated
>
>
> v/r,
>
> Rich
>
>
>

corr_output.png
Description: PNG image