discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]