I did a bootstrap, configure, make, make install on n4hy’s tree and when
I
try to run ofdm_benchmark_tx, I get
[root@aurora ofdm]# ./benchmark_ofdm_tx.py
Traceback (most recent call last):
File “./benchmark_ofdm_tx.py”, line 23, in ?
from gnuradio import gr, gru, modulation_utils
File “/usr/local/lib/python2.4/site-packages/gnuradio/gr/init.py”,
line 27, in ?
from gnuradio_swig_python import *
File
“/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py”,
line 6, in ?
import _gnuradio_swig_python
ImportError:
/usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_python.so:
undefined symbol: _Z15gr_make_fft_vccibSt6vectorIfSaIfEE
I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume
there’s a problem with my swig-python or swig- what versions of
everything
should I be using?
View this message in context:
http://www.nabble.com/OFDM-in-n4hy's-tree-tf3124511.html#a8656567
Sent from the GnuRadio mailing list archive at Nabble.com.
Brett Trotter wrote:
File
should I be using?
Replying to myself here, I heard from someone that I should do make
uninstall on the standard tree before doing make install on n4hy’s tree.
I
make uninstalled both just to make sure it was cleaned out, and toasted
/usr/local/lib/python2.4/site-packages/gnuradio (same for lib64) and did
make install of n4hy’s - only to discover that _gnuradio_swig_python is
now
missing. Another make uninstall, another rm, and reinstalled the stable
tree- which yields the same error.
Why is make install not putting _gnuradio_swig_python in place do you
suppose? Have I missed something?
–
View this message in context:
http://www.nabble.com/OFDM-in-n4hy's-tree-tf3124511.html#a8660301
Sent from the GnuRadio mailing list archive at Nabble.com.
On Fri, Jan 26, 2007 at 02:55:29PM -0800, Brett Trotter wrote:
File “/usr/local/lib/python2.4/site-packages/gnuradio/gr/init.py”,
missing. Another make uninstall, another rm, and reinstalled the stable
tree- which yields the same error.
Why is make install not putting _gnuradio_swig_python in place do you
suppose? Have I missed something?
Which distribution are you guys using?
I believe that the Ubuntu libtool problem is still unresolved.
I’d really appreciate it if somebody who uses ubuntu would test and
document a fix. I suspect that it could be as easy as rolling libtool
back to libtool-1.5.22-3
Eric
I am doubting the libtool error in this one. If you have the libtool
error, it shows up well before this. You cannot complete the make.
IF you cannot complete the make, and it dies in making the mblock
message block code, then you can go back to the pmt directory and in
that directory do install
cd pmt
make install
cd …
make
the make will now complete mblock in a few seconds and the rest of the
tree will build. From there, I have no problems at all with the main
branch.
I have been UNBELIEVABLY tied up since the first of the year and I have
no revisited the Rondeau, Ettus, and McGwier (n4hy) OFDM code since
that time. I will make it tonight and see what happens.
Tom will be here through the weekend and possible we can check into it
if I discover a problem.
Bob
(n4hy)
Eric B. wrote:
File “/usr/local/lib/python2.4/site-packages/gnuradio/gr/init.py”,
missing. Another make uninstall, another rm, and reinstalled the stable
I’d really appreciate it if somebody who uses ubuntu would test and
–
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
Robert McGwier-2 wrote:
cd …
Tom will be here through the weekend and possible we can check into it
Brett Trotter wrote:
line 27, in ?
I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume
make install of n4hy’s - only to discover that _gnuradio_swig_python is
[email protected]
I took Dan H.'s advice and totally deleted my build tree- I also
totally cleaned out all traces of gnuradio and re-checked out everything
from subversion and re-built (n4hy’s tree) and am still missing
_gnuradio_swig_python.
As you may have seen from my first post in this thread, I was originally
getting an error about _Z15gr_make_fft_vccibSt6vectorIfSaIfEE being
missing
using the n4hy’s benchmark_ofdm_tx on after make installing n4hy’s tree
over
the stable…- and after make uninstalling the stable tree, and make
installing n4hy’s, I now am missing the swig python bit.
So- I’m going to go and clean out everything again and rebuild the
stable
tree and see if I get my swig_python bits back. Am I making a rookie
mistake
here somewhere?
View this message in context:
http://www.nabble.com/OFDM-in-n4hy's-tree-tf3124511.html#a8662232
Sent from the GnuRadio mailing list archive at Nabble.com.
On Fri, Jan 26, 2007 at 07:22:58PM -0800, Eric B. wrote:
(2)
cd gnuradio-core/src/lib/swig
for file in *.d do; cp /dev/null $file; done
make
Eric
I’ve given you somewhat incorrect info.
Bob’s ofdm tree hasn’t been updated with the changes that split
gnuradio_swig_python into 5 pieces. Thus, there should be an
_gnuradio_swig_python file.
In any event, a checkout into an empty directory worked for me.
Eric
On Fri, Jan 26, 2007 at 06:25:29PM -0800, Brett Trotter wrote:
I took Dan H.'s advice and totally deleted my build tree- I also
totally cleaned out all traces of gnuradio and re-checked out everything
from subversion and re-built (n4hy’s tree) and am still missing
_gnuradio_swig_python.
There is no longer a _gnuradio_swig_python file. It’s not supposed to
be there. I believe the problem you are seeing is related to stale
swig dependencies left over in the current build tree.
See http://gnuradio.org/trac/ticket/130
Either of these should fix the problem:
(1)
If you start with a fresh checkout – into an empty directory –
I’m
pretty sure that you will not see the message. By empty I mean
empty. That is, no .deps or .libs files, or anything else for
that matter.
(2)
cd gnuradio-core/src/lib/swig
for file in *.d do; cp /dev/null $file; done
make
Eric
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
Eric B. wrote:
be there. I believe the problem you are seeing is related to stale
that matter.
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
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
Robert McGwier wrote:
from the single computer where Tom, Matt, and I did the work. I will
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