Matlab interface to USRP

Hello all,

I am trying to figure out the Matlab interface to USRP. Although I could
enable the communications between Matlab and GNU Radio, I am wondering
whether it is possible to make Matlab hook to USRP directly without GNU
radio. Thank you very much!

“Pu, Di” [email protected] writes:

I am trying to figure out the Matlab interface to USRP. Although I
could enable the communications between Matlab and GNU Radio, I am
wondering whether it is possible to make Matlab hook to USRP directly
without GNU radio. Thank you very much!

(This isn’t entirely directed at you - there has been discussion of
proprietary software recently, and I know from private correspondence
that several others share the views below. Thus, I thought it helpful
to air them.)

My impression is that the charter of the list is to advance GNU
Radio as a Free software implementation of SDR, within the context of a
larger effort to have enough Free software so that we don’t need to use
any proprietary software.</> Although I don’t see this notion on the
wiki, it’s the normal notion for lists associated with official GNU
projects of the FSF.

If you’re interested in using the USRP with proprietary software like
Matlab, I would suggest also asking on some Matlab user’s list. I
believe that a number of the more clueful people on this list are
philosophically disinclined to volunteer to help people use proprietary
software.

There has been some recent discussion about using Free software that has
matlab-like features, like octave and freemat.

http://www.gnu.org/software/octave/
http://freemat.sourceforge.net/

On Wed, Apr 9, 2008 at 8:59 AM, Greg T. [email protected] wrote:

There has been some recent discussion about using Free software that has
matlab-like features, like octave and freemat.

http://www.gnu.org/software/octave/
http://freemat.sourceforge.net/

I did some poking around the octave site and found this:

http://wiki.octave.org/wiki.pl?CategoryExternal

From this these interfaces may not be mature in octave yet, but the
info looks about a year old.

Philip

Greg-

My impression is that the charter of the list is to advance GNU
software.
I understand completely your viewpoint. However, let me point out that
one of your key objectives should be to
increase popularity of GNU Radio software. One way to do this is to
encourage and support GNU Radio software examples
that interface with MATLAB in some way.

There is no denying that 1000s of developers are using MATLAB as a tool
to develop radio and other RF applications.
I’m active on MATLAB lists and forums, and besides commercial
developers, I see literally 10s of student questions
about RF projects every day. OFDM, MIMO, xxSK, you name it… Professors
have assigned them to do it.

If you can draw those developers and students (and Profs) into the GNU
Radio environment and introduce them to what
you’re doing, it will only serve to further your goals. However
distasteful from an ideological standpoint, I might
suggest to take a page from Bill Gates: add low-level compatibility for
“other” RF software to GNU Radio software
(typical examples such as transfer data, call MATLAB functions,
MATLAB-callable functions), and eventually the
“others” will discover how much better, well-supported, and dynamically
growing is your GNU Radio software.

-Jeff

On Wed, Apr 9, 2008 at 11:38 AM, Jeff B. [email protected]
wrote:
[snip]

I understand completely your viewpoint. However, let me point out that one of your key objectives should be to
increase popularity of GNU Radio software. One way to do this is to encourage and support GNU Radio software examples
that interface with MATLAB in some way.

There is no denying that 1000s of developers are using MATLAB as a tool to develop radio and other RF applications.
I’m active on MATLAB lists and forums, and besides commercial developers, I see literally 10s of student questions
about RF projects every day. OFDM, MIMO, xxSK, you name it… Professors have assigned them to do it.

If you can draw those developers and students (and Profs) into the GNU Radio environment and introduce them to what
you’re doing, it will only serve to further your goals.
[snip]

Which is a role which the Octave embedding interface should be able to
serve reasonably well, without bumping into the philosophical (and
potentially legal) problems of linking matlab into GNU Radio.

If octave didn’t exist then perhaps the argument would be different
… But octave does exist and it is largely matlab compatible … So to
support embedding matlab in-lieu of octave wouldn’t just be
gratuitously promoting propritary software, it would be promoting
propritary software to the exclusion of free software.

Pedro-

GNU Radio). USRP developers/users perhaps would like a USRP-Matlab direct
connection, but GNU Radio developers/users surely not.

This is the original post:

Ya I know, I had read the original post. I would say that it’s not
possible to have it both ways, there is either
basic encouragement for GNU Radio interface with MATLAB or there is not.
I think drawing the line at not providing
support for interfacing MATLAB directly to USRP hardware is fine,
although I would note that over the years people
have interfaced MATLAB to many types of data acq/DSP/FPGA hardware that
originally didn’t support MATLAB. It happens.

