[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Correlate and sync matched filter: pitfall and an

From: Nick Foster
Subject: Re: [Discuss-gnuradio] Correlate and sync matched filter: pitfall and another bug (Re: Question on threshold mathematics in correlate_and_sync block)
Date: Mon, 5 Jan 2015 09:09:34 -0800

On Mon, Jan 5, 2015 at 5:00 AM, Andy Walls <address@hidden> 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.

Great! Thanks!

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


        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.

Yeah, this annoyed me, too. The new system actually takes in unmodulated symbols, modulates them with the modulator of your choice, and then applies the (non-polyphase) filter taps of your choice to the modulated symbols. This way, you can pass the same symbols into (for instance) a GMSK modulator with the shaping filter taps set to [1] since GMSK typically needs no additional post-modulation filter, a PSK modulator with RRC taps for the channel, etc. The correlate_and_sync block in my branch doesn't take in symbols, but bits, and lets a modulator block (passed into it as an argument) handle the modulating. I'm avoiding the polyphase filter because I don't have to do resampling in the correlate_and_sync block. The caveats are:

1) Every digital modulator in GNURadio seems to use its own input data format -- packed or unpacked bits, signed vs. unsigned, NRZ or straight binary, etc. Your input vector has to be constructed to match the format the modulator expects.
2) Many of the modulators don't support fractional samples per symbol. There are of course workarounds, but I consider this a bug.

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.

Pretty sure my changes have obviated this bug but I'll check it out.

My branch has bugs right now (mostly in tag alignment) but you can see it at https://github.com/bistromath/gnuradio/tree/msk_from_master. Suggestions and improvements of course welcome. Seems to me that we should collaborate on this, using my branch as a starting point. Still need to redo the test case and example, too. Attached is a working example showing the misalignment. Probably something simple but I was pulled away from working on it this weekend.



Attachment: test_modulators.grc
Description: application/gnuradio-grc

reply via email to

[Prev in Thread] Current Thread [Next in Thread]