discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source type value


From: Tobias Schmid
Subject: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source type value could not be interpreted as target
Date: Thu, 9 Dec 2010 14:22:44 +0100 (CET)

-
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 Blum" <address@hidden>
Gesendet: 09.12.2010 04:36:01
An: "Tobias Schmid" <address@hidden>
Betreff: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source type 
value could not be interpreted as target

>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
>
>On 12/08/2010 12:20 AM, Tobias Schmid wrote:
>> 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"
>> 
>> 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"
>> 
>> 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 <module>
>>  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 Schmid" <address@hidden>
>> Gesendet: 07.12.2010 16:04:22
>> An: address@hidden, address@hidden
>> Betreff: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source type 
>> value could not be interpreted as target
>> 
>>> 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 Blum:
>>>> I could not replicate the problem with the uhd_multi_usrp_source block.
>>>> I only had a single usrp to test with, I can try out multiple next week
>>>> when I get back to the office.
>>>>
>>>> Is it possible you have some weird device address arguments? My only two
>>>> guesses are eeprom map parsing or some weird device address. When you
>>>> ran the probe app, were you able to probe both usrps individually? That
>>>> would let me know that the eeprom parsing works fine on both boards.
>>>>
>>>> Can you rebuilt gnuradio after rebuilding UHD just to be sure were not
>>>> looking at some ABI change.
>>>>
>>>> -Josh
>>>>
>>>> On 12/01/2010 03:00 AM, Tobias Schmid wrote:
>>>>    
>>>>> Hello,
>>>>>
>>>>> sorry I had been out of office for some days.
>>>>>
>>>>> When I run uhd_usrp_probe the error doesn't occur.
>>>>> And using uhd.single_usrp_source doesn't occur either.
>>>>>
>>>>> The complete output of the terminal is:
>>>>>
>>>>> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839];
>>>>> Boost_103900; UHD_0001.20101124180824.2568efd
>>>>>
>>>>> Current recv sock buff size: 50000000 bytes
>>>>> Current recv sock buff size: 50000000 bytes
>>>>> Traceback (most recent call last):
>>>>>    File "/home/gnuradio/Desktop/top_block.py", line 95, in<module>
>>>>>      tb = top_block()
>>>>>    File "/home/gnuradio/Desktop/top_block.py", line 35, in __init__
>>>>>      num_channels=2,
>>>>>    File
>>>>> "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line
>>>>> 1023, 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
>>>>>
>>>>> The error also occurs when using udh.multi_usrp_sink.
>>>>> Maybe that could be another hint.
>>>>>
>>>>> By the way, what do I have to do to run a discontinous data transmission
>>>>> using uhd.single_usrp_source.
>>>>> I implemented some ARQ-protocols using USRP driver. Now I wanted to
>>>>> upgreade these applications, but it doesn't work well.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Tobias
>>>>>
>>>>> Am 26.11.2010 17:53, schrieb Josh Blum:
>>>>>      
>>>>>> 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
>>>>>>
>>>>>> On 11/26/2010 04:05 AM, Tobias Schmid wrote:
>>>>>>
>>>>>>        
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm trying to use 2 USRP2 using the UHD Driver.
>>>>>>> My version is the git version of yesterday.
>>>>>>>
>>>>>>> But when I'm trying to build a flowgraph using grc,
>>>>>>> gnuradio isn't able to run the generated code.
>>>>>>>
>>>>>>> The following error occurs:
>>>>>>>
>>>>>>> RuntimeError: bad lexical cast: source type value could not be
>>>>>>> interpreted as target
>>>>>>>
>>>>>>> And this is the generated code:
>>>>>>>
>>>>>>> self.uhd_multi_usrp_source_0 = uhd.multi_usrp_source(
>>>>>>> device_addr="addr=192.168.10.2 192.168.10.3",
>>>>>>> io_type=uhd.io_type_t.COMPLEX_FLOAT32,
>>>>>>> num_channels=2,
>>>>>>> )
>>>>>>> _clk_cfg = uhd.clock_config_t()
>>>>>>> _clk_cfg.ref_source = uhd.clock_config_t.REF_SMA
>>>>>>> _clk_cfg.pps_source = uhd.clock_config_t.PPS_SMA
>>>>>>> _clk_cfg.pps_polarity = uhd.clock_config_t.PPS_POS
>>>>>>> self.uhd_multi_usrp_source_0.set_clock_config(_clk_cfg,
>>>>>>> uhd.ALL_MBOARDS);
>>>>>>> self.uhd_multi_usrp_source_0.set_time_unknown_pps(uhd.time_spec_t())
>>>>>>> self.uhd_multi_usrp_source_0.set_samp_rate(1000000)
>>>>>>> self.uhd_multi_usrp_source_0.set_center_freq(2450000000, 0)
>>>>>>> self.uhd_multi_usrp_source_0.set_gain(20, 0)
>>>>>>> self.uhd_multi_usrp_source_0.set_center_freq(2450000000, 1)
>>>>>>> self.uhd_multi_usrp_source_0.set_gain(20, 1)
>>>>>>>
>>>>>>> Can someone help me solving this problem?
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Tobias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
>>>>>>> Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Discuss-gnuradio mailing list
>>>>>>> address@hidden
>>>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>>
>>>>>>>          
>>>>>> _______________________________________________
>>>>>> Discuss-gnuradio mailing list
>>>>>> address@hidden
>>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>>>        
>>>>>      
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ___________________________________________________________
>> WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit 
>> gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2
___________________________________________________________
WEB.DE DSL Doppel-Flat ab 19,99 &euro;/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2



reply via email to

[Prev in Thread] Current Thread [Next in Thread]