[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] usrp_spectrum_sense vs. usrp_fft
From: |
killoqg |
Subject: |
Re: [Discuss-gnuradio] usrp_spectrum_sense vs. usrp_fft |
Date: |
Mon, 21 Jun 2010 01:42:36 -0700 (PDT) |
Hi,
I've found (thanks to Firas) the solution to the incorrect localization in
frequency of the maximum values. It's due to the factors tune-delay and
dwell-delay of the bin_statistics_f function. You have to increase these
values (setting both in 50e-3 I can locate quiet well the max values) cause
the results vary depending on the hardware and the PC performance.
Now I will try to calibrate my system to measure the received power, but
it's a different issue.
Hope it can help other people.
Best Regards.
killoqg wrote:
>
> Hi,
>
> I'm having the same problem: the output of my spectrum analyzer and the
> output of the spectrum_sense.py doesn't match. I'm trying to detect
> activity int the GSM900 band, but it's impossible with the outputs I
> obtain.
>
> I was trying to correct the code and I think that your formula is
> incorrect. I'll try to explain:
>
> P=E/N, with P=power of signal, E=energy of signal and N=number of points
>
> 1) The output of the c2mag (gr.complex_to_mag_squared) is the energy of
> the signal, so the power of the same signal will be these values divided
> by N (number of points), I think the square root is not necessary.
>
> 2) For the same reason, when you make
> 10*math.log(tb.power/tb.fft_size/tb.fft_size) I think it should be
> 10*math.log(tb.power/tb.fft_size)
>
> 3) After that, the last operation (signalPower /= tb.fft_size) is
> unnecessary, it's already done in 1)
>
> The incorrect range of values could be a problem of the ref-scale
> parameter. I tried to correct the output values using
> -20*math.log10(tb.ref_scale) but they're still out of range.
>
> In my case, either the maximum values of the output doesn't match with
> the ones in the spectrum analyzer view.
>
> Does anybody have an answer to this problem? It seems that the
> spectrum_sense is used in several projects, but how does it function?
>
> Thanks in advance.
>
>
> adib_sairi wrote:
>>
>>
>>
>> TMob wrote:
>>>
>>> Hi,
>>>
>>> I am currently trying to use the USRP to sense the 802.11 channels for
>>> activity. So far, I am using the usrp_spectrum_sense to do this. Each
>>> time I get the callback from gr.bin_statistics_f, I calculate the signal
>>> power in the returned data vector using the following formula:
>>>
>>> for bin in m.data:
>>> signalPower +=
>>> 20*math.log10(math.sqrt(bin)/tb.fft_size)-20*math.log10(tb.fft_size)-10*math.log(tb.power/tb.fft_size/tb.fft_size)
>>> signalPower /= tb.fft_size
>>>
>>> According to previous posts, this should give me the signal power at the
>>> given center frequency in dBm.
>>> Unfortunately, it turned out that the values that I get using this code,
>>> vary very much, e.g. with the FFT size and the gain. When I leave gain
>>> and FFT size per default I get values from -28 through +5 (dBm) which
>>> definitely does not correspond to dBm. Is there any mistake in the
>>> formula? Is this really dBm that I get?
>>>
>>> Because the usrp_fft.py example shows more realistic values (around -50
>>> - -60dBm) than the usrp_spectrum_sense.py, I was wondering if somebody
>>> could explain how usrp_fft gets to these values. All I can see in the
>>> source code there is that a USRP source is defined and connected to the
>>> scope. But where is the conversion into dBm done? Can this be applied to
>>> usrp_spectrum_sense somehow?
>>>
>>> Thanks,
>>>
>>> TMob
>>>
>>
>> did anyone have the answer to this question? is it because of the
>> usrp_fft.py have the windowing block? regarding the windowing block, do
>> any body know why the blackmanharis is chosen?
>>
>> Adib
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/usrp_spectrum_sense-vs.-usrp_fft-tp21708925p28946269.html
Sent from the GnuRadio mailing list archive at Nabble.com.