Version Woes

We've been doing our best to ignore these issues and keep pressing on, but I fear we're getting closer and closer to having issues with some of our dependencies. Versioning is, sadly, a serious issue with software packaging. It's why our jump from 3.6 to 3.7 was so important, and it's why I've been pushing the use of our GnuradioConfig.cmake [Link too OOT tutorial] file to tie out-of-tree projects to API-compatible versions. But we have a lot of dependencies, any many of these are innovating just like we are. We try to make sure we keep a) compatible with older versions and b) use versions and packages that are easily obtainable on most OSes (like they should be apt-get-able in Debian/Ubuntu).

Minor Dependency Versions

There are a few dependencies that we have particular issues with. Boost is one, but we're keeping an eye on that since it's so integral to the project. You might have seen our ENABLE_BAD_BOOST since we keep a table of versions of Boost that have specific bugs such that we, by default, don't allow you to build GNU Radio off them.

A currently problematic dependency is PyQwt. We really like Qt and Qwt (once we figured out some build problems with it), and we like the ability we have of building our own widgets off of Qwt. We also like the idea of PyQwt because it gives us building blocks for interesting application control in Python. But, we have a problem. Qwt is moving on and doing good things, but PyQwt isn't. Emphatically so, in fact. They announced that they will not support Qwt 6 and are apparently in the works of creating their own version of Qwt completely in Python. Which sounds fine, but where is it? And will it be an easy replacement for what we've already done? And in the meantime, how hard would it have been to update to Qwt 6 while they were making this transition?

For now, we all want to use Qwt 6. Case in point, if you look closely, you can't even run the new time raster plots using Qwt 5.2. It's far too much of a CPU hog and just grinds to a halt. Qwt 6, however, runs fine. In all ways, Qwt 6 works better. And the API changes they've made all make sense: they are cleaner interfaces and more consistent with the use of pointers than before.

And yet, PyQwt 5.2 actually works fine with Qwt 6 installed, at least given the scope of what we want to do with PyQwt in GNU Radio. So that's interesting, but I'm always conscious that this is probably not going to be a long-lived solution. In fact, I've already seen issues with our code and Qwt 6.1, something that just today I worked on and should be pushing and update for GNU Radio soon. Even though Qwt 6.1 still works with the older PyQwt, I'm always wondering when these two projects will diverge far enough that we can't use them together?

The end thought here is that I would love to get rid of our use of PyQwt, but there doesn't appear to be an easy alternative right now. But I would greatly appreciate any pointers in this case.

And then we have ICE. ICE is the middleware library we use behind ControlPort. We initially wrote ControlPort against ICE 3.4.2, but they've released their 3.5 code. Luckily, it seems that ICE 3.5.0 and 3.5.1 work smoothly with our use of ICE. It's the preferred version to use, in fact. First, might as well stay up-to-date, but also, because GCC 4.7 actually doesn't compile an unpatched ICE 3.4.2 (you'll see upCast errors when compiling if you try). So when using GCC 4.7 or higher, we have to use ICE 3.5. The problem, however, is that most of our main OSes that we use still only ship ICE 3.4.2. So just using apt-get to use the latest version of GCC and the version of ICE they ship doesn't work together to build ControlPort. Which is very annoying. Instead, you either have to down-grade GCC or manually build and install ICE.

So these are some of the current issues that we have. And with the plethora of OSes we support out there with different configurations and supported versions of these, it can often be hard to protect against these issues early on.

Future Major Versions

In the not-too-distant future, we are also going to be concerned with Python 3 and Qt5. These look like they are going to require pretty big changes, possibly to the point that we have to break backwards compatibility with Python 2 and Qt4 to make it work well. Supporting multiple versions often requires #ifdefs in the code and to make sure that we test all supported versions this way when adding or changing any code. This is currently how we support Qwt 5 and 6, but I'm concerned that Qt will be too large a change and too invasive a procedure to keep both versions working properly. Python 3 has similar issues.

So sometime soon, I'll have to sit down and understand how much it's going to take to update to these new versions and how invasive changing to support them is going to be. It might turn out that we'll just have to make a clean cut in version 3.8 or 3.9 of GNU Radio. We'll see.



