Bandwidths< 400Khz no longer work with USRP2

GNU Radio
1

I did a “git pull” for both UHD GnuRadio yesterday. I’m on the “next”
branch for gnuradio, and on
“master” for UHD.

Since doing a rebuild yesterday, bandwidths below 400KHz no longer work
on the USRP2.

I did a test with a dead-simple flowgraph:

UHD single source–>multi-const x 32767–>FFT

For bandwidths >= 400KHz, the resulting FFT, with my existing RF
front-end with 40dB gain feeding
the BASIC_RX on my USRP2, the FFT looks just fine (showing a level
around -40dB).

But anything below 400KHz bandwidth (I tried various bandwidths between
200KHz and 400KHz),
produces an FFT with nothing useful in it, and a “level” around
-400dB.

This used to work just fine below 400KHz. What happened?

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

2

On 11/14/2010 02:28 PM, Marcus D. Leech wrote:

So, nobody has answered my question yet.

Even with the “latest and freshest UHD (master) and GnuRadio (next)”, Rx
bandwidths below 400KHz don’t appear to work correctly on a USRP2
with UHD, giving a flat-line at -410dB in the FFT display.

3

On Tue, Nov 16, 2010 at 6:13 PM, Marcus D. Leech [email protected]
wrote:

This used to work just fine below 400KHz. What happened?

So, nobody has answered my question yet.

Even with the “latest and freshest UHD (master) and GnuRadio (next)”, Rx
bandwidths below 400KHz don’t appear to work correctly on a USRP2
with UHD, giving a flat-line at -410dB in the FFT display.

No answer or insight, just another data point. I’ve been running UHD
apps today at 200 KHz sample rates with not problem.

Tom

4

On Tue, Nov 16, 2010 at 8:42 PM, Marcus D. Leech [email protected]
wrote:

Hmm, that is interesting. What daugthercard? What firmware?
WBX with latest firmware downloaded from Ettus Monday.

And you’re running latest GnuRadio and UHD?

Working from next and pulled from uhd/master yesterday.

Tom

5

On 11/16/2010 11:34 PM, Tom R. wrote:

On Tue, Nov 16, 2010 at 6:13 PM, Marcus D. Leech [email protected] wrote:

No answer or insight, just another data point. I’ve been running UHD
apps today at 200 KHz sample rates with not problem.

Tom

Hmm, that is interesting. What daugthercard? What firmware?

And you’re running latest GnuRadio and UHD?

I haven’t run my hardware under 400KHz for several weeks, and then a
coupla days ago,
after updating UHD and GnuRadio, it starts showing the “-410dB”
behaviour. Even in a simple,
simple flow-graph. But anything >= 400Khz, and it’s fine and dandy
again.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

6

On 11/17/2010 02:00 AM, Tom R. wrote:

WBX with latest firmware downloaded from Ettus Monday.

Hmmm, I’m using Basic_Rx. That should make zero difference.

I discovered that there’s a “magic” break at any sample rate that
requires a decimation >256.
So somewhere is having a hard time with greater-than-eight-bit
integers.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

7

On 11/17/2010 02:00 AM, Tom R. wrote:

WBX with latest firmware downloaded from Ettus Monday.

That’s the 20100901 firmware or something more recent?

And you’re running latest GnuRadio and UHD?

Working from next and pulled from uhd/master yesterday.

Tom

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

8

On 11/16/2010 11:13 PM, Marcus D. Leech wrote:

On 11/17/2010 02:00 AM, Tom R. wrote:

WBX with latest firmware downloaded from Ettus Monday.

Hmmm, I’m using Basic_Rx. That should make zero difference.

I discovered that there’s a “magic” break at any sample rate that
requires a decimation>256.
So somewhere is having a hard time with greater-than-eight-bit integers.

Decimation is filtering. When you decimate by 512 you are reducing
noise by a factor of 512 (27dB). Since you are using a BasicRX, there
will be very little noise, and 27dB less after decimation. In fact,
there is so little noise that the output of the filters is a constant 0
once it is rounded to 16 bit ints. That is why the FFT results
essentially show negative infinity.

The solution is to decimate less in hardware and more in software, or to
use more amplification.

Matt

9

On Tue, Nov 16, 2010 at 11:15 PM, Marcus D. Leech [email protected]
wrote:

On 11/17/2010 02:00 AM, Tom R. wrote:

WBX with latest firmware downloaded from Ettus Monday.

That’s the 20100901 firmware or something more recent?

Yes, that’s the firmware date I’m using (firmware and FPGA).

Tom

10

On 11/17/2010 02:20 AM, Matt E. wrote:

Decimation is filtering. When you decimate by 512 you are reducing
noise by a factor of 512 (27dB). Since you are using a BasicRX, there
will be very little noise, and 27dB less after decimation. In fact,
there is so little noise that the output of the filters is a constant
0 once it is rounded to 16 bit ints. That is why the FFT results
essentially show negative infinity.

