Re: [Discuss-gnuradio] GNU Radio 2.6 release!
On Tue, 13 Dec 2005 15:18, Eric Blossom wrote: On Sun, Dec 11, 2005 at 02:03:52PM +1030, Berndt Josef Wulf wrote: On Sun, 11 Dec 2005 12:05, Lamar Owen wrote: On Saturday 10 December 2005 20:41, Berndt Josef Wulf wrote: I should correct this. The documentation for gnuradio-core doesn't get installed using the new tarballs, however, other docs such as those for the usrp module are installed. Has anyone built and installed the new release using the tarballs and did it install the docs for gnuradio-core? Did you download the gnuradio-core-2.6-doc.tar.gz? Thanks for the info. I haven't downloaded gnuradio-core-2.6-doc.tar.gz as it's not mentioned on the download page. I'm was unaware that the docs have now been split. Just to clarify, the docs haven't been split off, they're just not built by default. The time it was taking was generating complaints from several quarters. I don't understand what the fuss is all about. It takes 11m1s to build all the binaries and documentation of all GNU Radio 2.6 modules supported by the NetBSD packages sytem from scratch on my laptop. The time it takes to generate the gnuradio-core documentation is 1m21s which is merely 10% of the total time taken to rebuild GNU Radio. What are these people running? Sinclair Pocket PCs? :-) NetBSD uses a later version of doxygen namely doxygen-1.4.5. It supports many new features, has seen many bugfixes and hence creates a different set of doc files. Perhaps its faster too... ;-) How about a --enable-build-docs configure switch to enable users to make that decision at the configuration stage? To build them: $ cd gnuradio-core/doc $ make; make install The above doesn't work but the procedure below will produce the desired outcome. cd gnuradio-core/doc make docs make install gnuradio-core-2.6-doc.tar.gz is the output of doxygen, and was primarily uploaded to fix a link on the main web page that says 2.x Docs (Download) Sorry for any confusion or inconvenience. cheerio Berndt pgprH0Ww9G81A.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sparc -- x86 data exchange
At 08:00 PM 12/15/2005 -0500, Dave Dodge spoke and all was made clear: sparc: 11 22 33 44 x86: 44 33 22 11 OIC. Ok, switching to 2-byte short data and using dd conv=swab, a dial tone file created on a sparc plays fine on the intel box now. Thanks very much. Ideally the endian conversions would be done in processing blocks. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 2.6 release!
On Sat, Dec 17, 2005 at 12:53:01AM +1030, Berndt Josef Wulf wrote: I don't understand what the fuss is all about. It takes 11m1s to build all the binaries and documentation of all GNU Radio 2.6 modules supported by the NetBSD packages sytem from scratch on my laptop. The time it takes to generate the gnuradio-core documentation is 1m21s which is merely 10% of the total time taken to rebuild GNU Radio. What are these people running? Sinclair Pocket PCs? :-) NetBSD uses a later version of doxygen namely doxygen-1.4.5. It supports many new features, has seen many bugfixes and hence creates a different set of doc files. Perhaps its faster too... ;-) Some version's of doxygen in wide circulation are *really* slow. Also, do you have dot installed? If so, additional time is spent generating graphs. On my opteron, it takes over 7 minutes to generate the docs with doxygen 1.4.1 and dot 2.2. How about a --enable-build-docs configure switch to enable users to make that decision at the configuration stage? A patch to configure.ac would be welcome! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Making a new packet_sink
Eric, I found my problem. I needed to use a different name for my new version of the packet_sink function even though it was going to be in my package group. Call it mr_packet_sink versus the original gr_packet_sink was not enough. SWIG could not rename my mr_packet_sink. The other porblem I found was that after making and installing my new block, I needed to manually copy the files _mr.la and _mr.so to my new block subdirectory /src/lib. Also I have added the location of my blocks to the PYTHONPATH name. I have made a 16 bit version of the CRC32 code. Would you like to include this code with the rest of gnuradio code? If you do, please help me with the following I have been trying to install this code with the general gnuradio core but I have not been successful. I get it to compile and install with the rest of the gnuradio-core-2.6 but it does not show up when I import gr. I have generate gr_crc16.cc, gr_crc16.h and gr_crc16.i in the gnuradio-core-2.6/src/lib/general directory (just like the crc32 file). I add added the approprite line in the Makefile.am and general.i (saw that there was an entry here for crc32 file). Is there another location I need to add code so that it will be available with the import gr? Mike mail2web - Check your email from the web at http://mail2web.com/ . ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Linux DSP attempt 2
I'll try to clarify my original question: I'm looking for low end DSPs which cannot run linux. Instead I'd like to find a low end DSP which has development tools like gcc that can be run on the developer's linux workstation. Does anyone know of anything like this? Some of the older TI DSPs met this criterion but they're expensive and no longer in production. A lot of the higher end DSPs have development tools that can be used in linux but they're very expensive. My targe cost for the chip is $20. Sorry for the ambiguity, -David Carr On Thu, Dec 15, 2005 at 02:21:03AM -0600, David Carr wrote: Does anyone know of any semi-modern DSP platforms that have a good linux/open source development chain? To clarify I'm looking for relatively low end DSPs that can worked with in a linux environment rather than DSPs which run linux. Thanks, David Carr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I am using the Analog Devices Blackfin with GCC. The blackfin is fairly high end. My board has a single core at 390MHz, and there is a dual core part that can run 750MHz. I am not using Linux on it, but an developing my own RTOS which should be ready within the next month. The SDR board using this is still a work in progress. I should be building a prototype soon. -- Darrell Harmon http://dlharmon.com/dspcard ___ 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] 64 bit
Just curious - how much might gnuradio benefit from running on 64 bit processors and how much of a rewrite would it take, to take full advantage of, say, an Athlon 64 X2, seeing as you could theoretically chunk thru twice the data every bus clock? I guess the Solaris build doesn't take advantage of the UltraSparc II's. A little benchmarking with a 300Mhz processor and a short graph: noise source -- throttle -- low pass filter -- null sink using 100Khz sample rate and 67 tap filter uses 80% of one cpu. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP on NetBSD, partly/mostly working now
I have been building GNU Radio from CVS on NetBSD, with all the prereqs installed via pkgsrc. I had a few minor problems which I'll list here in case they are useful to others. I made a wiki node: http://comsec.com/wiki?NetBSD 1) buildit assumes that everything is in /usr, or perhaps that everything is in the compiler's default paths. This isn't true on NetBSD. I added LDFLAGS=-R/usr/pkg/lib -L/usr/pkg/lib CPPFLAGS=-I/usr/pkg/include to resolve this, but obviously that's not portable. One could argue that such flags for the prefix should be added automatically, but it also might be that GNU Radio is being put in /usr/gnuradio while boost, swig, etc. are in the standard place. So, adding --use-prefix=FOO that adds flags for it (with -R on systems that use -R) could be useful, or perhaps even doing this by default per OS - buildit is meant to be maximally helpful, not a paragon of virtue. 2) GNU make is required in some cases. We could fix the makefiles to work with BSD make also, or far easier just make buildit switch on platform to invoke GNU make (gmake on BSD, and surely present on systems that have a hope of compiling the prereqs). 3) Some files are checked in that are written during the build. I use CVSREAD=t so that files in CVS are readonly, and then use ^X^Q to edit them, which does cvs edit, saves a local copy of the repo version, and often allows others to see who is editing what files. So, I wonder if these files should not be checked in. If that's too difficult it would be nice for the build should chmod +w them. gnuradio-core/src/lib/filter/Makefile.gen After looking at this one, I see that it's difficult. The Makefile is missing a dependency for Makefile.gen on generate_all.py, so removing Makefile.gen has no way to rebuild it, plus make chokes on the missing unconditional include. Also, Makefile.gen is unconditionally included. Perhaps creating Makefile.gen from src/lib before descending might avoid this. It would be nice if the generated file had the date and hostname of generation as well as RCD Ids of the generator code. gnuradio-core/src/lib/general/Makefile.gen Same issue I think. src/lib/swig/gnuradio_swig_bug_workaround.h If this is deleted, make regenerates it with no issues. So perhaps this can simply be deleted from CVS. With that, and calling buildit with --prefix=/usr/gnuradio, I was able to build usrp gnuradio-core gr-usrp gr-audio-oss gr-wxgui and am able to run the USB benchmark (4 MB/s via an NEC cardbus ehci, as good as has been reported on NetBSD), the oscope and fft. I could run usrp_nbfm_rcv after making a symlink from /dev/dsp to /dev/sound, and commenting out the following line self.fmrx.squelch.set_threshold(threshold_in_db) The audio doesn't sound right, I think due to USB lossage, but I do hear quieting. I have the EHCI spec on my reading pile... -- Greg Troxel [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: usrp-0.10 tarball released
Thanks Eric.Message: 6Date: Thu, 15 Dec 2005 21:20:16 -0800From: Eric Blossom [EMAIL PROTECTED]Subject: [Discuss-gnuradio] usrp-0.10 tarball releasedTo: discuss-gnuradio@gnu.orgMessage-ID: [EMAIL PROTECTED]Content-Type: text/plain; charset=us-asciiI've released an updated usrp tarball, 0.10.It's the same as the previous, only this one includes all the verilogfiles required to build the fpga image. Yes, I did test this ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 64 bit
On Fri, Dec 16, 2005 at 03:49:21PM -0500, cswiger wrote: Just curious - how much might gnuradio benefit from running on 64 bit processors and how much of a rewrite would it take, to take full advantage of, say, an Athlon 64 X2, seeing as you could theoretically chunk thru twice the data every bus clock? It already runs on the X86-64, including a first cut at the SSE/3DNow stuff. It's what I use everyday, and yes, it is substantially faster! I guess the Solaris build doesn't take advantage of the UltraSparc II's. A little benchmarking with a 300Mhz processor and a short graph: noise source -- throttle -- low pass filter -- null sink using 100Khz sample rate and 67 tap filter uses 80% of one cpu. --Chuck The noise source is pretty expensive, particularly for GR_GAUSSIAN. Also, you're using the generic fir filter kernel (straight C++). On x86 and x86-64 we've got hand-coded assembler for taking advantage of SSE and 3DNow SIMD instructions. I don't know if there's a Solaris equivalent to oprofile (profiling using the h/w performance counters), but the first step to making it faster would be to determine where it's slow. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 2.6 release!
On Sat, 17 Dec 2005 03:30, Eric Blossom wrote: On Sat, Dec 17, 2005 at 12:53:01AM +1030, Berndt Josef Wulf wrote: I don't understand what the fuss is all about. It takes 11m1s to build all the binaries and documentation of all GNU Radio 2.6 modules supported by the NetBSD packages sytem from scratch on my laptop. The time it takes to generate the gnuradio-core documentation is 1m21s which is merely 10% of the total time taken to rebuild GNU Radio. What are these people running? Sinclair Pocket PCs? :-) NetBSD uses a later version of doxygen namely doxygen-1.4.5. It supports many new features, has seen many bugfixes and hence creates a different set of doc files. Perhaps its faster too... ;-) Some version's of doxygen in wide circulation are *really* slow. Also, do you have dot installed? If so, additional time is spent generating graphs. On my opteron, it takes over 7 minutes to generate the docs with doxygen 1.4.1 and dot 2.2. Yes, dot is part of graphviz-2.2.1 producing the hierarchical plots. If the old versions are that bad wouldn't it make sense to specify doxygen-1.4.5 and graphviz-2.2.1 or later? How about a --enable-build-docs configure switch to enable users to make that decision at the configuration stage? A patch to configure.ac would be welcome! Eric pgpMqexn8GaeC.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] linux dsp development environments
On Thu, Dec 15, 2005 at 04:11:31PM -0500, Darrell Harmon wrote: [..] I am using the Analog Devices Blackfin with GCC. The blackfin is fairly high end. My board has a single core at 390MHz, and there is a dual core part that can run 750MHz. I am not using Linux on it, but an developing my own RTOS which should be ready within the next month. The SDR board using this is still a work in progress. I should be building a prototype soon. Xenomai[1], a free hard real-time OS fused with Linux is being ported to Blackfin. It brings best of both worlds in user-space, yet let you choose whatever skin API you like (RTAI, Posix, VxWorks, pSos, etc. ). Xenomai used to be known as RTAI/Fusion. Xenomai rocks! [1] http://xenomai.org -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] doxygen et al
On Sat, Dec 17, 2005 at 11:02:04AM +1030, Berndt Josef Wulf wrote: Yes, dot is part of graphviz-2.2.1 producing the hierarchical plots. If the old versions are that bad wouldn't it make sense to specify doxygen-1.4.5 and graphviz-2.2.1 or later? A comment in the README would be a good idea. I'll give these later versions a try when I get a chance. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sparc -- x86 data exchange
On Fri, Dec 16, 2005 at 03:04:01PM -0800, Matt Ettus wrote: [..] This would actually be a good place to make use of liboil, the library of optimized inner loops. They have code for all sorts of conversions, and they pick up MMX and SSE-type optimizations automatically. Indeed. liboil is really promising. I was waiting for GNU Radio 2.6 to be released, and provided you and Eric agree, IMHO it would be a smart move to outsource the SIMD speedups to liboil for the next GNU Radio release. It's way easier to develop speedups in liboil, introduce new archs, have them improved by people other than the GNU Radio gang (IOW share efforts and benefits), etc. Right now, I'm creating the missing liboil API entries along with reference implementations. Reference implementations are plain C code which implements the algorithm in a clear, readable, high- precision and always right way. Most of the time, reference implementations are horribly slow. But it's not a problem. Based on the reference prototype, you may write as many optimized implementations as you want. The liboil framework makes it easy to automate testing against the reference implementation and corner cases (spill, alignment, ..). Always wondered whether SSE or 3DNow! is faster on some new AMD chip? Don't care about that, liboil benchmarks at run time your breed(1) of optimized implementations and selects the one which has the best rating. (1) not *genetically* engineered so far, sorry Eric ;-) Expect liboil to gain more momentum, and pass the word among the other SDR projects you may be involved in. One thing I will need quickly is the list of inner loops in the need of optimization (OProfile reports anyone?). This is to begin with creating the API entries and the reference implementations. Then, making it familiar to some ears, liboil is The library that just keeps getting optimized better. See http://liboil.freedesktop.org/wiki/FrontPage Definitely worth mentioning! -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sparc -- x86 data exchange
Three opinions... * GNU Radio should be processing data in the local machine's native byte order and data format (e.g. IEEE float). You should have to explicitly tell it to do something about byte order (e.g. convert samples to little-endian). * Any conversions we offer should say nothing about machine types (x86), rather should be specific about byte orders. E.g. we should not offer convert longs from x86 to sparc, we should offer output big-endian longs and input big-endian longs. These conversions would be implemented on all machine types, but of course on some of them there's no work to do. An extra name for big-endian should be in network byte order, for people who are squirting partially-processed data over the net to another signal processing program on an arbitrary machine. (My opinions on byte order come from having co-designed and maintained the BFD library that the GNU binutils use to read and write object files, which require pervasive and specific attention to byte order. We changed our byte-order API several times until we got it right and easy to use.) * I'm hesitant to make GNU Radio depend on Yet Another random library package like liboil. Building it is already an exercise in frustration, as is trying to package it for a distribution. Can't we skip some premature optimization and get back to making the program do real things that real people want to do? I don't see the obvious GUI-operable scanners, recorders, radar screens, etc, that our capabilities are supposed to make it easy to create. We're how many years into this package?, and still re-re-rewriting the guts. Let's rather make it something that tens of thousands of people would use to record multiple FM stations, or scan and log police and ambulance frequencies, or TiVo the ham bands, or avoid DRM on over-the-air TV transmissions. Even our FM decoding is inferior to what cheap transistor radios do. Six months' focus on polish and applications would make a world of difference. Just my 2c... John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 2.6 release!
On Sat, 17 Dec 2005 03:30, Eric Blossom wrote: On Sat, Dec 17, 2005 at 12:53:01AM +1030, Berndt Josef Wulf wrote: I don't understand what the fuss is all about. It takes 11m1s to build all the binaries and documentation of all GNU Radio 2.6 modules supported by the NetBSD packages sytem from scratch on my laptop. The time it takes to generate the gnuradio-core documentation is 1m21s which is merely 10% of the total time taken to rebuild GNU Radio. What are these people running? Sinclair Pocket PCs? :-) NetBSD uses a later version of doxygen namely doxygen-1.4.5. It supports many new features, has seen many bugfixes and hence creates a different set of doc files. Perhaps its faster too... ;-) Some version's of doxygen in wide circulation are *really* slow. Also, do you have dot installed? If so, additional time is spent generating graphs. On my opteron, it takes over 7 minutes to generate the docs with doxygen 1.4.1 and dot 2.2. How about a --enable-build-docs configure switch to enable users to make that decision at the configuration stage? A patch to configure.ac would be welcome! Eric How about the attached patch? It will generate the doxygen documentation only with --enable-doxygen=yes. Default is no doxygen docs. cheerio Berndt --- config/gr_doxygen.m4.orig 2005-12-17 11:43:43.0 +1030 +++ config/gr_doxygen.m4 2005-12-17 11:58:49.0 +1030 @@ -25,19 +25,21 @@ AC_ARG_ENABLE(html-docs, [ --enable-html-docs enable HTML generation with doxygen (yes)], [], [ enable_html_docs=yes]) AC_ARG_ENABLE(latex-docs, [ --enable-latex-docs enable LaTeX doc generation with doxygen (no)], [], [ enable_latex_docs=no]) - if test x$enable_doxygen = xno; then -enable_doc=no - else + if test x$enable_doxygen = xyes; then AC_PATH_PROG(DOXYGEN, doxygen, , $PATH) if test x$DOXYGEN = x; then if test x$enable_doxygen = xyes; then AC_MSG_ERROR([could not find doxygen]) fi enable_doc=no + generate_docs= else enable_doc=yes + generate_docs=docs AC_PATH_PROG(DOT, dot, , $PATH) fi + else +enable_doc=no fi AM_CONDITIONAL(DOC, test x$enable_doc = xyes) @@ -53,4 +55,5 @@ AC_SUBST(enable_dot) AC_SUBST(enable_html_docs) AC_SUBST(enable_latex_docs) + AC_SUBST(generate_docs) ]) --- doc/Makefile.am.orig 2005-12-17 14:27:00.0 +1030 +++ doc/Makefile.am 2005-12-17 11:58:22.0 +1030 @@ -28,7 +28,7 @@ EXTRA_DIST = -all-local: prep +all-local: prep @generate_docs@ doc: docs# alias docs: prep html/index.html pgp9hYY0Hrm6d.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