Even in these borderline cases, people who see the bigger picture –
especially the Professors and instructors who
influence our future engineers – will clearly see the advantages of
USRP and start asking “what happens if we use GNU
Radio”. Any increased awareness of GNU Radio is a good thing.

-Jeff

I understand completely your viewpoint. However, let me point out that
one of your key objectives should be to
increase popularity of GNU Radio software. One way to do this is to
encourage and support GNU Radio software examples
that interface with MATLAB in some way.

Yes, you are right in that, but the person that originally posted did
not
like to use GNU Radio; He wanted to interface USRP to Matlab directly
without GNU Radio in the middle (in fact he managed to interface Matlab
with
GNU Radio). USRP developers/users perhaps would like a USRP-Matlab
direct
connection, but GNU Radio developers/users surely not.

This is the original post:

----- Original Message -----
From: “Pu, Di” [email protected]
To: [email protected]
Sent: Wednesday, April 09, 2008 12:03 AM
Subject: [Discuss-gnuradio] Matlab interface to USRP

Hello all,

I am trying to figure out the Matlab interface to USRP. Although I could
enable the communications between Matlab and GNU Radio, I am wondering
whether it is possible to make Matlab hook to USRP directly without GNU
radio. Thank you very much!

IMHO,
Pedro Ignacio Martos

On Wed, Apr 09, 2008 at 10:38:23AM -0500, Jeff B. wrote:

to air them.)
believe that a number of the more clueful people on this list are
philosophically disinclined to volunteer to help people use proprietary
software.

I understand completely your viewpoint. However, let me point out
that one of your key objectives should be to increase popularity of
GNU Radio software. One way to do this is to encourage and support
GNU Radio software examples that interface with MATLAB in some way.

I have no interest in supporting an interface to MATLAB, or any other
proprietary software for that matter. I’d be much more interested in
working with Octave, or better yet, working up an excellent
interface to scipy. Just because EE’s are trained in MATLAB, doesn’t
mean that it’s even a reasonable tool to use. Do you know of any
other language the allows only a single externally visible function
PER FILE??? Come on folks, stop drinking the kool-aid.

matplotlib supports pretty much all the high-level plotting features
found in MATLAB, and does it in Python, a language that provides a lot
more leverage than MATLAB. scipy’s got all the linear algebra, and
and ever expanding set of functions / toolboxes.

There is no denying that 1000s of developers are using MATLAB as a
tool to develop radio and other RF applications. I’m active on
MATLAB lists and forums, and besides commercial developers, I see
literally 10s of student questions about RF projects every
day. OFDM, MIMO, xxSK, you name it… Professors have assigned them
to do it.

No offense, but I think that EE professors are part of the problem.
Many of them have little or no real world programming experience.
You can tell. They think that MATLAB is a “reasonable” language.

Eric

Greg-

support embedding matlab in-lieu of octave wouldn’t just be
gratuitously promoting propritary software, it would be promoting
propritary software to the exclusion of free software.

On days that I’m in philosophical mode, I completely agree. But the
reality is that MATLAB is far more widely used
than Octave. MATLAB is at the core of the commercial and academic RF
community, Octave is not. If we are to increase
awareness and popularity of GNU Radio, there is no escaping MATLAB
compatibility.

-Jeff

Eric-

that several others share the views below. Thus, I thought it helpful
Matlab, I would suggest also asking on some Matlab user’s list. I
proprietary software for that matter. I’d be much more interested in

You can tell. They think that MATLAB is a “reasonable” language.
Yes you are right, MATLAB is outdated in many ways. I remember thinking
it was kludgy back in 1986, when I first saw
it at a tradeshow in Dallas! It was function-per-file then, as it still
is now. (If you’re wondering what I was
doing there, I was in the next booth over showing Hypersignal DSP
software for PCs.)

But there is no arguing with success, and MATLAB is highly successful.
For GNU Radio to succeed it should gracefully
navigate the RF community real world, and MATLAB is a key part of that.

-Jeff

On Wed, Apr 9, 2008 at 12:50 PM, Jeff B. [email protected]
wrote:

Greg-
On days that I’m in philosophical mode, I completely agree. But the reality is that MATLAB is far more widely used
than Octave. MATLAB is at the core of the commercial and academic RF community, Octave is not. If we are to increase
awareness and popularity of GNU Radio, there is no escaping MATLAB compatibility.

For this purpose you shouldn’t think of Octave as something totally
separate from MATLAB, think of it has the free software compatible
version of MATLAB.

