Gr_bin_statistics and usrp_spectrum_sense

blair · November 7, 2006, 10:49am

Hi Folks,

I wanted to let you know that I’ve checked in some code that should be
useful for building “spectrum sensing” applications, or for that
matter, anything that needs to scan across a wide chunk of RF (bigger
than you can get across the USB in a single chunk).

There are two primary pieces:

(1) gnuradio-core/src/lib/general/gr_bin_statistics_f, which combines
statistics gathering with a state machine for controlling the tuning

and

(2) gnuradio-examples/python/usrp/usrp_spectrum_sense.py which is
an application (closer to a skeleton) that ties it all together.

[eb@dee usrp]$ ./usrp_spectrum_sense.py --help
usage: usrp_spectrum_sense.py [options] min_freq max_freq

options:
-h, --help show this help message and exit
-R RX_SUBDEV_SPEC, --rx-subdev-spec=RX_SUBDEV_SPEC
select USRP Rx side A or B (default=A)
-g GAIN, --gain=GAIN set gain in dB (default is midpoint)
–tune-delay=SECS time to delay (in seconds) after changing
frequency
[default=0.001]
–dwell-delay=SECS time to dwell (in seconds) at a given frequncy
[default=0.01]
-F FFT_SIZE, --fft-size=FFT_SIZE
specify number of FFT bins [default=256]
-d DECIM, --decim=DECIM
set decimation to DECIM [default=16]
–real-time Attempt to enable real-time scheduling
-B FUSB_BLOCK_SIZE, --fusb-block-size=FUSB_BLOCK_SIZE
specify fast usb block size [default=0]
-N FUSB_NBLOCKS, --fusb-nblocks=FUSB_NBLOCKS
specify number of fast usb blocks [default=0]

[eb@dee usrp]$ ./usrp_spectrum_sense.py -R b -F 256 902M 928M

You may want to subclass gr_bin_statistics_f, it currently just
keeps track of the maximum power in each FFT bin.

You’ll also want to play with the --tune-delay and --dwell-delay
command line options to determine appropriate values. --tune-delay
should include time for the front end PLL to settle, plus time for the
new samples to propagate through the pipeline. The default is 1ms,
which is probably in the ballpark on the RFX-* boards. The TV RX
board is much slower. The tuner data sheets says it could take 100ms to
settle. YMMV. Please test and let us know what you find.
–dwell-delay says how long you want to “stare” at any particular
window.

Let me know if you’ve got any questions. As always, patches are welcome

When we’ve got the inband-signaling in place, we’ll be able to
pipeline the tuning and our effective scanning rate will increase.

Eric

blair · November 17, 2006, 3:18am

Hi Eric,

In the ‘main_loop’ of ‘usrp_spectrum_sense.py’ it says
that m.center_freq is the current tunning/tunned freq
and that m.data is the mag-squared of the FFT.

When I run it I always get:

0 (Zero) as the ‘m.center_freq’ and some numbers out
of the m.data structure (seems ok). Was not
‘center_freq’ supposed to reflect the actual tunned
freqquency?

I’ve just inserted the following code into ‘main_loop’
of “usrp_spectrum_sense.py”:

print m.center_freq, m.data[0], m.data[1]

My setup: gnuradio latest version out of SVN.
OS: Umbuntu-LTS

Thankx,

Angilberto.

— Eric B. [email protected] wrote:

There are two primary pieces:
gnuradio-examples/python/usrp/usrp_spectrum_sense.py
options:
–dwell-delay=SECS time to dwell (in seconds)
-B FUSB_BLOCK_SIZE,

plus time for the

Eric

Discuss-gnuradio mailing list
[email protected]

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Sponsored Link

$200,000 mortgage for $660/ mo -
30/15 yr fixed, reduce debt -
http://yahoo.ratemarketplace.com

blair · December 11, 2006, 10:19pm

Hi Eric,

I have the same problem Angilberto Muniz had with the new
gr_bin_statistics and usrp_spectrum_sense.
Angilberto Muniz Sb wrote:

Humm… I’ve put some ‘prints’ in the ‘set_freq’ and
‘set_next_freq’ functions and came to the conclusion
that those functions are never called !
I get exactly the same.

I tried to understand the advanced python magic that is going on but
that takes a bit of studying.

Before I do that.
Does this trick only work with specific python/swig/gcc versions or does
it have smp issues?
I use the following:

uname -r
2.6.16-2-k7-smp

$ swig-1.3 -version

$ python -V
Python 2.3.5

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: …/src/configure -v
–enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
–mandir=/usr/share/man
–infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3
–enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls
–without-included-gettext --enable-clocale=gnu --enable-debug
–enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc
i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)

These worked fine for gnuradio so far.

Greetings,
Martin

blair · November 17, 2006, 3:26am

Humm… I’ve put some ‘prints’ in the ‘set_freq’ and
‘set_next_freq’ functions and came to the conclusion
that those functions are never called !

Angilberto.

— Angilberto Muniz Sb [email protected] wrote:

0 (Zero) as the ‘m.center_freq’ and some numbers out
My setup: gnuradio latest version out of SVN.

There are two primary pieces:

after changing frequency
–real-time Attempt to enable

You’ll also want to play with the --tune-delay and
boards. The TV RX
Let me know if you’ve got any questions. As

Eric

Discuss-gnuradio mailing list
[email protected]

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio