Re: [Discuss-gnuradio] Matlab interface to USRP
"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/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 - 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. 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 > 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/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] bug / typo in gri_wavfile.cc (gr_wavfile_source)
Hello All,
I think there is a typo / bug in gri_wavfile.cc that prevents it from
working properly with big-endian machines.
Please see patch below.
Index: gnuradio-core/src/lib/io/gri_wavfile.cc
===
--- gnuradio-core/src/lib/io/gri_wavfile.cc (revision 8162)
+++ gnuradio-core/src/lib/io/gri_wavfile.cc (working copy)
@@ -71,7 +71,7 @@
static inline int16_t
host_to_wav(int16_t x)
{
- return bswap_32(x);
+ return bswap_16(x);
}
static inline uint32_t
@@ -89,7 +89,7 @@
static inline int16_t
wav_to_host(int16_t x)
{
- return bswap_32(x);
+ return bswap_16(x);
}
#else
Tim
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Patch-gnuradio] bug / typo in gri_wavfile.cc (gr_wavfile_source)
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. Could you try editing gnuradio-core/src/python/gnuradio/gr/qa_wavefile.py and remove the leading 'x' from line 43? This will reenable the QA check (which passes on little-endian machines.) -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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: 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP w/ 4-bit I&Q samples
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 happily share any test/usage results if we get there. Tyrel On Apr 8, 2008, at 9:18 AM, Paul Creekmore wrote: Tyrel, The current FPGA configuration does not support 4-bit samples, but it is possible to modify the configuration (Verilog code) to convert the samples to 4-bit. My research group is currently working on adding 1, 2, and 4-bit quantization options to the USRP, as well as accompanying data packing to maximize the number of samples that we can squeeze across the USB interface and thus also the receivable signal bandwidth. We've not yet tested the modifications. --Paul Tyrel Newton wrote: We have an application where the overall accuracy of the A/D converter is not terribly important but where we need as high a sampling rate as we can get. To this end, we found and intend to use the 8-bit option that allows for 8-bit I and Q signals instead of the normal 16-bit. However, is there a similar option that allows for 4-bit I and Q samples? Or similarly, would it be relatively easy to implement a 4-bits per sample scheme, possibly w/ slight modifications to the USRP firmware? Any feedback and/or advice is greatly appreciated. Regards, Tyrel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Patch-gnuradio] bug / typo in gri_wavfile.cc (gr_wavfile_source)
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 failure of the QA code on big-endian > machines but hadn't had time to track it down. > > Could you try editing > gnuradio-core/src/python/gnuradio/gr/qa_wavefile.py and remove the > leading 'x' from line 43? This will reenable the QA check (which > passes on little-endian machines.) removed the x (xtest -> test) QA check test passed > > -- > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com/ > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Patch-gnuradio] bug / typo in gri_wavfile.cc (gr_wavfile_source)
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
[Discuss-gnuradio] Re: [Patch-gnuradio] bug / typo in gri_wavfile.cc (gr_wavfile_source)
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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Patch-gnuradio] bug / typo in gri_wavfile.cc (gr_wavfile_source)
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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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: 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 >>- Original Message - >>From: "Pu, Di" <[EMAIL PROTECTED]> >>To: >>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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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. 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... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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. > 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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 :) Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
Eric- > 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 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. > >> 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A file_sink question
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 list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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 :) Would somebody hurry up and code up the C++ daughterboard support? That would solve many problems ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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. 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 Very nicely put. Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] No Tx output from any daughterboards
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 getting any RF output. I've tried using a Basic-Tx, an LFTX, an RFX-900, and an RFX-2400. The Basic and the LFTX put out nothing, and the two RFX boards put out a feeble carrier at about -80dbm. This is so weak that the LO leakage swamps it (we read that at about -60dbm, 4 MHz above of the carrier). I even tried a different USRP motherboard and TX daughterboard that were borrowed from another project and known to be working, with the same results. So I'm pretty sure it's not a HW problem. And I can't believe there would be such a fundamental flaw in the GRC/GnuRadio combination, so I've got to believe it's a configuration problem. I must be missing something really stupid! Here's my setup information: GnuRadio 3.1.1 (release version) GRC 0.69 (release version) USRP Rev 4.5 Mac OSX 10.4.11 (Intel Core2-Duo) When I setup the TX daughterboards in GRC, here's the parameters I use: Basic-TX or LFTX: Unit: 0 Side: Side B Freq: 3000 Interp: 20 Gain: 0 Mux: 0x0 (0 causes automatic calculation) Auto T/R: Ignore (only used on Flex dboards) TX Enab: Ignore (only used on Flex dboards) RFX-900: Unit: 0 Side: Side A Freq: 10 Interp: 20 Gain: 0 Mux: 0x0 (0 causes automatic calculation) Auto T/R: Ignore TX Enab: Enable RFX-2400 Unit: 0 Side: Side A Freq: 24 Interp: 20 Gain: 0 Mux: 0x0 (0 causes automatic calculation) Auto T/R: Ignore TX Enab: Enable What am I missing??? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Archlinux
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 Trac/Wiki in regards to making it work on Archlinux, as when I go through the steps of making it work on Arch, I usually just refer to a cross-section of Gentoo, Ubuntu, and Fedora (and all the others, grr). Do I need to just email Eric about this, or is there a way that I can personally maintain that section of the Wiki? _ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_skydrive_packup_042008 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Archlinux
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 contribute to the Trac/Wiki in regards to making it work on Archlinux, as when I go through the steps of making it work on Arch, I usually just refer to a cross-section of Gentoo, Ubuntu, and Fedora (and all the others, grr). Do I need to just email Eric about this, or is there a way that I can personally maintain that section of the Wiki? The wiki is always open to editing! login: guest password: gnuradio - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: Matlab interface to USRP
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Matlab interface to USRP
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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregory Maxwell Sent: Wednesday, April 09, 2008 2:42 PM To: Jeff Brower Cc: Matt Ettus; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Matlab interface to USRP 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 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No Tx output from any daughterboards SOLVED
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
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 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP w/ 4-bit I&Q samples
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 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 happily share any test/usage results if we get there. Tyrel On Apr 8, 2008, at 9:18 AM, Paul Creekmore wrote: Tyrel, The current FPGA configuration does not support 4-bit samples, but it is possible to modify the configuration (Verilog code) to convert the samples to 4-bit. My research group is currently working on adding 1, 2, and 4-bit quantization options to the USRP, as well as accompanying data packing to maximize the number of samples that we can squeeze across the USB interface and thus also the receivable signal bandwidth. We've not yet tested the modifications. --Paul Tyrel Newton wrote: We have an application where the overall accuracy of the A/D converter is not terribly important but where we need as high a sampling rate as we can get. To this end, we found and intend to use the 8-bit option that allows for 8-bit I and Q signals instead of the normal 16-bit. However, is there a similar option that allows for 4-bit I and Q samples? Or similarly, would it be relatively easy to implement a 4-bits per sample scheme, possibly w/ slight modifications to the USRP firmware? Any feedback and/or advice is greatly appreciated. Regards, Tyrel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] C++ daughterboard code [was MATLAB...]
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 > 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 OK guys, Thanks for all your comments re MATLAB. I'm declaring the topic closed. 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 you're interested in working on this, please post a note to the list, and Johnathan, Matt or I will give you our two cents worth about how we think it should work. Thanks again! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP w/ 4-bit I&Q samples
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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] C++ daughterboard code [was MATLAB...]
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 you're interested in working on this, please post a note to the list, and Johnathan, Matt or I will give you our two cents worth about how we think it should work. I could be talked into doing that. It would benefit my current efforts greatly. Please do send out (to the list, or me specifically) your US$0.02 worth. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] C++ daughterboard code [was MATLAB...]
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 give you our two cents worth about how we think it should work. 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 already implemented, but with a twist--it is designed to be used unchanged with both USRP1 and USRP2. The daughterboard C++ code itself is very straightforward. The key concept is abstracting out the USRP motherboard specific actions (e.g., set_pga_gain, write_i2c_register, etc.) which work via completely different underlying mechanisms between USRP1 and USRP2. The constructor for the daughterboard class takes a pointer an "hwa" object that encapsulates the differences between these environments, and the daughterboard class makes callbacks on this object to get things done. 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. For USRP1 with in-band signaling, there might need to be a different hwa object; I'm not sure as I'm not familiar with the code and whether it uses usrp_standard_*x underneath or replaces them. For USRP2, we will write the hardware access layer to abstract out the technique for accessing all the functionality over the Ethernet. (From the user API perspective, they won't see this hwa object, because the USRP daughterboard instantiate framework will handle it for him.) Once these hardware access shims are written, all the daughterboard code is usable unchanged, since it just making callbacks to the abstraction layer. In fact, there is a "hwa_qa" class now, which provides stubs for all the hwa methods and is used in the QA unit testing framework to test the daughterboard code for correctness. Once that is working, there is still the issue of migrating the Python-based daughterboard instantiation framework. It currently uses some clever Python coding to auto-detect the type of daughterboards connected to a USRP, then populate the usrp.db[][] database as appropriate. But it is doing it using features available in a late-binding, non-compiled language. The net is that none of this code will port to C++, the feature has to be written from scratch in C++. I have started it, but don't have time to finish it. I do think it is far enough along that someone can pick it up and I'm willing to help them to do so. Or, if someone wants to do a USRP1-only C++ implementation and rewrite major portions of it for USRP2, that's okay too. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] C++ daughterboard code
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 already implemented, but with > a twist--it is designed to be used unchanged with both USRP1 and USRP2. > The daughterboard C++ code itself is very straightforward. > > The key concept is abstracting out the USRP motherboard specific actions > (e.g., set_pga_gain, write_i2c_register, etc.) which work via completely > different underlying mechanisms between USRP1 and USRP2. The > constructor for the daughterboard class takes a pointer an "hwa" object > that encapsulates the differences between these environments, and the > daughterboard class makes callbacks on this object to get things done. > > 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. > For USRP1 with in-band signaling, there might need to be a different hwa > object; I'm not sure as I'm not familiar with the code and whether it > uses usrp_standard_*x underneath or replaces them. I think for a first pass, it can be the same as the existing USRP. At this stage in the game, the inband stuff is mostly about being able to send and receive frames at particular times, rather than being able to tweak for example the i2c inband. > For USRP2, we will write the hardware access layer to abstract out the > technique for accessing all the functionality over the Ethernet. > > (From the user API perspective, they won't see this hwa object, because > the USRP daughterboard instantiate framework will handle it for him.) > > Once these hardware access shims are written, all the daughterboard code > is usable unchanged, since it just making callbacks to the abstraction > layer. In fact, there is a "hwa_qa" class now, which provides stubs for > all the hwa methods and is used in the QA unit testing framework to test > the daughterboard code for correctness. > > Once that is working, there is still the issue of migrating the > Python-based daughterboard instantiation framework. It currently uses > some clever Python coding to auto-detect the type of daughterboards > connected to a USRP, then populate the usrp.db[][] database as > appropriate. But it is doing it using features available in a > late-binding, non-compiled language. The net is that none of this code > will port to C++, the feature has to be written from scratch in C++. > > I have started it, but don't have time to finish it. I do think it is > far enough along that someone can pick it up and I'm willing to help > them to do so. Or, if someone wants to do a USRP1-only C++ > implementation and rewrite major portions of it for USRP2, that's okay too. Following up on Johnathan's post, I think the way forward is to create a new developer branch by copying the trunk, then merge Johnathan's diffs into that. His branch is currently at least 2 months old. I would stick with the hardware abstraction (hwa_*). We're going to need it very soon with the USRP2. I really would like it done right the first time. I don't think the instantiation framework is going to be any big deal in C++. We basically just need to invoke the right daughterboard constructor based on the daughterboard ID feteched from the EEPROM. We'll probably end up needing to move some of the code that's currently in usrp.py into new C++ methods that'll handle the "two stage tuning" calculations, etc. Again, no big deal. After you get a chance to look at the existing work-in-progress, let me know if you've got more questions. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] C++ daughterboard code
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 and override the methods and supply the relevant implementations. The hwa_qa class is a good example. > At this stage in the game, the inband stuff is mostly about being able > to send and receive frames at particular times, rather than being able > to tweak for example the i2c inband. Okay, if the underlying function call->USB->FX2->[I2C|SPI] paths are still available, then a separate in-band hwa class isn't needed. > Following up on Johnathan's post, I think the way forward is to create > a new developer branch by copying the trunk, then merge Johnathan's > diffs into that. His branch is currently at least 2 months old. It should merge fairly cleanly as a new top-level component, usrpdb. There might be some interaction with the build system changes Michael did about that time, though I think he made some changes directly in the branch to avoid this. > I would stick with the hardware abstraction (hwa_*). We're going to > need it very soon with the USRP2. I really would like it done right > the first time. Agree. > I don't think the instantiation framework is going to be any big deal > in C++. We basically just need to invoke the right daughterboard > constructor based on the daughterboard ID feteched from the EEPROM. >From the user API view, I think the usrp_standard_rx or usrp_standard_tx classes should have a db() method that returns an array of instantiated daughterboard shared pointers. This allows non-GNU radio USRP users to access all the hardware functionality of the motherboard and daughterboards in a traditional function call environment. This could be a fixed-length array or an STL vector. > We'll probably end up needing to move some of the code that's > currently in usrp.py into new C++ methods that'll handle the "two > stage tuning" calculations, etc. Again, no big deal. Thanks, Michael, for picking this up. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP w/ 4-bit I&Q samples
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 frame that you are planning to complete this activity? I'm also keen to contribute if I'm fast enough.. Nagaraj, PhD Candidate, University of New South Wales On Thu, Apr 10, 2008 at 6:36 AM, Paul Creekmore <[EMAIL PROTECTED]> 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 > > > > > Tyrel Newton wrote: > 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 happily > share any test/usage results if we get there. > > > Tyrel > > > On Apr 8, 2008, at 9:18 AM, Paul Creekmore wrote: > > > Tyrel, > > The current FPGA configuration does not support 4-bit samples, but it is > possible to modify the configuration (Verilog code) to convert the samples > to 4-bit. > > My research group is currently working on adding 1, 2, and 4-bit > quantization options to the USRP, as well as accompanying data packing to > maximize the number of samples that we can squeeze across the USB interface > and thus also the receivable signal bandwidth. We've not yet tested the > modifications. > > --Paul > > Tyrel Newton wrote: > We have an > application where the overall accuracy of the A/D converter is not terribly > important but where we need as high a sampling rate as we can get. To this > end, we found and intend to use the 8-bit option that allows for 8-bit I and > Q signals instead of the normal 16-bit. However, is there a similar option > that allows for 4-bit I and Q samples? Or similarly, would it be relatively > easy to implement a 4-bits per sample scheme, possibly w/ slight > modifications to the USRP firmware? Any feedback and/or advice is greatly > appreciated. > > Regards, > Tyrel > > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP w/ 4-bit I&Q samples
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 not been addressing. We're only writing data to disk, using our own C++ program that uses only the lower-level GNU Radio libraries to access and control the USRP. I don't have a very good sense as to what it would take to "propagate" new quantization options throughout the rest of GNU Radio to make them available to the higher-level Python scripts. The data needs to be unpacked somewhere along the way, too. Additionally, the existing quantization algorithm that converts 16-bit samples to 8-bit samples looks like it may not be the best for lower quantization levels. So while I expect to have the USRP soon delivering quantized, packed data, handling it on the host side in GNU Radio is another task. --Paul Nagaraj C Shivaramaiah wrote: 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 frame that you are planning to complete this activity? I'm also keen to contribute if I'm fast enough.. Nagaraj, PhD Candidate, University of New South Wales On Thu, Apr 10, 2008 at 6:36 AM, Paul Creekmore <[EMAIL PROTECTED]> 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 Tyrel Newton wrote: 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 happily share any test/usage results if we get there. Tyrel On Apr 8, 2008, at 9:18 AM, Paul Creekmore wrote: Tyrel, The current FPGA configuration does not support 4-bit samples, but it is possible to modify the configuration (Verilog code) to convert the samples to 4-bit. My research group is currently working on adding 1, 2, and 4-bit quantization options to the USRP, as well as accompanying data packing to maximize the number of samples that we can squeeze across the USB interface and thus also the receivable signal bandwidth. We've not yet tested the modifications. --Paul Tyrel Newton wrote: We have an application where the overall accuracy of the A/D converter is not terribly important but where we need as high a sampling rate as we can get. To this end, we found and intend to use the 8-bit option that allows for 8-bit I and Q signals instead of the normal 16-bit. However, is there a similar option that allows for 4-bit I and Q samples? Or similarly, would it be relatively easy to implement a 4-bits per sample scheme, possibly w/ slight modifications to the USRP firmware? Any feedback and/or advice is greatly appreciated. Regards, Tyrel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Matlab interface to USRP
> 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Gregory Maxwell > Sent: Wednesday, April 09, 2008 2:42 PM > To: Jeff Brower > Cc: Matt Ettus; discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Matlab interface to USRP > > 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 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 > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
