Hi,
With latest gnuradio the scope view refuses to work in my flowgraphs.
Execution ends completely without any error message. Removing the block
and
putting it newly into the flowgraph changes nothing. Disabling the scope
makes the projects work, the water fall works without issues.
Uninstalling gnuradio, deleting the build folder and rebuilding
everything
changed nothing. All elements are built, cmake seems to be fine with the
prerequisites, still no working scope.
Kubuntu 14.04 64 bit, latest kernel and all other updates, gnuradio from
sources (master), no pybombs…
Where can I start searching for the reason?
Thx!
Ralph.
Hi Ralph,
first of all: that’s the WX GUI Scope, right?
Where can I start searching for the reason?
Do other Instrumentations from the same GUI framework work?
Tough one, but I’d tackle this with a debug build and GDB:
http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
Greetings,
Marcus
Hi,
Hi Ralph,
first of all: that’s the WX GUI Scope, right?
Yes.
Where can I start searching for the reason?
Do other Instrumentations from the same GUI framework work?
The WX GUI Waterfall Sink works as always.
Usually I do not use those gfx stuff that much, I just stumbled over it
when
firing up my DSD+ flow for DMR radio decoding, then I tried other flows
using WX GUI Scope Sink, with the same result.
Tough one, but I’d tackle this with a debug build and GDB:
http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
Looks complicated to a Windows guy like me, may take some days until I
find
time for such an adventure 
Greetings,
Marcus
Ralph.
Hi Ralph,
Usually I do not use those gfx stuff that much, I just stumbled over it when
firing up my DSD+ flow for DMR radio decoding, then I tried other flows
using WX GUI Scope Sink, with the same result.
I see… Hm. The point is that most of us is not really deep into the WX
code base, and GNU Radio is planning to move away from WX to QT, and
since I can’t reproduce the problem locally, it’s going to be very hard
to get you running. It really is an odd failure if only the scope is
failing.
I have one more idea: might be something with OpenGL acceleration; WX
always was a bit flakey on that side, but hardware accell for drawing
lines is really helpful… But maybe on modern machines with CPU cycles
to spare, maybe creating ~/.gnuradio/config.conf with the lines:
[wxgui]
style = nongl
does the trick (hell, if I knew where .gnuradio is on a windows
machine…).
Generally, if your application is “simple enough” to just switch
Generate Options from “WX” to “Qt” and replace a few GUI elements, then
I’d recommend using Qt; it’s more modern, and it will stick around
longer. Most features can be configured even at runtime using
“middle-click” on the visualization.
Greetings,
Marcus
Hi,
Hi Ralph,
I see… Hm. The point is that most of us is not really deep into the WX
code
base, and GNU Radio is planning to move away from WX to QT, and since I
can’t reproduce the problem locally, it’s going to be very hard to get you
running. It really is an odd failure if only the scope is failing.
So I will have a look at the qt stuff and simply forget about wx. To by
honest, I never bothered what kind of GUI I am using, but when qt GUI
offers
the same functionality, so why stay with wx?!
Generally, if your application is “simple enough” to just switch Generate
Options from “WX” to “Qt” and replace a few GUI elements, then I’d
recommend using Qt; it’s more modern, and it will stick around longer.
Most
features can be configured even at runtime using “middle-click” on the
visualization.
Yep, it is all quite simple stuff, nothing special. The scope I even do
not
really need most of the time, just the waterfall is nice to have.
Greetings,
Marcus
Ralph.