GNURADIO HW Interface

GNU Radio
1

While many HW solutions interfacing with GNURADIO has evolved but we
dont
see any of them listed under GNURADIO HW interface page. For example
here
is the link
http://gnuradio.org/redmine/projects/gnuradio/wiki#VI-Hardware

Is GNURADIO limited to a particular h/w?. Although we do not think so
but
still there seems to be a Gap.

Can anyone take us to a platform where any new HW can be plugged and
played
independent of UHD with a standard source and sink of IQ data. We do not
oppose UHD but we see it is more related to USRP.

However, if anyone can create a template to throw in there API’ there
and
compile with GNURADIO. That would be great start many h/w with GNURADIO.
Like GNURADIO, SDRSHARP is a simple example out there but provides a
great
flexibility in terms of interfacing new hardware’s.

2

On Fri, Aug 31, 2012 at 2:57 PM, My Radio [email protected]
wrote:

However, if anyone can create a template to throw in there API’ there and
compile with GNURADIO. That would be great start many h/w with GNURADIO.
Like GNURADIO, SDRSHARP is a simple example out there but provides a great
flexibility in terms of interfacing new hardware’s.

I wanted to address this in hopefully the least controversial way
possible…

In short, no, GNU Radio is not limited to any particular hardware, but
it’s a
bit up to the hardware vendors to work with us to interface to GNU
Radio. Similarly, the wiki is a place where anyone can get access to
update it, so if someone wants to offer their hardware solution on the
page, it’s not very difficult.

But this issue has a long history. It seems various platforms come and
go and don’t necessarily have a strong connection to our community.
On the other hand, Ettus R., both Matt in the early days of GNU
Radio and
now his team of engineers, has been a major contributor to GNU Radio
and has had a sustained business of shipping and supporting SDR
hardware for, what is it now, almost 10 years? So sure, it seems like
there is a bias on GNU Radio’s part to Ettus products, but that’s
because of a strong and sustained effort from them to work with and
contribute to the community.

But that does not prevent others from doing the same.

As I said, there’s a pretty long history here of different hardware
products and a lot of emotions that surround it. I expect that
answering this question publicly will draw a lot of comments and
criticisms, but there you have it.

There’s another issue on the table here about a hardware abstraction
layer or a general/global API for SDR front ends. That, too, is an
incredibly complicated problem that I haven’t seen any real solutions
for.

Tom

3

On 04 Sep 2012 10:29, Tom R. wrote:

There’s another issue
on the table here about a hardware abstraction
layer or a
general/global API for SDR front ends. That, too, is an
incredibly
complicated problem that I haven’t seen any real solutions
for.

Tom

The gr-osmosdr
block does some abstraction for the RX side, supporting:

o FunCube
Dongle

o OSMOSDR

o UHD devices (all the Ettus gear)

o RTLSDR

So, there is an example of an attempt at an abstraction layer that
works passably well. It’ll get better over time as people use it, and
can serve as an example for any other attempts out there.

4

On Tue, Sep 4, 2012 at 10:41 AM, [email protected] wrote:

o RTLSDR

So, there is an example of an attempt at an abstraction layer that works
passably well. It’ll get better over time as people use it, and can serve
as an example for any other attempts out there.

I’m not sure that I consider what they do an abstraction layer. They
just switch between a handful of devices.

Tom

5

On Tue, Sep 4, 2012 at 7:51 AM, [email protected] wrote:

A useful abstraction layer would provide an ‘upper API’ that user code
would rely on for providing a stable, common interface to program to,
while
also providing a ‘lower API’ to device manufacturers to register with
(at
runtime library initialization or as loadable modules) to inform GNU
Radio
of device capabilities and to perform actual API calls.

The challenge is in coming up with an upper API abstraction that
adequately
covers the common functions of device discovery, configuration, naming,
streaming vs. burst data transfers, metadata, multiple device support,
synchronization, etc., for a variety of devices, but that also allows
users
to get at any vendor specific features that don’t fit into the
abstraction.

I could certainly see developing a ‘gr-sdr’ component that provides the
upper API source and sink blocks and allows other blocks or libraries to
hook in underneath. That part, though, is fairly mechanical in nature
(pluggable APIs go back decades). I’d want to see a well-thought out
upper
and lower abstraction that people are happy with before writing any
code.

Johnathan

6

On 04 Sep 2012 10:48, Tom R. wrote:

On Tue, Sep 4, 2012 at
10:41 AM, [email protected] wrote:

On 04 Sep 2012 10:29, Tom
Rondeau wrote: There’s another issue on the table here about a hardware
abstraction layer or a general/global API for SDR front ends. That, too,
is an incredibly complicated problem that I haven’t seen any real
solutions for. Tom _______________________________________________ The
gr-osmosdr block does some abstraction for the RX side, supporting: o
FunCube Dongle o OSMOSDR o UHD devices (all the Ettus gear) o RTLSDR So,
there is an example of an attempt at an abstraction layer that works
passably well. It’ll get better over time as people use it, and can
serve as an example for any other attempts out there.

I’m not sure
that I consider what they do an abstraction layer. They
just switch
between a handful of devices.

Tom

Anything that reduces/eliminates
the need for multiple flow-graphs to support different devices with a
similar “high level” interface is a good thing. For that, gr-osmosdr
works quite well.

7

On Tue, Sep 04, 2012 at 10:29:38AM -0400, Tom R. wrote:

Similarly, the wiki is a place where anyone can get access to
update it, so if someone wants to offer their hardware solution on the
page, it’s not very difficult.

I’ll put in my usual preaching here: As Tom said, gnuradio.org is a
wiki. If anyone has stuff to offer here, please add it! Apart from the
hardware page, there’s other pages which will only work and stay
up-to-date if people contribute. Here’s a couple of pages anyone can
help to maintain:

  • Tutorials (both on-site and external; if you’ve written something
    about GNU Radio, don’t hesitate, either paste it here or post a link)
  • Downloadable examples
  • Downloadable sample streams (baseband files)
  • Academical papers on GNU Radio
  • The “who’s using GR” page
  • The FAQ

And there’s more. Don’t just consume, participate!

M

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association