Home

GNU Radio for Android

I have been slowly pushing out information here and there on my work on Android. I've been able to show it off at various conferences and workshops that I've attended over the past few months. It gets a lot of very positive feedback, and we know there are many, many exciting things we as a community of developers and wireless experts can do with this kind of a system.

It's time to start really pushing this project. I spent so much time getting things to work under the hood that I've completely lost track of any of the cool applications that I wanted to work on with it! But the more people that get access to this and know how to work with it, the more interesting the application space and possibilities will become. Because of that, I had been waiting for two things to finish before writing this post. First, I wanted to be able to use a bus-powered Ettus Research USRP with and Android device. And second, I wanted the process documented from the start of building the dependencies to the end of a working (if overly simple) app. Both of those are done.

To help get things started, I've created an Android support page on the gnuradio.org wiki:

  • http://gnuradio.org/redmine/projects/gnuradio/wiki/Android

This page is designed to walk a developer through all of the stages from building the dependencies to GNU Radio itself, GRAnd, UHD, RTL-SDR, and gr-omsosdr. This should be pretty much copy-and-paste to get everything built and ready. The final part was finished just today: a walk-through for how to build a basic Android application that launches a GNU Radio flowgraph. This is done using Android Studio, which is the latest development environment for building Android apps. The project can be downloaded from it's Github page to provide a template to set up your own project and verify a working installation:

  • https://github.com/trondeau/GrTemplate

Hopefully, we will continue to evolve the process to make setup and building apps easier in the future. The next step is walking through and providing the annoying boilerplate stuff for hardware access so you can start using USRPs and RTL-SDRs with your devices. But for right now, I want to make sure people who are excited about this stuff have a way to get in and start playing.

List of what we support on Android

So where do we stand with our GNU Radio support on Android?

  • GNU Radio components:
    • Runtime, VOLK, Blocks, FFT, Filter, Analog, Digital, UHD
    • ControlPort
  • Extras
    • gr-osmosdr including RTL-SDR and UHD support
      • HackRF support should be trivial but not done, yet
    • gr-grand: GRAnd (GNU Radio for Android) to support Android-specific I/O and capabilities such as:
      • audio input and output
      • shared buffers between app and flowgraph
      • sensors (e.g., accelerometer and luminosity)
  • Tested hardware
    • RTL-SDRs
    • USRP B200 and B210 (the latter required external power on a Nexus 7)
  • Android Version
    • Android Lollipop 5.0 or greater. Tested on 5.1.1
      • some complex support in previous versions is lacking in the ndk; we think we can get around it, just not out-of-the-box.

Latest GR Hackfest

We held our latest GNU Radio Hackfest at Ettus Research last week, and it was one of our most successful yet. It was also our largest gathering of one of these week-long events with something like 25 people at the most (plus or minus since a few were Ettus employees so had to come and go as they could). We had a huge amount of code worked on during the week with contributions from all over the field to make the project better. We fixed a number of bugs and issues that we've been meaning to deal with for a while, and we saw a good amount of other advances to the project happen. We haven't updated the hackfest wiki page yet with our projects, but you can certainly look forward to a lot of the results and features in the next release next week.

Updates and updates and updates

This blog has been rather silent lately, but that's not because there's not enough to talk about in the GNU Radio world. In fact, there's simply been too much! We've been too busy with events, adding new features, improving old features, and adding new website info that I keep forgetting to update here.

First, you can see for yourself the things that have been going on with the GNU Radio Project at the Events page. We just had hackfest at TU Delft that went quite well followed by another successful SDR Dev Room at FOSDEM. A Couple of the videos for that event are already online.

Meanwhile, coming up, we have:

And fred harris and I are teaching another SDR class with the UCLA Extension program.

We have also announced our plans for the 3.7.7 release of GNU Radio, which will now include VOLK as a separate library.

And the GNU Radio community has been working hard on improving our websites. We are near to a release of our new CGRAN website, which now ties in nicely with PyBOMBS and will help us keep up-to-date with everything better. And we are working on a new front page for gnuradio.org. You know how you've hated being dumped into that Redmine wiki page? Well, that will still hang around as the developer's portal, but we want our main page to be more user friendly and to address the GNU Radio project as a whole, including GRCon and other events and where to find users and use cases of GNU Radio.

Along with all of this, we've been working on a number of features. I'll spend more time on each of these later, but wanted to get the word out there.

  • Support for GNU Radio applications on Android. I'm calling this an alpha release since there's still lots to do to make things work smoothly here.
  • Reviving ControlPort functionality by using the Apache Thrift project. We're close to having this merged into master, but the branch is up on my github page.
  • Providing improved packet-based and burst digital signals. Again, a work-in-progress with the branch up on my github page.
  • Adding sample rate and timing info on a per-item basis in a flowgraph. This will allow a block to ask for the exact time stamp of any item, and it provides a global understanding of the sample rate of each block. The code on my public branch works, but I have a better idea how to handle things when sample rates change during runtime.
  • Improving our QA testing and continuous integration services. I've been rolling out a Jenkins server in my office (for now) that manages a handful of different nodes for different purposes. I have a box with the minimum dependencies we require for GNU Radio to make sure we're not moving past them as well as testing on various other things like OS X and 64/32-bit installs. And I even have a system testing our embedded SDK cross-compiler with on-board testing of the QA to see what breaks there. This will help ease my mind of missing something or overlooking some problems. I'll get weekly reports but can also kick off these tests whenever we need to get a state of the project.

think that wraps up the main points of the project that we're working on. I'll update again with details of some of these projects when they've rolled out more fully, especially on the Android, ControlPort, the website, and GRCon items.

European Hackfest hosted by TU Delft

If you follow GNU Radio at all, I'm sure you've heard about our Hackfests. This is where a lot of GNU Radio developers get together for a few days to a week at a time and hack out GNU Radio code. We've found these fantastic ways to improve the project as it gives us time to plan, discuss specific topics, hang out and get to know each other, and code code code! A large amount of the code making up GNU Radio has either come directly from or been inspired by these events.

Mostly, we've done these in the US. Ettus Research has been a fantastic host to a number of our hackfests as has Virginia Tech. Just recently, Karlsruhe Institute of Technology hosted a mini hackfest right after the WSR and a full hackfest a few months later. These were our first events held in Europe, and though I personally missed the second one, the post-WSR hackfest was great fun and hugely successful.

Following up on this, I wanted to announce and give a pre-emptive thanks to TU Delft in the Netherlands who has agreed to host a hackfest early next year! The plan is to hold the hackfest on TU Delft campus during the last week of January so that we can go straight from Delft to Brussels for FOSDEM that weekend (partly assuming that we have an SDR dev room at FOSDEM again this year). I think having these two events back-to-back is, pardon the Irish, going to be great craic. 

Want to come to the hackfest? We certainly don't want to discourage anyone, but I also want to point out that the hackfests are usually smallish affairs of 10 to 20 developers, usually people heavily involved in either writing or using GNU Radio regularly. So the facilities are on the small side to fit us, and you're on your own for housing, food, transportation, etc. But, if this is something that excites you and you can make it to Delft, please let me know if you'd like to come. Just shoot me an email. And if you don't know my email address, then you probably haven't been using GNU Radio that much :p

Release of 3.7.4

Well, I mentioned it here a few weeks ago and last week we did it. GNU Radio version 3.7.4 is now out and about. We're really happy with the release for a number of reasons. If you take a look at the release notes, you can see not only a lot of new features we've added on, but also the huge number of contributors. So not only are we feeling really good about the project itself, we have a great community of users that are doing really neat things and helping us improve our code. So a huge hand and big thanks to everyone!

I think that the release notes give you the basic idea of what's going on in this version, including ZeroMQ blocks for improved connections between networked flowgraphs over the UDP or TCP sources/sink, better QTGUI handling, and some nice improvements to the GRC interface. Also, as I mentioned in my last post, we now have our new FEC API concept included in gr-fec. Oh, and on that last note, we're very close to having some of the LDPC work done during last summer's GSoC integrated with the FEC API so we can all start to use it in our flowgraphs!

The good work is never done, though. We still have so much we can and want to do in this project, and so we've already started laying out some ideas and plans for release 3.7.5. There's some really fun work going on in GRC that I think everyone's going to love, and we're going to be one step closer to defaulting everything to QTGUI (don't worry! WXGUI will have a long lifetime as we migrate over!). We haven't made the full decision, yet, whether to switch the GRC defaults to QTGUI in this next release of wait until 3.7.6. I think we'll make that decision about midway through this release cycle to make sure we have enough time at get the development branch settled on that before the release.

Now, no guarantees, but I'm hoping we can get 3.7.5 out in time for GRCon14. That's a bit shorter than our normal time period between versions, but then again, we took a bit of extra time before 3.7.4. I think that it'd be nice going into the conference with a brand new version, plus a lot of features like some of the QTGUI and GRC updates are already done. We'll see what things look like by the end of August if it really makes sense to get 3.7.5 out the door by the conference.

Finally, I've said it elsewhere, and probably on other posts on this blog, but just a quick mention of 3.8. We have started collecting some ideas on what we're looking for with 3.8, but we haven't made any substantial efforts on it, yet. We're going to stick with 3.7 for a while longer because we feel like we're able to get a lot of work done with this API version without having to move on. In 3.8 we plan on updating our dependency list so we can be a little more free with features from our dependency libraries, and it'll help us fix a few holes we have in the runtime API that's causing some bugs that we've been tracking. But there's nothing really pushing us to a new API, yet, unlike our previous few API releases where we had some big changes. Instead, all of our big changes are all coming in our "minor" releases. But the only thing minor about it is our version naming scheme!

Update and 3.7.4

It's been a while since I've provided an update. Lots of travel, both work and otherwise, has kept me from letting everyone know what's been going on in GNU Radio. So let me see if I can start to fix that.

I think that our most interesting and fun development was the success of the ISEE-3 reboot team, including our own Balint Seeber (ok, so he's technically with Ettus, but for all of his work with GNU Radio, I'll claim him; at least partially) and John Malsbury. This was an incredibly cool and successful project, and Balint, John, and the rest of the reboot team have done and continue to do an amazing job. I'm not going to try and poorly rehash the work here. But there's been plenty of articles written on the effort and the links provided above here will give you a much better review of what happened and how.

In other news, we're close to releasing GNU Radio 3.7.4. I was really happy with our 3.7.3 release a few months ago, and this next release continues to strengthen the project. We have a lot more support and have debugged a few issues with the message passing infrastructure. I see the use of the message passing system as a growing trend in GNU Radio, especially for control and updating parameters of blocks.

Another development is a massive update and improvement to gr-atsc. While the original work here was great, it was based on GNU Radio ideas and capabilities from probably 10 years ago or so. Andrew Davis and Johnathan Corgan have done a wonderful job bringing this up to date and improving its speed and stability. This is part of a trend that we're working on (hopefully in the next version release) for more support of other digital TV standards, both transmitter and receiver code. Keep an eye out for gr-dtv in the near future.

A huge part of my work recently has been in the integration, development, documentation, and building examples for our new FEC API that is now a part of gr-fec. Historically, GNU Radio hasn't done a very good job with managing or allowing use of forward error correction (FEC) techniques. It's a difficult problem to solve to allow us to easily integrate different types of FECs in transmitters and receivers, either for streaming or packet-based communication links. Each FEC has different properties and conditions for use in the different types of comms links, and they can have different input/output data types that they are built to work with. The new FEC API that's been introduced allows us to handle these situations more seamlessly within a GNU Radio flowgraph.

The new gr-fec includes FEC encoders and decoders for a convolutional code (K=7, Rate=1/2, polynomials=[79, 109]) that has been highly optimized with SIMD (through VOLK), a repetition code that simply repeats each bit N times, and a dummy code that actually does no coding but provides a simple mechanism to use and study the API. We are also providing different blocks, called “deployments” in the FEC API, that allow us to make use of these encoders/decoders in streaming, tagged stream, and PDU message-passing flowgraphs. I was able to use the convolutional code FEC encoder and decoder in the gr-mac project for full network communications between multiple computers. This work can be found in the “fec_gmsk” branch of my fork of gr-mac.

The GNU Radio manual covers the API and deployments in a fair amount of depth. Obviously, you can always build the docs yourself with GNU Radio, but the main manual page on gnuradio.org will be updated to include this when 3.7.4 is released. Likewise, there are examples for the use of the codes and deployments that are distributed and installed with GNU Radio.

So that's just a brief review of what we've been up to the past few months. There are plenty of little fixes, tweaks, and additions that we've been making to the code base in this time that I've left out. But I'm really pleased with the progress and rate of progress we've been making lately. Lots of new, good stuff to help us fill a few gaps in capabilities we've had.

GRCon14 Agenda Posted

Earlier today, John Malsbury posted the following to the GNU Radio mailing list:

Greetings,

It's been a few weeks since our last update on GRCon14.  Here's the latest:

Conference Agenda is Posted

I am happy and proud to announce that the agenda for GNU Radio Conference 2014 has been posted. We received an variety of great, high-quality proposals on topics ranging from wireless security to satellite communications and networking. Tom Rondeau and Michael Dickens spent a great deal of time sorting through the presentations and assembling an agenda that is packed full of interesting and educational content.  While some minor details may change, you can find an up-to-date agenda at the following link.  If you are a presenter and need to modify your entry, please contact Michael Dickens to do so.

/grcon14-agenda/

Help Promote GNU Radio Conference

On another note its worth mentioning that we have been keeping a pulse on registration. Based on the current run rate, we believe that this is going to be the largest GNU Radio conference, by far.

With the conference agenda assembled and great forward momentum, we would like to ask this awesome community to help us promote this event. GRCon14  is on the verge of becoming one of the largest and most influential events with a focus on SDR and wireless implementation. With a community-driven effort, we could really put ourselves on the map this year and generate even more excitement with potential users and developers.

Whether you simply remind your fellow GNU Radio developer, or invite someone new to join us for this event, we think your enthusiasm for the event is the thing that will make the difference.

Register for the Event

If you would like to register for GRCon14, follow this link:

http://grcon14.eventbrite.com/

We look forward to seeing you in September!

Best Regards,

John Malsbury
GNU Radio Conference Chair

Release 3.7.3 and the WSR Hackfest

In case you missed the announcement, we've released version 3.7.3 of GNU Radio!

We're really pretty excited about this release. If you look at the news announcement or our changelog, you can see that we had many contributors to this release. It's also about a month overdue from our normal (though unspecified) timeline. But the result is something that we are really happy with.

One thing that strikes me with all of the contributions on this one is the amount people are really using GNU Radio for interesting stuff. They are testing all sorts of use cases, corner cases, and types of cases we don't yet have names for. Hard to find all of those issues without that kind of testing and use. So I feel good about the state of where we are with this version.

And then came the Workshop on Software Radio (WSR) in Karlsruhe. I presented two papers. The first was from Tim O'Shea and myself on our work on gr-benchmark and stats.gnuradio.org, and the second was on using our polyphase filterbank blocks in GNU Radio.

Following WSR, however, was our first European GNU Radio Hackfest. It was two and a half days and went brilliantly. Lots of fun, lots of good discussion, and lots of code written (and rewritten). There were a number of issues posted and pull requests made for new features or minor issues. In a way, it's a shame that some of these didn't make it into our 3.7.3 release, but we can't just keep waiting, so these will all make it into 3.7.4. I think we're just seeing a lot of interest and energy with the project and so we have to mark some time to get the releases out when we can.

We've logged our work from the hackfest as we always do. And I believe I have taken care of all issues and pull requests, so you'll find all the new (working and available stuff) already in the GNU Radio master branch.

Specifically, it was important to wrap up the loose ends of that hackfest as quickly as possible because we're heading right into our next hackfest at Ettus Research next week in California! So I expect more great stuff to come soon.

 

 

GRCon14 Announced!

We are really pleased to announce GRCon14. We've selected the location (a beautiful building right in the center of downtown DC) and time (Sept. 16 - 18). The call for presentations is already up, and we already have a submission! With John Malsbury leading the effort and help from Michael Dickens, this is definitely shaping up to be a fantastic conference.

Keep a look-out for news because we'll be opening up registration very soon.

FOSDEM

Just on my way to FOSDEM (fosdem.org). I've never been, and I'm really looking forward to it, especially with the software radio dev room we have on Sunday.

We've been working hard on a lot of stuff in GNU Radio, as usual, and I hope to be able to show off some of this over the weekend. Here's some of the gear I'm bringing with me to hack on while we're there.

Boarded my flight. Be seeing some of you in Brussels!

GRCon13

Last week was GNU Radio's third annual conference, GRCon13. I've made some personal comments over on my blog page, but I wanted to say thank you again to everyone who came and made this a great conference. I'd like to thank John Malsbury for his significant efforts this year to make it a great conference and Johnathan Corgan for his input throughout the year. And once again, a huge thanks to our sponsors.

Almost all of the presentations are available. You can see the agenda page to quickly link to specific talks or head straight to the presentations page to download them. There are also links there to find the wiki pages for the GNU Radio Working Group discussions and work done at the Hackfest.

This year renewed my belief that we're working in the right direction, and I'm now even more excited for what we can do with GNU Radio this year. And of course, we'll catch up on all of this at next years GRCon14!

GRCon13 is Almost Here

Over the past week, we've been really gearing up GRCon13. It's just less than a month away! The important news right now is:

  1. We have announced the agenda, which includes a number of areas of talks and shows a very strong program.
  2. We have had a lot of buy-in from the SDR hardware vendors and will be giving away hardware at the end of the conference.

The abstracts for most of the talks are also available if you want to know more about any one. Many of the abstracts for the tutorial talks are not yet up but will be over the next few days.

 

PyBOMBS

GNU Radio is a huge project in both the in-tree code as well as the growing number of out-of-tree projects. We have two main issues with the installation and use of GNU Radio that follow from this:

  1. Lots of dependencies with different projects, and each may have different levels of difficult to install on various systems.
  2. Lots of out-of-tree projects that can do incredible stuff but are difficult to know about, find, and install.

PyBOMBS is a new GNU Radio package manager that helps solve both problems. For the past year of so, Marcus Leech has provided the brilliant 'build-gnuradio' script, which went a long way to solving problem 1. It was, however, and not to demean it's impact, just a shell script designed for apt-get (Debian, Ubuntu) and yum (Red Hat, Fedora) Linux systems only. It could be fragile and required a lot of upkeep from Marcus. It also did little to solve the second problem of providing access to the OOT projects.

CGRAN is an attempt to solve the second problem. I still support the idea of CGRAN as an archive and a site to promote the existence of different OOT projects. But users would still have to search through the archive to find projects and then figure out how to install them. The other problem is that various projects would be out of date with GNU Radio versions, which isn't always clear.

PyBOMBS addresses both problem, and we are slowly trying to move everyone over to using it. For one thing, Marcus has declared his intent to stop working on build-gnuradio, and secondly, there's a strong, developing community of OOT projects that we want to help support. And while supporting and providing easy access to OOT project, we also provide some guarantee that a project that is included as a PyBOMBS recipe is built against and works with the version of GNU Radio that PyBOMBS installs.

That's the main intent of PyBOMBS, and we encourage people to use it and submit new recipes for their OOT projects. You can find out more information about how to use it on the PyBOMBS Redmine development page.

I also leave you with a link to Ben Hilburn's really nice peice on PyBOMBS and why he's excited about it for the GNU Radio community.

The 3.7.0 Release

Strangely, I seem to be the last to report our first major release of the 3.7 GNU Radio branch. We've been working on it for over a year and a half and it represents some serious improvements both structurally and stylistically. But luckily other's weren't as lax as I was in promoting the good news.

In the development of 3.7, we have introduced so many new and powerful features of GNU Radio that it's hard to keep track of them.  Let me just try to list off a few:

  • Message passing interface and easy Python access
  • ControlPort
  • Performance Counters and Performance Monitor
  • VOLK (been here for a while, but a new structure in 3.7 makes significant improvements)
  • A full logging API
  • Metadata files and sources/sinks to work with them
  • Block thread affinity (and thread priority)
  • Tagged stream blocks
  • New and improved OFDM implementation (and in GRC)
  • Improved support for packet data transmission

Each of these items deserves its own write-up. Luckily, another major improvement in our work on 3.7 is a lot more documentation. The main GNU Radio manual (our 'Doxygen' manual) has more and more pages dedicated to explaining these features such as how to use the API and examples of using them in your own code or application. So keep an eye out for improvements in the documentation as we move forward with 3.7.

The Vision for 3.7

It took us a year and a half to produce 3.7. In some respects, that feels like a fairly long time between an API release like this. And we felt that, too, when the 'master' and 'next' development branches were diverging so much and so quickly that we couldn't merge one into the other without major conflicts. But on the other hand, with so many changes and new features, we needed to make sure we had everything where it needed to be before a release.

That having been said, I'm going to say now that we probably won't see a 3.8 for about as long, maybe even longer. One of the drawbacks to all of this new stuff in the code is that we tend to leave people behind. The API changes alone are going to take a lot of projects some time to update their code. And it will also take a lot of time, documentation, and examples to help use the new features. So while we will continue to innovate and push forward with new stuff in an ongoing effort to improve GNU Radio, we are also increasingly interested in building and helping to build new applications that take advantage of all of the new features and improvements. There will be a lot more writing, examples, and example applications being written this year towards this end.

 

Major Milestone in v3.7 Progress

Earlier this week, we finished converting all of the main blocks over to the new 3.7 style and top-level components. We still haven't fully addressed gr-atsc and gr-shd, but I'm holding off on those two right now on purpose.

The main win here is that you will only see minor changes in which modules you pull blocks in from. Any changes now are bug fixes, but they will be minor and easily corrected. So you can now rebuild your Python and GRC flowgraphs around the 'next' branch, and you should be pretty much good to go.

Note that we've removed an 'blocks' from gnuradio-core. So now, the only things you pull in from the Python gr. module are data structure sizes, the top block, message queue stuff, and similar. If it's a block, it's now located in one of the other blocks. We'll try to post our spreadsheet of where each block is now, but hopefully we've done it so it's pretty intuitive. And if you don't know where something should be, it's probable in gr-blocks (from gnuradio import blocks).

We're really starting to close in on the release of 3.7, so the major churn from our users' perspective should be slowing down.

Configuring ControlPort

We've just pushed some new code to the 'next' branch for better control over ControlPort. Part of this was to make using configuration/preference files more easily and widely used in GNU Radio. While we've had a bunch of configuration files installed, we only really used them for some audio and wxgui parameters. I think we might start using them more heavily in the future for better control over how GNU Radio works, especially now that we're adding a lot of new features that need a finer touch to handle.

First, a word on the preference files. These get installed by default into ${prefix}/etc/gnuradio/conf.d. Each component has its own, but we actually treat it as a flattened list of sections and options (and so we have to be careful that we don't duplicate section and option names). These config files would be system-wide defaults. However, any option can be overwritten for a user by making a [HOME]/.gnuradio/config.conf file. Just duplicate the section name and the option name in this file, and it will take precedence over the system file.

For example, gnuradio-core.conf has a section [ControlPort] and an option "on". This toggles ControlPort on/off. Say by default we want to keep ControlPort off (which is how GNU Radio is installed be default now). So our /opt/etc/gnuradio/conf.d/gnuradio-core.conf file has the "on" option set to "Off" (or False, or 0). But a particular user wants to use ControlPort. So he would create a file /home/me/.gnuradio/config.conf and put in the following:

[ControlPort]
on = True

And then next time GNU Radio is launched, this preference is read and ControlPort is turned on.

As a side note, we can also control any preference with the use of environmental variables. Just take the section name and option name and convert them into all caps with underscores between them. Then append "GR_CONF_" to it and you have your variable name. Set this to whatever you'd like. So our user me above could use "export GR_CONF_CONTROLPORT_ON=True" to manipulate that setting.

But back to the main point here. ControlPort can now be easily configured based on any configuration parameters available through ICE. We have a section:option in gnuradio-core.conf called "ControlPort:config" that points to the ICE configuration file location. I've made a really simple example that you can find installed at ${prefix}/etc/gnuradio/ctrlport.conf.example. This just shows you the format of creating a specific endpoint, like:

ControlPort.Endpoints = tcp -t 300 -h 127.0.0.1 -p 23456

Why would this be important? Well, by default ControlPort doesn't know which interface or ports you want to use in your setup, so it defaults to opening a random port on all possible interfaces. This is good because it makes it easy and is the right behavior when no one knows any better, but it is also bad for two reasons. First, it's a security risk to open a random port on all of your machines network interfaces. Second, you probably want to know which port you are using so that you can connect remotely, possibly through a firewall. Setting specific endpoints allows us to control where ControlPort is exposed and on what port. And, frankly, it's about time.

By the way, most of what I've discussed here is also available in the Doxygen manual that you can build off the code in master/next (and will be made available online with the next release).

Block Core Affinity

I just pushed an update to master/next of GNU Radio that allows us to specifically set the affinity of a block to a particular core. We can do this pretty easily because each block is its own thread in the Thread-Per-Block scheduler, so really what we are doing is setting the thread affinity.

The reason to introduce this behavior is to help us start developing an understanding of GNU Radio on many-core machines. For example, we've been contacted by the Parallella project, and this kind of functionality might be crucial to working well on that platform. On most current systems, we can talk about multi-core, which are a small (up to a dozen or two) number of the same types of processors with shared memory and local cache. The OS scheduler probably does a fantastic job with scheduling the threads in this situations, and kernels like Linux have alternative scheduling strategies we can use for specific purposes. But in a many-core system where we have heterogeneous cores and maybe different access to memory transfers or DMA to IO devices, the ability to selectively choose which cores to run on may be more important. Think about a situation where you want your UHD source block to run on the core that has the closest/fastest access to the GigE system. I'm not saying that this will actually work or help in these scenarios, but it's worth it to make this kind of research and experimentation available.

The API for this is pretty straight-forward, and block affinity can be set before and during the flowgraph run. On a given block, you just call the function 'set_processor_affinity()'.

Notice that the function takes a list (a Python list or a C++ vector of ints), so you can set the affinity to a group of cores if you want. There's an example of how to use this in gnuradio-core/src/examples/mp-sched/affinity_set.py. When you run it, watch your CPU usage monitor(s). This runs two gigantic filters that are designed to take up most of a core, one is set to core 0 and the other is set to either core 0 or 1. As long as at least 1 of the cores specified is present, the system will just use that, so this example will run even on single-core machines (but I have not tested this behavior in Windows). On systems with 2 or more cores, core 0 will be largely taken up by the first filter. The second filter could use core 0, but will likely be scheduled to use core 1.

One thing to note: this is not fully cross-platform. Setting thread affinity seems to be a delicate subject and not fully supported. In fact, the pthread library call pthread_setaffinity_np has that suffix 'np' to specify that it is implicitly non-portable. The GNU Radio Utilities and Etc. Library (GRUEL) has been updated to provide abstracted calls for the different OSes that we support for this. Right now, we have Linux and Windows support. I tried to get OSX support, but their API isn't exactly what we are looking for (they are interested in sharing cache lines, not specifically tying a thread to a core). So until things change, our GRUEL thread affinity calls in OSX are nops.

In the Doxygen manual, look for the Related Pages page named 'Block Thread Affinity' for more details.

Project Updates

As always, we've been hard at work on extending and improving the features in GNU Radio. This is just a quick update on a few of the things we've been working on recently.

First, I have been adding specific pages to the Doxygen Manual that catalogue and describe certain features and functions of GNU Radio. You can find these in the "Related Pages" section. They feature discussions and examples for how to use some of the features in GNU Radio that might not otherwise be obvious. I like this model since it keeps the documentation of the code directly integrated into the code and the build system. You can always have a local copy of the manual for your version. We're also not trying, then, to keep multiple versions of code documentation all over the place.

Today, to make things easier, I expanded our Documentation section on the main GNU Radio webpage to directly link to some of these pages. I'm not sure how many others have found them or are using them already, but I wanted to make sure it was easy to what was available and where to locate the information.

The other thing that I wanted to mention today is the work that's been done on the QTGUI blocks. These are visualization tools for signals in GNU Radio. We've been significantly improving them over the past few months.

The first major improvement has been to add direct user control over the parameters while operating live. The figure below shows a screenshot of the gr-qtgui example *pyqt_freq_c.py*. First, notice the overall color scheme. This is based of the ability to use QT style sheets that can define the look of a QTGUI app. In this running example, I right-clicked outside of the curve canvas itself (where right-click means to unzoom) to pull up the menu. As you can see, the menu allows us to adjust a number of parameters. Some of these are available in all plotters, but others are specific to the type of plot (the FFT size or averaging would be meaningless in a time domain or constellation plot). In this figure, I have adjusted the color of line 'Data 0' to red, increased the width of the other two lines, changed the FFT size to 512, and turned on averaging. I then stopped the graph and tool a screen shot to make this image (notice, though, that there is a 'Save' option in the drop-down menu; this saves the current plot, but it would not have included the menu information).

I would encourage anyone using the QTGUI plotters to play around in these menus to understand the kind of flexibility we now have while looking at signals.

Finally, before this post gets too much longer, I wanted to also note that we have just added a new QTGUI plotter to do time raster plots. These types of plots show samples in time, line by line, so both x and y axes are in time. This is often used for looking at data and packet structure. The GNU Radio plotters can accept multiple signals in that are then plotted as an overlay. The intensity is then shown as the sum of the samples, so it will be higher when then overlap and lower when they are different.

The figure below shows the output of the example pyqt_time_raster_b.py that is shipped with GNU Radio. It has one signal that has 10 zeros, then 80 bits of alternating ones and zeros, and then ended with another 10 zeros. Another signal is then overlaid on top that just has a pattern of 3 one part-way into the vector. These vectors are then repeated. We can see the bright white stripe is where we get the 3 ones from signal 1 on top of the samples in signal 0.

 

Also note the diagonal. We draw these figures on a grid of a number of rows and number of columns. If we had 100 columns in this example, the samples would be plotted in straight columns. But in many situations where these types of plots are useful, we may have some fractional offset we want to handle. This example is showing us that we can set the number of columns to 100.25, so there's a quarter bit overlap between rows that causes this diagonal. Using the drop-down menu, we can adjust the number of columns to 100 to get what we see below.