[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Use of bin_statistics

From: Firas Abbas
Subject: Re: [Discuss-gnuradio] Use of bin_statistics
Date: Fri, 7 Nov 2008 22:22:28 -0800 (PST)


>  Paul Mathews <address@hidden> wrote:
> use "--tune-delay" with 10e-3 
> Based on the above, I'd expect an integer tune delay parameter.
> Is 10e-3 just a way of specifying a value smaller than 1, so
> there's no tune delay?

The tune delay timing parameter passed to bin_statistics is
calculated in FFT frames which depends on USRP rate and FFT
length as in :

tune_delay_passed_to_bin_stats = int(round(required_tune_delay_in_sec*usrp_rate/fft_size))

if this calculated value is less than "1", then we should make
it at least "1" FFT frame.

For example:


required_tune_delay_in_sec = 10e-3
and usrp_rate = 8000000 (decimation =8)
and FFT size is 1024


tune_delay_passed_to_bin_stats = 78 (FFT Frames)

This means we have to skip 78 incoming vectors (FFT frames) before
we actually use the accuired samples in our spectrum statistics.

Actually,I think the writer of the usrp_spectrum_sense.py code is
genius and I consider it as the best given working example in
the gnuradio project.

Important Note:
Beside tunning time depends on the hardware (RF syenthesizer speed),
one should remameber that the time needed to collect 1024 samples
with decimation rate=8 (minimum USRP decimation) is 128 usec

while :

Time needed to collect 1024 samples with decimation rate=256 (maximum
USRP decimation) is 4.096 msec

This means that the tune delay in the case of decimation rate =256
should be larger than that used for deimation = 8.

A working tune delay value (which gives accurate results) can be
known by experiments (for given decimation rate and FFT length).

I Hope this clarify the mater.



reply via email to

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