[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] usrp2_fft.py hehaves abnormally at a certain deci

From: Matt Ettus
Subject: Re: [Discuss-gnuradio] usrp2_fft.py hehaves abnormally at a certain decimation rate
Date: Tue, 06 Oct 2009 19:17:06 -0700
User-agent: Thunderbird (X11/20090825)

The short answer is that to receive very weak signals, you want to decimate LESS in the FPGA since it is fixed-point. Then do more decimation in your software on the host computer in floating point. Your optimal performance will come with a decimation of 4 in the USRP2, and all further decimation and filtering done in the host computer in floating point.

Remember, full scale on the ADC is about 10 dBm. It is a 14-bit ADC and thus max signals would be +/- 8192. A +/-1 signal is thus about 80dB lower, or -70dBm. In order to receive signals weaker than that, you need to filter to get processing gain. But this can only be done in floating point.


Thank you for your reply. Actually, I repeated the experiment again with a HP signal generator to find that it happens when the signal level was not quite much low( I don't remember the number.). Since I don't remember the exact level that the simptom appears, I will do the experiment again and let you know the result. Since I am trying to detect very low level signals with USRP2, this issue is rather critical for me. By the way, to work it around, I should do either 1) Amplifier input signal before AD Converting. (Put an LNA before RF input port, activate amplifier in the ADC chip, etc) 2) Enhance filters' signal suppression performance (Don't know if I can manage this, though... ) Do I get it right? Regards, ILKYOUNG.

2009/10/6 Matt Ettus <address@hidden <mailto:address@hidden>>

    Decimation involves filtering.  Filtering reduces the noise power,
    which can cause you to have many zero samples in a row, which will
    result in what you saw.  Different combinations of the CIC and
    halfband filters will result in different noise behavior.  What you
    are seeing is perfectly normal, and won't happen when there is a
    real signal there.



        I was in a test with 'usrp2_fft.py' code in the gr-utils
        directory and found that the program is not running as I
        expected in certain conditions.
        I was watching signals running the usrp2 as a spectrum analyzer
        with the code.
         Test environment information
           - usrp2 + gnuradio 3.2.1 (or gnuradio 3.2.2)
           - usrp2 H/W version : rev. 3
           - usrp2 SD card image/code version : Cannot identify
           - RF RX Interface : basic RX board
           - Host PC O/S : ubuntu 9.04 Desktop (64bit version)
           - When I set the decimation rate to '20', and open the RF
        input port(hooked up no signals), the noise level goes down to
        -380dBm and and flat. With the decimation rate of 18 or 22, it
        looks O.K. Noise level is around -90dBm and I can see the
        frequency domain envelope of white noise.
           - At that moment, the samples coming from usrp2 are all zero.
        I confirmed it with wireshark.
           - I figured out that it happens not only with the decimation
        rate of 20, but with 40, 60, etc.
             I was suspicous if it went like that with multiples of 20,
        but it happened with 50, 82, etc.
           - When I feed signal to the RF RX port, it goes back to
        normal. So, I can say that it happens when the input signal
        level(power) is lower that a certain level. However, it does not
        happen with other decimation rates like 4, 6, or 18.
         I would like to know
        1. If this is a known issue. In that case, I also would like to
        know if there is any workaround.
        2. If this is a new issue, I would like to ask experts in this
        mailing list to reproduce the experiment and let me know why
        this happens and what I should do.
         Best regards,


        Discuss-gnuradio mailing list
        address@hidden <mailto:address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]