In Response to Ben Hilburn

I really enjoyed Ben Hilburn's blog post from the other day. He has a good handle on the field and community, and I particularly liked his constructive criticisms (while I'm used to just criticisms). I wanted to respond to a lot of what he said to make sure that a) it's clear where I'm coming from on many of these issues and b) this is a good conversation to have and continue.

I'm suspicious about the desire for a paradigm shift. I often feel like trying to force that is a mistake and that it will happen when someone comes along with the right new idea. It's kind of like Intel claiming that they embrace disruptive technology and are working to properly direct how they can use it. If you are directing and controlling disruptive technology, I believe you've just landed yourself into a paradox.

As Ben said, he doesn't have the new idea or the new paradigm he'd like to see happen. I'm not entirely convinced that we need a big shift. I'm more excited right now about the idea for new tools that people are talking about and working on (specifically, all of the updates for GRC that were started at the Hackfest). But perhaps I'm so mired in the details of the project right now that I'm missing something in the bigger picture. Yep, I'm completely willing to admit that because there's still so much left that I want to do and so many projects and successes I can see from where we currently are.

Test, Measurement and Display Sinks

I generally agree with most of what Ben is saying here, and it's a large part of why I've been developing QTGUI and trying to push its use. It already addresses many of Ben's issues. I also think it looks better than the WxGUI stuff does, though I admit that it still needs a lot of work there.

I'm somewhat skeptical of trying to go too far in the direction of eye-candy. I agree that aesthetics are important, but they can get too flashy and start to obscure the real point of the plots. Take for instance the Rohde & Schwarz spectrum analyzer picture on Ben's post. What the hell does that even mean? I think they've actually gone overboard with the flash.

The other reason I'm skeptical of this idea is the amount of specialized work required. I'm a huge fan of Sylvain's gr-fosphor efforts, but we couldn't even try it on my laptop because my Sandybridge processor wouldn't support the OpenGL/OpenCL integration work he's done for performance reasons. Rendering these kinds of graphics is intensive and really needs to make use of GPUs, but the tools for generalizing this aren't really there. Just look at the mailing list archives on all the problems that are solved by turning OpenGL off to get a taste.

Still, there's a lot we can do, and I've talked to Balint about some of his work, which is in WxGUI that I would like to see added to QTGUI, instead. Specifically the measurement capabilities. Right now, the QTGUI FFT plots allow you to view the minimum and maximum, but there's very little control over it (like a reset button). Persistence would also be handy, especially in something like the constellation plots to see convergence over time.

Developer Organization

Ben really nailed this one. His idea of integrating the GNU Radio Working Groups (GRWGs) as first-class citizens was, basically, exactly the point. I mentioned this in my previous blog post that the areas identified for the GRWGs are problems that cannot be solved easily or by just one or two developers. We need sustained effort and ideas coming in to identify and execute the “right” solutions.

I'm looking to get a representative or the GRWG leader to report on progress during each monthly Developers' Call we hold (third Thursday of the month). We want to have continuous engagement with the working groups to keep up the momentum and enthusiasm.

Documentation and Theory

I know it's still a problem, but if you go back and look, we've come a long way in the documentation over the past two years. I've tried to provide good documentation for blocks that I'm working on, we're posting the manual's for every version release as well as the output of the weekly developer's builds, one of the GSoC projects integrates the documentation into GRC blocks, and in our efforts for 3.7 we tried to make sure at least the fundamentals for the block's constructor arguments were documented.

Still lots to be done, though. The theory aspect Ben brings up is important and useful, too. Again, I've tried to do this myself, like if you look at the manual pages for the polyphase filterbank blocks. I also try to point to papers and text books that are relevant. But I'm just one developer, and sometimes my efforts while good intentioned don't come out as useful to the end user as I'd like.

The idea of trying to write the theory into the code also helps with what I think is a mandate of open source code (and I might be alone on this). I really believe that one of the things we are doing with GNU Radio is breaking open the black box of communications. While experimentation was a huge part of the beginnings of radio with amateurs radio even being developed as part of the war efforts to make sure the US citizens were well equipped to communicate and organize in case of an attack or disaster. But the past few decades have been more oriented towards standards blocked off in ASICs and RFICs. GNU Radio is one way to break that down and demystify aspects of radio and communication theory. As I said at the conference, learning to transmit and receive BPSK isn't exciting anymore, so why do we keep redeveloping it when we should be pushing into new areas of research and development? Adding the theory into the code to explain what might otherwise be dense or obscure math (for the sake of compilation or runtime efficiency) should be a part of how we code. I'm definitely resolved to to better here.

But here's the problem that I've run into with users submitting documentation. They don't. I agree with Ben that this is an easy win for people to get involved and start contributing. Over the past year, I've had something like eight to ten users tell me that they are working on documentation and would like to contribute it back. I enthusiastically reply back with a “YES PLEASE!” and we start on the road down making them a contributor. And then they disappear.

I'm liking Ben's suggestion to not accept new code without proper documentation. We've not wanted to scare off potential contributors by forcing this, but it's probably time to do it. Ben helped convince me in his post by talking about “high-impact developers,” and he's right. Those are the types of people that recognize the need for comments and documentation and shouldn't be turned off by having it as a requirement.

Other issues

Ben's list of issues are all good ones to tackle. My only significant input here is this: don't run Valgrind against GNU Radio. Or if you do, be prepared for a lot of false positives because of the Python bindings. The rest of his thoughts are good ideas for where to go. We've started with a lot of these and need more people to work and focus on them. For instance, we started working on a gr-liquiddsp project at June's hackfest and the code is posted on github. I point that out to make sure anyone interested in that has a starting place and doesn't duplicate effort.


Thoughts on GRCon13

Overall Impression of the Conference

GRCon13 could almost not have gone better. There were some minor issues with the setup and location, but there always will be. Once the conference started, though, we hit pretty much all the notes I wanted it to this year.

My first impression about the room was the energy. From the start of the first breakfast, every session and almost no dead time. The audience was attentive, they asked questions, and we had a continuous side-channel discussion on IRC pretty much throughout the entire conference. Every break and lunch period was full of discussions and people exchanging ideas to the point where I felt bad wrapping things up to get back on the conference schedule. Even then, it was often difficult to get everyone seated and quiet again. Many of us took these conversations and others out to food and drink at night. I don't think there was a night that I got back to my hotel before midnight. Really, during the entire conference I barely got five minutes to myself and it seemed about as much sleep. But it was all worth it.

I've told anyone who's asked and I made reference to it in my opening talk on Tuesday why we selected the venue (Space with a Soul) that we did. The SwaS wasn't particularly the right venue for a technical conference like this: the Internet was stable but not particularly fast; the tables came in pretty poor condition without any coverings (and John Malsbury did some quick last-minute thinking to fix that); there were not enough power strips to serve all attendees (so we bought and distributed them). And there were two big problems faced during the entire week. First there were pillars in the middle of the room that made seating in places difficult. Second, the HVAC system was loud but necessary during the entire week. So we have number of things on the wish-list for next-years venue.

Still, even with these issues, the room felt so different from last year. Possibly it was just the growth and development of the community over the past year. Maybe it is partially due to the fact that I had John Malsbury and Johnathan Corgan helping out and I wasn't exhausted from over-work like last year. But I think it quite possibly had to do with the environment. The hotel in Atlanta was isolated and drab. The isolated part was a problem, but the drab part was pretty much what I expect from a conference hotel. It's always the same beiges and browns with no windows and a slightly too-sterile environment. This year's room, though, had a completely different atmosphere and made fore a far more energetic conference.


Juha Vierinen speaking on his remote sensing radar workTwo areas that I think proved how excited the conference attendees were this year were the discussion groups and the Friday hackfest. From my perspective as project leader and conference co-organizer, the main thing that I took away from this and why I was so impressed with everyone was how self-organized they were. We did a, purposefully, very minimal amount of prep work for both sessions. For the discussion groups, we set up four topics and identified a leader for each. For the hackfest, we started a list of items people would be addressing and the contacts for each project. Everyone took these basic cues and did what they needed to. Everyone participated, almost too much since it was difficult to get them to stop! It's exactly what we wanted, and also difficult to trust that it will. To me it reinforces the interest and enthusiasm for this project and the community.

Discussion Session

Looking forward with GNU Radio, I'm probably most excited about the working group discussion session we had at the conference. We set up four projects initially that we felt are some of the big problems we are facing and trying to address in GNU Radio. These are not things that are going to be solved immediately or simply by a single person. The problems include how to incorporate and use co-processors (GPUs, DSPs, FPGAs, etc.), how to better enable GNU Radio on embedded systems, where we can extend and develop VOLK, and what to do to improve the GNU Radio user experience. The user experience group was so full of both participants and members that they went ahead and split into two teams to address the original question of users and a separate topic on how to improve GRC.

The working groups worked so well that instead of giving an hour for discussion and half-hour for wrap-up reporting to the rest of the attendees, we let the discussions continue for 2 hours and kept the wrap-up to 20 minutes. The working groups are working on putting their notes and ideas online [Link to website] over the next little while to keep a record of what kinds of things people thought of and the main items to come from the discussions.

As the project leader, I think that these working sessions are going to prove invaluable. The ideas themselves are a fantastic place to start, but one of the main reasons for these sessions was continue to build and integrate the community of developers. The problems and the suggested actions are bigger than the development team can address in short time, but having the input and continuing involvement of those in the working group will allow us to address them better and faster. These groups now make up the current areas of interest to GNU Radio. During our monthly developers calls, I'm asking that participants of each group, if not the group leaders, will be able to report on progress and developments in their topic.

I am really looking forward to continuing to investigate these problem areas and interface with the community to better solve them. We in the core development team don't always know what we are specifically missing, and we all know that no single person can do it all. Ideas, developments, and the code itself needs input from the community to be successful.

Matt, Johnathan, Martin, and me answer audience questions


Another conference success. I was impressed by both the number of people that stuck around to work and how self-organized everyone was. A hackfest isn't necessarily a concept everyone gets. There is very little organization, and everyone is expected to find their own way. But realizing that too much freedom can actually stifle innovation, we try to identify specific projects or goals and the person or persons responsible for that. That at least gives some of the newcomers, who might be at a loss for project ideas, a better handle on what things they can address. I thought that I might have to help coordinate efforts and give people the general picture, but by the time I was ready that morning, everyone had already settled down and started working.

I'm not going to go over everything that happened, but I'll point to the wiki page for the hackfest [LINLK]. There was some great work accomplished on bug squashing, improving GRC, embedded system development, and digital modems. 

I'm tremendously excited about where the project can go from here.


Hilbert Transform and Windowing

We recently fixed a bug in GNU Radio where the rectangular window actually didn't work. It would fall through to the Hamming window because of a missing 'break' statement. Embarrassing bug, but not all that detrimental since the rectangular window is so rarely used.

The one place it was being used was in the Hilbert transform block. We can build Hilbert transform filters using the filter.firdes.hilbert function. In this way, we've been able to set the window type to anything we'd like (Hamming, Hann, Blackman, etc.). But with the Hilbert transform block (that is, filter.hilbert_fc), we could only ever specify the number of taps to use in the transform and the window would default to a rectangular window -- except, as noted above, it would actually default to the Hamming window.

So we decided to add another argument when creating a Hilbert transform block that allows us to set whatever window we wanted and not force a decision on the users. To keep the API sane, though, I wanted to make sure there was a good default for this, which brought up the question: what is the right default window for a Hilbert transform?

That question depends a bit on who you ask. Johnathan Corgan mostly uses the Hilbert as a way to suppress sidebands while I tend to use it to convert real signals to analytic signals. These have slightly different properties, and the window used can help determine this (a few dB here and there). And while we have a decent understanding of these effects, I didn't really have a gut feel for which window was the right for any given course of action. So I played with it.

