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:25:09 -0800 (PST)

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 <address@hidden> 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 <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
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
>
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




reply via email to

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