On Tue, May 31, 2011 at 4:56 PM, Colby B. [email protected]
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)
never know… good to have extra confirmation.
So this gets into the question of how to best submit work to the
There’s some work being done now to help convey this information. I’ll
the time now to comment on what you are proposing here.
There are two main ways to best contribute code. The simplest is the
and the more complex is creating a branch on a git server somewhere that
can then pull in and merge with our code.
In this case, I would rather get the submissions done as three different
branches. The fix for the clock recovery loop could be easily done as
patch, but if we’re going all out on the other two items, it’ll just
things simpler to do it all in the same way.
The thing to do is start a github (or your-favorite-git-service-here)
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
that would be more usable if you branched from me directly. I’ll leave
up to you for now.
We tend to like to see branches solve one particular problem. So you
have three branches here: one for the MM fix, one for the gardner loop,
one for the loopfilter work. I can then merge in the branches
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
branch should be easy submissions because one is a simple internal fix
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
the work in the loopfilter branch, but if possible, make sure there is
change to the API of any blocks using it. Also, in this case, we
be changing the behavior of any of the blocks, just the code structure,
the PLL blocks should provide the same output given the same input as
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
are working on the project.
BTW, if there is a change in the API of a block, we would put that
into the next branch.