Re: [Discuss-gnuradio] Matlab interface to USRP

[Jeff Brower]

> 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.

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

I would point out to Jeff Long 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

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of
> Gregory Maxwell
> Sent: Wednesday, April 09, 2008 2:42 PM
> To: Jeff Brower
> Cc: Matt Ettus; address@hidden
> Subject: Re: [Discuss-gnuradio] Matlab interface to USRP
> 
> On Wed, Apr 9, 2008 at 2:24 PM, Jeff Brower <address@hidden>
> 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.
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio