Fft realated problems

GNU Radio
1

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-tp20308034p20308034.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

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)

  1. Redo your experiments again!!.

Best Regards,

Firas

–
View this message in context:
http://www.nabble.com/fft-realated-problems-tp20308034p20316456.html
Sent from the GnuRadio mailing list archive at Nabble.com.

3

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-tp20308034p20318454.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

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-tp20308034p20324923.html
Sent from the GnuRadio mailing list archive at Nabble.com.

5

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-tp20308034p20325086.html
Sent from the GnuRadio mailing list archive at Nabble.com.

6

Yes I have tried both RX2 and TX/RX antennas, but I have same results.

Kaleem Ahmad

Eric B. wrote:

some other system is not working in the area.

–
View this message in context:
http://www.nabble.com/fft-realated-problems-tp20308034p20327209.html
Sent from the GnuRadio mailing list archive at Nabble.com.

7

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

8

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

9

You can find the code attached.

Thanks
Kaleem Ahmad

Firas A. wrote:

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

http://www.nabble.com/file/p20328754/COMAC_sensing.py COMAC_sensing.py

View this message in context:
http://www.nabble.com/fft-realated-problems-tp20308034p20328754.html
Sent from the GnuRadio mailing list archive at Nabble.com.

10

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 M.
Whidbey Island, WA

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-tp20308034p20328933.html
Sent from the GnuRadio mailing list archive at Nabble.com.

12

Hi,

 Paul M. [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

13

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.

14

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

15

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-tp20308034p27169855.html
Sent from the GnuRadio mailing list archive at Nabble.com.