Re: usrp_spectrum_sense vs. usrp_fft

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
    10math.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:

power in the returned data vector using the following formula:
and FFT size per default I get values from -28 through +5 (dBm) which
Thanks,


View this message in context:
http://old.nabble.com/usrp_spectrum_sense-vs.-usrp_fft-tp21708925p28819417.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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:

  1. After that, the last operation (signalPower /= tb.fft_size) is
    spectrum_sense is used in several projects, but how does it function?

Hi,

could explain how usrp_fft gets to these values. All I can see in 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.

When I run the FFT routine (usrp2_fft.grc) there are two apparent
anomalies that I do not understand. TIA to anyone who can help a poor
soul out with what are most likely simple things:

  1. When I execute, there are error messages and no window appears. The
    routine works fine, per the caveat of #2 below, if I ‘Build’ and the
    just run with Python from the command line.

  2. When I run usrp2_fft.py, the windows appear and the program runs
    fine, but it continually outputs an ‘S’ to the terminal. I looked for
    an output somewhere for stdio or stdout, but found nothing. Is this
    perhaps an old bug, or a Ubuntu thing? Is it something that needs to
    be edited in the Python file or with a switch?

Harley Myler

CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.

Hi Harley,

On Aug 14, 2010, at 1:18 AM, HR Myler wrote:

  1. When I run usrp2_fft.py, the windows appear and the program runs fine, but it continually outputs an ‘S’ to the terminal. I looked for an output somewhere for stdio or stdout, but found nothing. Is this perhaps an old bug, or a Ubuntu thing? Is it something that needs to be edited in the Python file or with a switch?

Looks like a sample over-run. I got that the last time, due to network
contention between Fedora 12 running inside a VM, and the host Mac OS.
Switching to Ubuntu helped fix that.

Try to re-check your network settings or allocate more CPUs for the VM.

Best regards,

Elvis D.