Issue with MMSE interp. filter (broken?)

GNU Radio
1

Hi All,

Recently I’ve been using the MMSE interp filter. I found that when I
shift a
signal by a fractional amount of 0 (or anything really), the signal goes
way
off! I would expect SOME difference, but not this much…

Some example output.

Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)

Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)

Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)

On the imgur links are two Re-Im scatter plots of a bpsk signal, one
with
the fractional shift of 0 and the other with a fractional shift of 0.1
The
points with ‘x’ are the resampled points and points with ‘o’ is the
original
signal. As you can see, the mmse fractional interp more or less destroys
the
signal! Unless I’m using it wrong!?

Any comments?

imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
delay.

Thanks!
Colby

2

On Tue, May 31, 2011 at 2:13 AM, Colby B. [email protected]
wrote:

Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)

imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
delay.

Thanks!
Colby

Colby,
This block has been around for years without any changes, and I and
others
have been successfully using it in various projects, so my guess is that
you
have some misconception about what it’s doing or what the parameters
are.

You can see how it’s used to simulate a timing offset in
gnuradio-core/src/lib/hier/gr_channel_model.cc where it’s used inside of
the
gr_fractional_interpolator_cc block. We also use it in the
gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.

Tom

3

On Tue, May 31, 2011 at 4:25 PM, Colby B. [email protected]
wrote:

goes way off! I would expect SOME difference, but not this much…
the fractional shift of 0 and the other with a fractional shift of 0.1 The
Colby
gr_fractional_interpolator_cc block. We also use it in the
sampling a few taps out of phase! After a time shift, it passes the sanity
check of ‘0.0’ delay. Thanks for the response!

–Colby

Excellent, glad that worked out. I was pretty sure it works, but you
never
know… good to have extra confirmation.

Tom

4

On Tue, May 31, 2011 at 5:59 AM, Tom R. [email protected]
wrote:

Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)

Colby,

Hi Tom,

I looked at the issue again and I was not taking in account the group
delay
of the interp filter (its 5 taps into the future or 3 in the past), so I
was
sampling a few taps out of phase! After a time shift, it passes the
sanity
check of ‘0.0’ delay. Thanks for the response!

–Colby

5

Related. It seems that this delay is not taking in account for the MM
clock
recovery block? It some cases, this delay will not matter (2 or 4
samples
per symbol), but for other rates it will.

–Colby

6

On Tue, May 31, 2011 at 1:46 PM, Tom R. [email protected]
wrote:

That’s an excellent point. Any chance for a patch? :slight_smile:

The points with ‘x’ are the resampled points and points with ‘o’ is the

gr_fractional_interpolator_cc block. We also use it in the
I was sampling a few taps out of phase! After a time shift, it passes the

Sure thing, perhaps later this week? I can submit all my patches at once
(this fix, gardner algorithm, multi-order loopfilter).

–Colby

7

On Tue, May 31, 2011 at 4:37 PM, Colby B. [email protected]
wrote:

Related. It seems that this delay is not taking in account for the MM clock
recovery block? It some cases, this delay will not matter (2 or 4 samples
per symbol), but for other rates it will.

–Colby

That’s an excellent point. Any chance for a patch? :slight_smile:

Tom

8

On Tue, May 31, 2011 at 4:56 PM, Colby B. [email protected]
wrote:

–Colby
On Tue, May 31, 2011 at 1:29 PM, Tom R. [email protected]wrote:

Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)
0.1 delay.
parameters are.
Hi Tom,
never know… good to have extra confirmation.

–Colby

Excellent, thanks!

So this gets into the question of how to best submit work to the
project.
There’s some work being done now to help convey this information. I’ll
take
the time now to comment on what you are proposing here.

There are two main ways to best contribute code. The simplest is the
patch
and the more complex is creating a branch on a git server somewhere that
I
can then pull in and merge with our code.

In this case, I would rather get the submissions done as three different
git
branches. The fix for the clock recovery loop could be easily done as
a
patch, but if we’re going all out on the other two items, it’ll just
make
things simpler to do it all in the same way.

The thing to do is start a github (or your-favorite-git-service-here)
repo
that is based on either my branch on github or the git master on
gnuradio.org. The one from gnuradio.org will of course always be more
up-to-date, but it sounds like there are nice visualization tools on
github
that would be more usable if you branched from me directly. I’ll leave
that
up to you for now.

We tend to like to see branches solve one particular problem. So you
would
have three branches here: one for the MM fix, one for the gardner loop,
and
one for the loopfilter work. I can then merge in the branches
individually.
This will help keep me organized, and each branch can be independently
audited and tested.

Just a note on the form of the branches, too. The MM fix and Gardner
loop
branch should be easy submissions because one is a simple internal fix
and
the other is a new block. This easily fits into the current API of the
blocks and doesn’t break anything. I’m not sure how you plan on
implementing
the work in the loopfilter branch, but if possible, make sure there is
no
change to the API of any blocks using it. Also, in this case, we
shouldn’t
be changing the behavior of any of the blocks, just the code structure,
so
the PLL blocks should provide the same output given the same input as
ever.
We have QA code for each of the three PLL blocks
in gnuradio-core/src/python/gnuradio/gr, so they should still pass after
these changes are made.

I hope that gives people some insight into how we think about things as
we
are working on the project.

BTW, if there is a change in the API of a block, we would put that
change
into the next branch.

Thanks!
Tom