Ruby Forum GNU Radio > GNU-Radio GUI applications freeze

Posted by Raul Siles (Guest)
on 06.09.2008 01:58
(Received via mailing list)
Hello,
I'm running GNU-Radio 3.1.3 under Fedora 8 (fully updated) with USRP
and all the USRP graphical (GUI) applications freeze, such as
usrp_oscope.py or usrp_fft.py.

The application, eg. usrp_oscope.py, main window is displayed but only
the signal diagram is visible and changes. All the controls and
buttons are not available. Sporadically the whole window, signal
diagram plus controls, is displayed but it is not possible to interact
with or adjust any control.

I've also tried compiling the stable GNU-Radio 3.1.2 version, and even
with GNU-Radio and USRP from the Fedora yum repositories
(3.1.2-2.fc8). I'm experiencing the same behaviour with all them. The
GNU-Radio and USRP command-line tools work fine, so it seems an issue
with wxPython and Fedora.

I'm using the 2.6.25.14-69.fc8 kernel version and wxPython version:

# rpm -aq | grep wxPython
wxPython-2.8.7.1-5.fc8
wxPython-devel-2.8.7.1-5.fc8
#

The computer VGA card is an ATI model:
# lspci
00:00.0 Host bridge: ATI Technologies Inc RS200/RS200M AGP Bridge [IGP
340M] (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M]
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP
330M/340M/350M
...
#

Has anyone experienced a similar behaviour? Any help or hints to
troubleshoot this issue are appreciated! Thanks!
--
Raul Siles
www.raulsiles.com
Posted by Eric Blossom (Guest)
on 06.09.2008 07:29
(Received via mailing list)
On Sat, Sep 06, 2008 at 01:57:31AM +0200, Raul Siles wrote:
> Hello,
> I'm running GNU-Radio 3.1.3 under Fedora 8 (fully updated) with USRP
> and all the USRP graphical (GUI) applications freeze, such as
> usrp_oscope.py or usrp_fft.py.

Raul,

What kind of computer are you running these tests on?

  $ cat /proc/cpuinfo

Eric
Posted by Raul Siles (Guest)
on 06.09.2008 13:25
(Received via mailing list)
Hello Eric,
The computer is a laptop with a Pentium 4 CPU and 1GB of RAM (only
350MB are used). When any of the GNU Radio GUI tools is launched, the
associated python process goes up to near 100% CPU usage.

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Genuine Intel(R) CPU 2.80GHz
stepping        : 9
cpu MHz         : 1596.000
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts
cid xtpr
bogomips        : 3196.91
clflush size    : 64

#

Thanks,
--
Raul Siles
www.raulsiles.com
Posted by Johnathan Corgan (Guest)
on 07.09.2008 18:30
(Received via mailing list)
On Fri, Sep 5, 2008 at 4:57 PM, Raul Siles <raul.siles@gmail.com> wrote:

> I'm running GNU-Radio 3.1.3 under Fedora 8 (fully updated) with USRP
> and all the USRP graphical (GUI) applications freeze, such as
> usrp_oscope.py or usrp_fft.py.

At first glance, this seems like a performance issue, but your CPU is
sufficient.

> I'm using the 2.6.25.14-69.fc8 kernel version and wxPython version:
> wxPython-2.8.7.1-5.fc8

This is the same wxPython version I am using successfully on Ubuntu
8.04, though the kernel is 2.6.24.

--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/
Posted by Jim Watson (Guest)
on 08.09.2008 10:27
(Received via mailing list)
I can reproduce something similar I think on Ubuntu 8.04 using recent
svn sources with the included grc to make an audio signal source and
scope sink, not using any usrp etc.

The scope gui displays the waveform but the mouse cannot get focus on
any buttons.

Then I installed the latest stable release of gnuradio 3.1.3 and the
separate grc 0.7, and everything works correctly as expected.

Hardware here is a iMac


jim@imac:~/Desktop/grc_0.70/src$ cat /proc/cpuinfo
processor  : 0
vendor_id  : GenuineIntel
cpu family  : 6
model    : 14
model name  : Genuine Intel(R) CPU            1500  @ 2.00GHz
stepping  : 8
cpu MHz    : 2000.000
cache size  : 2048 KB
physical id  : 0
siblings  : 2
core id    : 0
cpu cores  : 2
fdiv_bug  : no
hlt_bug    : no
f00f_bug  : no
coma_bug  : no
fpu    : yes
fpu_exception  : yes
cpuid level  : 6
wp    : yes
flags    : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc bts
pni monitor vmx est tm2 xtpr
bogomips  : 4004.41
clflush size  : 64

processor  : 1
vendor_id  : GenuineIntel
cpu family  : 6
model    : 14
model name  : Genuine Intel(R) CPU            1500  @ 2.00GHz
stepping  : 8
cpu MHz    : 2000.000
cache size  : 2048 KB
physical id  : 0
siblings  : 2
core id    : 1
cpu cores  : 2
fdiv_bug  : no
hlt_bug    : no
f00f_bug  : no
coma_bug  : no
fpu    : yes
fpu_exception  : yes
cpuid level  : 6
wp    : yes
flags    : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc bts
pni monitor vmx est tm2 xtpr
bogomips  : 3999.98
clflush size  : 64
Posted by Johnathan Corgan (Guest)
on 08.09.2008 16:33
(Received via mailing list)
On Mon, Sep 8, 2008 at 1:26 AM, Jim Watson <jim@amarooas.com.au> wrote:

> I can reproduce something similar I think on Ubuntu 8.04 using recent
> svn sources with the included grc to make an audio signal source and
> scope sink, not using any usrp etc.

In this particular case, since there is no rate limiting block, the
source and sink run at the fastest possible rate and consume all the
CPU, resulting in what you are seeing.  You can use gr.throttle
between them to eliminate the problem.

--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com/
Posted by Jim Watson (Guest)
on 09.09.2008 01:02
(Received via mailing list)
On Mon, 2008-09-08 at 07:24 -0700, Johnathan Corgan wrote:
> 
I just tried that - it works exactly as you predicted ;)
thanks
jim
Posted by Raul Siles (Guest)
on 09.09.2008 01:42
(Received via mailing list)
>> I'm using the 2.6.25.14-69.fc8 kernel version and wxPython version:
>> wxPython-2.8.7.1-5.fc8
>
> This is the same wxPython version I am using successfully on Ubuntu
> 8.04, though the kernel is 2.6.24.

