Problem with N200 and waterfall display in grc

GNU Radio
1

Hi Everyone,

I have a USRP N200 rev 2. I created a simple graph using the gnu radio
companion (grc) which is composed of three blocks, a UHD source, a
variable
slider, and a WX FFT Waterfall display. When I run this graph, i
quickly
see the waterfall display fill up with the color blue and then the
application becomes unresponsive. How can I fix this?

When I run the uhd_fft tool, it appears to work correctly – it shows me
a
spectrum and allows me to adjust the fc and the gain.

Also, where can i find a guide to the N200 debug lights? Lights C, E,
and F
seem to be on all the time. Is this okay?

Thanks in advance,
Isaac

2

On 08/16/2011 08:33 AM, Isaac G. wrote:

Hi Everyone,

I have a USRP N200 rev 2. I created a simple graph using the gnu radio
companion (grc) which is composed of three blocks, a UHD source, a variable
slider, and a WX FFT Waterfall display. When I run this graph, i quickly
see the waterfall display fill up with the color blue and then the
application becomes unresponsive. How can I fix this?

Sounds like the opengl plotter widget is getting overwhelmed. Its
different on every computer. Try a smaller fft size to shrink the size
of the on-screen texture.

When I run the uhd_fft tool, it appears to work correctly – it shows me a
spectrum and allows me to adjust the fc and the gain.

Also, where can i find a guide to the N200 debug lights? Lights C, E, and F
seem to be on all the time. Is this okay?

http://www.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds

3

On 16/08/2011 12:57 PM, Josh B. wrote:

Sounds like the opengl plotter widget is getting overwhelmed. Its
different on every computer. Try a smaller fft size to shrink the size
of the on-screen texture.

The usual issue is the frame-rate, not the FFT size. The default for
that widget is 15FPS, and since the colourmaps are
computed (as I recall) in Python, it has a hard time keeping up,
particularly if the bandwidth is high.

4

I fixed it by ensuring that the sample rates were correct in the blocks.
I
was requesting a fs of 100 Hz but was getting something around 190kHz.
Once
i got these numbers all synced up (to the 190kHz) the blocks worked as
expected.

Isaac

5

On 16/08/2011 3:20 PM, Isaac G. wrote:

I fixed it by ensuring that the sample rates were correct in the
blocks. I was requesting a fs of 100 Hz but was getting something
around 190kHz. Once i got these numbers all synced up (to the 190kHz)
the blocks worked as expected.

Isaac
The Fs on the FFT and Waterfall graphs is used to calculate the labels
for the X-axis, and also some internal decimation, but it doesn’t force
the
incoming stream to be arriving at that sample rate. It must match
the actual sample rate, which on the N2XXX is a minimum of
100e6/512 = 195312 Sps.

If you need to process samples at some rate other than one of the
properly-decimated rates coming out of a UHD source block, you’ll
have to resample within the flow-graph. I like to use the fractional
interpolator myself.