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 <[EMAIL PROTECTED]> 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. > > > > [EMAIL PROTECTED] 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] > > > [EMAIL PROTECTED] 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 > Discuss-gnuradio@gnu.org > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
