Hey,
Is it possible to use qtgui_sink_c with c++ code? I’m having problems
getting that to work.
I’m getting some warnings about things being redefined between
/usr/include/python2.7/pyconfig.h and /usr/include/features.h. Things
like _POSIX_C_SOURCE and _XOPEN_SOURCE.
I’m also getting an error about a file not being found. The file is
spectrumdisplayform.ui.h which is included by spectrumdisplayform.h.
The .ui.h file does not exist in any of the gnuradio installed areas.
But there is a copy in the area where I built gnuradio,
build/gr-qtgui/lib
So is it possible to use qtgui_sink_c with c++ code? I googled around
but I didn’t see any examples that use it.
thanks,
stephen
On Fri, May 18, 2012 at 10:56 PM, Stephen [email protected]
wrote:
spectrumdisplayform.ui.h which is included by spectrumdisplayform.h.
The .ui.h file does not exist in any of the gnuradio installed areas.
But there is a copy in the area where I built gnuradio, build/gr-qtgui/lib
So is it possible to use qtgui_sink_c with c++ code? I googled around
but I didn’t see any examples that use it.
thanks,
stephen
Hi Stephen,
No one that I know of has worked on getting gr-qtgui to work in pure
C++. Since it’s written in C++, I’m certain it’s possible, but since
it wasn’t built for it, I’m not sure what actually needs to be done.
For your purposes of getting it to work, if you need
spectrumdisplayform.ui.h to be installed, it should be easy enough to
add it to the CMakeLists.txt file for the install rule.
And since what you are reporting for POSIX_C_SOURCE are only warnings,
just ignore them for now. I don’t think that will be a hindrance to it
actually working.
If you figure out what things need to be updated/fixed for use in C++,
please send us a patch!
Tom
On 05/19/2012 08:41 AM, Tom R. wrote:
If you figure out what things need to be updated/fixed for use in C++,
please send us a patch!
Tom
If I can figure it out I will. There are two .h files from
…/build/gr-qtgui/lib that are needed. It compiles and I can create a
block of that type and add it to my flowgraph. But it doesn’t do
anything. The rest of the flowgraph works and I don’t get any errors but
I also don’t get any kind of spectrum window to appear.
stephen
On 05/19/2012 11:06 AM, Tom R. wrote:
Alright, but that sounds like it’s in the right direction. You
probably need to get a reference to the qApp and then execute that.
Take a look at some of the Python examples and how they work with the
qApp and then run the “exec_()” method with it. That gets the Qt
engine running.
Calling the block function exec_() (which calls exec() for the
QApplication) was what was needed. And setting the widget to be visible.
That makes a window pop up with the spectrum. But for some reason the
performance is very bad.
A couple of other things. exec() does not return till the QApplication
exits. And it must be called from the main thread. At least that is the
error output I got when I tried to call it from a boost thread. To use
it I would have to redesign my application. So I probably won’t be
spending any more time with it.
stephen
On Sat, May 19, 2012 at 11:13 AM, Steve [email protected] wrote:
…/build/gr-qtgui/lib that are needed. It compiles and I can create a
block of that type and add it to my flowgraph. But it doesn’t do
anything. The rest of the flowgraph works and I don’t get any errors but
I also don’t get any kind of spectrum window to appear.
stephen
Alright, but that sounds like it’s in the right direction. You
probably need to get a reference to the qApp and then execute that.
Take a look at some of the Python examples and how they work with the
qApp and then run the “exec_()” method with it. That gets the Qt
engine running.
Tom
On Sat, May 19, 2012 at 3:00 PM, Nick F. [email protected] wrote:
set_update_time(0.5);
to:
set_update_time(0.05);
This will use a 20fps update rate instead of the default (strangely) 2fps.
–n
I was going to suggest the same thing. To explain the “strange” 2 fps,
that was a request to help qtgui work better on the E100. It’s
perfectly fast enough for actually seeing stuff happening, but some
people think that it feels strange. It started off at 10 fps. What’s
really strange is why I never exposed this setting as a public
accessor…
A couple of other things. exec() does not return till the QApplication
exits. And it must be called from the main thread. At least that is the
error output I got when I tried to call it from a boost thread. To use
it I would have to redesign my application. So I probably won’t be
spending any more time with it.
stephen
Have you read up on Qt and how to handle the QApplication? They might
have some hints for you on how to handle your situation.
Tom
On 5/19/2012 3:00 PM, Tom R. wrote:
people think that it feels strange. It started off at 10 fps. What’s
really strange is why I never exposed this setting as a public
accessor…
There is a public set_update_time routine. Changing it to a faster
update does make it seem less strange.
On Sat, May 19, 2012 at 11:09 AM, Steve [email protected] wrote:
Calling the block function exec_() (which calls exec() for the
QApplication) was what was needed. And setting the widget to be visible.
That makes a window pop up with the spectrum. But for some reason the
performance is very bad.
I’m working on Qt performance in a separate branch. For now, though, if
by
“performance is very bad” you mean “update rate is slow”, then change
the
line in qtgui_sink_c which says:
set_update_time(0.5);
to:
set_update_time(0.05);
This will use a 20fps update rate instead of the default (strangely)
2fps.
–n
On 5/19/2012 3:00 PM, Tom R. wrote:
Have you read up on Qt and how to handle the QApplication? They might
have some hints for you on how to handle your situation.
If I create the block in the same thread I call exec() then it works. I
was creating the block in my main thread and then spawning a boost
thread to exec() the block. That didn’t work.
I also have a problem that about 25% of the time my app aborts when I
try to use the qtgui sink. Some times it runs just fine. Others it
aborts. when it aborts I can start it again right away and it works.
when I take the qt sink out it never aborts.
I also see a performance difference when using grc. If I create a simple
flowgraph with just a usrp sink and a gui fft window I can use higher
sampling rates with the wxwidget version before I hit overruns.
stephen
On Sat, May 19, 2012 at 8:11 PM, Stephen [email protected]
wrote:
thread to exec() the block. That didn’t work.
stephen
Can you send any info or messages when your program aborts?
Tom
On 5/20/2012 4:44 PM, Tom R. wrote:
Can you send any info or messages when your program aborts?
Segmentation fault (core dumped)
Process returned 139 (0x8B)
sometimes there is a core file and sometimes there isn’t.
Can you send any info or messages when your program aborts?
Tom
It does not appear to happen if I run in the debugger. I’ve tried many
times but never go it to happen in the debugger.
On 5/22/2012 8:33 AM, Tom R. wrote:
Ok, so it’s an issue with speed. What are you using the rate-control
the flowgraph? Is there a USRP or other hardware source or a throttle
block if nothing else?
Its not getting that far. I’m using a USRP as a data source. But it’s
aborting in the call my_qtgui_ptr->qwidget()->show()
It doesn’t happen in the debugger so I put cout lines all over the
place. I see the output before the show() call but not the output after.
I use a boost threat boost::thread to create the qtgui_sink and call
exec_().
stephen
On Mon, May 21, 2012 at 10:46 PM, Stephen [email protected]
wrote:
Can you send any info or messages when your program aborts?
Tom
It does not appear to happen if I run in the debugger. I’ve tried many
times but never go it to happen in the debugger.
Ok, so it’s an issue with speed. What are you using the rate-control
the flowgraph? Is there a USRP or other hardware source or a throttle
block if nothing else?
Tom