Forum: GNU Radio GNU Radio 3.2 Release Candidate 2 available for testing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-04-15 00:24
(Received via mailing list)
GNU Radio 3.2 release candidate 2 is now available for download and
testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz
http://gnuradio.org/releases/gnuradio/gr-howto-wri...

The associated firmware and FPGA bitstream images for the USRP2 are:

http://gnuradio.org/releases/usrp2-bin/release/txr...
http://gnuradio.org/releases/usrp2-bin/release/u2_...

This release contains all the features, fixes, and bugs of the GNU
Radio development trunk as of 4/14/09.

Our goal is for this to be the last release candidate before the
formal 3.2 release.   Those of you with your own GNU Radio projects
who wish to stabilize on the 3.2.x API should begin using the above
instead of the development trunk.  We will be making changes to the
trunk software that will break API compatibility soon after the formal
release.

As always, we will maintain the 3.2.x series of releases such that
upgrades to newer releases will not break existing code.  In addition,
to the extent possible, we will merge and release selected
functionality from the development trunk that is consistent with this
requirement.

Johnathan Corgan
Corgan Enterprises LLC
517629c0e192cdc44e62779fabebe5d5?d=identicon&s=25 Paco Garcia (Guest)
on 2009-04-15 17:18
(Received via mailing list)
Jonathan,

It works ok for me, except for the mpsk_receiver with the setup from
http://www.nabble.com/QPSK-phase-noise-td22934944.html.

This is the constellation I get for a > 40 dB SNR BPSK:
http://www.nabble.com/file/p23060668/Screenshot.png Screenshot.png



Johnathan Corgan-2 wrote:
>
> GNU Radio 3.2 release candidate 2 is now available for download and
> testing:
>
> http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz
> http://gnuradio.org/releases/gnuradio/gr-howto-wri...
>
>

--
View this message in context:
http://www.nabble.com/GNU-Radio-3.2-Release-Candid...
Sent from the GnuRadio mailing list archive at Nabble.com.
517629c0e192cdc44e62779fabebe5d5?d=identicon&s=25 Paco Garcia (Guest)
on 2009-04-15 17:20
(Received via mailing list)
Johnathan,

It works ok for me, except for the mpsk_receiver with the setup from
http://www.nabble.com/QPSK-phase-noise-td22934944.html.

This is the constellation I get for a > 40 dB SNR BPSK:
http://www.nabble.com/file/p23060683/Screenshot.png Screenshot.png



Johnathan Corgan-2 wrote:
>
> GNU Radio 3.2 release candidate 2 is now available for download and
> testing:
>
> http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz
> http://gnuradio.org/releases/gnuradio/gr-howto-wri...
>
>

--
View this message in context:
http://www.nabble.com/GNU-Radio-3.2-Release-Candid...
Sent from the GnuRadio mailing list archive at Nabble.com.
781e96b7bd64e8833d71e3914cb1594a?d=identicon&s=25 Michael Dickens (Guest)
on 2009-04-16 14:52
(Received via mailing list)
This release compiles, checks, installs, and uninstalls properly on
OSX 10.5.6 / XCode 3.1.2 using Apple's GCC 4.2 and MacPorts (latest
everything, since there's not much choice), using both "normal" and
VPATH builds.  Other pieces of good news:

* Looks like the GNU Radio build system and programming is compatible
with the just released Boost 1.38 and SWIG 1.3.39.

* When I upgraded from SWIG 1.3.38 to 1.3.39, the build system worked
perfectly: it recognized that the previous SWIG system files weren't
available, and recompiled just the SWIG-generated files as well as
regenerated the SWIG dependency file.  Much better than erroring out.
B538f3568f304bb9c10b6719e1d370af?d=identicon&s=25 Karthik (Guest)
on 2009-04-18 04:05
(Received via mailing list)
On Tue, Apr 14, 2009 at 3:23 PM, Johnathan Corgan
<jcorgan@corganenterprises.com> wrote:
> This release contains all the features, fixes, and bugs of the GNU
> upgrades to newer releases will not break existing code.  In addition,
> to the extent possible, we will merge and release selected
> functionality from the development trunk that is consistent with this
> requirement.
>
> Johnathan Corgan
> Corgan Enterprises LLC

Here is my setup:
OS: Ubuntu 8.04
USRP1 with 2 LFRX and 2LFTX daughterboards

I primary use the USRP as a 4 channel Digitizer and have been running
gnuradio-3.1.3 without any problems so far. To test 3.2rc2 I tried
running the multi_fft.py which is available in the
gnuradio-examples/python/multi-antenna/ directory. I commented out the
portion which checks for the the number of channels available and the
daughterboard ID since I didn't have the BASIC_RX. Here is the major
change that I found.

The value of len(self.subdev) = 4 in 3.1.3 and =6 in 3.2rc2.

Shouldn't this be 4 as it was previously?

Regards,
Karthik
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-04-18 04:20
(Received via mailing list)
On Fri, Apr 17, 2009 at 7:04 PM, Karthik <karthik1024@gmail.com> wrote:

> The value of len(self.subdev) = 4 in 3.1.3 and =6 in 3.2rc2.
>
> Shouldn't this be 4 as it was previously?

It appears this was an inadvertent consequence of the change in the
daughterboard code for the BasicRX and LFRX boards, to allow use as a
complex input device.  These daughterboards now have three subdevs
instead of two, so when the above variable is created by concatenating
the daughterboard table from each side, it comes out as six instead of
four.

I can't test it right now, but I think it is as simple as changing the
comparison to use 6 instead of 4.

Thanks for the bug report.

Johnathan
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-04-18 04:26
(Received via mailing list)
On Fri, Apr 17, 2009 at 07:04:25PM -0700, Karthik wrote:
> > http://gnuradio.org/releases/usrp2-bin/release/u2_...
> >
> OS: Ubuntu 8.04
> The value of len(self.subdev) = 4 in 3.1.3 and =6 in 3.2rc2.
>
> Shouldn't this be 4 as it was previously?

Thanks for pointing this out.

Fixed in [10877] to work with old and new handling of Basic Rx d'boards.

Eric
B538f3568f304bb9c10b6719e1d370af?d=identicon&s=25 Karthik (Guest)
on 2009-04-20 03:00
(Received via mailing list)
On Fri, Apr 17, 2009 at 7:25 PM, Eric Blossom <eb@comsec.com> wrote:
>> > http://gnuradio.org/releases/usrp2-bin/release/txr...
>> > release.
>> Here is my setup:
>>
>> The value of len(self.subdev) = 4 in 3.1.3 and =6 in 3.2rc2.
>>
>> Shouldn't this be 4 as it was previously?
>
> Thanks for pointing this out.
>
> Fixed in [10877] to work with old and new handling of Basic Rx d'boards.
>
> Eric
>

I checked out the trunk and tried compiling the code. I get the
following error message in in the middle of the compile. I have tried
compiling the latest trunk and also R10877 and still get the same
error. I did the regular ./bootstrap and used

./configure --enable-doxygen --with-boost=/opt/boost_1_36
--enable-usrp2=no --enable-gr-usrp2=no

g++ -g -O2 -g -O2 -pthread -pthread -Wall -Woverloaded-virtual -o
.libs/test_inband test_inband.o  ./.libs/libusrp-inband-qa.so
/home/anankekarthik/gnuradio/usrp/host/lib/inband/.libs/libusrp-inband.so.0:
undefined reference to `usrp_standard_rx::tune(int,
boost::shared_ptr<db_base>, double, usrp_tune_result*)'
/home/anankekarthik/gnuradio/usrp/host/lib/inband/.libs/libusrp-inband.so.0:
undefined reference to `usrp_standard_tx::tune(int,
boost::shared_ptr<db_base>, double, usrp_tune_result*)'
/home/anankekarthik/gnuradio/usrp/host/lib/inband/.libs/libusrp-inband.so.0:
undefined reference to
`usrp_standard_rx::determine_rx_mux_value(usrp_subdev_spec const&)'
/home/anankekarthik/gnuradio/usrp/host/lib/inband/.libs/libusrp-inband.so.0:
undefined reference to
`usrp_standard_tx::determine_tx_mux_value(usrp_subdev_spec const&)'
/home/anankekarthik/gnuradio/usrp/host/lib/inband/.libs/libusrp-inband.so.0:
undefined reference to `usrp_basic::selected_subdev(usrp_subdev_spec
const&)'
/home/anankekarthik/gnuradio/usrp/host/lib/inband/.libs/libusrp-inband.so.0:
undefined reference to `db_base::dbid()'

Karthik
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-04-20 17:22
(Received via mailing list)
> I checked out the trunk and tried compiling the code. I get the
> following error message in in the middle of the compile. I have tried
> compiling the latest trunk and also R10877 and still get the same
> error. I did the regular ./bootstrap and used
>
> ./configure --enable-doxygen --with-boost=/opt/boost_1_36
> --enable-usrp2=no --enable-gr-usrp2=no

BTW, you likely don't need to disable the usrp2 components in the
above, though that isn't the source of your problem.

> g++ -g -O2 -g -O2 -pthread -pthread -Wall -Woverloaded-virtual -o
> .libs/test_inband test_inband.o  ./.libs/libusrp-inband-qa.so
> /home/anankekarthik/gnuradio/usrp/host/lib/inband/.libs/libusrp-inband.so.0:
> undefined reference to `usrp_standard_rx::tune(int,
> boost::shared_ptr<db_base>, double, usrp_tune_result*)'

This looks like the build system is getting confused as to the
location of libusrp (which contains the functions above).  Just to
start from a known configuration, can you do a 'sudo make uninstall'
to ensure the system locations are devoid of any GNU Radio
libraries/header files, the start from scratch with the bootstrap
step?

Johnathan
B538f3568f304bb9c10b6719e1d370af?d=identicon&s=25 Karthik (Guest)
on 2009-04-20 19:26
(Received via mailing list)
On Mon, Apr 20, 2009 at 8:08 AM, Johnathan Corgan
<jcorgan@corganenterprises.com> wrote:
>
> libraries/header files, the start from scratch with the bootstrap
> step?
>
> Johnathan
>

Thanks, that worked!

Karthik
836538755450355b9da666e86aca0eff?d=identicon&s=25 Jan Schiefer (Guest)
on 2009-04-30 09:53
(Received via mailing list)
Johnathan Corgan wrote:
> GNU Radio 3.2 release candidate 2 is now available for download and testing:
>
> http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz
> http://gnuradio.org/releases/gnuradio/gr-howto-wri...
>
> [etc]
My 3.2-rc2 build fails with the following error:

Making all in tests
make[4]: Entering directory
`/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/tests'
/bin/bash ../../../libtool --tag=CXX   --mode=link g++ -g -O2 -g -O2
-pthread -pthread -Wall -Woverloaded-virtual   -o test_all test_all.o
../../../gnuradio-core/src/lib/libgnuradio-core-qa.la
/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/lib/libgnuradio-core.la
libtool: link: g++ -g -O2 -g -O2 -pthread -pthread -Wall
-Woverloaded-virtual -o .libs/test_all test_all.o
../../../gnuradio-core/src/lib/.libs/libgnuradio-core-qa.so -L/usr/lib
/usr/lib/libcppunit.so -ldl
/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/lib/.libs/libgnuradio-core.so
/home/jan/gr-build/gnuradio-3.2rc2/omnithread/.libs/libgromnithread.so
/home/jan/gr-build/gnuradio-3.2rc2/gruel/src/lib/.libs/libgruel.so
-lboost_thread-gcc43-mt-1_35 -lrt /usr/lib/libfftw3f.so -lgsl -lgslcblas
-pthread
../../../gnuradio-core/src/lib/.libs/libgnuradio-core-qa.so: undefined
reference to `CppUnit::assertDoubleEquals(double, double, double,
CppUnit::SourceLine)'
collect2: ld returned 1 exit status
make[4]: *** [test_all] Error 1
make[4]: Leaving directory
`/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/tests'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jan/gr-build/gnuradio-3.2rc2'
make: *** [all] Error 2

This is on Ubuntu 9.04, following the instructions on the wiki
(http://gnuradio.org/trac/wiki/UbuntuInstall). cppunit is 1.12.1-1 as
installed from the Ubuntu repositories. Some output from nm:

jan@ubuntu:~$ nm --demangle /usr/lib/libcppunit.a | grep
assertDoubleEquals
<snip/>
00000030 T CppUnit::assertDoubleEquals(double, double, double,
CppUnit::SourceLine, std::string const&)
<snip/>

So there seeems to be an extra parameter in the version of
assertDoubleEquals that I have. According to cppunit documentation,
there are macros with and without the extra parameter (which is a
user-supplied message in case of error).

Thanks,
   Jan
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-04-30 17:51
(Received via mailing list)
On Thu, Apr 30, 2009 at 12:52 AM, Jan Schiefer <radio@akalaitis.net>
wrote:

> ../../../gnuradio-core/src/lib/.libs/libgnuradio-core-qa.so: undefined
> reference to `CppUnit::assertDoubleEquals(double, double, double,
> CppUnit::SourceLine)'
[...]
> jan@ubuntu:~$ nm --demangle /usr/lib/libcppunit.a | grep assertDoubleEquals
> <snip/>
> 00000030 T CppUnit::assertDoubleEquals(double, double, double,
> CppUnit::SourceLine, std::string const&)
> <snip/>
>
> So there seeems to be an extra parameter in the version of
> assertDoubleEquals that I have. According to cppunit documentation, there
> are macros with and without the extra parameter (which is a user-supplied
> message in case of error).

I can't replicate your results here on an Ubuntu 9.04 machine.

There is only one actual assertDoubleEquals function in libcppunit,
and it takes all five arguments.  The macro
CPPUNIT_ASSERT_DOUBLES_EQUAL that takes three arguments supplies the
other two as defaults.  This has been the case on the default
installation of libcppunit for Ubuntu 8.04, 8.10, and 9.04.  I'm
trying to figure out how your libgnuradio-core-qa.so came to have a
dynamic link to a version of the function with only four arguments.

Has this specific source code tree been compiled before under a
different environment? Can you do a 'make distclean' and try again
(from the ./bootstrap step)?

Johnathan
836538755450355b9da666e86aca0eff?d=identicon&s=25 Jan Schiefer (Guest)
on 2009-05-01 06:58
(Received via mailing list)
> Has this specific source code tree been compiled before under a
> different environment? Can you do a 'make distclean' and try again
> (from the ./bootstrap step)?

I was working from the tarball, so this was a completely new source
tree.
However, I think I found the culprit after some more digging. There was
an
older version of cppunit hiding in /usr/local/lib (wasn't installed
through the package manager, so it escaped my attention for a while).
The
build is still underway, but I am pretty sure this is the root cause.
Sorry about the false alarm!

Cheers,
   Jan
This topic is locked and can not be replied to.