I created a GNU Radio flowgraph that runs a noisy (real) sine wave through Hilbert transforms with different windows and plotted the resulting PSD on the same graph. The first image you see below is the full two-sided spectrum. You can easily see how each of the windows has different attenuation in the negative frequencies. If we're trying to make an analytic signal, we want to remove as much of the negative frequency as possible to make the signal's real and imaginary parts as near orthogonal as we can. Looks like the Blackman-harris window is the best for this.

 But for sideband suppression, we want to minimize signals near 0 Hz as much and as quickly as possible. Below are two zoomed-in looks at this graph. The first is right around 0 Hz and the second is offset a little so we can see the negative image of the 1 kHz sine wave.

From these images, the Hamming window produces the fastest overall roll-off, even if it doesn't get quite as low as the Blackman-harris window does for full negative frequency rejection. On the other hand, the Hann window looks like it's the best compromise solution.

I find these plots to be generally helpful in giving me a basic understanding for what I'm trading off with the different windows, and so I wanted to provide them here, too.

As for the right default? Well, we have always been using the Hamming window, and it provides the best sideband suppression results. So we're going to stick with it as the default window so we don't change the behavior of existing GNU Radio projects that use the Hilbert transform block. The upside is that now we can select the right window for our needs if the default isn't suitable.


DySPAN 2014 Announcements

I'm really pleased to once again be serving on the Technical Program Committee for the upcoming IEEE DySPAN conference. They have announced the call for papers, due Nov. 1, and are starting to get the program up and going. 

Now, if you've talked to me about DySPAN as a conference, I've been somewhat critical of it in the recent years. Partly, it seems to have lost a bit of relevancy as the regulators have dictated how DSA was going to happen. For a couple of years, this suppressed a lot of innovative though in the conference. I recall that it was either in Singapore or Aachen when any spectrum sensing paper was immediately attacked for being irrelevant because the regulators were going database-driven. To me that felt like it lacked real foresight and creativity.

At the same time, I was also getting upset with the quality of the papers that I was seeing on spectrum sensing. My favorite way to describe the problem is that if you threw in the all sensing papers since the original DySPAN into a pile and pulled one at random, you wouldn't be able to tell which year it was published. Now, this probably isn't actually true, but having been involved with the community since the first DySPAN in 2005, I've seen that it's more true than not. I think the main reason for this problem is that we aren't setting up our work in a way that promotes the scientific process, and so each paper sets itself up as a new, or "novel" as the papers always say, way of doing spectrum sensing. We aren't doing much in the way of comparing techniques, building off other good ideas, or even finding fault in other approaches. It's all about the new novel approach that I would simply title a YASST: yet another spectrum sensing technique.

My other major criticism of the conference is that we haven't quite successfully integrated the policy and technical people like the conference was supposed to. The DySPAN problem is much, much bigger than technical problems, and so the conference was established to address all (or at least many) of the challenge areas. Part of that idea is to allow multiple sides to understand each other and build collaborative, multi-disciplinary approaches (and by multi-disciplinary, I don't mean an engineer working with a mathematician). Instead, I've felt like, save some very specific people that I can think of (and they mostly come out of Dublin), both sides just live in silos with very little mixing.

But, we have a new DySPAN coming up, and I've just read the briefing on the call for papers, posters, demos, and tutorials. The committee has put together the workings of an innovation-driven program. A lot of this I attribute to the very strong team they have put together who are interested and knowledgeable about both the research space and the current technology capabilities and trends. And yes, admittedly, a few of them are good friends, so. But specifically, a lot of these are among those (non-Dubliners, actually) that have an understanding and appreciation for the social, political, and economics of DSA aside from just the technical. So given what I'm seeing, I think we're going to see a really interesting conference with a lot of strong ideas.

Now, having said all of this, I admit to having been part of the problem of the culture of DySPAN in the past. While reviewing papers on the TPC, I've tried to do my part to help foster as strong a program of papers that I could. But on the other hand, when I've attended the conferences, I, like most engineers, went in and only saw the technical presentations with maybe one or two presentations from the policy track. I expect that I'll be going to this DySPAN, and my goal this time will be to focus on those policy tracks and learn as much about that area as possible.