[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] fft realated problems
From: |
kaleem ahmad |
Subject: |
[Discuss-gnuradio] fft realated problems |
Date: |
Mon, 3 Nov 2008 10:32:42 -0800 (PST) |
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.
- [Discuss-gnuradio] fft realated problems,
kaleem ahmad <=
- Re: [Discuss-gnuradio] fft realated problems, Firas A., 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, kaleem ahmad, 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, Firas A., 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, kaleem ahmad, 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, Eric Blossom, 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, kaleem ahmad, 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, Firas Abbas, 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, kaleem ahmad, 2008/11/04
- Re: [Discuss-gnuradio] fft realated problems, Firas A., 2008/11/04
- [Discuss-gnuradio] Use of bin_statistics, Paul Mathews, 2008/11/07