[Discuss-gnuradio] FYI: svn-current build problem

[Berndt Josef Wulf]

G'day,

I'm currently seeing this when attempting to compile svn-current revision 
4315.
 
g++ -DHAVE_CONFIG_H -I. -I../../../.. 
-I../../../../gnuradio-core/src/lib/runtime 
-I../../../../gnuradio-core/src/lib/general 
-I../../../../gnuradio-core/src/lib/general 
-I../../../../gnuradio-core/src/lib/gengen 
-I../../../../gnuradio-core/src/lib/gengen 
-I../../../../gnuradio-core/src/lib/filter 
-I../../../../gnuradio-core/src/lib/filter 
-I../../../../gnuradio-core/src/lib/reed-solomon 
-I../../../../gnuradio-core/src/lib/io -I../../../../gnuradio-core/src/lib/g72x 
-I../../../../gnuradio-core/src/lib/omnithread 
-I../../../../gnuradio-core/src/lib/swig 
-I../../../../gnuradio-core/src/lib/swig -I/usr/pkg/include 
-I/usr/pkg/include/python2.4 -I. -I/usr/pkg/include -g1 -O1 -Wall 
-Woverloaded-virtual -pthread -MT 
_gnuradio_swig_py_io_la-gnuradio_swig_py_io.lo -MD -MP -MF 
.deps/_gnuradio_swig_py_io_la-gnuradio_swig_py_io.Tpo -c 
gnuradio_swig_py_io.cc  -fPIC -DPIC -o 
.libs/_gnuradio_swig_py_io_la-gnuradio_swig_py_io.o
../../../../config.h: In function 'double exp10(double)':
../../../../config.h:417: error: redefinition of 'double exp10(double)'
../../../../config.h:417: error: 'double exp10(double)' previously defined 
here
../../../../config.h: In function 'double exp10(double)':
../../../../config.h:417: error: redefinition of 'double exp10(double)'
../../../../config.h:417: error: 'double exp10(double)' previously defined 
here
../../../../gnuradio-core/src/lib/io/gr_udp_source.cc: In member 
function 'virtual int gr_udp_source::work(int, gr_vector_const_void_star&, 
gr_vector_void_star&)':
../../../../gnuradio-core/src/lib/io/gr_udp_source.cc:139: warning: comparison 
between signed and unsigned integer expressions
gmake[6]: *** [_gnuradio_swig_py_io_la-gnuradio_swig_py_io.lo] Error 1
gmake[6]: Leaving directory 
`/home/wulf/projects/gnuradio/gnuradio/gnuradio-core/src/lib/swig'
gmake[5]: *** [all] Error 2
gmake[5]: Leaving directory 
`/home/wulf/projects/gnuradio/gnuradio/gnuradio-core/src/lib/swig'

I haven't had a chance to further investigate this as I'm preparing to go 
interstate. AFAIK, libm doesn't support exp10() on NetBSD and hence it 
shouldn't be defined.

cheerio Berndt


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

Re: [Discuss-gnuradio] ofdm2 branch

[Robert McGwier]

Johnathan Corgan wrote:

Robert McGwier wrote:

  

Caveat,  I need the c++ hierarchy and wanted the dial_tone example to
work so this directory has been enabled in my branch.



The build system for C++ only applications has not been done yet.

The dial_tone example assumes the existence of gr-audio-alsa, so anyone
compiling off this developer branch will have problems if they don't
enable gr-audio-alsa.  This obviously means that non-ALSA systems like
Win32 or Mac OSX will fail make/make check on this developer branch.

  


Understood.  That is why I was giving out a warning.  If you are 
impacted by this,  you can remove the references to c++ and 
c++/dial_tone  in config/grc_gnuradio_examples.m4 and life will be 
peachy keen.  I have to have both ofdm and c++ working by March 15.  I 
would prefer not doing this with hacks but with the new hierarchy but 
this code needs to be running in some form for my applications.  The 
ever silent Jason and I have to move forward smartly to meet this deadline.


Thanks,
Bob

--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine



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

RE: [Discuss-gnuradio] QAM, carrier tracking and clock recovery

[Tom Rondeau]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:discuss-
> [EMAIL PROTECTED] On Behalf Of Martin Dvh
> Sent: Sunday, January 28, 2007 6:15 PM
> To: gnuradio mailing list
> Subject: [Discuss-gnuradio] QAM, carrier tracking and clock recovery
> 
> Hi All,
> I am trying to build a working QAM modulator/demodulator, based on the
> existing BPSK/QPSK code.
> 
> Is the Mueller and Muller clock-recovery as used in the current QPSK
> examples also usable for QAM?
> 
> I couldn't find a good description of the algorithm or the parameters.
> 
> For clock recovery the only options I found on the net which are supposed
> to work for QAM are  modified early/late tracking and modified
> zero-crossing.
> Has anybody any info on this?
> 
> I am also looking for the best option for carrier-tracking.
> For QAM there are special requirements for carrier-tracking and clock-
> recovery.
> A simple costas loop will not do for carrier tracking.
> 
> This is what I have so far:
> 
> For now I implemented a to-the fourth-power PLL for carrier tracking.
> (PLL locks to the fourth power of the input, output is divided by four)
> This is supposed to work for all QAM versions and should NOT suffer from
> catastrophic collaps when the BER gets too high.
> (The other option. Decision based carrier-tracking does suffer from
> catastrophic collaps.)
> The disadvantage is the long time before lock.
> 
> For clock-recovery I am trying to use the existing clock-recovery.
> 
> I am fiddling with the parameters and I do get a non-very-stable but
> recognisable QAM constellation as output of the clock-recovery when I use
> a
> very  slow timeconstant for my PLL.
> No packets get through yet, I think because the PLL only locks after a lot
> of symbols are missed and the constellation is not very stable.
> 
> The output constellation of the output of the clock-recovery now can be
> seen in:
> http://www.olifantasia.com/projects/gnuradio/QAM/screenshots/
> The output files (--log) before and after clock-recovery is in
> http://www.olifantasia.com/projects/gnuradio/QAM/
> 
> greetings,
> Martin

Martin,

I've been doing a bit of work on this problem and have two developer
branches open for this. In branches/developers/trondeau/digital-wip you will
find QAM modulator code; I have transmitted this and received it on my
Signature signal analyzer and see the perfect constellations. The code also
performs Gray coding on the constellation. This code only has the QAM
modulator side and no demodulator. This should be very quick to work up, and
it sounds like you might already have it.

In branches/developers/trondeau/digital-wip2, I've been doing modifications
on the MPSK receiver and implementing D8PSK. This work is almost complete
and will be merged into the branch soon. I would look the 'gr_mpsk_receiver'
block code from now on. It's decision-aided and does the Costas loop and M&M
(a modified version) at the same time and improves the DQPSK reception.

The mpsk_receiver should be fairly easily extended to work for QAM, too,
with improved decision making on the quadrant and "shell" the symbols are
in. It's similar to what you said, except it does joint estimation of the
timing.

I'm swamped with other responsibilities right now, so I won't have time to
hack on the QAM work, although I really want to get the 8PSK code into the
trunk, so expect that soon. If this code helps you in working on your QAM
solutions, please use it, and we can hopefully work together to get this
done and part of the release.

Tom




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

[Discuss-gnuradio] QAM, carrier tracking and clock recovery

[Martin Dvh]

Hi All,
I am trying to build a working QAM modulator/demodulator, based on the existing 
BPSK/QPSK code.

Is the Mueller and Muller clock-recovery as used in the current QPSK examples 
also usable for QAM?

I couldn't find a good description of the algorithm or the parameters.

For clock recovery the only options I found on the net which are supposed to 
work for QAM are  modified early/late tracking and modified
zero-crossing.
Has anybody any info on this?

I am also looking for the best option for carrier-tracking.
For QAM there are special requirements for carrier-tracking and clock-recovery.
A simple costas loop will not do for carrier tracking.

This is what I have so far:

