Extending UHD Device Support

GNU Radio
1

Designation: Non-SSA/Finmeccanica

Hello,

We make several RF front-ends that we’d like to see supported in GNU
Radio. Our initial idea is was to extend the Ettus UHD to include
support for our devices, so that a waveform/flow graph using a UHD block
could run using either a USRP or one of our devices with only minor
modifications. Does it “make sense” to extend UHD for this purpose?

Our radios are embedded Linux systems that can communicate over USB as
well as Ethernet. Initially I would like to use Ethernet as
communication (using sockets). As far as I can figure a good place to
start would be to follow the USRP2 UHD implementation and re-implement
it for our system.

Any tips, examples or general guidance would be very much appreciated.

Thank you!

–

Jeff Wilson

DRS Signal Solutions, Inc.

Direct: 301.944.8772

3.1.1001

2

On Wed, Aug 24, 2011 at 11:23 AM, Wilson, Jeffery (DS-1)
[email protected] wrote:

make sense to extend UHD for this purpose?
Any tips, examples or general guidance would be very much appreciated.

DRS Signal Solutions, Inc.

Direct: 301.944.8772

Hi Jeff,
We’d love to have support for your radios in GNU Radio! I would rather
let Matt or Josh from Ettus comment on the suitability of using the
UHD as the software interface. In many senses, yes, I think it’s the
right thing, but there are issues of compatibility that might be a
problem. But even if you don’t go with it as your interface, making an
interface that is similar in the API to the UHD would certainly help
people use it.

Tom

3

Jeffery,

The first thing to keep in mind is that everything is GPL’ed (and
specifically, not LGPL). This means that if you use any UHD host
code,
you must obey the GPL for EVERYTHING that links in. This goes all the
way
up to your customer’s application. This restriction already applies for
GNU
Radio itself since it is also GPL’ed.

The firmware is GPL’ed. This means that if you use any of the firmware,
your ENTIRE firmware image must obey the terms of the GPL.

The FPGA design is GPL’ed. This means that if you use any of our
Verilog,
everything compiled into that FPGA image must comply with the GPL.
This
would include all of your custom signal processing code, if it is in the
same FPGA.

The implementation of UHD host code is heavily oriented towards the
state
machines in the firmware and FPGA, so modifying it to work with other
devices is easier if they use the same firmware and FPGA designs. This
is
fine as long as you are ok with invoking the GPL requirements on those
portions of your design.

Users of Ettus R. hardware are able to use all of this under less
restrictive terms in our alternative license.

Matt E.
President, Ettus R. LLC

On Wed, Aug 24, 2011 at 8:23 AM, Wilson, Jeffery (DS-1)
<[email protected]

4

Designation: Non-SSA/Finmeccanica

Matt,

Thank you for your response. We will certainly be sure to abide by any
and all licensing requirements as we move forward.

As for now I would like to develop a simple source block (without using
UHD) for our radio so I can at least do something like a basic FFT
display as a proof of concept that we can in fact get our radio working
in some way with GNU Radio. Is there anywhere I can find help/guidance
specific to creating new source blocks other than picking apart the
current ones? If not, which block(s) would be a good starting place?

Thanks!

– Jeff

From: Matt E. [mailto:[email protected]]
Sent: Thursday, August 25, 2011 6:18 PM
To: Wilson, Jeffery (DS-1); [email protected]
Subject: Re: [Discuss-gnuradio] Extending UHD Device Support

Jeffery,

The first thing to keep in mind is that everything is GPL’ed (and
specifically, not LGPL). This means that if you use any UHD host
code, you must obey the GPL for EVERYTHING that links in. This goes all
the way up to your customer’s application. This restriction already
applies for GNU Radio itself since it is also GPL’ed.

The firmware is GPL’ed. This means that if you use any of the firmware,
your ENTIRE firmware image must obey the terms of the GPL.

The FPGA design is GPL’ed. This means that if you use any of our
Verilog, everything compiled into that FPGA image must comply with the
GPL. This would include all of your custom signal processing code, if
it is in the same FPGA.

The implementation of UHD host code is heavily oriented towards the
state machines in the firmware and FPGA, so modifying it to work with
other devices is easier if they use the same firmware and FPGA designs.
This is fine as long as you are ok with invoking the GPL requirements on
those portions of your design.

Users of Ettus R. hardware are able to use all of this under less
restrictive terms in our alternative license.

Matt E.
President, Ettus R. LLC

On Wed, Aug 24, 2011 at 8:23 AM, Wilson, Jeffery (DS-1)
[email protected] wrote:

Designation: Non-SSA/Finmeccanica

Hello,

We make several RF front-ends that we’d like to see supported in GNU
Radio. Our initial idea is was to extend the Ettus UHD to include
support for our devices, so that a waveform/flow graph using a UHD block
could run using either a USRP or one of our devices with only minor
modifications. Does it “make sense” to extend UHD for this purpose?

Our radios are embedded Linux systems that can communicate over USB as
well as Ethernet. Initially I would like to use Ethernet as
communication (using sockets). As far as I can figure a good place to
start would be to follow the USRP2 UHD implementation and re-implement
it for our system.

Any tips, examples or general guidance would be very much appreciated.

Thank you!

–

Jeff Wilson

DRS Signal Solutions, Inc.

Direct: 301.944.8772

3.1.1001

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

3.1.1001

5

Try to explore IT++ as well.

On Fri, 26 Aug 2011 11:45:13 -0400,
“Wilson, Jeffery (DS-1)” wrote:

Designation: Non-SSA/Finmeccanica

Matt,

Thank you for your response. We will certainly be sure to
abide by any and all licensing requirements as we move forward.

As
for now I would like to develop a simple source block (without using
UHD) for our radio so I can at least do something like a basic FFT
display as a proof of concept that we can in fact get our radio working
in some way with GNU Radio. Is there anywhere I can find help/guidance
specific to creating new source blocks other than picking apart the
current ones? If not, which block(s) would be a good starting
place?

Thanks!

– Jeff

FROM: Matt E.
[mailto:[email protected]]
SENT: Thursday, August 25, 2011 6:18 PM
TO:
Wilson, Jeffery (DS-1); [email protected]
SUBJECT: Re:
[Discuss-gnuradio] Extending UHD Device Support

Jeffery,

The first
thing to keep in mind is that everything is GPL’ed (and specifically,
not LGPL). This means that if you use any UHD host code, you must
obey the GPL for EVERYTHING that links in. This goes all the way up to
your customer’s application. This restriction already applies for GNU
Radio itself since it is also GPL’ed.

The firmware is GPL’ed. This
means that if you use any of the firmware, your ENTIRE firmware image
must obey the terms of the GPL.

The FPGA design is GPL’ed. This means
that if you use any of our Verilog, everything compiled into that FPGA
image must comply with the GPL. This would include all of your custom
signal processing code, if it is in the same FPGA.

The implementation
of UHD host code is heavily oriented towards the state machines in the
firmware and FPGA, so modifying it to work with other devices is easier
if they use the same firmware and FPGA designs. This is fine as long as
you are ok with invoking the GPL requirements on those portions of your
design.

Users of Ettus R. hardware are able to use all of this
under less restrictive terms in our alternative license.

Matt
Ettus
President, Ettus R. LLC

On Wed, Aug 24, 2011 at 8:23 AM,
Wilson, Jeffery (DS-1) wrote:

Designation: Non-SSA/Finmeccanica

Hello,

We make several RF front-ends that we’d like to see
supported in GNU Radio. Our initial idea is was to extend the Ettus UHD
to include support for our devices, so that a waveform/flow graph using
a UHD block could run using either a USRP or one of our devices with
only minor modifications. Does it “make sense” to extend UHD for this
purpose?

Our radios are embedded Linux systems that can communicate
over USB as well as Ethernet. Initially I would like to use Ethernet as
communication (using sockets). As far as I can figure a good place to
start would be to follow the USRP2 UHD implementation and re-implement
it for our system.

Any tips, examples or general guidance would be
very much appreciated.

Thank you!

–

Jeff Wilson

DRS Signal
Solutions, Inc.

Direct:
301.944.8772

3.1.1001

Discuss-gnuradio
mailing list
[email protected]
[2]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[3]

3.1.1001

Links:

6

On Fri, Aug 26, 2011 at 11:45 AM, Wilson, Jeffery (DS-1)
[email protected] wrote:

GNU Radio. Is there anywhere I can find help/guidance specific to creating
new source blocks other than picking apart the current ones? If not, which
block(s) would be a good starting place?

Thanks!

– Jeff

Hi Jeff,
Most of the hardware interfaces we have consist of a hardware
interface library (call it drs0) and a GNU Radio wrapper block around
that one that would be called gr-drs0. The gr-drs0 is structured in a
standard GNU Radio format. It inherits from a gr_block (actually, it’s
usually a gr_sync_block), has a constructor to initialize the device
through the drs0 library, and has a work function that either gets
samples to push onto the flow graph for a receiver or takes samples
from a flow graph and sends them to the device for a transmitter. This
will also have wrapper accessors to get and set the properties of the
device, like frequency, gain, etc.

If you want to have a quick hack at it without the UHD, you can look
at how things were done with usrp and gr-usrp (or usrp2 and gr-usrp2),
which are both in the GNU Radio source tree.

If you can work with the UHD, though, I would recommend doing so. It
would make integration into GNU Radio projects much simpler.

Tom