[Top][All Lists]

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

Re: [Discuss-gnuradio] Correlation Estimation Block Oddity

From: Andy Walls
Subject: Re: [Discuss-gnuradio] Correlation Estimation Block Oddity
Date: Fri, 24 Apr 2015 12:11:24 -0400

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.


a. Get rid of leading 0's in the correlation sequence that you are
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

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:

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.


> 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

Attachment: corr_start.png
Description: PNG image

reply via email to

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