# Weird behavior of the correlate\_and\_sync block **URL:** \ **Category:** GNU Radio\ **Created:** [March 29, 2015, 4:00am UTC](https://www.ruby-forum.com/t/weird-behavior-of-the-correlate-and-sync-block/234771 "2015-03-29T04:00:38Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 29, 2015, 4:00am UTC](https://www.ruby-forum.com/t/weird-behavior-of-the-correlate-and-sync-block/234771/1 "2015-03-29T04:00:38Z")
I’m trying to use the correlate\_and\_sync block to get an initial timing estimate from a packet radio, but it doesn’t seem to work at all. I decided to dig a bit deeper and try to figure out what it was doing. As it turns out, the sequence it correlates against seems to be completely wrong. Here’s a simple test script to demonstrate the problem: #!/usr/bin/python from gnuradio import digital from gnuradio.filter import firdes from pylab import \* preamble = [1,1,-1,-1] \* 10 taps = firdes.root\_raised\_cosine(32, 32, 1, 0.35, 11_4_32) corr\_and\_sync = digital.correlate\_and\_sync\_cc(preamble, taps, 8, 32) plot(corr\_and\_sync.symbols()) show() This produces a non-deterministic graph, but will often show wildly oscillating samples, with an amplitude as high as 1e31. Clearly something is amiss. When I extend the preamble to be 64 symbols long, everything seems to work. However, when I change the filter it uses, it breaks again. Any ideas what’s going on? - Karl ---
**Author:** ![Karl\_Koscher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a6a055/32.png) [@Karl\_Koscher](https://www.ruby-forum.com/u/Karl_Koscher)\ **Post date:** [March 29, 2015, 8:24am UTC](https://www.ruby-forum.com/t/weird-behavior-of-the-correlate-and-sync-block/234771/2 "2015-03-29T08:24:13Z")
I was seeing results with amplitudes like that as well, but I didn’t trust myself. I didn’t push hard enough to get it working. I let it go. I’m still need to get it working, for the same reason as you, but I can’t say when I will be able to put the time in. I’ll let you know what happens when I do, if no one else comments on this. Rich On Sat, Mar 28, 2015 at 6:19 PM, Karl Koscher [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Karl\_Koscher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a6a055/32.png) [@Karl\_Koscher](https://www.ruby-forum.com/u/Karl_Koscher)\ **Post date:** [March 30, 2015, 5:55pm UTC](https://www.ruby-forum.com/t/weird-behavior-of-the-correlate-and-sync-block/234771/3 "2015-03-30T17:55:56Z")
On Sun, 2015-03-29 at 12:00 -0400, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > myself. I didn’t push hard enough to get it working. I let it go. I’m still > > > estimate from a packet radio, but it doesn’t seem to work at all. I decided > > preamble = [1,1,-1,-1] \* 10 > > When I extend the preamble to be 64 symbols long, everything seems to > > work. However, when I change the filter it uses, it breaks again. > > > > Any ideas what’s going on? > > > > - Karl Karl and Rich, The short story is I know why these things happen; check the list archives if you care to learn the whys. You really want the correlate and sync block changes waiting in this pull request: > > > This branch separates out my and Andy Walls's work on modifying the correlate an…d sync block from the MSK branch on which it was based, and rebases the work on master. > > My work allows the user to modulate a candidate (preamble) vector with the modulator of their choice using the modulate\_vector block, allowing the correlate\_and\_sync block to therefore be modulation independent. I've updated the test\_corr\_and\_sync example in gr-digital/examples to show the operation of the new block. > > Andy's work fixed a lot of bugs in the block, adjusted phase\_est and time\_est calculations, Volkified the work function, and generally cleaned things up. You will be much happier with its performance, as I tried to address everything I found amiss with the block. The patches are based on top of Nick F.'s work of specifying the correlation pattern input by using the GNURadio modulators to build the target correlation waveform. If you rebuild GNURadio with these patches, you can look at the example test\_corr\_and\_sync.grc file, that is in that pull request, for guidance. Hopefully, Tom will merge this in some form in the next release or two. It is an ABI change, so it just can’t be winged in as a fix. HTH, Andy ---
**Author:** ![Karl\_Koscher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a6a055/32.png) [@Karl\_Koscher](https://www.ruby-forum.com/u/Karl_Koscher)\ **Post date:** [March 30, 2015, 7:25pm UTC](https://www.ruby-forum.com/t/weird-behavior-of-the-correlate-and-sync-block/234771/4 "2015-03-30T19:25:06Z")
On Sun, Mar 29, 2015 at 3:47 PM, Andy W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > ``` > > > > > ``` > > do, > decided > > > > is amiss. > > > The short story is I know why these things happen; check the list > > > The patches are based on top of Nick F.'s work of specifying the > > > correlation pattern input by using the GNURadio modulators to build the > > > target correlation waveform. If you rebuild GNURadio with these > > > patches, you can look at the example test\_corr\_and\_sync.grc file, that > > > is in that pull request, for guidance. > > Hopefully, Tom will merge this in some form in the next release or two. > It is an ABI change, so it just can’t be winged in as a fix. > > HTH, > Andy Yeah, I’ve looked into this and am trying to pull in as much of this work into the 3.7 API so we can get it out there and help people with these issues. It’s just one of those things that I need more time to focus just on that problem. Tom ---
**Author:** ![Karl\_Koscher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a6a055/32.png) [@Karl\_Koscher](https://www.ruby-forum.com/u/Karl_Koscher)\ **Post date:** [March 30, 2015, 8:11pm UTC](https://www.ruby-forum.com/t/weird-behavior-of-the-correlate-and-sync-block/234771/5 "2015-03-30T20:11:53Z")
Andy, I searched and found your archived discussions about this block. It certainly seems like there were a lot of issues that you (and Nick Foster) fixed. The github block you linked is in working order then? Is there an example or documentation or can you explain how the matched filter should be implemented on yours? Thanks, Rich ---
**Author:** ![Karl\_Koscher](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/a6a055/32.png) [@Karl\_Koscher](https://www.ruby-forum.com/u/Karl_Koscher)\ **Post date:** [March 31, 2015, 12:26am UTC](https://www.ruby-forum.com/t/weird-behavior-of-the-correlate-and-sync-block/234771/6 "2015-03-31T00:26:49Z")
On Mon, 2015-03-30 at 09:03 -0700, Richard B. wrote: > The github block you linked is in working order then? It works for me. But of course, per the GPL, “[…] is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE […]” 🙂 > Is there an example or documentation or can you explain how the > matched filter should be implemented on yours? “If you rebuild GNURadio with these patches, you can look at the example test\_corr\_and\_sync.grc file, that is in that pull request, for guidance.” Specifically pay attention to the ‘Modulate Vector’ block; which lets you specify a GNURadio modulator to run, a preamble to feed the modulator, and a post filter; used to build the sample sequence which is the matched filter sample sequence. The new correlate and sync block handles time reversal of the sample sequence you give to it. (Although it doesn’t if you update the matched filter sometime later while the block is running - sorry 1 bug that was not critical enough for me to fix). The ‘Modulate Vector’ block might not be in mainline GNURadio, so you’ll have to pick that up from that pull request too. You could always “manually” build the sample sequence for the matched filter in MatLab or Python and paste it into GNURadio as well. -Andy