For now I implemented a to-the fourth-power PLL for carrier tracking.
(PLL locks to the fourth power of the input, output is divided by four)
This is supposed to work for all QAM versions and should NOT suffer from 
catastrophic collaps when the BER gets too high.
(The other option. Decision based carrier-tracking does suffer from 
catastrophic collaps.)
The disadvantage is the long time before lock.

For clock-recovery I am trying to use the existing clock-recovery.

I am fiddling with the parameters and I do get a non-very-stable but 
recognisable QAM constellation as output of the clock-recovery when I use a
very  slow timeconstant for my PLL.
No packets get through yet, I think because the PLL only locks after a lot of 
symbols are missed and the constellation is not very stable.

The output constellation of the output of the clock-recovery now can be seen in:
http://www.olifantasia.com/projects/gnuradio/QAM/screenshots/
The output files (--log) before and after clock-recovery is in 
http://www.olifantasia.com/projects/gnuradio/QAM/

greetings,
Martin


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

Re: [Discuss-gnuradio] ofdm2 branch

[Johnathan Corgan]

Robert McGwier wrote:

> Caveat,  I need the c++ hierarchy and wanted the dial_tone example to
> work so this directory has been enabled in my branch.

The build system for C++ only applications has not been done yet.

The dial_tone example assumes the existence of gr-audio-alsa, so anyone
compiling off this developer branch will have problems if they don't
enable gr-audio-alsa.  This obviously means that non-ALSA systems like
Win32 or Mac OSX will fail make/make check on this developer branch.

--
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] Compilation failed [Ubuntu 6.06]

[Eric Blossom]

On Sun, Jan 28, 2007 at 09:18:08PM +0100, Davide Anastasia wrote:
> On dom, 2007-01-28 at 11:20 -0800, Eric Blossom wrote:
> > It's being triggered here because it's trying to link against the
> > _installed_ version of the library, not the _build_ version of the
> > library.  The problem is that it's passing the "--rpath
> > /usr/local/lib" to the linker.  This is wrong at this stage of the
> > build.
> > 
> > I believe that you can change the symptom by doing a "make uninstall"
> > and ensuring that there's no gnuradio related stuff in PREFIX/lib or
> > PREFIX/lib/python/site-packages/gnuradio.
> > 
> > When you rebuild, I believe that it will fail someplace else in the
> > build. 
> 
> You believe wrong! :)
> I done "make uninstall", "make distclean" and then... everything
> works! :)
> 
> Thank you,

Glad to hear it's working, though I still suspect there's a problem
lurking here somewhere...

Eric


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

Re: [Discuss-gnuradio] Compilation failed [Ubuntu 6.06]

[Davide Anastasia]

On dom, 2007-01-28 at 11:20 -0800, Eric Blossom wrote:
> It's being triggered here because it's trying to link against the
> _installed_ version of the library, not the _build_ version of the
> library.  The problem is that it's passing the "--rpath
> /usr/local/lib" to the linker.  This is wrong at this stage of the
> build.
> 
> I believe that you can change the symptom by doing a "make uninstall"
> and ensuring that there's no gnuradio related stuff in PREFIX/lib or
> PREFIX/lib/python/site-packages/gnuradio.
> 
> When you rebuild, I believe that it will fail someplace else in the
> build. 

You believe wrong! :)
I done "make uninstall", "make distclean" and then... everything
works! :)

Thank you,
-- 
Davide Anastasia

web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]



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

Re: [Discuss-gnuradio] Compilation failed [Ubuntu 6.06]

[Eric Blossom]

On Sun, Jan 28, 2007 at 07:52:07PM +0100, Davide Anastasia wrote:
> On dom, 2007-01-28 at 09:51 -0800, Eric Blossom wrote:
> > > automake (GNU automake) 1.9.6
> > > 
> > > Ideas?
> > 
> > Random guess: you've got more than one version of libtool installed
> > (perhaps in a different path), and autoconf isn't looking in the
> > directory in which you installed libtool.  It appears that libtool was
> > installed with using the package manager.  Is it in /usr/local? 
> 
> Ok, I remove automake-1.8 and I install automake-1.8. ./bootstrap run
> nicely, but during compiling I receive the same error as above:

