Re: [Discuss-gnuradio] Weird behavior of the correlate_and_sync block

[Richard Bell]

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

On Sun, Mar 29, 2015 at 5:18 PM, Tom Rondeau <address@hidden> wrote:

On Sun, Mar 29, 2015 at 3:47 PM, Andy Walls <address@hidden> wrote:

On Sun, 2015-03-29 at 12:00 -0400, address@hidden
wrote:


> From: Richard Bell <address@hidden>
> To: Karl Koscher <address@hidden>
> Cc: "address@hidden" <address@hidden>
> Subject: Re: [Discuss-gnuradio] Weird behavior of the
>       correlate_and_sync      block
> Message-ID:
>       <CAMMoi3u0OVyALDYQezdFLPxn_UwkyW2zf-2XAuJV+MOPOOv=address@hidden>
> Content-Type: text/plain; charset="utf-8"

>
> 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 <address@hidden>
> wrote:
>
> > 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

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:

https://github.com/gnuradio/gnuradio/pull/376

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 Foster'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

 

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio