Vendor and platform neutral SDR support Thu, Oct 16 2014 PM

Background

Its time to add support in Pothos for SDR hardware. We want to handle most of the devices on the market. The Pothos support needs to have the right look and feel, and integrate with the framework in the most optimized way.

Pothos GNU Radio support

We potentially have support through the GNU Radio support branch. The support branch could bring in gr-uhd and gr-osmosdr. However, the GrPothosUtil.py script probably wont deal well with the generated GRC wrappers used in both projects, and that would give us 2 pairs of source and sink blocks.

The SDR library ecosystem

• miscellaneous vendor userspace drivers like rtl, hackrf, bladerf
• gr-osmosdr - GNU Radio blocks that wrap several userspace drivers
• uhd - interface library for USRPs, other vendors through modules
• gr-uhd - GNU Radio blocks that wrap the uhd interface library
• platforms like GNU Radio, SDR#, various visualization tools

This is a mess

This is a mess, not just for me as a platform maintainer or user, but for everyone involved.

Suppose I am a platform maintainer. How do I add support for new devices? Do I make a new wrapper in my platform every time a new driver appears on the market? Or do I make another platform a build requirement just for the sake of using an interface wrapper? I really want a single interface that I write support for once.

Suppose I am a hardware vendor. My goal is to make it easy for people to use my product. I want to streamline support for my device into every platform and user-tool out there. Instead I have created a driver specific to my device and paid for support in a few platforms. I really want a common interface in front of my hardware for instant platform adoption.

Suppose I am a user. I want to interface with an existing platform or write code to interface with one or more SDR devices. The SDR library ecosystem is a confusing matrix of partially complete options to choose from. Do I pick a particular platform because its acting as a wrapper for the devices that I'm interested in? Do I figure out how to call into one or more of the vendor-provided user-space drivers? Like the platform maintainer, I also want a single well-documented interface to deal with.

Introducing SoapySDR

It looks like just about everyone could bennefit from a common interface. We need a sort of middle layer for the SDR world in the same way that we have IP for the internet. So, with a good idea of what is needed for an SDR wrapper, and inspiration from both the uhd and osmosdr projects, I created SoapySDR.

SoapySDR is a vendor and platform neutral interface. In this system, the user or platform provider has a C++ and C API to code with. Hardware support is provided through runtime-loadable library modules.

Ideally, vendors will ship SoapySDR support modules along with their driver. In the long run, users will install a stable SoapySDR library (possibly from the package manager), then install the drivers for the given hardware. Neither SoapySDR nor the platform has to be recompiled/reinstalled to support additional hardware.

For now, the SoapySDR build system includes module support for most gr-osmosdr hardware, and module support for the uhd driver interface.

GNU Radio SDR support

Poor gr-osmosdr never made it into mainline GNU Radio. The cheif complaint has been that gr-osmosdr is hard to maintain because it contains frequently changing vendor support code. Thats not stable enough to merge and maintain in mainline GNU Radio, and would be a huge burden on the developers. In contrast, the SoapySDR library is slim and seldom changes, and because of this, we can create stable GNU Radio blocks around it.

gr-sdr is a new vendor-neutral SDR support component for GNU Radio. Currently its an out-of-tree module while its in the development stages. But the end goal is to mainline this very simple and slim component and then a stock GNU Radio install will come with vendor-neutral SDR support. Currently, all the configuration hooks, streaming hooks, swig, python, and GRC wrappers are complete. What missing is porting basic applications like the a frequency plotter, and advanced streaming support for stream tags and timed streaming. Volunteers are welcome!

• There has been some debate about the name gr-sdr being acceptable. Please help us name gr-sdr by taking this poll.

Pothos SDR support

Pothos SDR support is getting its own blog entry. Stay tuned...