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 SWIG Version 1.3.24 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2004 University of Chicago Compiled with g++ [i686-pc-linux-gnu] $ 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 > > Angilberto. > > --- Angilberto Muniz Sb <[EMAIL PROTECTED]> wrote: > > >>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 > > > > > > ____________________________________________________________________________________ > Sponsored Link > > $420k for $1,399/mo. > Think You Pay Too Much For Your Mortgage? > Find Out! www.LowerMyBills.com/lre > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
