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 <[email protected]> wrote: > On Sun, Mar 29, 2015 at 3:47 PM, Andy Walls <[email protected]> > wrote: > >> On Sun, 2015-03-29 at 12:00 -0400, [email protected] >> wrote: >> >> >> > From: Richard Bell <[email protected]> >> > To: Karl Koscher <[email protected]> >> > Cc: "[email protected]" <[email protected]> >> > Subject: Re: [Discuss-gnuradio] Weird behavior of the >> > correlate_and_sync block >> > Message-ID: >> > <CAMMoi3u0OVyALDYQezdFLPxn_UwkyW2zf-2XAuJV+MOPOOv= >> [email protected]> >> > 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 < >> [email protected]> >> > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
