OP25

h1. Questions and Answers

h2. Do I need a USRP?

The USRP is not essential. You can use sample files collected by others or one of a number of alternative hardware approaches. If you already have a suitable radio receiver you can even interface to it to via your PC's soundcard. Check out the [HardwarePage hardware page] for a short write-up of approaches people are investigating. 

h2. How do I install OP25?

At present you can only install OP25 from source. Check the [BuildInstructionsPage build instructions] for details.

h2. I have an error in libtool - what's going wrong?

I run the ./bootstrap and ./configure commands succesfuly but the make command failed with the following error:

<pre>

libtool:Version mismatch error. This is libtool 2.2.4, but the definition of this LT_INIT comes from an older release. You should recreate aclocal.m4 with macros from libtool 2.2.4 and run auto conf again.

</pre>

The aclocal.m4 file is auto-generated as a result of running the 'bootstrap' script that comes with the tarball. It is safe to delete 'aclocal.m4' - bootstrap will re-create it. The usual routine is to run the following after un-tarring the tarball -

<pre>

./bootstrap

./configure

make

make install

</pre>

If you've made other changes in the middle of this process, such as installing new stuff, it might be best to always re-start at the first of these steps (bootstrap)...

h2. The self-test doesn't work

When I try the python self-test programs I get something like this:-

<pre>

./qa_fsk4.py

Traceback (most recent call last):

File "./qa_fsk4.py", line 24, in <module>

import fsk4

ImportError: No module named fsk4

</pre>

This occurs because you aren't meant to run qa_fsk4.py or qa_op25.py directly. Instead you should run "make check" from the block's top-level directory.

h2. When I run usrp_p25_rx.py the user interface is unresponsive

The receiver consumes a significant amount of CPU and I/O bandwidth. If you have a slow computer and are trying to receive/play very wideband captures then there maybe little left to do anything else. Try using a lower sampling rate (a higher decimation factor) to see how much bandwidth your computer can process. One trick which might work is to cut down on the amount of time the CPU spends drawing on the screen. To do this cut&paste the following command into a shell to create a file called ~/.gnuradio/config.conf:

<pre>

[ -d ~/.gnuradio ] || mkdir ~/.gnuradio

cat >> .gnuradio/config.conf <<EOF

[wxgui]

style=nongl

fft_rate=2

EOF

</pre>

Also you can install the "System Monitor" applet into your task bar which gives a good visual indication of how heavily loaded your CPU is. In the last last analysis you can use the GNURadio usrp_rx_cfile.py example program to capture sample files at the command line but you will always be limited by CPU and I/O bandwidth as to how much spectrum you can sample at any one time.

h2. Why are you guys so s-l-o-w?

Well, we're a part-time hobby effort by a couple of enthusiasts. If you want to speed us up please feel free to help.

h2. How can I help?

We're looking for help with coding, testing, providing advice, gathering sample data, writing documentation or providing hardware. Whatever you can volunteer is welcome.