Weird WX scope problem

GNU Radio
1

Running the current SVN I’m having a problem with apps that display
multiple scopes (usrp_nbfm_rcv.py) for example. What happens is that
the application will update only a single scope at a time. One scope
updates for a couple of seconds then another scope does, in a round
robin fashion. The GUI is mostly unresponsive. I see no
overflow/underflow, the audio runs fine, only the GUI is screwy.
Switching the app to one scope resolves the problem. Top is reporting
the app only using ~30% of a cpu on a dual core box.

I had this problem some months previously but it was intermittent and
I thought it might have been some power management glitch slowing down
my system since I was running on a laptop.

I’m at a bit of a loss as to where to begin troubleshooting this.
Suggestions?

2

Gregory M. wrote:

I thought it might have been some power management glitch slowing down
my system since I was running on a laptop.

I’m at a bit of a loss as to where to begin troubleshooting this. Suggestions?

This is usually caused by your system not being able to keep up. Try
lowering the fft_rate.

Matt

3

On Saturday 20 September 2008 23:22:20 Matt E. wrote:

This is usually caused by your system not being able to keep up. Try
lowering the fft_rate.

The code from trunk does not use the fft_rate from the config file
(opengl
version of scope sink).

Sent a patch to patch-gnuradio on thursday.

Stefan

4

http://gnuradio.org/trac/changeset/9637

How’s this?

5

On Monday 22 September 2008 04:38:49 Josh B. wrote:

http://gnuradio.org/trac/changeset/9637

Yeah, looks fine …

Just a small nitpick, in fftsink_gl.py, there is still this line:

class _fft_sink_base(gr.hier_block2, common.prop_setter):
…
def init(
…
fft_rate=gr.prefs().get_long(‘wxgui’, ‘fft_rate’,
fft_window.DEFAULT_FRAME_RATE),

Although this should have no effect, it might be misleading for anyone
looking
at the code.

Kind regards,

Stefan