Hi,
> Paul Mathews <address@hidden> wrote:
> use "tunedelay" with 10e3 > > Based on the above, I'd expect an integer tune delay parameter. > Is 10e3 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:
IF
required_tune_delay_in_sec = 10e3 and usrp_rate = 8000000 (decimation =8) and FFT size is 1024
THEN
:
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.
Regards,
Firas
