Hi,
> Paul Mathews <[EMAIL PROTECTED]> 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: IF required_tune_delay_in_sec = 10e-3 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
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
