[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] usrp2_fft.py hehaves abnormally at a certain deci
Re: [Discuss-gnuradio] usrp2_fft.py hehaves abnormally at a certain decimation rate
Tue, 06 Oct 2009 19:17:06 -0700
Thunderbird 184.108.40.206 (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
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
ILKYOUNG KWOUN wrote:
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
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.
ILKYOUNG KWOUN wrote:
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.
Discuss-gnuradio mailing list