If I were going to advocate something other than for purposes of
compatibility it wouldn’t be any matlab-esq language. Really with
being built on python GNU radio already has much of what people need
for development work all built in…

On Wed, Apr 9, 2008 at 2:01 PM, Jeff B. [email protected]
wrote:

But there is no arguing with success, and MATLAB is highly successful. For GNU Radio to succeed it should gracefully
navigate the RF community real world, and MATLAB is a key part of that.

The pragmatic approach involves someone interfacing MATLAB with GNU
radio and hosting it on a non-free GNU Radio site.

Although I hope someone supports octave first and reduces the demand
for MATLAB support :slight_smile:

Philip

I think the problem is that there are basically 2 separate cultures
here. There are those coming from the CS and free software world, and
those coming from the radio, engineering, academic, industry, hardware,
etc. worlds. Those in the free software world often don’t understand
how truly separate the two cultures are. While everybody has heard of
Linux, they usually haven’t heard of GNU, RMS, GPL, or freedom as
applied to software. For example, I often have people talk to me about
“the GNU Project”, when they really mean the GNU Radio Project, so I
take the time to explain that the GNU project is actually much bigger
than just GNU Radio.

When someone comes here from that second world, where the lingua franca
is Matlab, and we immediately hit them with a moral argument without any
background, it doesn’t help anybody, it just scares them off. I think a
better response would be something along the lines of:


If you are very comfortable in the Matlab world, then perhaps you

should try Octave, which has a high degree of compatibility with
Matlab. A link between GNU Radio and Octave would not be difficult at
all. However, there are many other free programs which might also
function in a similar manner and be even easier to work with, like
scipy, matplotlib, and scilab. Most people here just use GNU Radio
without all that other stuff because it fits their needs without
anything else added on. Is there any particular reason that you need to
use Matlab? Is GNU Radio missing any particular features?

For a number of reasons, many people here choose not to use

proprietary software. Some of those reasons are outlined here:

         http://www.gnu.org/philosophy/philosophy.html

I know that a lot of GNU Radio users and even contributors started out
using Matlab, Simulink, LabView, or other proprietary packages. If they
are scared off before they get to that point we all lose.

Matt

On Wed, Apr 09, 2008 at 10:38:08AM -0700, Matt E. wrote:

the GNU project is actually much bigger than just GNU Radio.
try Octave, which has a high degree of compatibility with Matlab. A link


I know that a lot of GNU Radio users and even contributors started out
using Matlab, Simulink, LabView, or other proprietary packages. If they
are scared off before they get to that point we all lose.

Matt

Very nicely put.

Thanks,
Eric

Matt-

all. However, there are many other free programs which might also


I know that a lot of GNU Radio users and even contributors started out
using Matlab, Simulink, LabView, or other proprietary packages. If they
are scared off before they get to that point we all lose.

I agree with Eric, well said. My one exception is your reasoning based
on what
features MATLAB and/or GNU Radio have or don’t have. If you ask
colleagues “why do
you need to use MATLAB” they will say because it’s what their company
has available,
what their colleagues use, it’s a widely accepted technical programming
language for
publishing papers, etc. If you ask students, they will say “because my
Prof said
so”. A lot of pragmatic reasons.

As you said, a moral argument (or in my terms, an ideological argument)
isn’t going
to accomplish much. But if GNU Radio gracefully plays with MATLAB, at
least at the
data exchange and function-callable level, then you open the door for
the other
culture to walk in – and discover just how far GNU Radio software and
hardware has
advanced. That’s a great way to attract new adherents and supporters.

-Jeff

On Wed, Apr 9, 2008 at 2:24 PM, Jeff B. [email protected]
wrote:

I agree with Eric, well said. My one exception is your reasoning based on what
features MATLAB and/or GNU Radio have or don’t have. If you ask colleagues “why do
you need to use MATLAB” they will say because it’s what their company has available,
what their colleagues use, it’s a widely accepted technical programming language for
publishing papers, etc. If you ask students, they will say “because my Prof said
so”. A lot of pragmatic reasons.

Thats fine for them. I endorse their use of matlab. Three cheers for
them. Fantastic.

As you said, a moral argument (or in my terms, an ideological argument) isn’t going
to accomplish much. But if GNU Radio gracefully plays with MATLAB, at least at the
data exchange and function-callable level, then you open the door for the other
culture to walk in – and discover just how far GNU Radio software and hardware has
advanced. That’s a great way to attract new adherents and supporters.

It’s also a great way to make GNU radio useless to anyone who can’t
afford matlab. As I was told on IRC “every researcher has access to
matlab”, so of course if GNU radio deeply integrates matlab then many
people will incorporate Matlab-only features into their projects since
the mindset is “every researcher has access to matlab” even though far
from everyone does…

Why bother? There are hardware decks specifically built for matlab
which are less costly than USRP. … and a USRP driver for matlab
could probably be written with comparable effort to matlab support in
GNUradio.

If someone simply wants some compatibility for their own matlab
language code, there is octave… but it seems that idea is being
categorically rejected because what is wanted is just a shim to use
USRP from matlab. Their needs could probably be best served by a USRP
driver for matlab.

On Wed, Apr 09, 2008 at 01:29:55PM -0400, Philip B. wrote:

On Wed, Apr 9, 2008 at 2:01 PM, Jeff B. [email protected] wrote:

But there is no arguing with success, and MATLAB is highly successful. For GNU Radio to succeed it should gracefully
navigate the RF community real world, and MATLAB is a key part of that.

The pragmatic approach involves someone interfacing MATLAB with GNU
radio and hosting it on a non-free GNU Radio site.

Although I hope someone supports octave first and reduces the demand
for MATLAB support :slight_smile:

Would somebody hurry up and code up the C++ daughterboard support?
That would solve many problems :wink:

Eric

more two cents

I love Matlab and I use it every day but there is a time and a place
for it and it is not as an computational engine for a software defined
radio. Signal processing for an SDR is just not the right use for it.
It just can’t keep up. If you were generating complied code in simulink
for some real time target OS via the real time workshop with the intent
of interfacing with the USRP I could see the application but just
streaming data into Matlab for processing is just using the USRP as a
cheap sampling scope frontend. I would hope the USRP is more than a
cheap front end to a digital scope. I know alot of people use it(USRP)
for this but the real work and beauty of this project is the signal
processing blockset and framework to allow the construction of a radio.
I think the effort should be put into moving the GNU radio code forward
not trying to support a sideline application.

Eric B. wrote:

I have no interest in supporting an interface to MATLAB, or any other
proprietary software for that matter. I’d be much more interested in
working with Octave, or better yet, working up an excellent
interface to scipy. Just because EE’s are trained in MATLAB, doesn’t
mean that it’s even a reasonable tool to use. Do you know of any
other language the allows only a single externally visible function
PER FILE??? Come on folks, stop drinking the kool-aid.

Absolutely. Matlab has been far too long teaching poor coding practices
to upcoming SDR and signal processing engineers. It’s a horrible
language that is really a very bad teaching tool for the future
challenges we face.

matplotlib supports pretty much all the high-level plotting features
found in MATLAB, and does it in Python, a language that provides a lot
more leverage than MATLAB. scipy’s got all the linear algebra, and
and ever expanding set of functions / toolboxes.

Scipy, numpy, and matplotlib have completely replaced my indoctrinated
use of Matlab from my EE undergrad days. They have almost as much in
their toolbase (if you are willing to pay the extra $200 for the Comms
toolbox, which requires the extra $200 for the signal processing toolbox
you get a few neat features not included in the free software world),
run faster, and actually use real coding practices like objects and
callback functions. No, I don’t consider how Matlab does them to be real
objects or real callback functions.

This has been a recent campaign of mine, so I had to add something to
the discussion.

Tom

cheap front end to a digital scope. I know alot of people use it(USRP)
for this but the real work and beauty of this project is the signal
processing blockset and framework to allow the construction of a radio.
I think the effort should be put into moving the GNU radio code forward
not trying to support a sideline application.

I know I will be in trouble with Eric for posting on this subject
again…

I would point out to Jeff L. that MATLAB has always been intended for
simulation,
not real-time operation. Everyone knows it can’t keep up.

The synergy of using it with GNU Radio would be to simulate a system
before
coding/implementing it entirely in GNU Radio. The common example is a
block diagram
where MATLAB is handling a few (typically new/advanced/experimental)
blocks in the
middle, with GNU Radio everywhere else, including RF analog I/O. Then
at some point
the simulation works and the focus moves to real-time operation without
MATLAB.

It’s been this way for years with many types of DSP and FPGA
hardware/software
set-ups. Get it simulated first, then move blocks out of MATLAB,
one-by-one. One
advantage of this technique is it provides a “known good” to fall back
on for debug
purposes.

I’m not commenting on merits of MATLAB vs. or merits of proprietary vs.
free, I’m
just saying that the “start with MATLAB simulation” approach is very
common in the RF
(and signal processing) developer communities. Supporting that approach
with GNU
Radio would only be advantageous to GNU Radio.

-Jeff

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs