Re: [Discuss-gnuradio] Use of bin_statistics
Adib- > > 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. > > > > > > i have a question regarding the above quote, if we are taking 1024 bin FFT, > do we need to have 1024 of signal samples? It's not necessary, you can "zero-fill" remaining samples until 1024. In some analyses, the time domain collection frame size is held constant (it may be dependent on the nature of the data) and the FFT size increased, giving more "bins per Hz" and an improved view of what's going on. But if you do this, then you may want to apply a Hamming or other window prior to the FFT to avoid a potentially abrupt amplitude cutoff at the zero-fill point. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Use of bin_statistics
Firas A. wrote: > > > 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. > > i have a question regarding the above quote, if we are taking 1024 bin FFT, do we need to have 1024 of signal samples? and i have another question, regarding the FFT block, i try to come out with the equation on what is actually this block (gr_fft_vcc) do in the code, but i cannot trace the whole code (in c++). if we open the c++ code and we can see that the only thing that gr_fft_vcc class do is calling set_window function but no "work" class inside.. so which file/class actually does implement the fft computing? is it in gr_fft__vcc_fftw.cc? i am sorry to ask this question.. hope anyone can help =) thanks.. Adib -- View this message in context: http://old.nabble.com/fft-realated-problems-tp20308034p27169855.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Use of bin_statistics
Firas A. wrote: > > 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. > > Regards, > > Firas > > I see now that usrp_spectrum_sense.py rescales the timing parameters to seconds before passing them to bin_statistics. Thanks. - Paul Mathews Design Services: non-contact sensors, RFID, collision avoidance, EMI compliance -- View this message in context: http://www.nabble.com/fft-realated-problems-tp20308034p20398398.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Use of bin_statistics
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 = 800 (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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Use of bin_statistics
Working to understand sink block bin_statistics_f. Examining the User Manual, the sourcecode gr_bin_statistics_f.cc and related includes, and hacking qa_bin_statistics.py, this is my current understanding: 1. bin_statistics determines max values of vectors with length vlen over a number of samples dwell_delay after discarding tune_delay samples. 2. After processing N = dwell_delay samples, bin_statistics composes a message and inserts it in the message queue. 3. Each message from bin_statistics consists of a vector of max values, prefixed by the center frequency corresponding to the associated samples, i.e., it is just the frequency value delivered to bin_statistics with the input samples. I was hoping that bin_statistics would do more than the above, and perhaps I'm not yet understanding something. Any additional hints will be appreciated. In particular, I'd like to know the frequency of the highest peak in an FFT vector (see below). Unless I can find a better starting point, I intend to hack bin_statistics. I was also confused by some of the recent threads about usrp_spectrum_sense.py. In particular, there was the following advice from Firas Abbaz in this thread http://www.nabble.com/fft-realated-problems-td20308034.html#a20328754 -- Firas A. wrote: Hi, 1) 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? I actually need to do the following (I think) to implement a simple AFC: A. Find the highest peak in an FFT output vector. B. Compare highest peak freq to current tuning. If diff is significant, retune to new peak freq C. Allow settling time before looping If anyone is aware of existing code that would be a good starting point, please advise. Thanks. Paul Mathews Whidbey Island, WA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
