Usrp2_fft.py hehaves abnormally at a certain decimation rate

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)

Symptom
- 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,

ILKYOUNG.

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.

Matt

Matt,

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 E. [email protected]

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.

Matt

Matt,

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. :frowning:

Again, thank you for your help.

Best regards,

ILKYOUNG.
2009/10/7 Matt E. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs