[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Matlab interface to USRP

From: Moeller
Subject: Re: [Discuss-gnuradio] Matlab interface to USRP
Date: Wed, 04 Aug 2010 18:16:44 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100713 Thunderbird/3.1.1

 On 09.04.2008 18:08, Eric Blossom 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
Why making a difference? Most code is compatible between Octave and Matlab.
Even Matlab C++ MEX functions compile very well in Octave.
The Octave scripts in gnuradio are not working in Matlab, because they use
Octave-specials (comments as ## instead of %%, endfor instead of end).
I'm used to code in a style that both Matlab and Octave understand.

> 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.
This function-per-file ideology is the most annoying thing about this language, 
that's true.
But when playing around with signal samples, you can do very complex things with
just a few commands in Matlab. Python is far more "chatty". All the "self." 
statesments in Python
code don't look very elegant. They don't follow the "don't repeat yourself" 
rule of coding.
Mathematical formulas in Python don't look very elegant with 
instead of just A' in Matlab (the mathematical style).
And you first have to think about a long import list before starting even 
simple one-liners.
This is Ok for large software projects, but not for interactive experiments.

On the other hand, Python has advantages with more "computer science" oriented
features like multithreaded modules for data streams.
So, listening live to a radio channel is fine in gnuradio.
For offline data analysis I would still prefer Matlab or Octave.

There is not a single "reasonable" software tool for all purposes.

>> 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.
Matlab is a reasonable language for certain situations and applications.
Especially for an easy way of interactive numerical and graphical data analysis.
The "bash" language is also reasonable when communicating with your operating 
Or did you see anybody using Python as an OS shell ?

The only thing I miss, that professors do not promote the free alternatives 
SciLab and Octave.

I think for gnuradio and USRP it would be best to provide multilingual 
that the user can choose between the environment he likes.
Matlab, Octave and C++ are very important tools for signal processing and 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]