There are still lots of questions on properly using git for doing development work with GNU Radio. Jason Abele from Ettus Research sent me this link, which is a good, general guide to using Git with gEDA. gEDA is also an open source project, so some of the lessons they teach here are relevant to our community, too. I've added a link to this on our GNU Radio project site's page on using Git (http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopingWithGit).
I have recently been working on updating our digital modulation capabilities in GNU Radio. This has involved making a gr-digital namespace, moving all relevant digital modulation work over, and going through and fixing up a number of the algorithms. One issue in particular that I have been working on is the concept of the loop gains in all of our control loops. You will find in any control loop we have, like in the clock recovery, Costas loop, constellation receiver, FLL and PLL blocks, that the control loop has two gains, alpha and beta. These are used in the following ways:
freq = freq + beta * error
phase = phase + freq + alpha * error
When creating any of these blocks, we have to specify both alpha and beta. But what should these values be? What relationship do they have to each other, or, indeed, the physical properties of the control loop? Well, that's not easy to understand or explain, and because of this, it's not the right way to build these algorithms.
A better way is to convert these gains into a damping factor and loop bandwidth, which gives us a bit more intuition as to what's going on and makes them easier to set. So I have been switching over to using these concepts instead of alpha and beta. The loop equations are the same, and so we have to derive alpha and beta from these two new concepts. This is done in the following way where damp is the damping factor and bw is the loop bandwidth:
alpha = (4 * damp * bw) / (1 + 2 * damp * bw + bw * bw)
beta = (4 * bw * bw) / (1 + 2 * damp * bw + bw * bw)
So now we just have to know what damping factor and bandwidth we require from our loops. Of course, right now it seems like we've just translated from one set of unknowns to another set of unknowns. But at least we can better explain this new set. In fact, we're going to break it down so that we only specify one of those numbers.
In control systems, the damping factor specifies the oscillation of the loop, whether it's under, over, or critically damped. In a normalized system, a damping factor of 0.707 (or the sqrt(2)/2) is a critically damped system. This is a good approximation for most systems, so we can just set it and forget about it.
So now, we just have to set a loop bandwidth. This is a bit more difficult, but as a rule, this value should be somewhere around (2pi/100) to (2pi/200), so we can work around there. If we're trying to optimize the behavior of our system, it's now a hell of a lot easier to work with a single value instead of two.
Just to be complete about the whole thing, though, as I have been reworking all of these blocks, I have also been adding set and get functions for every value. So while the constructor only needs us to give it the loop bandwidth, we can also change the damping factor if there's a particular need to do so. We can also individually change alpha and beta, still, if really want to.
In the previous post on this topic, I was discussing how to set the gains of the control loop inside our various signal recovery blocks (PLLs and the like). The control loop looks like the following figure, where the alpha and beta blocks are the gains that we want to set. I then laid out a formula that describes how to derive these values from the more standard concepts of the natural loop bandwidth and damping factors. Instead of just tossing those equations out there, I thought I would provide a derivation for how we get there.
I especially want to thank fred harris for his help in the steps to go from the z-domain to the s-domain so that I could connect the dots to put alpha and beta in terms of zeta (the damping factor) and theta sub n (the natural frequency of the loop).
Control Loop Model
Other useful links
A TI paper on modeling phase-locked loops: http://www.ti.com/lit/an/slyt169/slyt169.pdf
A Nice table of Laplace and Z Transforms: http://lpsa.swarthmore.edu/LaplaceZTable/LaplaceZFuncTable.html
A explanation of the z-transform and Tustin's transformation, used in the derivation: http://en.wikipedia.org/wiki/Z-transform
After reading a few of the IEEE Signal Processing Magazine's series on "DSP Tips and Tricks" it struck me that these are very interesting, easily digestible, and useful tools that we could use in GNU Radio. If you have access to IEEE Xplore or the Signal Processing Magazine, search for "DSP Tips and Tricks" to get a list of all of the articles. They are all about 3 pages long and geared towards practical outcomes. Many of them focus on FPGA and fix-point DSP projects in particular, but they each teach some lessons that GNU Radio could potentially benefit from.
I would love to see a series of maybe junior or senior year ECE student projects to implement these (they probably aren't capstone-level projects, though). They'd be great hands-on projects with math and programming and you would be required to demonstrate it working with real signals.
There has been some talk recently about the GNU Radio project and it's development. I had made a request for people to help and contribute more, but one of our users, Martin Braun, made some excellent points. I wanted to record them here to make sure that I had them ready to be addressed. One thing that I hope to improve upon in the near future is our web page. We have a great resource in the gnuradio.org Wiki that is underutilized, and questions like Martin's could be answered by crafting good pages to describe the development process and methods for contributing.
".... let me suggest some other things to smoothen the 'community integration':
- There could be another document with the definitive guide on how to contribute. Perhaps updating the previous link would be enough. Questions answered should include:
- What kind of stuff is accepted into the core, what kind of stuff is
- better maintained as a separate CGRAN project? (Examples, refer to the mailing lists as a place to discuss this...)
- The mechanics/protocol of actually submitting
- What happens after submitting?
- Revive the bug tracker.
- Explain who's who in GNU Radio (seriously, who's actually actively developing GR besides Tom? Are there areas of responsibility? Who may submit to the master?)
- Create a list of suggestions of contributions ("You want to contribute? How about you write a foo-agulator for standard bar? How about writing the docs for block `grep -R 'FIX MY DOCS' src/lib/`?")
I've developed a bit of an interest in compressive sensing. It's a fun topic that has some potential for solving various problems. I coauthored a paper at DySPAN about using compressive sensing for white space detection (that is, finding spectrum "holes"). While not really related to GNU Radio, it certainly fits into the areas of communications that we should be thinking about in SDR.
My specific point of this post was to recommend a paper by Davenport, et al., from Rice University. This team, under Richard Baraniuk, has done some great work in the practical aspects of using compressive sensing, and this particular paper addresses the benefits and drawbacks.
It provides a good background in what compressive sensing is and goes on to analyze and discuss what you can expect from a compressive sensing receiver.