[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] gr_bin_statistics and usrp_spectrum_sense
From: |
Angilberto Muniz Sb |
Subject: |
Re: [Discuss-gnuradio] gr_bin_statistics and usrp_spectrum_sense |
Date: |
Thu, 16 Nov 2006 18:17:27 -0800 (PST) |
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 Blossom <address@hidden> wrote:
> 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.
>
>
>
> address@hidden 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]
>
>
> address@hidden 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
>
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
- Re: [Discuss-gnuradio] gr_bin_statistics and usrp_spectrum_sense,
Angilberto Muniz Sb <=