Re: [Discuss-gnuradio] libusrp/libusrp2 vs uhd plans

2010-04-26 Thread Charles Herdt
 Thank you so much for the quick reply.
 Just to add: The LICENSE file on the git repository states GPL v3.

 Perhaps I should have made the question a bit clearer: my concern was
over the future releases of it, and Matt has nailed it.
 Really happy to see the way things are being conducted.
 Cheers :)

 Charles


On Mon, Apr 26, 2010 at 4:27 PM, Johnathan Corgan
 wrote:
> On Mon, Apr 26, 2010 at 12:16, Charles Herdt  wrote:
>
>>  Do we have any details on licensing of the UHD?
>>  You mentioned full FSF only for libusrp. Will UHD be closed source?
>
> I'll answer this briefly now in case Matt doesn't see this for a
> while, though I can't speak for Ettus Research.
>
> In short, UHD will be copyright Ettus Research and licensed for use
> using GPL (I don't think the GPL version number has been announced).
> In addition, it will also be available for licensing to third parties
> with non-GPL licenses for use in environments besides GNU Radio.  The
> source code in its current state has already been published as a git
> repository.
>
> Johnathan
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] libusrp/libusrp2 vs uhd plans

2010-04-26 Thread Charles Herdt
 Johnathan or Matt

 Do we have any details on licensing of the UHD?
 You mentioned full FSF only for libusrp. Will UHD be closed source?

 Charles

On Mon, Apr 26, 2010 at 2:17 PM, Johnathan Corgan
 wrote:
> As Ettus Research has announced the UHD software support for USRP1 and
> USRP2 is stabilizing.  There are many long awaited features that will
> become part of this next generation code, and the question has come up
> about the future of the current GNU Radio support for this hardware.
>
> We will address this in three stages.
>
> Firstly, the current libusrp/libusrp2/gr-usrp/gr-usrp2 components will
> become part of the 3.3 stable release series.  This is intended as a
> measure to support existing user code that depends on this
> functionality, and we will maintain this with bug fixes as needed.
> The GNU Radio release tarballs will include the host and firmware
> code, and the gnuradio.org website will host binaries for the
> associated FPGA image and firmware images.  The corresponding FPGA
> source code will continue to be hosted/distributed by Ettus Research.
> This gives long-term support for existing users who do not plan to
> upgrade.
>
> Secondly, during the 3.4 development series, we will incorporate the
> gr-uhd GNU Radio host code blocks, and begin transitioning our
> examples, demos, and other code that uses gr-usrp/gr-usrp2 to use
> gr-uhd instead.  This will be gated by available
> functionality/stability of the Ettus Research code.
>
> Finally, also during the 3.4 development series, we will extract the
> libusrp/libusrp2 code (but not gr-usrp or gr-usrp2) into its own
> stand-alone distribution and remove it from GNU Radio proper.  This
> will give developers the choice of installing the "FSF" version of the
> libraries or the Ettus Research libraries (or both) as desired, and
> GNU Radio will install gr-usrp/gr-usrp2 and/or gr-uhd depending on
> what was detected during configuration.
>
> It is intended that as of stable series 3.4, future GNU Radio
> development will continue around the Ettus Research UHD code features,
> and only critical bug fixes in the stand-alone FSF library be
> considered.
>
> Please feel free to respond with any questions/concerns.
>
> Johnathan Corgan
>
>
> ___
> 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] USRP2 Diagnostics in GRC

2010-03-31 Thread Charles Herdt
 Umair

 It seems to me you are using the USRP block when you should be using the USRP2.
 If not... which version of Gnuradio are you using?

 Charles

On Wed, Mar 31, 2010 at 11:19 AM, Umair Naeem  wrote:
> Hi,
>
> I have a problem concerning USRP2. I am using GRC to make flow graphs but I 
> can not find USRP2 when I use USRP source block. When I run a simple program 
> with only two blocks (USRP source and Scope Sink) I get  following error:
>
 Verbose:
> usrp: failed to find usrp[0]
> Traceback (most recent call last):
>  File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 231, in OnInit
>    self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first 
> argument is the flow graph
>  File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 159, in __init__
>    FlowGraphBuilder.__init__(self, file_path)
>  File "/usr/share/grc/src/ExecFlowGraph.py", line 50, in __init__
>    self._parse_nested_data(ParseXML.from_xml(ParseXML.from_file(file_path)))
>  File "/usr/share/grc/src/ExecFlowGraph.py", line 145, in _parse_nested_data
>    signal_blocks_dict[signal_block.get_id()] = 
> runnable_signal_block(*data_type_params)
>  File "/usr/share/grc/src/SignalBlockDefs/USRP.py", line 182, in make
>    u = type.parse()[0](number, nchan=1)
>  File "/usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py", line 
> 1699, in source_c
>    return _usrp_swig.source_c(*args, **kwargs)
> RuntimeError: can't open usrp
>
>
> I also tried using USRP Diagnostics in Help menu but it also does nt detect.
> I run find_usrps through terminal and it works like,
> 00:50:c2:85:34:6f hw_rev = 0x0400
>
>
> Regards,
> Umair Naeem
> MSc Communication Engineering
> Chalmers University ot Technology, Sweden.
>
>
> ___
> 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] GR on CentOS 5 x64_64?

2010-01-13 Thread Charles Herdt
 Hi Michael

 I haven't installed gnuradio on CentOS in a while (since gr 1.3.1),
but these instructions should point you to the right direction.
 To install properly on CentOS 5, you'll be better off installing the
RPMForge repository for packages.

(instructions to add rpmforge:)
http://wiki.centos.org/AdditionalResources/Repositories/RPMForge?action=show&redirect=Repositories/RPMForge

Once rpmforge is ok, try yum upgrade and then the following command:

yum groupinstall "Engineering and Scientific" "Development Tools" -y
&& yum install fftw-devel cppunit-devel wxPython-devel libusb-devel
guile boost-devel alsa-lib-devel gsl-devel python-devel pygsl
python-cheetah python-lxml zlib-devel glib2-devel python-numpy -y

 This should set you up with most of what's needed to compile gnuradio.
 Unfortunately rpmforge doesn't have (or didn't use to have) all
that's needed for gnuradio, so some stuff still has to be done by
hand:

SDCC:
http://sourceforge.net/projects/sdcc/files/sdcc/sdcc-src-2.9.0.tar.bz2/download
(needed for USRP support)

SWIG:
http://sourceforge.net/projects/swig/files/

FFTW:
http://www.fftw.org/download.html
Make sure you configure FFTW with the --enable-float and --enable-shared
./configure --enable-float --enable-shared

Libjack (only if you want jack audio)
http://jackaudio.org/downloads/jack-audio-connection-kit-0.116.2.tar.gz

After compiling and installing (configure, make, make install) all of
those, you should be all set to compile gnuradio.
Last time I tried this was with 1.3.1, so some minor adjustments may
be needed if you will be compiling the latest sources.
If your processing is the bottleneck, make sure you stick to 86_64
kernel as it gives you roughly twice as much sample processing power
if compared to the 32 bit kernel on the same machine.

Good luck!
Charles

On Wed, Jan 13, 2010 at 12:09 PM, Michael Dickens  wrote:
> I'm wondering if anyone has successfully installed GR on CentOS 5 x86_64,
> and if so any advice would be appreciated.  Thanks in advance. - MLD
>
> I've been trying to install GNU Radio on CentOS 5 x86_64.  I get some of the
> dependencies from yum, but I'm having to find alternative repositories for
> some, and even compiling some by hand (gasp!).  IMHO, it's never a good
> thing to combine too many install locations when building any reasonably
> complex package (e.g., GNU Radio).
>
> Anyway, I can get to the point of compiling GR -- configure seems to find
> everything it needs -- but during linking of gruel LD spits out a whole slew
> of library dependency issues and finally exits with an error that it can't
> like the library since it can't find some system library.  I think this is a
> 32/64-bit issue, but as this is my first real venture in 32/64 bit territory
> on Linux it's just my best guess.
>
> I don't have that particular terminal in front of me to write specifically
> what the error is.  I've search the internet for various combinations of GR
> and centos, and all of the hits are old and not relevant -- most are from
> the GR discuss list a couple years back.
>
>
>
> ___
> 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] GNUradio debugging and stepping

2009-12-03 Thread Charles Herdt
 Hi Jason

 I've been wanting something like that also, and one of the tricks
that have been working well is to dump the streams to a file.
 If you want to visualize everything in sync, you can interleave
samples from different points of the flow graph and sink it to a file.
 You can use audacity to import the raw samples for easy visualization.
 I'd be curious to know of other solutions for this.

 Charles

On Thu, Dec 3, 2009 at 2:49 PM, Jason Uher  wrote:
> All,
>
> I was wondering if there was a simple method that allows someone to
> step through a gnuradio flow graph like you might when using a
> debugger.  I have tried using gdb, but the swig/python stuff gives a
> whole lot of clutter.
>
> I'm not even sure it's possible given the way the gnuradio handles
> scheduling, but is there a way to build a graph and step through it
> sample by sample, watching the outputs from each block?
>
> Thanks,
> Jason
>
>
> ___
> 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


[Discuss-gnuradio] Re: Jack instead of ALSA

2009-11-18 Thread Charles Herdt
 Just in case someone else has the same problem:

 if you need to force Jack audio:

 from gnuradio import audio_jack

 and on the source/sink linles, use audio_jack.source or
audio_jack.sink instead of audio.source and audio.sink.

 Thanks to Oswald Berthold for the help.

 Best regards,
 Charles

On Tue, Nov 17, 2009 at 9:54 PM, Charles Herdt  wrote:
>  Hello
>
>  Hoping anyone had gone through this before.
>  I am trying to make some experiments with jack audio in linux (Ubuntu
> 9.10), but so far, all I could get is Alsa.
>  I'm using the audio.sink and audio.source blocks, and have not yet
> figured out a way for it to use Jack.
>  I have jack audio compiled in gnurario 3.2.2.
>  Any suggestions?
>
>  Thank you in advance,
>  Charles A. Herdt
>


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Jack instead of ALSA

2009-11-17 Thread Charles Herdt
 Hello

 Hoping anyone had gone through this before.
 I am trying to make some experiments with jack audio in linux (Ubuntu
9.10), but so far, all I could get is Alsa.
 I'm using the audio.sink and audio.source blocks, and have not yet
figured out a way for it to use Jack.
 I have jack audio compiled in gnurario 3.2.2.
 Any suggestions?

 Thank you in advance,
 Charles A. Herdt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio