> 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.
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.
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
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.