On Mon, 23 Oct 2006, Dave hartzell wrote:
OK, that is interesting....are these things (G4s) really that slow?
Yes. It seems that wxPython is the rate-limiting step. A GNU Radio
flowgraph can process samples much much faster than wxPython can display
them, at least on a G4. I've used Linux also and it seems that wxPython
is appreciably slower, relative to the flow graph, on OS X compared to
Linux.
I know how to limit FFT CPU utilization via the window sizes, but is
there a way to limit the WxPython window updates to something lower?
Yes. In scope_sink_f and _c there is a parameter frame_decim, when
frame_decim = 2 scope_sink only tries to display every other buffer of
data that comes from the flow graph, etc. Start with frame_decim at 20 or
30, then reduce it until you get a reasonable refresh rate. When you run
scopesink from the command line, the first command line argument (with no
option flag in front of it) is frame_decim. This makes it easy to
experiment to find a reasonable value for your system. For more details
see
http://staff.washington.edu/~jon/gr-osx/scopesink.html
In fft_sink there is a parameter fft_rate that has a similar effect.
Jon Jacky
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
