On Mon, Jan 5, 2015 at 8:00 AM, Andy Walls <[email protected]>
wrote:

> On Fri, 2015-01-02 at 09:56 -0800, Nick Foster wrote:
>
>
> > I'm in the middle of generalizing correlate_and_sync_cc to allow use
> > with any candidate vector you want (although I hadn't considered the
> > real-only case).
>
> > --n
>
> Hi Nick,
>
> Since you're reworking the correlate and sync block, I thought you might
> want to address some additional things I've found regarding the matched
> filter generation. I've noticed 1 end-user pitfall that you may want to
> document and 1 bug in how the matched filter is generated.
>
> 1. Pitfall: The pulse filter tap specification requirments are not
> obvious.  In my experimentation over the weekend, the pulse filter taps
> have to be generated assuming a rate of:
>
>         nfilts samples/symbol, or equivalently
>         (nfilts * symbol_rate) samples/second
>
> where
>
>         nfilts is the number of filters in the polyphase resampler
>         symbol_rate is the symbol rate in symbols/second
>
> regardless of the user's "sps" (samples/symbol) value.
>
> This is certainly the case for the real rectangular pulse with no ISI
> and real half-sinusoid pulse with no ISI, with which I was playing.
>
> So, if nfilts = 32, these are my proper pulse filter taps specifications
> in python:
>
>         rectangular:   [1.0]*nfilts
>         half-sinusoid: [math.sin(math.pi*float(i)/float(nfilts)) for i in
> range(nfilts)]
>
> even though my sps = 13.3333.
>
> This was very non-intuitive and should be documented for the end-user.
>
>
>
> 2. Bug:  The generated matched filter appears to be short a symbol.
> Using my real variant of correlate_and_sync, I specified the following:
>
>         symbols:           [1,0]*10 + [1,0,1,1,1,1]   (block converts
> these to NRZ)
>         pulse filter taps: [math.sin(math.pi*float(i)/float(32)) for i in
> range(32)]
>         samples/symbol:    13.3333333333
>         nfilts:            32
>
> and the block generates the matched filter in the attached PNG.  The
> missing final symbol from the start of the filter is obvious.  Since my
> block is a very closely cut-and-paste clone of
> correlate_and_sync_impl.cc and msk_correlate_impl.cc, the bug probably
> exists in them as well.
>
>
> Regards,
> Andy
>

Andy,

You're finding some stuff out here and pointing out bugs and documentation
issues. I really appreciate the bug reports on our Issues page, but this
would be a lot easier if you would also provide patches, since I'm assuming
you're doing this for yourself, anyways. Since you're actively working on
it and learning, I think you're more qualified to provide the added
documentation and these bug fixes right now. When you're done going through
this, please put together a pull request for us that addresses these issues.

Thanks!
Tom
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to