Re: [Discuss-gnuradio] Software stopping of runaway realtime processes?

[Eric Blossom]

On Fri, Feb 09, 2007 at 09:56:24PM -0500, Frank Brickle wrote:
> Dan Halperin wrote:
> 
> > I can't think of what else to try...
> 
> /etc/security/limits.conf?
> 
> Frank

Never noticed that before.  Is it part of SELINUX?

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Cygwin Python Import Error

[Brian Padalino]

I had an old version of GNURadio installed on my cygwin setup, but
decided to get the current development version in the svn repository.

After checking it out, bootstrapping, configuring and starting a make
- I had an error where the linker complained about omnithread being
made into a static library and not shared followed by a whole bunch of
missing omnithread declarations.

I got around this by doing --enable-shared=omnithread at configure,
and it went past that point.  Once the build was successful, I went
and did an make install and tried to run python and import gr.  Here
are the results:

$ python
Python 2.4.3 (#1, May 18 2006, 07:40:45)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.

from gnuradio import gr

Traceback (most recent call last):
 File "", line 1, in ?
 File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py",
line 27, in ?
   from gnuradio_swig_python import *
 File 
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py",
line 23, in ?
   from gnuradio_swig_py_runtime import *
 File 
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
line 6, in ?
   import _gnuradio_swig_py_runtime
ImportError: No module named _gnuradio_swig_py_runtime

I have 2 files in /usr/local/lib/python2.4/site-packages/gnuradio/gr
with the name _gnuradio_swig_py_runtime - one an ar archive and the
other a libtool library file.

After this error, I went and tried make check and I fail with the error:

make  check-TESTS
make[4]: Entering directory `/tmp/gnuradio/gnuradio-core/src/tests'
 14645 [main] test_all 620 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)
/bin/sh: line 4:   620 Segmentation fault  (core dumped) ${dir}$tst
FAIL: test_all.exe
===
1 of 1 tests failed
===
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory `/tmp/gnuradio/gnuradio-core/src/tests'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/tmp/gnuradio/gnuradio-core/src/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/tmp/gnuradio/gnuradio-core/src'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/tmp/gnuradio/gnuradio-core'
make: *** [check-recursive] Error 1

I really have no idea what's going on, so any help would be appreciated.

Brian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] rational_resampling question

[Eric Blossom]

On Fri, Feb 09, 2007 at 01:26:30PM -0800, Hans Glitsch wrote:
> Hello,
> 
> If I want to use the rational resampler without filtering, is it valid do 
> this?
> 
> taps = [1]
> self.resampler = gr.rational_resampler_base_scc( 3, 2, taps )

If by valid you mean, "will it compute what I ask it", the answer is
yes.  However, I don't think you're going to like the answer you get.

Why do you want to remove the filtering?
FWIW, it's a polyphase implementation and runs at the low rate.

See gnuradio-core/src/lib/filter/gr_rational_resampler_base_scc.cc
for the implementation.

Also, if you're trying to solve a performance problem, I _strongly_
suggest that you use floats or complex, not shorts.  
Trust me, they're _much_ faster.

Using *_scc you've effectively moved the short to float conversion
into the inner loop of the dot product.  This results in terrible
performance on most machines since the conversion is relatively slow
and you're performing it O(N^2) times.

If you're using the USRP as the front end, I suggest that you adjust
to doing most everything at complex baseband.  It simplifies many
things, and we've got very fast SIMD filtering kernels for floats and
complexes, not to mention fft-based filtering too.

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio