Re: [Discuss-gnuradio] cannot ping my USRP2
Hello Josh, we don't have the required converter at the institute. Is there any other way to get the desired information from the USRP2? As I wrote yesterday the behavior is the same with the older firmware version. Thanks, Tobias -Ursprüngliche Nachricht- Von: "Josh Blum" Gesendet: 14.12.2010 18:54:06 An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] cannot ping my USRP2 > > >On 12/14/2010 09:39 AM, Tobias Schmid wrote: >> Hello, >> >> our institute owns 4 USRP2. Three of them can be pinged. >> The 4th one cannot. >> It's neither possible to use it with UHD firmware and FPGA image. >> If I try uhd_find_device no device is found. >> The firmware and the FPGA image on the SD card is working fine. >> I checked this using one of my other devices. >> >> Can someone tell me, what the problem might be? >> Is it demaged? Is the eeprom demaged? >> Or can I solve this problem on my own? >> > >What LEDs light up upon power on? D and F? > >Can you attach a serial terminal to the rear and tell me what the USRP2 >prints to the terminal at power up? >http://www.ettus.com/uhd_docs/manual/html/usrp2.html#debugging-networking-problems > >Can you try an older image set and tell me if the behavior is the same? >http://www.ettus.com/downloads/uhd_images/UHD-images-.20100901003255.b5461fc/ > >Thanks, >-Josh > >___ >Discuss-gnuradio mailing list >Discuss-gnuradio@gnu.org >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://movieflat.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot ping my USRP2
Hello Matthias, all thos works. The USRP even works with the common USRP images. But not with UHD. Thanks, Tobias Am 14.12.2010 18:54, schrieb Matthias Wilhelm: Hi, is the USRP2 starting at all, with LEDs on and the fan running? Was it running before? We had the problem that the fuse on the USRP2 was blown. Its rather easy to replace once you identified it as the problem. Matthias Am 14.12.2010 um 18:39 schrieb Tobias Schmid: Hello, our institute owns 4 USRP2. Three of them can be pinged. The 4th one cannot. It's neither possible to use it with UHD firmware and FPGA image. If I try uhd_find_device no device is found. The firmware and the FPGA image on the SD card is working fine. I checked this using one of my other devices. Can someone tell me, what the problem might be? Is it demaged? Is the eeprom demaged? Or can I solve this problem on my own? I used to usrp2_recovery.py. But it doesn't change the behavior. best regards, Tobias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot ping my USRP2
Hello, I'm out of office now. but all LEDs on the right side light up. I guess these are B,D and F. I will follow the other advices tomorrow, when I'm back in the office. I the error occured with the images of yesterday (you pushed to the experimental branch), with the images from 24th of november and with the images of 14th of August. Thanks, Tobias Am 14.12.2010 18:54, schrieb Josh Blum: On 12/14/2010 09:39 AM, Tobias Schmid wrote: Hello, our institute owns 4 USRP2. Three of them can be pinged. The 4th one cannot. It's neither possible to use it with UHD firmware and FPGA image. If I try uhd_find_device no device is found. The firmware and the FPGA image on the SD card is working fine. I checked this using one of my other devices. Can someone tell me, what the problem might be? Is it demaged? Is the eeprom demaged? Or can I solve this problem on my own? What LEDs light up upon power on? D and F? Can you attach a serial terminal to the rear and tell me what the USRP2 prints to the terminal at power up? http://www.ettus.com/uhd_docs/manual/html/usrp2.html#debugging-networking-problems Can you try an older image set and tell me if the behavior is the same? http://www.ettus.com/downloads/uhd_images/UHD-images-.20100901003255.b5461fc/ Thanks, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] cannot ping my USRP2
Hello, our institute owns 4 USRP2. Three of them can be pinged. The 4th one cannot. It's neither possible to use it with UHD firmware and FPGA image. If I try uhd_find_device no device is found. The firmware and the FPGA image on the SD card is working fine. I checked this using one of my other devices. Can someone tell me, what the problem might be? Is it demaged? Is the eeprom demaged? Or can I solve this problem on my own? I used to usrp2_recovery.py. But it doesn't change the behavior. best regards, Tobias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - December 13th 2010 - MIMO cable support
Hey Josh, thanks a lot. Now it works. I'll try to implement algorithms soon. But this should be a first step. Am 14.12.2010 01:34, schrieb Josh Blum: Hello list, I would like to announce support for the MIMO cable with UHD. The support is experimental, so its not in the mainline yet, and is only available for USRP2 at the moment. The source for the FPGA code has not yet been pushed but you can get the pre-built images here: http://www.ettus.com/downloads/uhd_images/experimental/UHD-mimo-cable-support/ The supporting host code is available on the packet_router branch of the uhd repo: http://code.ettus.com/redmine/ettus/projects/uhd/repository/show?rev=packet_router Here is an excerpt from the docs on the MIMO cable in UHD: MIMO cable configuration Using the MIMO cable, two USRP devices can be grouped together in a multi-device configuration. Only one device in the configuration can be attached to the ethernet. This device will be referred to as the master, and the other device, the slave. * The master provides reference clock and time synchronization to the slave. * All data passing between the host and the slave is routed over the MIMO cable. * Both master and slave must have different IPv4 addresses but in the same subnet. * The master and slave may be used individually or in a multi-device configuration. I hope that explains it. Feedback is welcome! Thanks, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source type value could not be interpreted as target
- 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" Gesendet: 09.12.2010 04:36:01 An: "Tobias Schmid" 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: 5000 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: 5000 bytes >> Current recv sock buff size: 5000 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 le
Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source type value could not be interpreted as target
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: 5000 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: 5000 bytes Current recv sock buff size: 5000 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 Schmid" Gesendet: 07.12.2010 16:04:22 An: j...@joshknows.com, discuss-gnuradio@gnu.org 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. >> >> -
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: 5000 bytes Current recv sock buff size: 5000 bytes Traceback (most recent call last): File "/home/gnuradio/Desktop/top_block.py", line 95, in 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(100) self.uhd_multi_usrp_source_0.set_center_freq(245000, 0) self.uhd_multi_usrp_source_0.set_gain(20, 0) self.uhd_multi_usrp_source_0.set_center_freq(245000, 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source type value could not be interpreted as target
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: 5000 bytes Current recv sock buff size: 5000 bytes Traceback (most recent call last): File "/home/gnuradio/Desktop/top_block.py", line 95, in 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(100) self.uhd_multi_usrp_source_0.set_center_freq(245000, 0) self.uhd_multi_usrp_source_0.set_gain(20, 0) self.uhd_multi_usrp_source_0.set_center_freq(245000, 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RuntimeError: bad lexical cast: source type value could not be interpreted as target
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 targetAnd 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(100) self.uhd_multi_usrp_source_0.set_center_freq(245000, 0) self.uhd_multi_usrp_source_0.set_gain(20, 0) self.uhd_multi_usrp_source_0.set_center_freq(245000, 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Data transmission in bursts using uhd
Hello,
I implemented a selective repeat ARQ-protocol using the USRP2.
Up til now I used the USRP2 driver.
Now I want to upgrade my system to use UHD.
I upgrade the to hosts, the FPGA image and the firmware of my USRP2s.
Now the continous data transmission works fine.
But the bursty protocol communication doesn't work.
I used this code form the ursp sink in the downstream part of the transmitter:
if not self.usrp:
self.usrp2_sink = uhd.single_usrp_sink(
device_addr="addr=192.168.10.2",
io_type=uhd.io_type_t.COMPLEX_FLOAT32,
num_channels=1,
)
self.usrp2_sink.set_samp_rate(self.output_samp_rate)
self.usrp2_sink.set_center_freq(self.center_frequency, 0)
self.usrp2_sink.set_gain(self.tx_gain, 0)
else:
self.usrp2_sink = usrp2.sink_32fc('eth1','')
self.usrp2_sink.set_interp(self.usrp_interp_rate)
self.usrp2_sink.set_center_freq(self.center_frequency)
self.usrp2_sink.set_gain(self.tx_gain)
And this one for the usrp source for the resceiving part of the feedback
channel in the transmitter of the overall system.
if not self.usrp:
self.usrp_source = uhd.single_usrp_source(
device_addr="addr=192.168.10.2",
io_type=uhd.io_type_t.COMPLEX_FLOAT32,
num_channels=1,
)
self.usrp_source.set_samp_rate(self.input_samp_rate)
self.usrp_source.set_center_freq(self.center_frequency, 0)
self.usrp_source.set_gain(self.rx_gain, 0)
self.usrp_rate = self.input_samp_rate
else:
self.usrp_source = usrp2.source_32fc('eth1','')
self.usrp_source.set_decim(self.usrp_decim_rate)
self.usrp_source.set_center_freq(self.center_frequency)
self.usrp_source.set_gain(self.rx_gain)
self.usrp_rate = int(self.usrp_source.adc_rate() /
self.usrp_decim_rate) # sample rate from USRP
Do I have to do something in addition to make it work for bursty transmissions.
Furthermore I get an 'U' in terminal of the transmitter after each burst. Is
this the same problem?
Thanks for your help.
Regards,
Tobias
___
WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Preamble
Hi, I found the appended THread in the archive. That time, there was no answer to this mail. But I have exactly the same problem to understand the architecture of the packets. It would be nice, if anyone could write a short explanation why the \x55 and the preamble are added to the packet. Thanks a lot. Regards, Tobias Hi all, I was going through the pkt.py and packet_utils.py just to try and understand how packets are generated. Is it right to say that preamble has not being added to the payload? "(packed_preamble, _*ignore*_) = conv_1_0_string_to_packed_binary_string(preamble)" If it is being added how is it helpful on the receiver side because i don't see where it has been used or extracted. I know that it can be used to contain the training sequence for channel estimation but i doubt it has been used for the same here. I can only see the access code correlator to mark the beginning of payload and no correlator for the preamble. Is it right to assume that the access code correlator alone can be suffice? What is the significance of _*'\x55'*_ at the end of the packet before introducing usrp pad? I am asking because according to my understanding it should make the end of payload(post amble) but I don't see a correlator for it. Kind regards, Nelson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Viterbi--OFDM
Hello Achilleas, I tried out your idea and added an interleaver. While doing this, I got the error that really caused my trouble. I splited the coded sequenceinto 2 packets. And as I changed this, I worked fine, even better after adding an interleaver. So thanks for your idea. But that brought up another question. Although my working with gnu radio, I'm not really sure if I understud the output of the viterbi_combined right. The input in case is one bit per byte. I'm using the pack_to_unpack block. For trellis coding I'm using the trellis_encoder_bs. With the awgn1o2_4.fsm fsm. So what exactly is me output. Is it a short with two valid bits each? So if I use a unpack_to_pack block afterwards, I would get as much shorts as the number of chars before entering the pack_to_unpack block. Is that right? So after packing the fsmsymbols into shorts, I catch them with am message sink to get the whole coded sequence and hand it over as a payload for the ofdm_mod. So me next question is, while catching the items in that queue, do I have to count the incoming bytes or the number of incoming samples? Thanks for your help Tobias Am 11.09.2010 20:18, schrieb Tobias Schmid: Hello Achilleas, that's exactly what I thought abaout as well. Because the part I discribed as channel in my last mail is a wireless transmission using usrp2. Not using channel coding, I have packet error rates of 1 to 2 % using bpsk subcarrier constellation and abaout 18 % using qpsk. And if I evaluate the packet error rates not as a mean value, but in smaller periodes, there are periodes where the viterbi correcty almost every error, but there are also periodes in which there are just erroneus packets produced. So as you said, I thought about using an interveaver to reduce the problem of burst errors. If that doesn't work, it's no bigger problem, because I've implemented a selective repeat arq as well, so using this protocol, I'm getting good or even better performances, due to the reduced amount of data to transmit. So thanks for your quick help, I'll try this out, when I'm back a university on monday. Tobias Am 10.09.2010 20:47, schrieb Achilleas Anastasopoulos: My guess is that the inner channel (ie the combination of OFDM modulator/channel/OFDM demodulator) is producing big bursts of errors. Essentially either the packet is correctly received or completely erroneously received. In that case the outer Convolutional code cannot do much; on the contrary it deteriorates performance because of the SNR loss due to coding. One way to verify this hypothesis is to measure the error statistics of the inner channel. The way to improve is to interleave before the inner channel with sufficient depth (multiple OFDM symbols). Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Viterbi--OFDM
Hello Achilleas, that's exactly what I thought abaout as well. Because the part I discribed as channel in my last mail is a wireless transmission using usrp2. Not using channel coding, I have packet error rates of 1 to 2 % using bpsk subcarrier constellation and abaout 18 % using qpsk. And if I evaluate the packet error rates not as a mean value, but in smaller periodes, there are periodes where the viterbi correcty almost every error, but there are also periodes in which there are just erroneus packets produced. So as you said, I thought about using an interveaver to reduce the problem of burst errors. If that doesn't work, it's no bigger problem, because I've implemented a selective repeat arq as well, so using this protocol, I'm getting good or even better performances, due to the reduced amount of data to transmit. So thanks for your quick help, I'll try this out, when I'm back a university on monday. Tobias Am 10.09.2010 20:47, schrieb Achilleas Anastasopoulos: My guess is that the inner channel (ie the combination of OFDM modulator/channel/OFDM demodulator) is producing big bursts of errors. Essentially either the packet is correctly received or completely erroneously received. In that case the outer Convolutional code cannot do much; on the contrary it deteriorates performance because of the SNR loss due to coding. One way to verify this hypothesis is to measure the error statistics of the inner channel. The way to improve is to interleave before the inner channel with sufficient depth (multiple OFDM symbols). Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Viterbi--OFDM
Hallo, I guess I explained to less. I'm using hard symbol coding. As I read in the documentation, I can use the trellis modulated Symbols how ever I want to. So on the transmitter side, I do not forward the trellis modulated symbols to a QAM modulator or something. I convert the generated fsm symbols let's say with 2 Bits per Byte with a unpacked_to_packed block back into a byte with all symbols use. So I have 4 trellis coded symbols in each byte. And the so coded bytes I forward to the ofdm_mod to transmit it. On the receiver side, I take the packet handed over by the ofdm_demodulator "complete usual ofdm demodulation". So if no error occured i should get back bytes with 4 fsm hard symbols each. I take these bytes and make a pack_to_unpack and get back the 4 bytes with one 2bit fsm symbol each. this steam of chunks is than decoded by a hard_symbol viterbi. The principle is the same like in one of the trellis examples with an outer coding. it should in an error free case be the same as taking the symbols generated by a tcm into a viterbi. the scheme is: input(packet with leading and ending zeros to force defined states)---pack_to_unpack--tcm(hard_symbol)--unpack_to_pack--ofdm_mod--CHANNEL--ofdm_demod--pack_to_unpack--combined_viterbi(hard_symbol)--unpack_to_pack--- And I don't know why I doesn't work all the time. Is there an error in my idea? Cheers, Tobias Am 09.09.2010 21:57, schrieb Veljko Pejovic: Hi Tobias, I'm trying to implement coded OFDM as well. I think we are following the same approach when it comes to the transmission, but I'm afraid I do not understand your receiver. When exactly do you do OFDM demodulation? combined_viterbi does demodulation of the BPSK, QAM, etc signal based on the given constellation. However, OFDM decoding has to happen before that. The tricky part is that the OFDM blocks in gnuradio don't allow you to easily plug the combined_viterbi module. Are you putting it between ofdm_recv and ofdm_demod in the ofdm_demod class? If so, what about the control signal that tells you where the frame starts, which flows on the other ofdm_recv port? Cheers, Veljko On Thu, Sep 9, 2010 at 7:10 AM, Tobias Schmid mailto:tobiasschmid22...@web.de>> wrote: Hi, I've got another question. I implemented an OFDM-transmission eviroment and now I additionally added channel coding. It works fine, but when using trellis modulator and viterbi decoder, the packeterrorrate increases. I realized the blockbuilding, using a message_queue counting the incomming items and when reached a certain limit, push it into an message source. To realize the defined initial and final state, I added zeros at the end of each block using the python --struct-- module. These data blocks are converted to chunks and handed over to the trellis_modulator. The outcoming chunks are, depending on there number of bits packt to shorts to transmit it using the ofdm_mod block. Obn the receiver side the recieved block is unpackt using the inverse operation of the block after the trellis_mod und the tcm output symbols are handed over to the combined_viterbi afterwards packt to the original data stream. This stream is catched by a message queue as well and packets of the original length are reconstructed. So my question is, what did I do wrong, to get an packet error rate, that is worse than the uncoded transmission. It seems to me, that some times in the transmission the viterbi works fine and corrects all the errors, but sometimes, it doesn't output any correct data. Is there a solution to this problem? Thanks alot for your help. Tobias Neu: WEB.DE <http://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 Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Viterbi--OFDM
Hi,I've got another question. I implemented an OFDM-transmission eviroment and now I additionally added channel coding. It works fine, but when using trellis modulator and viterbi decoder, the packeterrorrate increases.I realized the blockbuilding, using a message_queue counting the incomming items and when reached a certain limit, push it into an message source.To realize the defined initial and final state, I added zeros at the end of each block using the python --struct-- module. These data blocks are converted to chunks and handed over to the trellis_modulator.The outcoming chunks are, depending on there number of bits packt to shorts to transmit it using the ofdm_mod block.Obn the receiver side the recieved block is unpackt using the inverse operation of the block after the trellis_mod und the tcm output symbols are handed over to the combined_viterbi afterwards packt to the original data stream. This stream is catched by a message queue as well and packets of the original length are reconstructed.So my question is, what did I do wrong, to get an packet error rate, that is worse than the uncoded transmission. It seems to me, that some times in the transmission the viterbi works fine and corrects all the errors, but sometimes, it doesn't output any correct data.Is there a solution to this problem?Thanks alot for your help.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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis and streaming
Hello MB, I implemented a viterbi application and I realized this problem somehow identical to the ofdm-streaming block for grc. I took packet_sink that waits until enough samples have arrived. These packets can be used as packet in the rest of your code. It's not that much work. Tobias Am 04.08.2010 14:56, schrieb Martin Braun: Hi list, if anyone has an idea about the gr-trellis module, perhaps you can help me: It seems the trellis_viterbi*-blocks are only suitable for packetized data (with 'K' symbols). Is there a way to use them in a streaming fashion, e.g. like gr_ccsds_decode_fb? Thanks, MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Fwd: [Discuss-gnuradio] No UHD Devices Found
Hello Matthias, thanks again for your help. As you have possibly seen, I have opened another thread yesterday, because I wasn't able to burn my card and to get a positiv verification message. This morning I didn't know what to do anymore and I decided to try another card writer. And suddenly it worked. Or I got at least an positiv verification message. So I thought this should have worked. But as you know, it didn't. So I followed your suggestion and downloaded the files for another time. I compared the FPGA and firmware image and they had identical properties. So I thought it wouldn't work. But not knowing what to do else, I just retried burning. And "I don't know why" this time it worked. So I don't know the reason why, but never the less I'll go on with my project now. Thanks for your help. Tobias Am 28.07.2010 14:30, schrieb Matthias Wilhelm: Hello, thanks for your quick answer. I checked it and I think ists okay. inupc33:/home/gnuradio/gnuradio/uhd/host/utils # route -n Kernel IP Routentabelle Ziel Router Genmask FlagsMetric RefUse Iface 129.69.175.00.0.0.0 255.255.255.0 U 0 00 eth0 192.168.10.00.0.0.0 255.255.255.0 U 0 00 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 129.69.175.254 0.0.0.0 UG 0 00 eth0 And in contrast to Luca I used the ping -I eth1 192.168.10.2 -command to be sure that is use the right network device. Tobias Luca wrote me that he solved the issue, maybe you have a firmware/FPGA image mismatch, such that the firmware boots and lights the LEDs but cannot receive/reply to ethernet packets properly. Matthias Anfang der weitergeleiteten E-Mail: *Von: *Luca Pascale <mailto:pascale.luca...@gmail.com>> *Datum: *28. Juli 2010 11:56:41 MESZ *An: *Matthias Wilhelm <mailto:wilh...@informatik.uni-kl.de>> *Betreff: **Re: [Discuss-gnuradio] No UHD Devices Found* Hi Matthias, thanks for your reply. I have solved loading the UHD last firmware/FPGA image. Now all is ok. Next step is to control 2 USRP2 in a fully synchronized(and coherent) way. Thanks again. Luca 2010/7/28 Matthias Wilhelm <mailto:wilh...@informatik.uni-kl.de>> Hello, "destination host unreachable" indicates that the route is not set correctly. Try # route add -net 192.168.10.0/24 <http://192.168.10.0/24> dev eth1 or check # route -n to see if the routing is using the proper network devices. Matthias Am 28.07.2010 um 11:10 schrieb Tobias Schmid: > Hi, > > I've got exactly the same problem. > In my case the lights D and F are light up. > > The usrp2_card_burner_gui.py works correctly. I've checked that by flashing the cards with the common firmware. > And that works fine. > > Tobias > > Am 15.07.2010 18:32, schrieb Josh Blum: >> Are the UHD images burned onto the sd card? >> >> http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries#UHD-Firmware-and-FPGA-Images >> >> http://www.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-sd-card >> >> Are lights E and F light up on the front panel once powered up? >> >> -Josh >> >> On 07/15/2010 09:28 AM, Luca Pascale wrote: >>> Hi, >>> I have received two new USRP2 (rev 4) with a BasicRx DB. I connect the DB, >>> set the gbit lan so that : >>> >>> eth1 Link encap:Ethernet HWaddr 00:15:17:e6:86:56 >>> inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 >>> inet6 addr: fe80::215:17ff:fee6:8656/64 Scope:Link >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:190 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:1000 >>> RX bytes:0 (0.0 B) TX bytes:27244 (27.2 KB) >>> Memory:f300-f302 >>> >>> I connect the USRP2 to the GBIT lan port and try: >>> ping 192.168.10.2 >>> >>> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. >>> From 192.168.10.1 icmp_seq=2 Destination Host Unreachable >>>
Re: [Discuss-gnuradio] No UHD Devices Found
Hello, thanks for your quick answer. I checked it and I think ists okay. inupc33:/home/gnuradio/gnuradio/uhd/host/utils # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric RefUse Iface 129.69.175.00.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.10.00.0.0.0 255.255.255.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 129.69.175.254 0.0.0.0 UG 0 00 eth0 And in contrast to Luca I used the ping -I eth1 192.168.10.2 -command to be sure that is use the right network device. Tobias -Ursprüngliche Nachricht- Von: Matthias Wilhelm Gesendet: 28.07.2010 11:30:50 An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] No UHD Devices Found >Hello, > >"destination host unreachable" indicates that the route is not set correctly. >Try > ># route add -net 192.168.10.0/24 dev eth1 > >or check > ># route -n > >to see if the routing is using the proper network devices. > >Matthias > > >Am 28.07.2010 um 11:10 schrieb Tobias Schmid: > >> Hi, >> >> I've got exactly the same problem. >> In my case the lights D and F are light up. >> >> The usrp2_card_burner_gui.py works correctly. I've checked that by flashing >> the cards with the common firmware. >> And that works fine. >> >> Tobias >> >> Am 15.07.2010 18:32, schrieb Josh Blum: >>> Are the UHD images burned onto the sd card? >>> >>> http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries#UHD-Firmware-and-FPGA-Images >>> >>> >>> http://www.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-sd-card >>> >>> >>> Are lights E and F light up on the front panel once powered up? >>> >>> -Josh >>> >>> On 07/15/2010 09:28 AM, Luca Pascale wrote: >>>> Hi, >>>> I have received two new USRP2 (rev 4) with a BasicRx DB. I connect the DB, >>>> set the gbit lan so that : >>>> >>>> eth1 Link encap:Ethernet HWaddr 00:15:17:e6:86:56 >>>> inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 >>>> inet6 addr: fe80::215:17ff:fee6:8656/64 Scope:Link >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:190 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:1000 >>>> RX bytes:0 (0.0 B) TX bytes:27244 (27.2 KB) >>>> Memory:f300-f302 >>>> >>>> I connect the USRP2 to the GBIT lan port and try: >>>> ping 192.168.10.2 >>>> >>>> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. >>>> From 192.168.10.1 icmp_seq=2 Destination Host Unreachable >>>> From 192.168.10.1 icmp_seq=3 Destination Host Unreachable >>>> From 192.168.10.1 icmp_seq=4 Destination Host Unreachable >>>> >>>> am I missing something ? >>>> >>>> (I have also builded UHD and tried uhd_find_devices...result: No UHD >>>> Devices >>>> Found ) >>>> >>>> Any suggestions ?? (same behaviours on both uspr2) >>>> thanks in advance Luca >>>> >>>> >>>> >>>> >>>> ___ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >___ >Discuss-gnuradio mailing list >Discuss-gnuradio@gnu.org >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ WEB.DE DSL ab 19,99 Euro/Monat. Bis zu 150,- Euro Startguthaben und 50,- Euro Geldprämie inklusive! https://freundschaftswerbung.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No UHD Devices Found
Hi, I've got exactly the same problem. In my case the lights D and F are light up. The usrp2_card_burner_gui.py works correctly. I've checked that by flashing the cards with the common firmware. And that works fine. Tobias Am 15.07.2010 18:32, schrieb Josh Blum: Are the UHD images burned onto the sd card? http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries#UHD-Firmware-and-FPGA-Images http://www.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-sd-card Are lights E and F light up on the front panel once powered up? -Josh On 07/15/2010 09:28 AM, Luca Pascale wrote: Hi, I have received two new USRP2 (rev 4) with a BasicRx DB. I connect the DB, set the gbit lan so that : eth1 Link encap:Ethernet HWaddr 00:15:17:e6:86:56 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fee6:8656/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:190 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:27244 (27.2 KB) Memory:f300-f302 I connect the USRP2 to the GBIT lan port and try: ping 192.168.10.2 PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data. From 192.168.10.1 icmp_seq=2 Destination Host Unreachable From 192.168.10.1 icmp_seq=3 Destination Host Unreachable From 192.168.10.1 icmp_seq=4 Destination Host Unreachable am I missing something ? (I have also builded UHD and tried uhd_find_devices...result: No UHD Devices Found ) Any suggestions ?? (same behaviours on both uspr2) thanks in advance Luca ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Update the USRP2
Am 27.07.2010 18:06, schrieb Matt Ettus: On 07/27/2010 08:38 AM, Tobias Schmid wrote: Hello, it's me for the third time. I decided to try working with the uhd. I followed the instructions on http://www.ettus.com/uhd_docs/manual/html/usrp2.html , but when the usrp2_card_burner(_gui).py finished it's work, I get the following messages: gnura...@inupc33:~/gnuradio/uhd/host/utils> sudo ./usrp2_card_burner.py --dev=/dev/sdd --fpga=/home/gnuradio/USRP2_Images/USRP2/FPGA/u2_rev3-20100603.bin root's password: Burn fpga image: 1684+1 Datensätze ein 1684+1 Datensätze aus 862584 Bytes (863 kB) kopiert, 4,09834 s, 210 kB/s Verification Failed: 2048+0 Datensätze ein 2048+0 Datensätze aus 1048576 Bytes (1,0 MB) kopiert, 1,33575 s, 785 kB/s Verification failed means that the card doesn't have a good image, so it definitely won't work until you get a good image on there. Are you sure the write protect is off? Matt Hello, thanks for the quick answer. I can't check it right now, because I am out of office. Tomorrow morning I'm going to check it and afterwards I'll post it here. Tobias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Update the USRP2
Hello, it's me for the third time. I decided to try working with the uhd. I followed the instructions on http://www.ettus.com/uhd_docs/manual/html/usrp2.html , but when the usrp2_card_burner(_gui).py finished it's work, I get the following messages: gnura...@inupc33:~/gnuradio/uhd/host/utils> sudo ./usrp2_card_burner.py --dev=/dev/sdd --fpga=/home/gnuradio/USRP2_Images/USRP2/FPGA/u2_rev3-20100603.bin root's password: Burn fpga image: 1684+1 Datensätze ein 1684+1 Datensätze aus 862584 Bytes (863 kB) kopiert, 4,09834 s, 210 kB/s Verification Failed: 2048+0 Datensätze ein 2048+0 Datensätze aus 1048576 Bytes (1,0 MB) kopiert, 1,33575 s, 785 kB/s gnura...@inupc33:~/gnuradio/uhd/host/utils> sudo ./usrp2_card_burner.py --dev=/dev/sdd --fw=/home/gnuradio/USRP2_Images/USRP2/Firmware/txrx_xcvr_raw_eth_20100608.bin Burn firmware image: 47+1 Datensätze ein 47+1 Datensätze aus 24208 Bytes (24 kB) kopiert, 0,147917 s, 164 kB/s Verification Failed: 2048+0 Datensätze ein 2048+0 Datensätze aus 1048576 Bytes (1,0 MB) kopiert, 1,43747 s, 729 kB/s And if I insert the card into the USRP2, not even a LED is switched on. I searched through the list for a long time, but I didn't find anything helping me. So I would be very thankful getting an answer. Tobias -Ursprüngliche Nachricht- Von: Tobias Schmid Gesendet: 27.07.2010 14:54:20 An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] Update the USRP2 >Hello again, > >that was my mistake. My network devices have been installed with >different names by the System. The network card I connected my USRP2 to, >was names eth1. So I had to change the default settings of the gr_usrp2 >block. So my code workes fine. >But the other question remains: >Would it be better to continue my work using the uhd or not? > >Tobias > >Am 27.07.2010 08:10, schrieb Tobias Schmid: >> Hello, >> >> I've got another short question.Up til now, I used the 3.2.2 release of >> Gnuradio, but now I've updates it to the latest git version 3.3.1. >> I wanted to check if my already written code still works, but I didn't even >> recognize my USRP2. So my question is, do I have to update my USRP2 firmware >> and the FPGA image as well? Isn't it possible to run my application without >> updating the USRP? >> If so, do I have the possibility to choose between the new UHD and the >> common USRP firmware and FPGA image? >> >> I had a look on the binaries offered on: >> http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries >> >> Due to this page, I thougt it is possible to choose. On the host side I have >> already installed the next git branch, as well as the uhd git from ettus. So >> what would you suggest? Go on working with the common USRP2 staff or change >> to UHD right now? >> My final ambition is to implement some MIMO staff. >> >> Thanks for your help >> >> Tobias >> ___ >> GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://movieflat.web.de >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > >___ >Discuss-gnuradio mailing list >Discuss-gnuradio@gnu.org >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Update the USRP2
Hello again, that was my mistake. My network devices have been installed with different names by the System. The network card I connected my USRP2 to, was names eth1. So I had to change the default settings of the gr_usrp2 block. So my code workes fine. But the other question remains: Would it be better to continue my work using the uhd or not? Tobias Am 27.07.2010 08:10, schrieb Tobias Schmid: Hello, I've got another short question.Up til now, I used the 3.2.2 release of Gnuradio, but now I've updates it to the latest git version 3.3.1. I wanted to check if my already written code still works, but I didn't even recognize my USRP2. So my question is, do I have to update my USRP2 firmware and the FPGA image as well? Isn't it possible to run my application without updating the USRP? If so, do I have the possibility to choose between the new UHD and the common USRP firmware and FPGA image? I had a look on the binaries offered on: http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries Due to this page, I thougt it is possible to choose. On the host side I have already installed the next git branch, as well as the uhd git from ettus. So what would you suggest? Go on working with the common USRP2 staff or change to UHD right now? My final ambition is to implement some MIMO staff. Thanks for your help Tobias ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Update the USRP2
Hello, I've got another short question.Up til now, I used the 3.2.2 release of Gnuradio, but now I've updates it to the latest git version 3.3.1. I wanted to check if my already written code still works, but I didn't even recognize my USRP2. So my question is, do I have to update my USRP2 firmware and the FPGA image as well? Isn't it possible to run my application without updating the USRP? If so, do I have the possibility to choose between the new UHD and the common USRP firmware and FPGA image? I had a look on the binaries offered on: http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries Due to this page, I thougt it is possible to choose. On the host side I have already installed the next git branch, as well as the uhd git from ettus. So what would you suggest? Go on working with the common USRP2 staff or change to UHD right now? My final ambition is to implement some MIMO staff. Thanks for your help Tobias ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Update the USRP2
Hello, I've got another short question.Up til now, I used the 3.2.2 release of Gnuradio, but now I've updates it to the latest git version 3.3.1. I wanted to check if my already written code still works, but I didn't even recognize my USRP2. So my question is, do I have to update my USRP2 firmware and the FPGA image as well? Isn't it possible to run my application without updating the USRP? If so, do I have the possibility to choose between the new UHD and the common USRP firmware and FPGA image? I had a look on the binaries offered on: http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries Due to this page, I thougt it is possible to choose. On the host side I have already installed the next git branch, as well as the uhd git from ettus. So what would you suggest? Go on working with the common USRP2 staff or change to UHD right now? My final ambition is to implement some MIMO staff. Thanks for your help Tobias ___ WEB.DE DSL ab 19,99 Euro/Monat. Bis zu 150,- Euro Startguthaben und 50,- Euro Geldprämie inklusive! https://freundschaftswerbung.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MIMO capability of USRP2
Hello, I've got a question about the firmware of my USRP2. I'm writing mydiploma thesis on a MIMO topic using your USRP2 and Gnu radio. Our institute boughtthe USRPs in July 2009. So I would like to know, if it is necessary toupdate my SD cards for the purpose. And I read in the gnuradio mailinglist, that there are two versions of the firmware. One for the slave andone for the master device. So my second question is, if it is possibleto use the updated USRPs in my SISO transmission system anyway?Further on, it would be nice to know, if and how it is possible toaddress the USRPs. Are there any blocks in python or in c++ which realize theaddressing of the modified USRPs .Or are there any other ways to do this.If so, can anyone tell me where I can find some examples. I've found some examples and block using multiple USRP1, but unfortunately not for USRP2.Maybe it's importent to mention which version of Gnu radio I'm using. I working with the stable version of Gnu radio 3.2.2.At first I would like to realize maximum ratio combining.Thanks a lot for your helpTobias Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to write a signal processing block problems
Hello, I am working on project ofdm project using gnuradio. Up til now I just used python blocks to build my flowgraphs. But now I want to create my own C++ blocks. I read the available tutorials and I wrote a block on my own. After that, I tried to build that block to use it in my python code. I followed the guidelines in the tutorials and changed/added the path of my .h and .cc file and I also changed the .i file in the gr-howto_write_a_block_3.2.2 directory. But now I don't know how to go on. Do I thought I have to run ./bootstrap ->./make? By the way I have autoconf 2.63 and automake 1.10.1 installed. And I am working with gnuradio 3.2.2. I would be nice if anyone could help me. I am not that experienced in linux and don't know how to go on at the moment. Thank you for your help. Tobias ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
