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
On Wed, Apr 9, 2008 at 8:59 AM, Greg Troxel [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
Greg-
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 -
On Wed, Apr 9, 2008 at 7:38 AM, Tim Meehan [EMAIL PROTECTED] wrote:
I think there is a typo / bug in gri_wavfile.cc that prevents it from
working properly with big-endian machines.
Good catch. We had noted the failure of the QA code on big-endian
machines but hadn't had time to track it down.
Paul,
Would you mind sharing your implementation along with any accompanying
documentation? We are making some modifications to the FPGA firmware
ourselves (mods for a much more application specific usage) and while
I'm not sure how far we'll get with needing the 4-bit samples, we'd
On Wed, Apr 9, 2008 at 10:47 AM, Johnathan Corgan
[EMAIL PROTECTED] wrote:
On Wed, Apr 9, 2008 at 7:38 AM, Tim Meehan [EMAIL PROTECTED] wrote:
I think there is a typo / bug in gri_wavfile.cc that prevents it from
working properly with big-endian machines.
Good catch. We had noted the
Tim Meehan wrote:
removed the x (xtest - test)
QA check test passed
What is your processor/OS combination?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Wed, Apr 9, 2008 at 8:23 AM, Tim Meehan [EMAIL PROTECTED] wrote:
removed the x (xtest - test)
QA check test passed
Fixed in trunk revision r8163.
--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/
___
Discuss-gnuradio
On Wed, Apr 9, 2008 at 11:20 AM, Johnathan Corgan
[EMAIL PROTECTED] wrote:
Tim Meehan wrote:
removed the x (xtest - test)
QA check test passed
What is your processor/OS combination?
PS3 / Linux
___
Discuss-gnuradio mailing list
On Wed, Apr 9, 2008 at 11:38 AM, Jeff Brower [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
Pedro-
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
Greg-
On Wed, Apr 9, 2008 at 11:38 AM, Jeff Brower [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
On Wed, Apr 9, 2008 at 12:50 PM, Jeff Brower [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.
On Wed, Apr 09, 2008 at 10:38:23AM -0500, Jeff Brower wrote:
Greg-
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
On Wed, Apr 9, 2008 at 2:01 PM, Jeff Brower [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
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
When I tried to dump audio stream data into a file_sink, I found this
was doable on a Ubuntu 7.10 with Python 2.5 but not on a FC6 with Python
2.4. I had no clues so far why this happened. Any ideas?
Thanks.
- David
___
Discuss-gnuradio mailing
On Wed, Apr 09, 2008 at 01:29:55PM -0400, Philip Balister wrote:
On Wed, Apr 9, 2008 at 2:01 PM, Jeff Brower [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
On Wed, Apr 09, 2008 at 10:38:08AM -0700, Matt Ettus wrote:
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.
Matt-
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
On Wed, Apr 9, 2008 at 2:24 PM, Jeff Brower [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
This is primarily aimed at Josh, but I'll take advice from
anyone. :)
I've been using GnuRadio and GRC for about 9 months, and
built several successful receiver projects.
Recently, I've tried my first transmitter project and run into
a snag. According to our hardware spectrum analyzer, I'm not
Thanks for looking into the GCC 4.3 issue. I have successfully compiled
gnuradio with the previous GCC which will work fine for now, although I am glad
to see that the new one will be supported soon. Gotta love working in a field
of constant change :S
I would like to contribute to the
Casey Tucker wrote:
Thanks for looking into the GCC 4.3 issue. I have successfully
compiled gnuradio with the previous GCC which will work fine for now,
although I am glad to see that the new one will be supported soon.
Gotta love working in a field of constant change :S
I would like to
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
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
Josh Blum wrote:
What are the range of floating point numbers going into the usrp sink?
Some boards need amplitudes in the 10e3 floating point range.
-Josh
That was it. I was inadvertantly giving it numbers with a range
of plus or minus 1.0 ! +-16000 works nicely.
@(^.^)@ Ed
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
interface to scipy. Just because EE's are trained in MATLAB, doesn't
mean
We'll be looking into the possibility of contributing the new FPGA
configuration to GNU Radio once our code has been tested and refined.
--Paul
Tyrel Newton wrote:
Paul,
Would you mind sharing your implementation along with any accompanying
documentation? We are making some modifications
On Wed, Apr 09, 2008 at 03:45:56PM -0400, Kevin Rudd wrote:
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
On Wed, Apr 09, 2008 at 04:36:48PM -0400, Paul Creekmore wrote:
We'll be looking into the possibility of contributing the new FPGA
configuration to GNU Radio once our code has been tested and refined.
--Paul
Thanks!
Eric
___
Discuss-gnuradio
On Apr 9, 2008, at 4:56 PM, Eric Blossom wrote:
If somebody wants do do something useful that would forward the
action, I suggest investing the effort required to convert the
daughterboard code to C++. Johnathan has looked at this, and may
still have a developer branch around somewhere. If
Eric Blossom wrote:
I suggest investing the effort required to convert the daughterboard
code to C++. Johnathan has looked at this, and may still have a
developer branch around somewhere. If you're interested in working
on this, please post a note to the list, and Johnathan, Matt or I
will
On Wed, Apr 09, 2008 at 02:48:50PM -0700, Johnathan Corgan wrote:
There is a developer branch:
http://gnuradio.org/trac/browser/gnuradio/branches/developers/jcorgan/usrpdb
This branch has implemented the framework for a C++ implementation of
all the daughterboards, and several boards
Eric Blossom wrote:
For the USRP1, then, there needs to be a method on usrp_standard_rx and
usrp_standard_tx classes that produces one of these callback objects.
I'm assuming that this is just a simple C++ class with virtual methods.
Yes, it would derive from a the hwa virtual base class
Hi Paul and Tyrel,
I'm also in a similar situation to get the maximum bandwidth possible,
but just started... For me 2 bit quantization is sufficient
I've started modifying the FPGA firmware but I think it will take some
time before I implement and test it thoroughly..
Any approximate time
Well, I'm hoping to have 1, 2, 4, 8, and 16-bit quantization options
tested and working by the end of the month, if not within the next two
weeks. We're debugging an implementation right now.
But for full integration into GNU Radio, there are several other
considerations that my group has
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
38 matches
Mail list logo