I have tested it too using the Fedora 2.6.23.1-42 kernel version with
the same results :(

Are there any specific test I could try to troubleshoot Python,
wxPython, or any other GUI component?
Anyone else running GNU Radio & USRP on Fedora 8 succesfully?

Thanks!
--
Raul Siles
www.raulsiles.com


On Sun, Sep 7, 2008 at 6:30 PM, Johnathan Corgan
Posted by Eric Blossom (Guest)
on 09.09.2008 01:57
(Received via mailing list)
On Tue, Sep 09, 2008 at 01:41:30AM +0200, Raul Siles wrote:
> wxPython, or any other GUI component?
> Anyone else running GNU Radio & USRP on Fedora 8 succesfully?
> 
> Thanks!
> -- 
> Raul Siles
> www.raulsiles.com

Fedora 7, 8, and 9 are known to work fine.  I us them.

Eric
Posted by Robert McGwier (Guest)
on 09.09.2008 02:02
(Received via mailing list)
As Matt is so fond of pointing,  I LOVE to install new toys.

I have F 8,9, Ubuntu 8.04 with F8 and F9 on x86, x86_64, PPC, and
Cell.  I have Ubuntu 8.04 on x86, x86_64.

They all do gnuradio.

Bob
Posted by Raul Siles (Guest)
on 20.09.2008 01:51
(Received via mailing list)
Hello again,
After hearing about success cases of GNU Radio and the USRP GUI tools
on Fedora 8 and 9, and after reviewing and retesting the previously
described setup, I've reinstalled my whole GNU Radio environment under
Fedora 9 (vs Fedora 8) using the same laptop. Fedora 9 has been fully
updated today. I'm using GNU Radio 3.1.3 but I'm still suffering the
same GUI-based tools freeze issue.

When running "usrp_oscope.py" (or other GUI tools, like
"usrp_wfm_rcv.py") I get the following warning messages:

# usrp_oscope.py -f 2.412G

** (python:2988): WARNING **: IPP request failed with status 1030

** (python:2988): WARNING **: IPP request failed with status 1030
uOuOuOuOuOuOuOuOuOuOuOuOuOuOuOKilled
#

After some searching, I didn't find how to remove and solve them,
although they seem to be related with wxPython (and perhaps the issue
I'm suffering). Could anyone confirm this?

I've tried to run other (non GNU Radio) wxPython basic examples, such
as "/usr/share/doc/wxPython-2.8.7.1/samples/wxProject/wxProject.py",
and they work fine.

Some details about the current setup:

- wxPython versions:
# rpm -aq | grep -i wx
wxPython-devel-2.8.7.1-5.fc9.i386
wxBase-2.8.7-2.fc9.i386
wxGTK-gl-2.8.7-2.fc9.i386
wxGTK-devel-2.8.7-2.fc9.i386
wxPython-2.8.7.1-5.fc9.i386
wxGTK-2.8.7-2.fc9.i386


- CPU:
# cat /proc/cpuinfo
processor  : 0
vendor_id  : GenuineIntel
cpu family  : 15
model    : 2
model name  : Genuine Intel(R) CPU 2.80GHz
stepping  : 9
cpu MHz    : 1596.000
cache size  : 512 KB
fdiv_bug  : no
hlt_bug    : no
f00f_bug  : no
coma_bug  : no
fpu    : yes
fpu_exception  : yes
cpuid level  : 2
wp    : yes
flags    : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up pebs bts cid
xtpr
bogomips  : 3196.88
clflush size  : 64
power management:


- Graphical card and USB bus/ports: (I'm using the USB 2.0 bus/port)
# lspci
00:00.0 Host bridge: ATI Technologies Inc RS200/RS200M AGP Bridge [IGP
340M] (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M]
00:0b.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
00:0b.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50)
00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP
330M/340M/350M

- Kernel version:
# uname -a
Linux aereo 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008
i686 i686 i386 GNU/Linux


Any suggestion about how to troubleshoot this GUI issue? I'm starting
to think it is related to the hardware I'm using.
Thanks for your help!
--
Raul Siles
Posted by Raul Siles (Guest)
on 24.09.2008 02:19
(Received via mailing list)
Just in case anyone is interested, I'm experiencing the same behavior
(GNU Radio USRP graphical tools freeze, such as usrp_oscope.py) when
running Fedora 9 inside VMware 6.x (it includes USB 2.0 support).
--
Raul Siles
Posted by Paul Mathews (Guest)
on 24.09.2008 03:59
(Received via mailing list)
Use the optional parameter in usrp_oscope.py that slows down the data 
rate
to where wx can handle it....your screen will then not freeze. I can't
remember off-hand what it needs to be set to...
Paul Mathews
Posted by Paul Mathews (Guest)
on 24.09.2008 05:38
(Received via mailing list)
It's the "scope frame decimation factor". Try -n100 to start with...
Paul Mathews
Posted by Raul Siles (Guest)
on 27.09.2008 01:07
(Received via mailing list)
Paul, you rock!!!!

Changing the decimation factor (-n) to a bigger value (the default
value is 1) works like a charm and solves all my GUI freeze issues,
even within VMware.
I started with "-n 100" (as you suggested) for usrp_oscope.py, but it
is too much and the refresh rate is very slow. Then I tried, 10, 5,
and in my case, it even works great with "-n 2".

Thanks a lot!!
--
Raul Siles
www.raulsiles.com
Posted by Paul Mathews (Guest)
on 27.09.2008 02:53
(Received via mailing list)
Thanks should go to Jon Jacky, who identified the problem some time ago.
Paul
Posted by Raul Siles (Guest)
on 27.09.2008 14:00
(Received via mailing list)
Thanks to Jon Jacky then, and all the list members that replied to
this thread trying to help!
--
Raul Siles
www.raulsiles.com
Posted by Eric Blossom (Guest)
on 27.09.2008 18:40
(Received via mailing list)
On Wed, Sep 24, 2008 at 02:18:46AM +0200, Raul Siles wrote:
> Just in case anyone is interested, I'm experiencing the same behavior
> (GNU Radio USRP graphical tools freeze, such as usrp_oscope.py) when
> running Fedora 9 inside VMware 6.x (it includes USB 2.0 support).
> --
> Raul Siles

Raul,

I suspect that your real problem is that your machine is too slow to
run the GUI at the default refresh rate.

Not that we have any such thing as a supported configuration, but if
we did, VMware wouldn't be on the list.

Eric
Posted by Bob McGwier (Guest)
on 28.09.2008 11:25
(Received via mailing list)
If you have a hardware accelerated graphics card which supports opengl, 
you
can get even better speed up:

http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl


ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"Trample the slow ....  Hurdle the dead"
Posted by feldmaus (Guest)
on 26.01.2009 19:20
(Received via mailing list)
Raul Siles <raul.siles <at> gmail.com> writes:

> with or adjust any control.
Hi,

i have the same Problems on Suse 11.1 and gnuradio 3.1svn.

I solved it by executing <grc> with:
$nice -n 19 grc

Regards Markus
Posted by Martin DvH (Guest)
on 27.01.2009 00:06
(Received via mailing list)
On Mon, 2009-01-26 at 10:56 +0000, feldmaus wrote:
> > buttons are not available. Sporadically the whole window, signal
> Regards Markus
The fft and/or scopedisplay is needing more processing power then your
CPU has (your computer is too slow for the settings you are using)
A better solution is to restrict the maximum processing power the scope
and/or fft uses.
You can change the defaults
in /usr/local/etc/gnuradio/conf.d/gr-wxgui.conf

Change:
# fftsink and waterfallsink
fft_rate = 15

# scopesink
frame_decim = 1

into something like:
# fftsink and waterfallsink
fft_rate = 5

# scopesink
frame_decim = 10

Important: don't put any comments after the numbers.

Greetings,
Martin Dudok van Heel
Olifantasia