[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 dec

Subject: Re: [Discuss-gnuradio] usrp2_fft.py hehaves abnormally at a certain decimation rate
Date: Wed, 7 Oct 2009 21:01:16 +0900

Thank you for your clear advice. That really explains my previous experiment result. For some reason, I was completely ignorant to the dynamic range of ADC: the fact that just a simple calculation gives me 84dB for 14 bit (6.02 * 14 = 84.28dB). Maybe I was obsessed by other stuffs too much to forget the basic.  :-(
Again, thank you for your help.
Best regards,
2009/10/7 Matt Ettus <address@hidden>

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?

 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]