On Tue, Oct 24, 2006 at 08:48:27AM -0700, Jonathan Jacky wrote: > > 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
FYI, You can set the defaults for these in your ~/.gnuradio/config.conf E.g., # This file contains system wide configuration data for GNU Radio. # You may override any setting on a per-user basis by editing # ~/.gnuradio/config.conf [wxgui] fft_rate = 15 # fftsink and waterfallsink frame_decim = 1 # scopesink _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
