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 <richard.be...@gmail.com> 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 <a...@silverblocksystems.net> > 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 >> > >> > >> > >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
