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 > > _______________________________________________ > 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