David, there's no indication that any of your problems have to do with
automake.  I'm not sure why you're messing with that.

> g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
> test_mblock.o  ./.libs/libmbl ock-qa.so ./.libs/libmblock.so -ldl
> -Wl,--rpath -Wl,/usr/local/lib
> ./.libs/libmblock.so: undefined reference to `pmt_nth(unsigned int,
> boost::shared_ptr)'
> ./.libs/libmblock-qa.so: undefined reference to
> `pmt_intern(std::basic_string,
> std::allocator > const&)'
> ./.libs/libmblock.so: undefined reference to
> `pmt_wrong_type::pmt_wrong_type(std::basic_string std::char_traits, std::allocator > const&,
> boost::shared_ptr)'
> ./.libs/libmblock.so: undefined reference to
> `pmt_subsetp(boost::shared_ptr, boost::sha red_ptr)'
> collect2: ld returned 1 exit status

This is the Ubuntu libtool symptom.

It's being triggered here because it's trying to link against the
_installed_ version of the library, not the _build_ version of the
library.  The problem is that it's passing the "--rpath
/usr/local/lib" to the linker.  This is wrong at this stage of the
build.

I believe that you can change the symptom by doing a "make uninstall"
and ensuring that there's no gnuradio related stuff in PREFIX/lib or
PREFIX/lib/python/site-packages/gnuradio.

When you rebuild, I believe that it will fail someplace else in the
build.

Eric


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

[Discuss-gnuradio] ofdm2 branch

[Robert McGwier]

In branches/developers/n4hy  Tom and I have added ofdm2.  It contains a 
merge of the latest trunk with my ofdm directory.  svn merge was 
unusable for this and it had to be built by hand.   This branch will be 
the branch where ofdm work will be attempted by Tom, I, and others.  
Caveat,  I need the c++ hierarchy and wanted the dial_tone example to 
work so this directory has been enabled in my branch.  This enables me 
to bring ONE development branch into work for all my needs.  I will 
attempt to keep this branch current with the trunk.


Bob



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine



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

Re: [Discuss-gnuradio] Compilation failed [Ubuntu 6.06]

[Davide Anastasia]

On dom, 2007-01-28 at 09:51 -0800, Eric Blossom wrote:
> > automake (GNU automake) 1.9.6
> > 
> > Ideas?
> 
> Random guess: you've got more than one version of libtool installed
> (perhaps in a different path), and autoconf isn't looking in the
> directory in which you installed libtool.  It appears that libtool was
> installed with using the package manager.  Is it in /usr/local? 

Ok, I remove automake-1.8 and I install automake-1.8. ./bootstrap run
nicely, but during compiling I receive the same error as above:

g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
test_mblock.o  ./.libs/libmbl ock-qa.so ./.libs/libmblock.so -ldl
-Wl,--rpath -Wl,/usr/local/lib
./.libs/libmblock.so: undefined reference to `pmt_nth(unsigned int,
boost::shared_ptr)'
./.libs/libmblock-qa.so: undefined reference to
`pmt_intern(std::basic_string,
std::allocator > const&)'
./.libs/libmblock.so: undefined reference to
`pmt_wrong_type::pmt_wrong_type(std::basic_string, std::allocator > const&,
boost::shared_ptr)'
./.libs/libmblock.so: undefined reference to
`pmt_subsetp(boost::shared_ptr, boost::sha red_ptr)'
collect2: ld returned 1 exit status
make[4]: *** [test_mblock] Error 1
make[4]: Leaving directory
`/home/rocker/Tesi/SVN/gnuradio/mblock/src/lib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/rocker/Tesi/SVN/gnuradio/mblock/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/rocker/Tesi/SVN/gnuradio/mblock'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/rocker/Tesi/SVN/gnuradio'
make: *** [all] Error 2


:(
-- 
Davide Anastasia

web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]



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

Re: [Discuss-gnuradio] Compilation failed [Ubuntu 6.06]

[Eric Blossom]

On Sun, Jan 28, 2007 at 06:31:44PM +0100, Davide Anastasia wrote:
> On dom, 2007-01-28 at 09:28 -0800, Eric Blossom wrote:
> > 
> >   [EMAIL PROTECTED]:~$ autoconf --version
> >   autoconf (GNU Autoconf) 2.59
> > 
> Yep! It's the same.
> 
> >   [EMAIL PROTECTED]:~$ libtool --version
> >   ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-2 (1.1220.2.365
> > 2005/12/18 22:14:06)
> > 
> Actually:
> ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
> 
> 
> >   [EMAIL PROTECTED]:~$ automake --version
> >   automake (GNU automake) 1.8.5 
> 
> automake (GNU automake) 1.9.6
> 
> Ideas?

Random guess: you've got more than one version of libtool installed
(perhaps in a different path), and autoconf isn't looking in the
directory in which you installed libtool.  It appears that libtool was
installed with using the package manager.  Is it in /usr/local?

>From the messages in the prior email, it appears that libtool isn't
the only problem with your autoconf installation.  It was reporting
problems finding other AC_* macros too, though it could have been some
kind of cascading error problem.

Again, I don't have much admin experience on Debian or Ubuntu, so I
can't be of much help.

Is there a "force a reinstall of autoconf and libtool" option?
Again, I'm clueless about Debian packaging, so I could be leading you
off a cliff ;)

Eric


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

Re: [Discuss-gnuradio] Getting tar balls

[Eric Blossom]

On Sun, Jan 28, 2007 at 08:24:32PM +0300, Nick Othieno wrote:
> I've been looking for the latest tar balls for the gnuradio
> components-gr-usrp,gr-audio-alsa,gr-wxgui,usrp,gr-usrp etc. The GNU radio
> wiki seems of no help. Where can I find them
> 


Uhh, links to the tarballs are _right_ on the front page of the wiki

See http://gnuradio.org/trac/wiki

As it says...

If you prefer to build from release tarballs instead of from the
source code repository, the latest can be downloaded here:

  * ftp://ftp.gnu.org/gnu/gnuradio/gnuradio-3.0.2.tar.gz
  * ftp://ftp.gnu.org/gnu/gnuradio/gr-howto-write-a-block-3.0.2.tar.gz 


gnuradio-3.0.2.tar.gz contains the source code for everything in the
latest stable release.

You'll also want to take a look at the BuildGuide
http://gnuradio.org/trac/wiki/BuildGuide

Eric


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

Re: [Discuss-gnuradio] Compilation failed [Ubuntu 6.06]

[Davide Anastasia]

On dom, 2007-01-28 at 09:28 -0800, Eric Blossom wrote:
> 
>   [EMAIL PROTECTED]:~$ autoconf --version
>   autoconf (GNU Autoconf) 2.59
> 
Yep! It's the same.

>   [EMAIL PROTECTED]:~$ libtool --version
>   ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-2 (1.1220.2.365
> 2005/12/18 22:14:06)
> 
Actually:
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)


>   [EMAIL PROTECTED]:~$ automake --version
>   automake (GNU automake) 1.8.5 

automake (GNU automake) 1.9.6

Ideas?
-- 
Davide Anastasia

web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]



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

Re: [Discuss-gnuradio] Compilation failed [Ubuntu 6.06]

[Eric Blossom]

On Sun, Jan 28, 2007 at 05:48:35PM +0100, Davide Anastasia wrote:
> On sab, 2007-01-27 at 10:13 -0800, Eric Blossom wrote:
> > Yes, this is the "Ubuntu libtool problem".
> > (Looks like they've propagated the bad idea to 6.06 LTS too.)
> > 
> > I suspect that you are using Debian libtool-1.5.22-4.
> > 
> >   $ libtool --version
> > 
> > Try rolling back to libtool-1.5.22-3
> > and let us know what happens.
> 
> No, I have libtool-1.5.22-2.
> 
> > After rolling back, you'll need to remove the old version that was
> > installed in top level of your build tree and rebuild
> > 
> >   $ make distclean
> >   $ rm libtool ltmain.sh
> >   $ ./bootstrap && ./configure
> >   $ make
> > 
> > 
> > If Ubuntu libtool-1.5.22-3 still has the problem, please use the
> > unmolested libtool 1.5.22 available at
> > http://ftp.gnu.org/gnu/libtool/libtool-1.5.22.tar.gz
> > 
> 
> Done, but it doesn't work. I remove deeply the compilation folder and
> download again by SVN tree. While ./boostrap script runs, I receive some
> cryptic messages:
> 
> configure.ac:73: warning: AC_PROG_LIBTOOL is m4_require'd but is not
> m4_defun'd
> configure.ac:73: AC_PROG_LIBTOOL is required by...
> config/gr_scripting.m4:30: GR_SCRIPTING is expanded from...
> configure.ac:73: the top level
> configure.ac:147: warning: AC_PROG_LD is m4_require'd but is not
> m4_defun'd
> configure.ac:147: AC_PROG_LD is required by...
> config/gr_libgnuradio_core_extra_ldflags.m4:40:

[snip]

> GR_LIBGNURADIO_CORE_EXTRA_LDFLAGS is expanded fro m...
> configure.ac:147: the top level
> configure.ac:65: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
>   If this token and others are legitimate, please use
> m4_pattern_allow.
>   See the Autoconf documentation.
> configure.ac:67: error: possibly undefined macro: AC_ENABLE_SHARED
> configure.ac:68: error: possibly undefined macro: AC_DISABLE_STATIC
> configure.ac:69: error: possibly undefined macro: AC_PROG_LIBTOOL
> configure:10311: error: possibly undefined macro: AC_PROG_LD
> configure.ac:73: warning: AC_PROG_LIBTOOL is m4_require'd but is not

[snip]

> ezdop/src/firmware/Makefile.am: installing `./compile'
> ezdop/src/firmware/Makefile.am: installing `./depcomp'
> ezdop/src/host/ezdop/Makefile.am:24: Libtool library used but `LIBTOOL'
> is undefined
> ezdop/src/host/ezdop/Makefile.am:24:
> ezdop/src/host/ezdop/Makefile.am:24: The usual way to define `LIBTOOL'
> is to add `AC_PROG_LIBTOOL 
> 
> ...and so on!

Something's hosed with either your autoconf or libtool installation.

I've just built GNU Radio from scratch on an Ubuntu 6.06 LTS machine
with no problem.  That machine was using:

  [EMAIL PROTECTED]:~$ autoconf --version
  autoconf (GNU Autoconf) 2.59

  [EMAIL PROTECTED]:~$ libtool --version
  ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-2 (1.1220.2.365 2005/12/18 
22:14:06)

  [EMAIL PROTECTED]:~$ automake --version
  automake (GNU automake) 1.8.5


Eric


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

[Discuss-gnuradio] Getting tar balls

[Nick Othieno]

I've been looking for the latest tar balls for the gnuradio
components-gr-usrp,gr-audio-alsa,gr-wxgui,usrp,gr-usrp etc. The GNU radio
wiki seems of no help. Where can I find them

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

Re: [Discuss-gnuradio] Compilation failed [Ubuntu 6.06]

[Davide Anastasia]

On sab, 2007-01-27 at 10:13 -0800, Eric Blossom wrote:
> Yes, this is the "Ubuntu libtool problem".
> (Looks like they've propagated the bad idea to 6.06 LTS too.)
> 
> I suspect that you are using Debian libtool-1.5.22-4.
> 
>   $ libtool --version
> 
> Try rolling back to libtool-1.5.22-3
> and let us know what happens.

No, I have libtool-1.5.22-2.

> 
> After rolling back, you'll need to remove the old version that was
> installed in top level of your build tree and rebuild
> 
>   $ make distclean
>   $ rm libtool ltmain.sh
>   $ ./bootstrap && ./configure
>   $ make
> 
> 
> If Ubuntu libtool-1.5.22-3 still has the problem, please use the
> unmolested libtool 1.5.22 available at
> http://ftp.gnu.org/gnu/libtool/libtool-1.5.22.tar.gz
> 

Done, but it doesn't work. I remove deeply the compilation folder and
download again by SVN tree. While ./boostrap script runs, I receive some
cryptic messages:

configure.ac:73: warning: AC_PROG_LIBTOOL is m4_require'd but is not
m4_defun'd
configure.ac:73: AC_PROG_LIBTOOL is required by...
config/gr_scripting.m4:30: GR_SCRIPTING is expanded from...
configure.ac:73: the top level
configure.ac:147: warning: AC_PROG_LD is m4_require'd but is not
m4_defun'd
configure.ac:147: AC_PROG_LD is required by...
config/gr_libgnuradio_core_extra_ldflags.m4:40:
GR_LIBGNURADIO_CORE_EXTRA_LDFLAGS is expanded fro m...
configure.ac:147: the top level
configure.ac:73: warning: AC_PROG_LIBTOOL is m4_require'd but is not
m4_defun'd
configure.ac:73: AC_PROG_LIBTOOL is required by...
config/gr_scripting.m4:30: GR_SCRIPTING is expanded from...
configure.ac:73: the top level
configure.ac:147: warning: AC_PROG_LD is m4_require'd but is not
m4_defun'd
configure.ac:147: AC_PROG_LD is required by...
config/gr_libgnuradio_core_extra_ldflags.m4:40:
GR_LIBGNURADIO_CORE_EXTRA_LDFLAGS is expanded fro m...
configure.ac:147: the top level
configure.ac:65: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
  If this token and others are legitimate, please use
m4_pattern_allow.
  See the Autoconf documentation.
configure.ac:67: error: possibly undefined macro: AC_ENABLE_SHARED
configure.ac:68: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:69: error: possibly undefined macro: AC_PROG_LIBTOOL
configure:10311: error: possibly undefined macro: AC_PROG_LD
configure.ac:73: warning: AC_PROG_LIBTOOL is m4_require'd but is not
m4_defun'd
configure.ac:73: AC_PROG_LIBTOOL is required by...
config/gr_scripting.m4:30: GR_SCRIPTING is expanded from...
configure.ac:73: the top level
configure.ac:147: warning: AC_PROG_LD is m4_require'd but is not
m4_defun'd
configure.ac:147: AC_PROG_LD is required by...
config/gr_libgnuradio_core_extra_ldflags.m4:40:
GR_LIBGNURADIO_CORE_EXTRA_LDFLAGS is expanded fro m...
configure.ac:147: the top level
configure.ac:73: warning: AC_PROG_LIBTOOL is m4_require'd but is not
m4_defun'd
configure.ac:73: AC_PROG_LIBTOOL is required by...
config/gr_scripting.m4:30: GR_SCRIPTING is expanded from...
configure.ac:73: the top level
configure.ac:147: warning: AC_PROG_LD is m4_require'd but is not
m4_defun'd
configure.ac:147: AC_PROG_LD is required by...
config/gr_libgnuradio_core_extra_ldflags.m4:40:
GR_LIBGNURADIO_CORE_EXTRA_LDFLAGS is expanded fro m...
configure.ac:147: the top level
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
ezdop/src/firmware/Makefile.am: installing `./compile'
ezdop/src/firmware/Makefile.am: installing `./depcomp'
ezdop/src/host/ezdop/Makefile.am:24: Libtool library used but `LIBTOOL'
is undefined
ezdop/src/host/ezdop/Makefile.am:24:
ezdop/src/host/ezdop/Makefile.am:24: The usual way to define `LIBTOOL'
is to add `AC_PROG_LIBTOOL 

...and so on!
-- 
Davide Anastasia

web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]



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

Re: [Discuss-gnuradio] OFDM in n4hy's tree

[Tom Rondeau]

Robert McGwier wrote:
Like all things in branches, until they are not in branches,  this is 
absolutely development code and here is no guarantee of completeness 
or even correctness.  It is the reason for doing this kind of work in 
branches rather than imposing it on everyone in the trunk.


In the gnuradio-examples/python/ofdm directory, the only functional 
up-to-date file as of this moment is ofdm_benchmark.py.   It does a 
loopback through noise test.


ofdm_benchmark_tx.py calls upon a tx_pick_bitrate  which is missing 
from the single computer where Tom, Matt, and I did the work.  I will 
make sure that this is not an accidental omission that was actually on 
Tom's laptop when he arrives tomorrow.


We are attempting a very difficult thing which requires some delicacy 
and art.  We want to be able to come up with a compact description of 
any kind of constellation,  cyclic prefix size, or complete absence of 
cyclic prefix and then have support for the requirement for sync 
channels of several types.  At the same time,  we have the design goal 
for this to be reasonably efficient and even dynamic.  We have chosen 
not to take the fast road to a single exemplar but to abstract as much 
of this as possible believing this will aid experimentation and serve 
the greatest possible good.


I have been so busy for the last few weeks that all of this slipped 
out of the sieve that is left of my mind ;-).


When Tom and I can get some work done tomorrow, one of the things we 
will be planning is the next big steps in the ofdm tree.  You may 
expect nothing to work until we say it does work.


Bob


A quick look showed that pick_bitrate.py was not checked into the 
repository, this has been corrected. However, I don't think we've ever 
tested running the OFDM modulator with the USRP yet, as the 
benchmark_ofdm_tx.py is meant to do.


The pick_bitrate.py file was copied over the digital examples; it will 
probably be modified in the future for OFDM-specific operation.


To test the OFDM system, we were using a loopback mode using 
benchmark_ofdm.py, which calls upon receive_path_simple and 
transmit_path_simple, which bypass the calls to the USRP and connect 
directly to each other. A checkout and install had this working with no 
issues. You should just be able to run:

   ./benchmark_ofdm.py
With no argument and you'll see a stream of packet info being spit out. 
You can change a lot of the parameters now, including the SNR.


As Bob said, this is development code. We have no synchronization in the 
receiver yet, so this will definitely not work over the air yet.


Tom



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

Re: [Discuss-gnuradio] ( An attempt ) to run GNURadio on WinTV : )

[Hew How Chee]

Hi Jim,
   
  Can't remember that clearly, but the idea is to get the 2nd sound IF of the 
TV/FM tuner capacitively to one of the ADC inputs. The IF pin is one of the 
TV/FM tuner output pin. (It might not be available in all tuner module). I 
removed the existing circuit that was attached to this IF pin, in my case, I 
just need to removed a 0 ohm resistor. I also resisitively divide the IF pin 
output voltage just enough so that it does not exceed CX23881 voltage level. 
This step might be redundant since I do not have a oscilloscope to measure the 
IF pin voltage swing.
   
  The sine came from a program written for Palm Pilot. Looking back at the 
code, I guess its about 2k. You can inject the tone direct to the composite 
video in and use the CX built in multiplexer to select this input.
   
   
  Regards,
  Hew
  

Jim Perkins <[EMAIL PROTECTED]> wrote:
  Hew,
Do you recall what the hardware mods were?  I'm wondering if  I can clean up 
card with caps here and there.  I looked at your sine wave data.  I low pass 
filtered it and got rid of most of that garbage.  The tone is at 1890 Hz as far 
as I can tell.  How did you generate that tone and what was the center 
frequency?  Where did you inject the tone?
 -Jim

Hew How Chee wrote:   Hi Jim,

The card I use last time is PV-TV304P+ (REV .2B) with FMRC (FM and Remote 
Control) . The chipset used is CX23881. The card from newegg.com is using 
CX23883. Can't tell it is compatible or not. The data I got is 8 bit unsigned. 
Didn't try out 10 bit since I was quite dissapointed by the noise in the 8 bit 
digitized signal. Nevertheless, it is still possbile to digitize the 10.7 MHz 
FM IF with hardware mods.

Note that the source code at http://www.geocities.com/how_chee/cx23881.htm 
can't compile and run in Linux kernel 2.6 and is not hooked up to GNURadio. It 
was developed using Knoppix Live CD 3.4 running kernel 2.4.x.

Best regards,
Hew

 
-
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio