I know no one asked for it, but I am going to throw my two cents in on
this discussion.
I model and simulate RF systems in MATLAB all day long. Some of which
are very complex. MATLAB is easy to use and very powerful for that
purpose. It would be great to demonstrate the systems using the USRP.
I bought a USRP and many of the daughter boards. I played around with
it and GNU Radio for several months. Unfortunately, it now sits in my
office unused. It is unfortunate, because I know how useful it can be.
I hope that one day I can use it for my needs.
Kevin
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
num.transpose(A).cong()
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 system.
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
interfaces,
that the user can choose between the environment he likes.
Matlab, Octave and C++ are very important tools for signal processing
and analysis.
On Wed, Aug 04, 2010 at 06:16:44PM +0200, Moeller wrote:
On 09.04.2008 18:08, 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
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.
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.
Please send a patch to fix the comments.
I didn’t change those manually, instead I wrote a bash script for this
task,
see attachment. It can patch all octave-scripts at once.
But this is not perfect. In octave both ! and ~ allowed for negating,
in matlab just ~. This is not handled. I made no tests, since I
use my own signal processing and analysis toolbox.
There is a better converter:
but this also replaces functions calls, which may result in
octave-incompatible code.
It always has to be tested for compatibility. There are some
differences between Octave and Matlab, concerning
available commands and so called ‘object oriented’ functions.
Sometimes it works without modifications, sometimes not.
At least for my code, I try do avoid proprietary specials.
It’s an ideological question (promoting Octave over Matlab),
whether we want the Octave-only style (which looks better indeed),
or a Matlab-compatible style.I don’t want to judge about this,
since I didn’t contribute to the gnuradio code (yet).