gnuradio - usrp

Notebook of a new challenge

I owned and used with satisfaction a RFSpace SDR14 for several years, however I wanted to get more control of my device and the USRP/GNUradio seemed to fit the bill. I'm not a professional software developer or radio engineer and I'm aware that my road is going to be very steep and ful of pitfalls.
In the typical bazaar approach well known to Linux users, documentation is not too friendly with newbies: software was developed by gurus with specialists in mind and tried to catch up is not so easy.
When I got my USRP, after compiling GNURadio, it took somewhere around two hours before getting a sound from it. This is a notebook for my slow progress through this new challenge, in the hope someone can benefit from my experience.
Hardware
No particular issues on this side. I've ordered my USRP ("1") with rx only frontends covering all the way up to 2.4GHz  (LFRX, TVRX, DBSRX). Assembling is straightforward: only doubt was which way the fan should be mounted and it turned out that having the sticker facing outside of the box makes less noise.
My USRP will be used on a Ubuntu 10.10 box (AMD Athlon 64 X2 dual core 3800+) with three soundcards... and the many who had sound problems with Linux can understand the big assle they may represent.

Installation
At the time of writing (Nov2010) Ettus Research reccomends using UHD instead of a plain USB driver to connect your USRP. At first I downloaded and compiled it, but eventually decided not to use it for the time being, since I understand not all examples and software available around will work with it without some rewriting.

Thereafter I followed instructions from the GNURadio site, in the Ubuntu specific flavour.		 Geremia checking on the new toy
Everything went smooth apart that I wasn't able to access the device unless I was root. Solution: the step by step procedure will indeed work, but you need at least to logoff/login again before you are recognized as a member of the USRP user group and therefore be allowed control of the device.

usrp_probe is the first thing to try before any other example: if you can't access the receiver from that anything else will fail.
This is the output I get for the two boards I've currently installed (LFRX as RX "A" and TVRX as RX "B".
Output also gives some info that may come handy in the future when setting parameters in the various blocks.


Examples
The first attempt at  running GRURadio-Companion (GRC for short) examples involving the USRP took me almost nowhere.
Dialtone example works, which is somehow reassuring.
usrp_wbfm_receive.grc returned this error:

audio_alsa_sink[hw:0,0]: unable to support sampling rate 32000
  card requested 44100 instead.

Apparently my default souncard (external USB by Trust) wouldn't like sampling at 32khz. Solution to this issue is provided directly in the documentation frame of the module:

Leave the device name blank to choose deafult audio device. ALSA users with audio trouble may try setting the device name to plughw:0,0

Following suggestions does the trick and indeed the script goes further, only to crash onto a different issue:
Traceback (most recent call last):
  File "/home/sinager/gnuradio/gnuradio-examples/grc/usrp/usrp_wbfm_receive.py", line 183, in <module>
    tb = usrp_wbfm_receive()
  File "/home/sinager/gnuradio/gnuradio-examples/grc/usrp/usrp_wbfm_receive.py", line 123, in __init__
    tau=75e-6,
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/fm_demod.py", line 65, in __init__
    60)       # Stopband attenuation
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/optfir.py", line 53, in low_pass
    taps = gr.remez (n + nextra_taps, fo, ao, w, "bandpass")
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py", line 432, in remez
    return _gnuradio_swig_py_general.remez(*args, **kwargs)
RuntimeError: gr_remez: number of taps must be >= 3

Set aside for the time being.

GRC looks cool but may in fact be complicating things. Decision to check leaner Python examples.
Following a Unix practice, all of them return a quick reference of arguments and options when called with --help.
Remember the plughw trick, which is applicable to commad line scripts as well, start trying...

usrp_nbfm_rcv.py is the first one I get to work, although the GUI seems a bit garbled. Big relief.
usrp_wbfm_rcv_nogui.py works as well. Good.

---27Nov2010---
usrp_am_mw_rcv.py won't work. This is the error message I get (name is different from original as I was working on a copy):

sinager@SIRAD:~/gnuradio/gnuradio-examples$ ./am_rcv.py -f 10700000 -O plughw:1,0
Using RX d'board A: LF Rx
>>> gr_fir_ccf: using 3DNow!
gr_remez: insufficient extremals -- cannot continue
Traceback (most recent call last):
...
  File "./am_rcv.py", line 133, in __init__
    60)          # stopband attenuation
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/optfir.py", line 53, in low_pass
    taps = gr.remez (n + nextra_taps, fo, ao, w, "bandpass")
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py", line 432, in remez
    return _gnuradio_swig_py_general.remez(*args, **kwargs)
RuntimeError: gr_remez: insufficient extremals -- cannot continue

Error refers to stopband attenuation parameter in the filter section. By changing the "60" to no more than "40" the script works in my case, no clue why so far.
audio_filt_coeffs = optfir.low_pass (1,           # gain
                                    demod_rate,   # sampling rate
                                    8e3,        # passband cutoff
                                    10e3,       # stopband cutoff
                                    0.1,         # passband ripple
                                    60)          # stopband attenuation    <--- adjust


---04Dec2010---
Some more playing with the basic stuff, as I have not surrendered to serious study sessions yet (such as the great stuff at ComplexToReal).
This is the first receiver I managed to build from scratch in GRC: a simple NFM frontend for the TVRX board.
click to enalrge
 This is the very minimum you need and reception may be affected by poor selectivity when high gain is used on the frontend.

Following the block schematics:
USRP is used as a source and I selected "side B" which is where the TVRX board is connected.
Frequency and Gain are straightforward concepts: their value (within the TVRX allowed limits) can be typed in directly but it's not very practical, since every adjustment would need stopping the app to change them. A slider is a more conveniente solution: just use the ID as a variable wherever it needs to be referenced.
Decimation is one of the first new concepts to deal with and can be roughly be compared to a downconversion IF. The USRP samples signals coming from the TVRX 64 million times per second. In order to get a simple audio signal the only concern is scaling it down to audio frequencies, where a 8kHz sampling is more than enough.
In this case a decimation rate of 250 reduces the samples to just 256'000 before feeding them to next stage.
The following block is a bandpass filter letting through just the audio band between 300 and 5000 Hz, cutting therefore any out-of-band signalling that may interfere.

Audio filtering maybe is not strictly necessary, but the block also does a second step in the decimation of signal: a further division by 8 brings it to down to the 32000 samples per second that are compatible with the soundcard.
Immediately after comes the "simple squelch" module. Threshold is set by a slider as the background noise level will change depending on frequency and gain set.
Then comes the NBFM demodulator.
Quadrature rate shall be a perfect multiple of the sampling rate, so I eventually settled on using the same variable and forgetting about it. Hopefully I'll get more knowledge in the future and have a better rationale for the choice.
In the end comes the audio sink, with the usual "plughw" addressing.

Contact:indirizzo come immagine per diminuire lo spam

Published:  Nov10 - Home