Well, OK, I’ll buy that. But there’s a significant change below
decimation=256. A non-linear
jump from “reasonable-looking data” to “negative infinity”.

I’m seeing a jump from a level of around -20dB to “negative infinity” by
changing decimation from
256 to 260, which is a noise bandwidth change of something like
0.04dB.

So while I’m totally willing to believe that a gross change from 400KHz
to 200KHz might cause a
bit of weirdness, it seems highly counter-intuitive that a small
change as implied by
decimation=256 to decimation=260 would cause a huge nonlinear leap in
filter output in
the decimator.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

11

On 11/17/2010 12:43 PM, Marcus D. Leech wrote:

the same filter sequence in the decimator, correct?

Marcus, you’re a blithering idiot who should routinely be denied air.
You have clearly conflated the decimation/bandwidth numbers and
erroneously come to the conclusion that they should use the same
half-band filter lineup. They don’t, you stupid, sorry excuse for
an advanced lifeform you. God, can you even tie your shoes reliably?
Let’s see, 250KHz uses a decimation of 400, which uses both
half-bands in the FPGA because it’s both even and a multiple of 4,
whereas 400KHz uses a decimation of 250, which is even, but not a
multiple of four, and so only uses a single half-band. So
naturally, the numbers won’t “add up” between the two bandwidths.

Frikkin’ hell man, get a clue would you? Before I come over there and
whack you upside the head with a gnarly-great clue-by-four.

:slight_smile: :slight_smile: :slight_smile:

12

On Wed, Nov 17, 2010 at 2:45 PM, Marcus D. Leech [email protected]
wrote:

by less than 3dB. Both 400Khz and 250KHz use a decimation that is both
400KHz uses a decimation of 250, which is even, but not a
multiple of four, and so only uses a single half-band. So naturally,
the numbers won’t “add up” between the two bandwidths.

Frikkin’ hell man, get a clue would you? Before I come over there and
whack you upside the head with a gnarly-great clue-by-four.

:slight_smile: :slight_smile: :slight_smile:

Don’t be so hard on yourself…many of us would have still been stumped
:slight_smile:
It’s definitely not obvious/intuitive (to me, at least) that changing
the
decimation rate just slightly results in adding a whole 'nother
additional
set of filtering.

Shouldn’t the half-band filters have unity-gain in the pass-band?

-Steven

13

On 11/17/2010 03:05 PM, Steven C. wrote:

     are roughly 0.002 to 0.003 when I'm using 400KHz sampling,
air.  You have clearly conflated the decimation/bandwidth numbers and
and whack you upside the head with a gnarly-great clue-by-four.

-Steven
Yes, they definitely should have unity-gain within the passband, but
they have a Bessel-like response
as far as I recall. The edges have a 10dB roll-off, so my guess is
that the convolution of the
response of those (extended) edges gives us the apparent 8-10dB
difference in average
power level between 400KHz and 250KHz (or more generally,
decimination-by-factor-of-four vs
decimation-by-other-even factor). The difference in detected power
that one would “expect” for
this bandwidth difference is roughly 2dB, all else being equal.
Clearly, “all else isn’t equal”.

Matt would know for sure.

14

On 11/17/2010 02:20 AM, Matt E. wrote:

Matt

OK, to follow-up after a few experiments this morning. I added roughly
40dB of gain (in addition to the 35dB or so that was already there)
of well-filtered gain in front of the USRP2/Basic_Rx. That appears
to have caused <400KHz to start working, so I got caught up by
a red-herring of decimation=256 – that was a coincidence, but my oh
my what a coincidence!

So, I have over 70dB of gain in front of the USRP2+Basic_Rx combination,
and I have a stripped-to-the-bones app for investigating things
that consists of a UHD source, and FFT sink block, and also a
complex-to-mag block with a number sink.

What I’m seeing is that the magnitudes (as seen in the number sink)
coming off the source, even with roughly 75dB of gain ahead
are roughly 0.002 to 0.003 when I’m using 400KHz sampling, and
roughly 0.0006 to 0.0007 when the bandwidth is 250KHz. If you
process the numbers as voltages, then we’re talking a roughly 10dB
drop in apparent average power level by reducing the bandwidth
by less than 3dB. Both 400Khz and 250KHz use a decimation that is
both even, and a multiple of 4, so they should be using exactly
the same filter sequence in the decimator, correct?

What surprises me is how tiny these numbers are–I’m connected to an
antenna outdoors, and the system can easily “see”
distant CB stations, for example (I use stuff on the CB bands as a
kind of gross sanity test for sensitivity).

So now, I’m wondering how things are scaled between the ADC and the
host. The ADC is 14 bits twos-complement signed, then it goes
into the FPGA–do you do 32-bit arithmetic inside the FPGA and then
re-scale back to 16-bits?

Then those 16-bits get squirted over the GiGe, where UHD picks them up,
and re-scales them into +/- 1.0 floating point numbers, yes?