RuntimeError: bad lexical cast: source type value could not be interpreted as target

Dobai-Pataky_BSSSSl · November 26, 2010, 10:06am

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

tobstarr · November 26, 2010, 5:54pm

boost lexical cast doesnt have a very telling error does it…

Can you send me the complete verbose?

Does the error happen when you run uhd_usrp_probe?

Howabout uhd.single_usrp_source?

Does GDB give any hint as to where the exception is thrown?

Thanks,
-Josh

tobstarr · December 8, 2010, 9:11am

I tried to rebuild gnuradio, but now the uhd module is not found
anymore.
So how do I rebuild my enviroment correctly?

What I did is:

In the uhd directory /host/build/ I did:

make unistall
make clean
cd …
cd …
git pull
cd /host/build/
make
make test (all tests passed)
make install

In the gburadio directory I did:

make unistall
make clean
make distclean
git pull
git checkout next
git pull
git checkout master
./configure
make
make check
make install

Is that right so far?

Or is it necessary to delete some files by hand?
Futhermore I do not have the same uhd blocks availible in grc.
I have just the older uhd blocks.

I am able to probe both usrp individually.
The device arguments are 192.168.10.2 and 192.168.10.3.
Is that correct so far.

I guess, that I have some older versions of symbolic links in my
pythonpath.
Do you think that might be a possible reason?
If so, which directories can be deleted?

Thanks,

Tobias

Am 02.12.2010 20:42, schrieb Josh B.:

tobstarr · December 8, 2010, 10:06am

make install

In the gburadio directory I did:

make unistall
make clean
make distclean
git pull
git checkout next
git pull
git checkout master

gr-uhd is only on the next branch

./configure

make sure gr-uhd is a configured component, if not see
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Gnuradio-UHD

tobstarr · December 8, 2010, 9:22am

I now rebuild uhd and gnuradio.
But the error still occurs.

Running uhd_find_devices I get the following outputs:

linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
Boost_103900; UHD_0001.20101204162446.a51fb2e

Warning:
Could not locate USRP1 firmware.
Please install the images package.

– UHD Device 0

Device Address:
type: usrp2
addr: 192.168.10.2
name:
serial: 00:50:c2:85:32:6b

:/home/gnuradio/gnuradio/uhd/host/utils> uhd_find_devices
linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
Boost_103900; UHD_0001.20101204162446.a51fb2e

Warning:
Could not locate USRP1 firmware.
Please install the images package.

– UHD Device 0

Device Address:
type: usrp2
addr: 192.168.10.3
name:
serial: 00:50:c2:85:32:66

Should I assign another IP address to the devices?
It’s also posslible to build up a SIS0 transmission with both USRPs.

But if I use the uhd_multi_usrp_source block, I get the same error as
before:

Generating:
“/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py”

Executing:
“/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py”

linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
Boost_103900; UHD_0001.20101204162446.a51fb2e

Current recv sock buff size: 50000000 bytes

Warning:
error in pthread_setschedparam
Failed to set thread priority 0.5 (realtime):
Performance may be negatively affected.
See the general application notes.

Done

Generating:
“/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py”

Executing:
“/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py”

linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
Boost_103900; UHD_0001.20101204162446.a51fb2e

Current recv sock buff size: 50000000 bytes
Current recv sock buff size: 50000000 bytes
Traceback (most recent call last):
File “/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py”,
line 96, in
tb = uhd_test()
File “/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py”,
line 36, in init
num_channels=2,
File “/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py”,
line 1031, in multi_usrp_source
return _uhd_swig.multi_usrp_source(*args, **kwargs)
RuntimeError: bad lexical cast: source type value could not be
interpreted as target

Done

I hope I didn’t ignore anything important.

Tobias

-----Ursprüngliche Nachricht-----
Von: “Tobias S.” [email protected]
Gesendet: 07.12.2010 16:04:22
An: [email protected], [email protected]
Betreff: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source
type value could not be interpreted as target

cd …
make distclean
Is that right so far?
Do you think that might be a possible reason?

On 12/01/2010 03:00 AM, Tobias S. wrote:

linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
“/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py”, line
I implemented some ARQ-protocols using USRP driver. Now I wanted to

Can you send me the complete verbose?
On 11/26/2010 04:05 AM, Tobias S. wrote:

The following error occurs:
)
self.uhd_multi_usrp_source_0.set_center_freq(2450000000, 1)
Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
gratis Notebook-Flat! WEB.DE Produkte Übersicht: Apps, Browser, MailCheck & Co.

tobstarr · December 9, 2010, 10:50pm

Hello Josh,

thanks for the help. I think my configuration is correct, but I am using
the mimo cable.
And as I just read, MIMO cable doesn’t work with UHD at the moment.
I read some mails in the list form the 18th of november, in which you
wrote, that you’re realizing the routing of the FPGA at the moment.
So I guess I have to wait for the release of the new FPGA images for
UHD, do I?
Or did you already release the new UHD image?

Thanks Tobias
----Ursprüngliche Nachricht-----
Von: “Josh B.” [email protected]
Gesendet: 09.12.2010 04:36:01
An: “Tobias S.” [email protected]
Betreff: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source
type value could not be interpreted as target

addresses are found devices so it errors further down the line.

Running uhd_find_devices I get the following outputs:

name:
Generating: “/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py”
Performance may be negatively affected.

return _uhd_swig.multi_usrp_source(*args, **kwargs)

make install
./configure

Tobias

Traceback (most recent call last):

Tobias

I’m trying to use 2 USRP2 using the UHD Driver.
And this is the generated code:
self.uhd_multi_usrp_source_0.set_clock_config(_clk_cfg,
Best regards,

WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
gratis Notebook-Flat! WEB.DE Produkte Übersicht: Apps, Browser, MailCheck & Co.

WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
gratis Notebook-Flat! WEB.DE Produkte Übersicht: Apps, Browser, MailCheck & Co.

tobstarr · December 9, 2010, 4:24pm

Alright, i was able to replicate the problem. If i tried to create a
multi usrp with one or more addresses that did not correspond to an
actual usrp it would throw “lexical cast error”.

It wanted to throw “no control response error” but the exception threw
an exception. Anyway, I pushed a fix for this (thought i had already
fixed this prior).

So, in conclusion, I believe that you are addressing a the configuration
wrongly. The code needs polishing in that it wont check that the
addresses are found devices so it errors further down the line.

See
http://www.ettus.com/uhd_docs/manual/html/usrp_nxxx.html#soft-mimo-configuration

-Josh

tobstarr · December 9, 2010, 11:58pm

thanks for the help. I think my configuration is correct, but I am using the
mimo cable.

OK, I polished the multi-device addressing scheme. Previously you gave
it a list of IP addresses. Well there wasnt any sanity checking
implemented and it was missing all of the device identification
granularity that is possible with UHD. The old way will still work and
print a deprecation warning; it will provide the sanity checking as
well.

http://www.ettus.com/uhd_docs/manual/html/usrp2.html#addressing-the-device

This way, UHD will more appropriately yell at you if something is wrong
and we can resolve this problem. Just git pull and rebuild to get it.

And as I just read, MIMO cable doesn’t work with UHD at the moment.
I read some mails in the list form the 18th of november, in which you wrote,
that you’re realizing the routing of the FPGA at the moment.
So I guess I have to wait for the release of the new FPGA images for UHD, do I?
Or did you already release the new UHD image?

It only works in my private development branch. Once I get the time
syncing working, I will push an experimental branch public and upload
images so people can try it out.

-josh