Bug in waterfall window "Time scale" GUI control

GNU Radio
1

If you try to increase the timescale beyond what can be accomplished
given the window geometry and
input frame rate, it provokes a floating-point divide error, near line
307 in …waterfall_window.py

My naive attempt to fix it, by making sure the frame_rate counter never
dropped below 1, just seems
to have moved the problem around, provoking a different problem:

File
“/usr/local/lib/python2.6/site-packages/gnuradio/wxgui/waterfall_window.py”,
line 159, in _on_incr_time_scale
self.parent[FRAME_RATE_KEY] *= 0.75
File
“/usr/local/lib/python2.6/site-packages/gnuradio/wxgui/pubsub.py”, line
46, in setitem
p[pkey] = val
File
“/usr/local/lib/python2.6/site-packages/gnuradio/wxgui/pubsub.py”, line
52, in setitem
sub(val)
File
“/usr/local/lib/python2.6/site-packages/gnuradio/blks2impl/logpwrfft.py”,
line
82, in set_vec_rate
self._sd.set_vec_rate(vec_rate)
File
“/usr/local/lib/python2.6/site-packages/gnuradio/blks2impl/stream_to_vector_decimator.py”,
line 64, in set_vec_rate
self._update_decimator()
File
“/usr/local/lib/python2.6/site-packages/gnuradio/blks2impl/stream_to_vector_decimator.py”,
line 75, in _update_decimator
self.set_decimation(self._sample_rate/self._vec_len/self._vec_rate)
ZeroDivisionError: float division

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

2

On Wed, Apr 28, 2010 at 18:15, Marcus D. Leech [email protected]
wrote:

If you try to increase the timescale beyond what can be accomplished
given the window geometry and
input frame rate, it provokes a floating-point divide error, near line
307 in …waterfall_window.py

Marcus, thanks for all the testing/fixes/ideas for the GRC/gr-wxgui
code. You’re uncovering places where we’ve (well, I’ve) been less
than…diligent in coding things.

I really need to get you set up as a git-based contributor so we can
easily test/merge what you’re doing.

Johnathan

3

On 04/28/2010 09:33 PM, Johnathan C. wrote:

On Wed, Apr 28, 2010 at 18:15, Marcus D. Leech [email protected] wrote:

Marcus, thanks for all the testing/fixes/ideas for the GRC/gr-wxgui
code. You’re uncovering places where we’ve (well, I’ve) been less
than…diligent in coding things.

Diligence? Diligence is for the weak! :slight_smile: :slight_smile: :slight_smile:

I really need to get you set up as a git-based contributor so we can
easily test/merge what you’re doing.

Yup, that would probably be good.

I’ve done a number of things this evening to my own code base:

o added a new method in gr_file_sink_base, ::set_unbuffered() that

causes the ::work method to
always issue a fflush() after the write loop. This is critical
for outputs to named pipes
where the input data rate is modest–even when you’re writing
complex-floats, it can take
a long time to fill up a stdio BUFSIZ. One would be tempted
to add a function that
places a call to setvbuf(), with an appropriately small buffer,
but setvbuf() can only be
used properly before any I/O has taken place on the file stream.

   I updated the file_sink.xml  for GRC to match the new method, in

that there’s a creation-time
option to make this file_sink unbuffered.

 o Used the "prefs" functionality to control a few things in the

wxgui sinks:

     o A boolean 'run_always'  controls whether your plot-type

things run all the time, or only when visible

     o A long 'trig_mode' that sets the default trigger mode when an

OSCOPE comes up. No fancy converter
here, it has to be between 0…3 or lord alone knows what
will happen.

     o a string 'waterfall_color'  (notice how I deferred to the

American spelling of colour to maintain
consistency with the code :slight_smile: ), which sets the default
waterfall colour-map on init.

This is an OK, but not wonderful, way to do this. Ideally, of course,
all the functionality within a wxgui
object should be programmatically accessible, but I admit that
making that happen is a daunting
task. The params list for these things is already really freaking
long, and we’d end up adding probably
10 new params, which has implications for GRC, etc, etc.

I wonder how easy it would be to tweak the “prefs” module to support
app-specific preferences? Hmmm.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

On Wed, Apr 28, 2010 at 19:37, Marcus D. Leech [email protected]
wrote:

I really need to get you set up as a git-based contributor so we can
easily test/merge what you’re doing.

Yup, that would probably be good.

I’ve done a number of things this evening to my own code base:

Don’t be too upset when I ask you to separate all these things into
individual branches off of the git master, so they can be
tested/modified/merged independently of one another :slight_smile:

Johnathan

5

On Wed, Apr 28, 2010 at 10:37:45PM -0400, Marcus D. Leech wrote:

On 04/28/2010 09:33 PM, Johnathan C. wrote:

I wonder how easy it would be to tweak the “prefs” module to support
app-specific preferences? Hmmm.

Not sure how to handle inheritance of attributes, but you can use any
key you like. The prefs stuff uses the standard Python ConfigParser
class.

Eric

6

On 04/29/2010 12:07 PM, Eric B. wrote:

Eric

Yup, “prefs” doesn’t care what keys you use, to be sure.

I think there’s a large issue here that needs to be thought about
carefully. Much of the
controllable parameters in the wx-gui blocks in particular don’t have
a programmatic
interface, so there’s no convenient way to set the up “in advance”,
etc.

Using the “prefs” mechanism is only really a partial solution.

Much thinkage required.

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium