On 03/27/2011 12:28 PM, Tom R. wrote:
Also, from another thread, I agree that being able to put multiply
streams into a single scope plot would be really useful. I’ll see what
I can do about that, too, but that’s going to take some serious
surgery since all of the plots (fft, waterfall, scope, constellation,
etc.) are generated at the same time.
Yeah, the “monolith” approach that’s currently used for the Qt-GUI
“sink” is a bit awkward for making changes.
My main reason for going down this path is to hopefully avoid some of
the OpenGL flakiness, the somewhat-better performance, and a
(subjective) nice “look” to the Qt GUI widgets as compared to the
WxPython ones.
One of the “hacks” I was thinking of implementing was that if the user
had selected only the time-domain plot, and the sample-rate was
“low”, then it would automatically do a strip-chart type display.
But that was simply a way to avoid changing the API in any way.
Strip-chart is fairly easy to implement as a “preprocessor” for the
regular time-domain display. Instead of waiting for a buffers-worth of
samples before calling the time-domain plotter, you shift all the
samples in the buffer over by one (dropping one off the end), then
insert the fresh sample at the beginning, then call the plotter. The
difference is that the plotter gets called on every sample addition,
instead
of every DISPLAY-SIZE samples. Obviously, you only want to do this
for fairly low-rate data, but strip-charts tend to be used for
low-data-rate stuff, a few samples per second is the usual maximum.
The time-domain plotter already supports separate “pens” for I and Q, so
adding more pens shouldn’t be that huge a deal at the level
of the plotter. But the “work” function needs to be made aware of
potentially more than 1 input data stream.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium