| Version 38 (modified by , 16 years ago) ( diff ) |
|---|
Jrock and Ibob attempt to create the most recent gnu radio implementation fresh from the GNU radio svn.
12/19/08
James and Bob go to the grid.
The first and lamest attempt was a simple apt-get install gnuradio. This failed miserably due to unresolved dependeniceis. Following the instructions of (http://gnuradio.org/trac/wiki/DebianPackages) for Ubuntu installations, we added
deb http://gnuradio.org/ubuntu stable main contrib deb-src http://gnuradio.org/ubuntu stable main
to the /etc/apt/sources.list
This didn't help. The trail of failed dependencies goes as follows:
gnuradio -> python-gnuradio -> python-gnuradio-comedi -> libcomedi-0.7.22
the last one is not installable as there is no package target.
It should be noted that the baseline image is based on debian (and not ubuntu, so this may be the problem).
We're going to attempt the debian source install, the apt install doesn't work for the previously mentioned reasons. We installed the build-essentials package. And we nnow modify the sources list again. we added
deb http://ftp.at.debian.org/debian/ etch main non-free contrib
We then ran apt-get build-dep gnuradio which had 519 megs of stuff to install. It was followed by apt-get build-dep usrp which had nothing to install.
All of this was to "prep" the image for a build of the gnu-radio software by source. There is no source package for it, we have to check it out from svn. (note: this required installing subversion package).
Running
svn co http://gnuradio.org/svn/gnuradio/branches/releases/3.1 gnuradio
yeilds a large download and a gnuradio directory. Hopefully with all the dep building of prior this should be a make / make install simple setup.
First running ./bootstrap required automake, that we didn't have. After apt-getting the automake package and all its dependencies, ./bootstrap chugs along. Note: this take a while, and throws a bunch of perl warnings.
./configure yeilds
********************************************************************* The following GNU Radio components have been successfully configured: config omnithread gnuradio-core gr-audio-alsa gr-audio-jack gr-audio-oss gr-audio-portaudio gr-atsc gr-gsm-fr-vocoder gr-pager gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gnuradio-examples You my now run the make command to build these components. ********************************************************************* The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp gr-usrp gr-audio-osx gr-audio-windows gr-comedi gr-gpio gr-radar-mono gr-sounder gr-utils These components will not be built.
The make process takes a 1.5 hours. We've run out of time on our slot, so I'm saving an image.
INFO n_1_1: - Saving disk image from node n_1_1 in the file 'node-1-1-2008-12-19-16-01-15.ndz'
Image creation was a success:
INFO exp: - Saving process finished correctly at: Fri Dec 19 16:13:07 -0500 2008 INFO Experiment: DONE! INFO ExecApp: Application 'commServer' finished INFO run: Experiment sb5_2008_12_19_15_59_43 finished after 13:26
I moved a copy from the tmp directory to the images directory and renamed it.It has 777 permissions.
ssugrim@repository2:/export/orbit/image$ ls -al | grep james -rw-r--r-- 1 ssugrim winlab 585105408 2008-12-19 16:22 james-bob-gnuradio-ver0.ndz
1/28/09
The saga continues…
The make was actually successful. We ran make install intinally, but after consulting with the documentation the correct order of steps was:
$ ./bootstrap # Do NOT perform this step if you are building from a tarball. $ ./configure $ make $ make check $ sudo make install
We had to do some group modifications to get udev devices to show up properly. Note that in lsusb:
node1-1:~# lsusb Bus 004 Device 002: ID fffe:0002 <--- this is the usrp Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000
Here we had to create a usrp group, add root to it, and then throw some file in the udev rules. Like So:
sudo addgroup usrp
sudo addgroup <YOUR_USERNAME> usrp
echo 'ACTION=="add", BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002", GROUP:="usrp", MODE:="0660"' > tmpfile
sudo chown root.root tmpfile
sudo mv tmpfile /etc/udev/rules.d/10-usrp.rules
NOTE: the naming convention of the rules files on the flavor of debian thats on the nodes is a little different. I made a copy of the 10-usrp.rules and named it z10_usrp.rules. Not really sure which one its reading, but ehh disk space is cheap.
that being said, post actual reboot (not restarting udev as the guide suggests) ls -lR /dev/bus/usb | grep usrp yeilds:
node1-1:~# ls -lR /dev/bus/usb | grep usrp crw-rw---- 1 root usrp 189, 385 Jan 28 14:20 002
The guide claims one entry per usrp (and thus just one entry).
We added PYTHONPATH=/usr/local/lib/python2.5/site-packages/gnuradio/
export PYTHONPATH=/usr/local/lib/python2.5/site-packages/gnuradio/
We're trying to import one of the gnuraido libraries into a running python shell, it's complaining about
ImportError: libgnuradio-core.so.0: cannot open shared object file: No such file or directory
Bob seems to think this is caused by the Broken libtool on Debian and Ubuntu documented in the Ubuntu install docs.
To fix it we modified the ld.so.conf and ran ldconfig.
cp /etc/ld.so.conf /tmp/ld.so.conf echo /usr/local/lib >> /tmp/ld.so.conf mv /tmp/ld.so.conf /etc/ld.so.conf ldconfig
ldconfig ran with out complaint. the ld.so.conf contains this:
node1-1:~# more /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf /usr/local/lib/ node1-1:~#
after this step in a python shell from gnuradio import gr ran with out complaint.
However from gnuradio import usrp failed, this was due to an error thrown during the configure phase:
The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp gr-usrp
That is the usrp stuff was never built. Examining the config.log file in
node1-1:~/gnuradio# less config.log | grep usrp configure:31892: result: Component usrp requires guile, which was not found. <---- configure:32681: result: Not building component usrp. configure:32791: result: Component gr-usrp requires usrp, which is not being built or specified via pre-installed files. configure:32834: result: Not building component gr-usrp. configure:35081: result: Component gr-gpio requires usrp, which is not being built or specified via pre-installed files. configure:35495: result: Component gr-radar-mono requires usrp, which is not being built or specified via pre-installed files. configure:36993: result: Component gr-sounder requires usrp, which is not being built or specified via pre-installed files. configure:37164: result: Component gr-utils requires usrp, which is not being built or specified via pre-installed files.
From this we can see guile was the missing components (what ever the heck that is). According to the Ubuntu install docs, we need guile version 1.6. Apt-get says that guile is a pointer:
Package guile is a virtual package provided by: guile-1.8 1.8.5+1-4.1 guile-1.6 1.6.8-6.1
We're gonna pick 1.8.
We've reached a stopping point as inventory has clobbered our image.
next time we'll need to
- install guile
- run configure again
- run make, make check, make install again
- check to see if we can run form gnu-radio import uspr. This might require
- the python path change
- usrp group addtion and
- modification to udev
- the ld.so.conf (linker) modifications.
2/2/09
The Radio Strikes back…
Ran apt-get install guile, it threw some perl warnings, but I guess we're not worried:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Selecting previously deselected package guile-1.8-libs.
(Reading database ... 52898 files and directories currently installed.)
Unpacking guile-1.8-libs (from .../guile-1.8-libs_1.8.5+1-4.1_i386.deb) ...
Selecting previously deselected package guile-1.8.
Unpacking guile-1.8 (from .../guile-1.8_1.8.5+1-4.1_i386.deb) ...
Setting up guile-1.8-libs (1.8.5+1-4.1) ...
Setting up guile-1.8 (1.8.5+1-4.1) ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Rerunning configured got the same results because a package (sdcc) was missing.
After going through the list of required packages listed on http://gnuradio.org/trac/wiki/UbuntuInstall
We additionally installed:
- sdcc
- boost-build
- wx-common
- libqt3-mt-dev
- libgsl0-dev
The locale warnings can be ignored.
With the help of Ivan we've determined that the version of SDCC that is installed by default does not support asx8051.
It does support
node1-1:~/gnuradio# sdcc -v SDCC : avr/pic16/pic14/xa51 2.8.0 #5117 (May 16 2008) (UNIX)
We downgraded the version of sdcc to 2.6.0-5:
wget http://ftp.egr.msu.edu/debian/pool/main/s/sdcc/sdcc-libraries_2.6.0-5_all.deb dpkg -i sdcc-libraries_2.6.0-5_all.deb
This downgraded the libraries, but we also had to downgrade the complier it self, and the docs for laughs.
http://packages.debian.org/etch/all/sdcc-doc/download
http://packages.debian.org/etch/i386/sdcc/download
Note: uname -a says that our architecture is i686, but they only had debs for i386. We used the i386 ones. The install process was the same as for the libraries.
Sucess!!! Or at least a glimpse of hope, the usrp module was now listed in the list of shite to be built after running ./configure again.
Make and Make check ran through with minimal complaints, mostly barking about locale again.
An image was taken, new image name is:
ssugrim@repository2:/export/orbit/image$ ls -al | grep james -rwxrwxrwx 1 ssugrim winlab 585105408 2008-12-19 16:22 james-bob-gnuradio-ver0.ndz -rw-r--r-- 1 ssugrim winlab 628097024 2009-02-02 16:13 james-bob-gnuradio-ver1.ndz
The follow is whats left to do:
- run make install again
- check to see if we can run form gnu-radio import uspr. This might require:
- the python path change
- usrp group addtion
- modification to udev
- the ld.so.conf (linker) modifications.
Make install was successful. After doing the ld.so.conf modifications, importing usrp was successful.
We then added the usrp group and made the udev modifications.
Our first run of :
# ./usrp_benchmark_usb.py
failed. Jrock had noticed that the console was spitting usb events and "renumbering" the usrp. Each run of lsusb or
# ls -lR /dev/bus/usb | grep usrp crw-rw---- 1 root usrp 189, 450 Feb 2 17:14 067 <-- note the 067 instead of 002
would get a higher number for the device id. Rebooting the usrp fixed the problem. I guess it was in some kind of loop where it rebooted continuously/ reassociated with the usb controller. The controller then thinking it found a new device, would assign a new number to it.
After that we had a SUCCESSFUL run of the benchmark:
# ./usrp_benchmark_usb.py Testing 2MB/sec... usb_throughput = 2M ntotal = 1000000 nright = 999506 runlength = 999506 delta = 494 OK Testing 4MB/sec... usb_throughput = 4M ntotal = 2000000 nright = 1997978 runlength = 1997978 delta = 2022 OK Testing 8MB/sec... uUuOusb_throughput = 8M ntotal = 4000000 nright = 3822354 runlength = 1563106 delta = 2436894 FAILED Testing 16MB/sec... usb_throughput = 16M ntotal = 8000000 nright = 7996578 runlength = 7996578 delta = 3422 OK Testing 32MB/sec... uUuOuOuOuOuOuOuOuOuOuOuOuOuOuOuOuOuOuOusb_throughput = 32M ntotal = 16000000 nright = 14442379 runlength = 3383 delta = 15996617 FAILED Max USB/USRP throughput = 16MB/sec
Ibob says the last set of failures was expected as we've reached the through put limit of the usb controller.
We also ran usrp_sigen.py and were able to sucessfully transmit a signal (although we can't verify it went out, the software didn't complain).
We're taking an image from this point:
ls -al | grep james -rwxrwxrwx 1 ssugrim winlab 585105408 2008-12-19 16:22 james-bob-gnuradio-ver0.ndz -rw-r--r-- 1 ssugrim winlab 628097024 2009-02-02 16:13 james-bob-gnuradio-ver1.ndz -rw-r--r-- 1 ssugrim winlab 656408576 2009-02-02 17:56 james-bob-gnuradio-ver2.ndz
Next we will try:
- transmit from one node and display the received signal on another.
- export the display to a local x server.
2/4/09
The jade ssh…
So we have ofically dubbed ssh a piece of shit. After much debugging, we found that the ssh multi-hop tunneling does work as advertised.
ssh -Y user@host
should capture the X output of the machine you shell is running on and transport it you the machine you ssh'd from. The -Y option passes it back through any other machines you might have come through, and deposits the result on the originating machines X server.
You should be able to tell if this is working because there should be an environment variable DISPLAY=localhost:10.0. (Or some number greater than 10) This works because the tunnel captures local X traffic via a dummy xserver setup on the host at port 10.0 and ferries that to the remote machine.
The failure we were experiencing was due to the version of ssh that comes with the baseline image being a piece of shit. This was fixed but a simple
apt-get install openssh-server
Assuming the /etc/ssh/sshd_config has the allowX11forward flag set to yes, we should be good to go.
Make sure you have the -Y option specified all the way through, other wise it will fail silently. cd
ssugrim@repository2:/export/orbit/image$ ls -al | grep james -rwxrwxrwx 1 ssugrim winlab 585105408 2008-12-19 16:22 james-bob-gnuradio-ver0.ndz -rw-r--r-- 1 ssugrim winlab 628097024 2009-02-02 16:13 james-bob-gnuradio-ver1.ndz -rw-r--r-- 1 ssugrim winlab 656408576 2009-02-02 17:56 james-bob-gnuradio-ver2.ndz -rw-r--r-- 1 ssugrim winlab 670040064 2009-02-04 19:44 james-bob-gnuradio-ver3.ndz
An image was saved with the working ssh. Now on to the actual issue we were working on, exporting the gnuradio visuals:
2/11/09
Things on the Block…
- Compile a block
- view oscilloscope
2/18/09
Localemotion…
After running node1-2:~/gnuradio/gr-utils/src/python# ./usrp_fft.py —help, we found that those meaningless locale barkings, were now not meaning less. It barked with this error:
node1-2:~/gnuradio/gr-utils/src/python# ./usrp_fft.py --help
Traceback (most recent call last):
File "./usrp_fft.py", line 27, in <module>
from gnuradio.wxgui import stdgui2, fftsink2, waterfallsink2, scopesink2, form, slider
File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 24, in <module>
import wx
File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/__init__.py", line 45, in <module>
from wx._core import *
File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 14280, in <module>
default = locale.getpreferredencoding()
File "/usr/lib/python2.5/locale.py", line 514, in getpreferredencoding
setlocale(LC_CTYPE, "")
File "/usr/lib/python2.5/locale.py", line 478, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting
Googling for the last bit yeilded this page (http://ubuntuforums.org/showthread.php?t=35517) which basically told us to do a reconfigure on the locale package. When I tried to reconfigure it, the session barked because locale wasn't installed. An apt-get install locales later, and the commnad runs with sucess.
We added xterm and successfully exported them. We then ran
node1-2:~/gnuradio/gr-utils/src/python# ./usrp_fft.py -R A -f 5M -d 128 & node1-2:~/gnuradio/gr-utils/src/python# ./usrp_siggen.py -T A -f 5M -i 512 --gaussian &
Great Sucess:
Now if only we had two nodes.
03/04/09
Next up:
- Attempt to build test block
- step through a pyhtong script
- Try to transmit some data via (*sk)
Slide Out line:
- Image setup - SB5
- where the Usrps are located
- Usrp Arch description
- Description of Rf front ends
- Gluing block together - Python Libraries
- Build your own block
- compiling
- swig
- Reference Build block
- Demo of Basic Tx / Rx on sb5
3/11/09
Blocks on my head…
We're going to attempt to build the example block:
In the /root/gnuradio/gr-howto-write-a-block directory, we first ran the bootstrap script (cuz we got it from SVN).
node1-1:~/gnuradio/gr-howto-write-a-block# ./bootstrap configure.ac:28: installing `./install-sh' configure.ac:28: installing `./missing' src/lib/Makefile.am: installing `./depcomp' src/lib/Makefile.am:56: installing `./py-compile'
This created a configure script which puke out much stuffs but in the end didn't complain about any thing:
node1-1:~/gnuradio/gr-howto-write-a-block# ./configure . . . configure: creating ./config.status config.status: creating Makefile config.status: creating config/Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating src/lib/Makefile config.status: creating src/python/Makefile config.status: creating src/python/run_tests config.status: creating config.h config.status: executing depfiles commands config.status: executing run_tests commands
After a successful configure, make pushed through with a few warning, but no halting errors. Make check passed all the tests:
node1-1:~/gnuradio/gr-howto-write-a-block# make check . . . OK PASS: run_tests ================== All 1 tests passed ================== make[3]: Leaving directory `/root/gnuradio/gr-howto-write-a-block/src/python' make[2]: Leaving directory `/root/gnuradio/gr-howto-write-a-block/src/python' make[2]: Entering directory `/root/gnuradio/gr-howto-write-a-block/src' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/root/gnuradio/gr-howto-write-a-block/src' make[1]: Leaving directory `/root/gnuradio/gr-howto-write-a-block/src' make[1]: Entering directory `/root/gnuradio/gr-howto-write-a-block' make[1]: Nothing to be done for `check-am'. make[1]: Leaving directory `/root/gnuradio/gr-howto-write-a-block' node1-1:~/gnuradio/gr-howto-write-a-block#
Make install - no complaints. Thus all the libraries and tools are in place for making blocks. Taking an image, also did some house keeping.
ssugrim@repository2:/export/orbit/image$ ls -alh | grep james -rw-r--r-- 1 ssugrim winlab 639M 2009-02-04 19:44 james-bob-gnuradio-ver3.ndz -rw-r--r-- 1 ssugrim winlab 649M 2009-03-11 18:01 james-bob-gnuradio-ver4.ndz
For further reference http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html
Send a *shift keying signal (*sk).
In the /root/gnuradio/gnuradio-examples/python/digital we can use the script
/gnuradio/gnuradio-examples/python/digital#./benchmark_tx.py to push out a gmsk signal.
From the sender (node1-1) we did:
node1-1:~/gnuradio/gnuradio-examples/python/digital# ./benchmark_tx.py -f 5M -r 250k -T A -v >>> gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board A: Basic Tx Tx amplitude 12000 modulation: gmsk_mod bitrate: 250kb/s samples/symbol: 2 interp: 256 Tx Frequency: 5M
On the recive side (node1-2) we ran:
node1-2:~/gnuradio/gr-utils/src/python# ./usrp_fft.py -R A -f 5M -d 128
and we saw :
To actually "recieve" the sginal we did:
node1-2:~/gnuradio/gnuradio-examples/python/digital# ./benchmark_rx.py -f 5M -r 125k -R A -v >>> gr_fir_fff: using SSE bits per symbol = 1 M&M clock recovery omega = 2.000000 M&M clock recovery gain mu = 0.175000 M&M clock recovery mu = 0.500000 M&M clock recovery omega rel. limit = 0.005000 frequency error = 0.000000 Receive Path: Using RX d'board A: Basic Rx Rx gain: 10 modulation: gmsk_demod bitrate: 125kb/s samples/symbol: 2 decim: 256 Rx Frequency: 5M ok = True pktno = 1 n_rcvd = 1 n_right = 1 ok = True pktno = 2 n_rcvd = 2 n_right = 2 ok = True pktno = 3 n_rcvd = 3 n_right = 3 ok = True pktno = 4 n_rcvd = 4 n_right = 4 ok = True pktno = 5 n_rcvd = 5 n_right = 5 ok = True pktno = 6 n_rcvd = 6 n_right = 6 ok = True pktno = 7 n_rcvd = 7 n_right = 7 ok = True pktno = 8 n_rcvd = 8 n_right = 8
Note the drop in rate (-r 125k), we had to do this to prevent over runs on the receiver(uOuOuOuOuOuOuOu)
The sender was passed:
node1-1:~/gnuradio/gnuradio-examples/python/digital# ./benchmark_tx.py -f 5M -r 125k -T A -v >>> gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board A: Basic Tx Tx amplitude 12000 modulation: gmsk_mod bitrate: 125kb/s samples/symbol: 2 interp: 512 Tx Frequency: 5M .................................................
to ship out packets.
Bobs notes on over/under runs:
uU: The [u]srp is experiencing an [U]nderrun. This only occurs on the transmitter, and means we are not getting data to the transmitter fast enough.
uO: The [u]srp is experiencing an [O]verrun. This only occurs on the receiver, and means we are dropping/missing data.
Most often, these errors are due to USB bus limitations. Keep in mind that there is a single USB interface from the node to the USRP, so it needs to be shared between the transmitter and receiver.
Attachments (3)
- usrp-fft.JPG (59.4 KB ) - added by 16 years ago.
- usrp-Gaussian.JPG (73.6 KB ) - added by 16 years ago.
- usrp-gmsk-250kbps-fft.JPG (71.8 KB ) - added by 16 years ago.
Download all attachments as: .zip
