Weird behavior of the correlate_and_sync block

GNU Radio
1

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, 11432)
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
2

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
[email protected]

3

On Sun, 2015-03-29 at 12:00 -0400, [email protected]
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:

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

4

On Sun, Mar 29, 2015 at 3:47 PM, Andy W.
[email protected]
wrote:

  <CAMMoi3u0OVyALDYQezdFLPxn_UwkyW2zf-2XAuJV+MOPOOv=

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

5

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

6

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 […]”

:slight_smile:

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