Hi, I am using RFX2400 + USRP + SUSI. In one line what I want to do....I want to find signal amplitude at a given frequency. Or other wise I want to find the signal level at any frequency just as graphically shown by fft_sink (the peak of the signal). For this I started with usrp_spectrum_sense.py. With the freq. step of 3M it is continuesly scanning the spectrum. For any center frequency it returnes vector "m" with a length equal to fft_size. My perception (Please correct me if I am wrong) was that I will get this vector m at different desired center frequencies and then for each frequency I will get max(m.data) which will give me the peak value around that center frequency. Theoretically it looked very simple but when I implemented it I found strange results which I am going to discuss one by one in the following: 1-When I run usrp_spectrum_sense.py without any changes the max values were in the order e.g [7141325.0, 12567175168.0, 12465465344.0....] which are extremely big for fft size 512 (This is the only change which I did in original code , but doesnt matter even for other fft values it remains in the same order). 2-Then I did a little change in the code. Rather than original freq step, min_cen_freq etc idea, I defined 6 channels as follows [2.41e9, 2.42e9, 2.43e9, 2.44e9, 2.45e9....] and I sanned only these center frequencies and the max(m.data) were in the order as follows [36.9894752502, 65.4092178345, 43.0024604797, .....]. I am surprised why these are extreamly small as compared to first results?????? 3-Then I merged this code with another code where I was using txpath and rxpath with topblock, with rxpath I used as follows: self.connect(self.u, gr.stream_to_vector, gr.fft_vcc, gr.complex_to_mag_squared, gr.nlog10_ff, gr.bin_statistics_f) self.connect(self.u, gr.fir_filter_ccf, gr.quadrature_demod_cf, gr.simple_correlator, gr.vector_sink_b) and the results were in the order [8.3423, 14.76875, 25.1657, 7.789723.....]...even smaller values than above both..............can someone please explain WHY? It would be acceptable if it would be giving the peak value in this way, doesnt matter if it would be small or large...at least it would help me to decide where is the peak and which peak is smaller than the other. But unfortunately the results are meaningless. For example I started one narrowband FSK system at 2.4606 GHz my code which I mentioned above in [2] give following results (while reading these results please keep in mind that as seen from the spectrum analyzer there is only one system as I mentioned at 2.4606GHz, remaing entire 2.4GHz ISM band is free, but the results dont show this): NEW FREQ-------------- 2410560000.0 max(m.data): 55.9439315796 (I dont have any thing here, I can see from spectrum analyzer) NEW FREQ-------------- 2420064000.0 max(m.data): 19.0843219757 (nothing here) NEW FREQ-------------- 2430432000.0 max(m.data): 51.505443573 (nothing here) NEW FREQ-------------- 2440800000.0 max(m.data): 49.089176178 (nothing here) NEW FREQ-------------- 2450304000.0 max(m.data): 36.2235908508 (nothing here) NEW FREQ-------------- 2460672000.0 max(m.data): 65.4090957642 (An FSK system here) NEW FREQ-------------- 2410560000.0 max(m.data): 59.4409942627 (nothing here) NEW FREQ-------------- 2420064000.0 max(m.data): 18.2838001251 (nothing here) NEW FREQ-------------- 2430432000.0 max(m.data): 51.4855537415 (nothing here) NEW FREQ-------------- 2440800000.0 max(m.data): 49.1326179504 (nothing here) NEW FREQ-------------- 2450304000.0 max(m.data): 36.7711868286 (nothing here) NEW FREQ-------------- 2460672000.0 max(m.data): 64.7095947266 (FSK here) NEW FREQ-------------- 2410560000.0 max(m.data): 65.3698883057 (nothing here) NEW FREQ-------------- 2420064000.0 max(m.data): 18.146987915 (nothing here) NEW FREQ-------------- 2430432000.0 max(m.data): 51.4791488647 (nothing here) NEW FREQ-------------- 2440800000.0 max(m.data): 49.112991333 (nothing here) NEW FREQ-------------- 2450304000.0 max(m.data): 37.0178260803 (nothing here) NEW FREQ-------------- 2460672000.0 max(m.data): 64.8787078857 (FSK here) By having a look at these results you can see that these are meaningless because I have only one 864khz system working at 2.4606GHz and at all other frequencies I have nothing and by spectrum analyzer I can see that I have a peak at 2.4606GHz with -60dBm peak..but above results give high values at other frequencies even. Except 2.4606 at all other frequencies the results should be the same (doesnt matter what would be the absolute value) and smaller than of 2.4606GHz (because only system is working at 2.4606 GHz)????? Please first of all let me know my idea was correct or not which I presented in the begining. Secondally please let me know why these results are so meaningless. Thirdly please explain what m.data have? and what relation it have with decimation rate set by the software and fft? I have following idea about it: Assume fft = 32 the center freq. is 2.45GHz and decimation_rate = 16 Then m.data would be of length 32 and will these 32 values will be corresponding to 32 different freq. separated by ??? around above given center frequency. Is above concept correct and what will be the amount in ???. Please give me some suggestions. I am really tired and this problem have seriously threatens my job!!! Looking for some responces Best Regards -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-03 19:33

on 2008-11-04 06:36

Hi, 1) use "--tune-delay" with 10e-3 2) Uncomment : #self.connect(self.u, s2v, fft, c2mag, log, stats) 3) Comment: self.connect(self.u, s2v, fft, c2mag, stats) 4) Change the line : self.max_center_freq = self.min_center_freq + (nsteps * self.freq_step) to be : self.max_center_freq = self.min_center_freq + ((nsteps-1) *self.freq_step) 5) Redo your experiments again!!. Best Regards, Firas -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-04 10:02

Dear Firas, Thanks for your reply, I am trying this although I had already tried by changing tune_delay and center_freq, but I still have similar results. But can you explain me please why you think changing these parameters shold work? and if I choose some frequencies from an array (e.g. [2.41e9, 2.42e9, 2.43e9, 2.44e9, 2.45e9]), rather to set max and min center frequencies then what can be the problem in that? Best Regards Kaleem Ahmad Firas A. wrote: > > Best Regards, > > > Firas > > -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-04 16:50

Hi, 1) Are you feeding RF2400 directly from signal generator or by Antenna ?. Remember that the ISM 2.4GHz band is occupied by wireless devices. 2) Is your RFX2400 works normally with usrp_fft.py ? Can you see clearly the signals you generate in it at the specified frequencies ?. Try to Adjust the RF gain in usrp_fft to get best signal view. Use this gain value in your experiments. 3) Tune delay is very important. When you command the usrp RF daughterboard to change its frequency, then there is many delays along the digitization path (RF synthesizer tuning time, FPGA FIFO filling time, USB transferring time...etc). Using enough tune delay time, you will be sure that the samples entering your FFT block are belong to the requested center frequency. 4) To clearly see the spectrum, you must use the math log function (as implemented in usrp_fft.py). Regards, Firas -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-04 16:59

Dear Firas, Thanks for your reply, First of all I am using antenna (RX2), and yes I know 2.4 band is messed up with many wireless tech. but I am continuesly monitoring it with spectrum analyzer during my experiments to make sure that some other system is not working in the area. I have tried with many TX and RF gains. I am also using log function, and I have already checked with larger tune_delays but all in vain???????? Any suggestions?? Best Regards Kaleem Ahmad Firas A. wrote: > value in your experiments. > > > Regards, > > Firas > -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-04 18:17

On Tue, Nov 04, 2008 at 07:59:09AM -0800, kaleem ahmad wrote: > I am also using log function, and I have already checked with larger > tune_delays but all in vain???????? > > Any suggestions?? > > Best Regards > Kaleem Ahmad Are you selecting the RX2 input in the software? By default the s/w uses TX/RX. Try connecting your input to the TX/RX connector. Eric

on 2008-11-04 18:38

Yes I have tried both RX2 and TX/RX antennas, but I have same results. Kaleem Ahmad Eric Blossom wrote: >> some other system is not working in the area. > > > -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-04 19:27

Hi, Post your code usedÂ in the experimentsÂ (the one you used to get input signal from RX2) and the command line arguments you use to run the it. Firas

on 2008-11-04 19:58

You can find the code attached. Thanks Kaleem Ahmad Firas A. wrote: > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > http://www.nabble.com/file/p20328754/COMAC_sensing.py COMAC_sensing.py -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-04 20:11

Hi, This is not the standard usrp_spectrum_sense.py. Is the "grcomac.bin_statistics_f" same as gr.bin_statistics_f or modified one?. Why you are not upgrading from gr_flow_graph() to top_block()?. I cannot run the code in my system to help you. Regards, Firas -- View this message in context: http://www.nabble.com/fft-realated-problems-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2008-11-08 05:41

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

on 2008-11-08 07:23

Hi, >Â Paul Mathews <opto@whidbey.com> 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

on 2008-11-08 18:42

Firas A. wrote: > > Regards, > > Firas > > I see now that usrp_spectrum_sense.py rescales the timing parameters to seconds before passing them to bin_statistics. Thanks.

on 2010-01-15 00:21

Firas A. wrote: > 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-tp2030... Sent from the GnuRadio mailing list archive at Nabble.com.

on 2010-01-15 00:42

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