Hey Andy, When you mentioned I should remove leading or trailing zeros from the Correlation Estimator symbols field, how would you go about doing this if you used the modulate vector block as done in the example? I'm stuck on this.
v/r, Rich On Mon, Apr 27, 2015 at 4:52 PM, Richard Bell <richard.be...@gmail.com> wrote: > 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
