[Discuss-gnuradio] scopesink.py and wxPython on Mac OS X

[Jonathan P Jacky]

I find I still have to tweak the new scopesink.py a bit to get it to
work on Mac OS X, even after the recent corrections and additions:

 http://lists.gnu.org/archive/html/discuss-gnuradio/2005-05/msg00137.html

It seems that the wxPython graphics can't quite keep up with the flow
graph, even with the new gr.throttle in the graph.  When I run
scopesink.py, the scope window with the control buttons appears, but
the scope face remains blank.  The twirling beachball appears that
indicates the program is busy, and "top" says the CPU is 0% idle
(it also says Python is getting 50-60% of the CPU).  This is Mac OS X
10.3.8 "Panther" running on a 1 GHz PPC G4.

I found two different ways to get scopesink.py working:

First, in test_app_flow_graph, set the samples_per_sec parameter in
the gr.throttle constructor to a value which is appreciably lower than
the input_rate arguments assigned in the gr.sig_source_c and
scope_sink_c constructors.  scopesink.py comes with input_rate 1e6,
setting the gr.throttle samples_per_sec to half that (5e5) works
well. At that rate Python is getting 50-55% of the CPU and the CPU is
2-3% idle.  Suprisingly (to me), it doesn't work when both the input
rates and the throttle rate are lower still but equal --- when they
are all 2e5 the CPU is 0% idle and the scope face is blank --- even
though data should be passing through the throttle at a rate lower
than the case that does work - !?

The other way I found to get the scope traces to show up is to let the
throttle run at the same speed as the source and scope_sink, but then
discard scope traces in the input_watcher thread, posting an event for
only 1 trace in N.  When N = 10 (discard 9 traces out of 10) the scope
still looks fine, the CPU is about 20% idle, and Python gets about 30%
of the CPU.  The smallest N that works is 4, which leaves the CPU
5-10% idle, with Python taking about 50% of the CPU.

Neither of these two interventions causes any changes to the scope
traces that I can see.  The waveforms look the same, have the correct
period, refresh often enough etc.

gr.throttle seems to be doing the right thing, even when the scope
face is blank.  I added some debugging printfs --- which don't seem to
slow it down much!  When the throttle sample rate is 1e6 and the
beachball is spinning, the scan interval is about 4 msec, and the
delay added by gr.throttle is about 2 msec.  That figures: the sample
rate should be 1/4 msec * 1000 msec/sec * 4095 samples/scan ~= 1e6
samples/sec.  Also the 2 msec delay in a 4 msec period suggests that
the flow graph computations are not saturating the CPU.

I only observe the problem on the Mac.  The scopesink.py with
gr.throttle works fine on Linux: top says the CPU is about 30% idle,
and python gets about 35% of the CPU.  This is Fedora Core 3 on a 1.6
GHz Pentium M "Centrino".

It would be nice to have one version of scopesink.py that works on all
platforms, but I'm not sure what to suggest.  It does seem that
wxPython consumes a lot more resources on Mac OS X than Linux.

Jon Jacky

PS - I have attached a version of scopesink.py that I used for these
experiments.  It takes four command line arguments.  They are the
sample rate for the signal source, throttle, and scope, and the
frequency of the signal source, in that order.  If an argument is
absent or less than 10, the default is used (1e6 for all three sample
rates and 25.1e3 for the frequency).  So to run the signal source and
scope at 1e6 and the throttle at 5e5, type the command

 % pythonw scopesink-args.py.n10 0 5e5

In this version the input_watcher thread only posts events for 1 in 10
scope traces (so you can run at full throttle).  There is no command
line argument for this, you have to edit the file.

PPS - slider.py and plot.py work.  fftsink.py and waterfallsink.py
both display a blank window and a spinning beachball.  I haven't
looked into them yet but I suspect the same issue as with scopesink.py

scopesink-args.py.n10
Description: Binary data