Fft scope frequent hangs

Hello every1,
I haven’t been playing with the fft scope for a while until yesterday,
when I realized that it frequently hangs on my fc5 with two weeks ago
trunk gnuradio… The scope freezes (in all modes) and it needs to be
killed to get the control back. No underruns or any messgae that could
give a further investigation advice.

Has anyone experienced the same? Is there any suggestion that could help
diagnose the problem?

Btw, decimation and all the other parms where the default ones, I just
retouched the dbs board gain.

Regards
Matteo iz2eeq

I haven’t been playing with the fft scope for a while until yesterday,
when I realized that it frequently hangs on my fc5 with two weeks ago
trunk gnuradio… The scope freezes (in all modes) and it needs to be
killed to get the control back. No underruns or any messgae that could
give a further investigation advice.

Has anyone experienced the same? Is there any suggestion that could help
diagnose the problem?

I find the scope will hang (on Windows with Cygwin or MinGW) if it
(along
with anything else that is running) overloads the cpu. This is
especially
likely in x:y mode.

– Don W.

Don W. wrote:

(along with anything else that is running) overloads the cpu. This is
especially likely in x:y mode.

– Don W.

I have seen the same behavior using Gentoo 2006.1. This seems to be
related to the number of points present in the plot window. I haven’t
looked into the guts of the program but would assume, based on the cpu
usage, that the data points plotted do not take the pixel range into
account ? For example, an array of 1000 points of time series data is
plotted across 200 pixels (should plot every fifth point).

–Ryan

On Fri, 17 Nov 2006, Matteo C. wrote:

fft scope … frequently hangs on my fc5
The scope freezes (in all modes) and it needs to be killed to get the
control back.

Has anyone experienced the same?

A GNU Radio flowgraph can generate samples much faster than wxPython can
display them. In fft_sink, fft_rate is the number of frames fft_sink
attempts to draw per second. Try adjusting it down. There is a similar
parameter frame_decim in scope_sink, again adjust this down until the
display updates and the program works.

Also, if the flowgraph data rate
is not limited by some hardware device (like audio or the USRP), you
need to put a gr.throttle block in the flow graph to limit it.

Jon Jacky

Eric B. wrote:

There’s an enhancement request, ticket:91, http://gnuradio.org/trac/ticket/91
that talks about improving the plotting peformance by coding up a
plotting widget in C++.

It’s looking for an owner. Hint, Hint.

Eric

When you say C++, do you mean wxWidgets ? I had previously written both
an oscilloscope/spectrum analyzer using QT 3 (and Blitz,FFTW) that grabs
data from shared memory. If I could find some time I would be willing to
help out with the C++ part if someone could handle the Python part.

–Ryan

On Fri, Nov 17, 2006 at 12:35:18PM -0400, Ryan Seal wrote:

It’s looking for an owner. Hint, Hint.

Eric

When you say C++, do you mean wxWidgets ?

That’s what I was thinking. Write a simple, fast plot widget for
wxWidgets, then built the appropriate wxPython wrapper for it.
No autoscaling. Just pass a transform matrix and the array of
samples.

I had previously written both an
oscilloscope/spectrum analyzer using QT 3 (and Blitz,FFTW) that grabs data
from shared memory. If I could find some time I would be willing to help
out with the C++ part if someone could handle the Python part.

Great!

Eric

On Fri, Nov 17, 2006 at 11:15:22AM -0500, Don W. wrote:

with anything else that is running) overloads the cpu. This is especially
likely in x:y mode.

– Don W.

The problem doesn’t appear to be platform specific. In general our
current plotting code is dog slow. It’s mostly implemented in Python
and could use a serious overhaul.

There’s an enhancement request, ticket:91,
http://gnuradio.org/trac/ticket/91
that talks about improving the plotting peformance by coding up a
plotting widget in C++.

It’s looking for an owner. Hint, Hint.

Eric

I’ve noticed on my older iBook G4 that I have to vary the fft_rates to
as low as 3, depending on the application.

Usable, and not too bothersome. I think PythonW and WxGUI on Mac OS X
is even slower than on Linux…

On Fri, 17 Nov 2006, Jonathan Jacky wrote:

In fft_sink, fft_rate is the number of frames fft_sink
attempts to draw per second. Try adjusting it down. There is a similar
parameter frame_decim in scope_sink, again adjust this down until the display
updates and the program works.

Correction – in scope_sink, you make frame_decim larger to display
fewer frames, so adjust it up until the program works. Or, start
at some large value like 20 or 30, then adjust it down until the program
stops working.

Recently Eric pointed out that both fft_rate (for fftsink and
waterfallsink) and frame_decim (for scopesink) can be assigned in
your ~/.gnuradio/config.conf like this:

[wxgui]
fft_rate = 15 # fftsink and waterfallsink
frame_decim = 1 # scopesink

Jon Jacky

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