Hey guys,
I started to have this with the git master and uhd from yesterday
evening:
linux; GNU C++ version 4.6.0 20110415 (prerelease); Boost_104600;
UHD_003.000.001-8212f22
[…]
ub/grotarapi/PHY/PhysicalLayer.py", line 47, in init
self.u_tx = uhd.usrp_sink(hint,
io_type=uhd.io_type_t.COMPLEX_FLOAT32, num_channels=1)
File “/usr/lib/python2.7/site-packages/gnuradio/uhd/init.py”, line
73, in constructor_interceptor
if kwargs.has_key(key): kwargs[key] = cast(kwargs[key])
File “/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py”, line
409, in init
this = _uhd_swig.new_io_type_t(*args)
NotImplementedError: Wrong number or type of arguments for overloaded
function ‘new_io_type_t’.
Possible C/C++ prototypes are:
uhd::io_type_t(uhd::io_type_t::tid_t)
uhd::io_type_t(size_t)
[…]
If I try the same with a size_t instead (in bpython):
a = uhd.usrp_sink(device_addr=‘type=usrp2’, io_type=32, num_channels=1)
OUT: Traceback (most recent call last):
OUT: File “”, line 1, in
OUT: File
“/usr/lib/python2.7/site-packages/gnuradio/uhd/init.py”, line 74,
in constructor_interceptor
OUT: return old_constructor(*args, **kwargs)
OUT: File
“/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py”, line
1854, in usrp_sink
OUT: return _uhd_swig.usrp_sink(*args, **kwargs)
OUT: RuntimeError: gr_io_signature(3)
Any hints how to fix this? Did someone already see something like this?
I think it might be somehow related to
7787d1fc1aecc7b59e476c31865b4f32348cb729
All the best,
Moritz
Whats your swig version? The last time I encountered this, someone had
swig 2 and it was incorrectly parsing an enum to type ‘str’ (rather than
int). Whats this print?
python -c “from gnuradio import uhd; print
type(uhd.io_type.COMPLEX_FLOAT32)”
-Josh
On 04/20/2011 08:41 AM, Moritz Fischer wrote:
as you guessed:
<type ‘str’>
What do other gnuradio enums give you?
python -c “from gnuradio import gr; print type(gr.GR_COS_WAVE)”
Can you create a gr.sig_source?
Just trying to narrow it down…
-Josh
On Wed, Apr 20, 2011 at 06:28:45PM +0200, Josh B. wrote:
What do other gnuradio enums give you?
python -c “from gnuradio import gr; print type(gr.GR_COS_WAVE)”
Can you create a gr.sig_source?
Yeah, it’s a <type ‘int’>
Just trying to narrow it down…
Thanks for your efforts 
Moritz
On 04/20/2011 10:02 AM, Moritz Fischer wrote:
On Wed, Apr 20, 2011 at 06:28:45PM +0200, Josh B. wrote:
What do other gnuradio enums give you?
python -c “from gnuradio import gr; print type(gr.GR_COS_WAVE)”
Can you create a gr.sig_source?
Yeah, it’s a <type ‘int’>
I think I see why:
//! Complex floating point (64-bit floats) range [-1.0, +1.0]
COMPLEX_FLOAT64 = ‘d’,
//! Complex floating point (32-bit floats) range [-1.0, +1.0]
COMPLEX_FLOAT32 = ‘f’,
//! Complex signed integer (16-bit integers) range [-32768, +32767]
COMPLEX_INT16 = ‘s’,
//! Complex signed integer (8-bit integers) range [-128, 127]
COMPLEX_INT8 = ‘b’
Swig 2 is interpreting that as a string. Which in kind of nice, except
that things that use those enums in python expect type int.
I dont know the magical swig switch to turn that off. Does this diff
make it work for you?
//! Complex floating point (64-bit floats) range [-1.0, +1.0]
-Josh
On Wed, Apr 20, 2011 at 07:13:15PM +0200, Josh B. wrote:
Swig 2 is interpreting that as a string. Which in kind of nice, except
that things that use those enums in python expect type int.
Swig seems to me like black magic … on the other hand … the whole
gnuradio build process sometimes does …
I dont know the magical swig switch to turn that off. Does this diff
make it work for you?
If you didn’t know it, you pushed it by accident or good guess
It’s working just fine now 
Thanks again for your quick fix!
All the best,
Moritz