wiki:Internal/BuildingGNURadioImage

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.

Last modified 12 years ago Last modified on Mar 11, 2009, 10:51:47 PM

Attachments (3)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.