Re: [Discuss-gnuradio] Narrowband Tunnel.py Error
On Fri, Jul 25, 2014 at 4:28 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: On Fri, Jul 25, 2014 at 1:13 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 24, 2014 at 7:42 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: Thanks for the response. A colleague of mine recommended going into the uhd_interface file and change the self.u.set_center_freq() and not use the lo_offset as a parameter. Then again it couldn't hurt to just add the command line argument. Thank you for the gr-mac link, it is within my interests to use it. Jonathan Best to focus on using gr-mac. Getting started with it might be a bit difficult, but it's far superior to tunnel.py and where we want to go, anyways. GNU Radio will hopefully be adopting this in the future, too, and removing tunnel.py. Tom On Thu, Jul 24, 2014 at 7:09 PM, Mike Jameson mike.jame...@ettus.com wrote: Try adding '--lo-offset=10e6' as a commandline argument. Thanks for the bug report, I'll push a fix asap. FYI, the tunnel.py script has been superseded by gr-mac: https://github.com/balint256/gr-mac Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Thu, Jul 24, 2014 at 10:15 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: I am currently running GNU Radio 3.7.4 and I am getting an error running the stock narrowband tunnel.py script. This is what I am getting: [root@cobra narrowband]# ./tunnel.py -f 146.0M -a addr=10.2.8.104 linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_104100; UHD_003.007.001-64-g92b0b7ab Using Volk machine: sse4_2_64 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- Detecting internal GPSDO Found an internal GPSDO -- found -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Traceback (most recent call last): File ./tunnel.py, line 296, in module main() File ./tunnel.py, line 259, in main options) File ./tunnel.py, line 103, in __init__ options.verbose) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 199, in __init__ freq, lo_offset, gain, spec, antenna, clock_source) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 70, in __init__ self._freq = self.set_freq(freq, lo_offset) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 120, in set_freq r = self.u.set_center_freq(uhd.tune_request(freq, lo_offset)) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/__init__.py, line 52, in __init__ super(tune_request_t, self).__init__(*args) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 792, in __init__ this = _uhd_swig.new_tune_request_t(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_tune_request_t'. Possible C/C++ prototypes are: uhd::tune_request_t(double) uhd::tune_request_t(double,double) I am not too sure what to do, I have looked up the error but I couldn't find a solution. Anyone know what to do? Also, the benchmark scripts work, it is just the tunnel script that doesn't. Thanks Jonathan I did try the --lo-offset=10e6 argument and it didn't work. I may just have to tweak the self.u.set_center_freq to not have the uhd.tune_request because it doesn't work just as self.u.set_center_freq(uhd.tune_request(freq)). I know the latest version of GNU Radio has a burst tagger block, so is the gr-mac project already incorporated? No. As I said, we will hopefully be adopting it in the future, but it is still a separate project. And the burst tagger block has been in GNU Radio for quite some time. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Narrowband Tunnel.py Error
On Thu, Jul 24, 2014 at 7:42 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: Thanks for the response. A colleague of mine recommended going into the uhd_interface file and change the self.u.set_center_freq() and not use the lo_offset as a parameter. Then again it couldn't hurt to just add the command line argument. Thank you for the gr-mac link, it is within my interests to use it. Jonathan Best to focus on using gr-mac. Getting started with it might be a bit difficult, but it's far superior to tunnel.py and where we want to go, anyways. GNU Radio will hopefully be adopting this in the future, too, and removing tunnel.py. Tom On Thu, Jul 24, 2014 at 7:09 PM, Mike Jameson mike.jame...@ettus.com wrote: Try adding '--lo-offset=10e6' as a commandline argument. Thanks for the bug report, I'll push a fix asap. FYI, the tunnel.py script has been superseded by gr-mac: https://github.com/balint256/gr-mac Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Thu, Jul 24, 2014 at 10:15 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: I am currently running GNU Radio 3.7.4 and I am getting an error running the stock narrowband tunnel.py script. This is what I am getting: [root@cobra narrowband]# ./tunnel.py -f 146.0M -a addr=10.2.8.104 linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_104100; UHD_003.007.001-64-g92b0b7ab Using Volk machine: sse4_2_64 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- Detecting internal GPSDO Found an internal GPSDO -- found -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Traceback (most recent call last): File ./tunnel.py, line 296, in module main() File ./tunnel.py, line 259, in main options) File ./tunnel.py, line 103, in __init__ options.verbose) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 199, in __init__ freq, lo_offset, gain, spec, antenna, clock_source) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 70, in __init__ self._freq = self.set_freq(freq, lo_offset) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 120, in set_freq r = self.u.set_center_freq(uhd.tune_request(freq, lo_offset)) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/__init__.py, line 52, in __init__ super(tune_request_t, self).__init__(*args) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 792, in __init__ this = _uhd_swig.new_tune_request_t(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_tune_request_t'. Possible C/C++ prototypes are: uhd::tune_request_t(double) uhd::tune_request_t(double,double) I am not too sure what to do, I have looked up the error but I couldn't find a solution. Anyone know what to do? Also, the benchmark scripts work, it is just the tunnel script that doesn't. Thanks Jonathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Narrowband Tunnel.py Error
On Fri, Jul 25, 2014 at 1:13 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 24, 2014 at 7:42 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: Thanks for the response. A colleague of mine recommended going into the uhd_interface file and change the self.u.set_center_freq() and not use the lo_offset as a parameter. Then again it couldn't hurt to just add the command line argument. Thank you for the gr-mac link, it is within my interests to use it. Jonathan Best to focus on using gr-mac. Getting started with it might be a bit difficult, but it's far superior to tunnel.py and where we want to go, anyways. GNU Radio will hopefully be adopting this in the future, too, and removing tunnel.py. Tom On Thu, Jul 24, 2014 at 7:09 PM, Mike Jameson mike.jame...@ettus.com wrote: Try adding '--lo-offset=10e6' as a commandline argument. Thanks for the bug report, I'll push a fix asap. FYI, the tunnel.py script has been superseded by gr-mac: https://github.com/balint256/gr-mac Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Thu, Jul 24, 2014 at 10:15 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: I am currently running GNU Radio 3.7.4 and I am getting an error running the stock narrowband tunnel.py script. This is what I am getting: [root@cobra narrowband]# ./tunnel.py -f 146.0M -a addr=10.2.8.104 linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_104100; UHD_003.007.001-64-g92b0b7ab Using Volk machine: sse4_2_64 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- Detecting internal GPSDO Found an internal GPSDO -- found -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Traceback (most recent call last): File ./tunnel.py, line 296, in module main() File ./tunnel.py, line 259, in main options) File ./tunnel.py, line 103, in __init__ options.verbose) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 199, in __init__ freq, lo_offset, gain, spec, antenna, clock_source) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 70, in __init__ self._freq = self.set_freq(freq, lo_offset) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 120, in set_freq r = self.u.set_center_freq(uhd.tune_request(freq, lo_offset)) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/__init__.py, line 52, in __init__ super(tune_request_t, self).__init__(*args) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 792, in __init__ this = _uhd_swig.new_tune_request_t(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_tune_request_t'. Possible C/C++ prototypes are: uhd::tune_request_t(double) uhd::tune_request_t(double,double) I am not too sure what to do, I have looked up the error but I couldn't find a solution. Anyone know what to do? Also, the benchmark scripts work, it is just the tunnel script that doesn't. Thanks Jonathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I did try the --lo-offset=10e6 argument and it didn't work. I may just have to tweak the self.u.set_center_freq to not have the uhd.tune_request because it doesn't work just as self.u.set_center_freq(uhd.tune_request(freq)). I know the latest version of GNU Radio has a burst tagger block, so is the gr-mac project already incorporated? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Narrowband Tunnel.py Error
I am currently running GNU Radio 3.7.4 and I am getting an error running the stock narrowband tunnel.py script. This is what I am getting: [root@cobra narrowband]# ./tunnel.py -f 146.0M -a addr=10.2.8.104 linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_104100; UHD_003.007.001-64-g92b0b7ab Using Volk machine: sse4_2_64 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- Detecting internal GPSDO Found an internal GPSDO -- found -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Traceback (most recent call last): File ./tunnel.py, line 296, in module main() File ./tunnel.py, line 259, in main options) File ./tunnel.py, line 103, in __init__ options.verbose) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 199, in __init__ freq, lo_offset, gain, spec, antenna, clock_source) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 70, in __init__ self._freq = self.set_freq(freq, lo_offset) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 120, in set_freq r = self.u.set_center_freq(uhd.tune_request(freq, lo_offset)) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/__init__.py, line 52, in __init__ super(tune_request_t, self).__init__(*args) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 792, in __init__ this = _uhd_swig.new_tune_request_t(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_tune_request_t'. Possible C/C++ prototypes are: uhd::tune_request_t(double) uhd::tune_request_t(double,double) I am not too sure what to do, I have looked up the error but I couldn't find a solution. Anyone know what to do? Also, the benchmark scripts work, it is just the tunnel script that doesn't. Thanks Jonathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Narrowband Tunnel.py Error
Try adding '--lo-offset=10e6' as a commandline argument. Thanks for the bug report, I'll push a fix asap. FYI, the tunnel.py script has been superseded by gr-mac: https://github.com/balint256/gr-mac Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Thu, Jul 24, 2014 at 10:15 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: I am currently running GNU Radio 3.7.4 and I am getting an error running the stock narrowband tunnel.py script. This is what I am getting: [root@cobra narrowband]# ./tunnel.py -f 146.0M -a addr=10.2.8.104 linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_104100; UHD_003.007.001-64-g92b0b7ab Using Volk machine: sse4_2_64 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- Detecting internal GPSDO Found an internal GPSDO -- found -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Traceback (most recent call last): File ./tunnel.py, line 296, in module main() File ./tunnel.py, line 259, in main options) File ./tunnel.py, line 103, in __init__ options.verbose) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 199, in __init__ freq, lo_offset, gain, spec, antenna, clock_source) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 70, in __init__ self._freq = self.set_freq(freq, lo_offset) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 120, in set_freq r = self.u.set_center_freq(uhd.tune_request(freq, lo_offset)) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/__init__.py, line 52, in __init__ super(tune_request_t, self).__init__(*args) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 792, in __init__ this = _uhd_swig.new_tune_request_t(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_tune_request_t'. Possible C/C++ prototypes are: uhd::tune_request_t(double) uhd::tune_request_t(double,double) I am not too sure what to do, I have looked up the error but I couldn't find a solution. Anyone know what to do? Also, the benchmark scripts work, it is just the tunnel script that doesn't. Thanks Jonathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Narrowband Tunnel.py Error
Thanks for the response. A colleague of mine recommended going into the uhd_interface file and change the self.u.set_center_freq() and not use the lo_offset as a parameter. Then again it couldn't hurt to just add the command line argument. Thank you for the gr-mac link, it is within my interests to use it. Jonathan On Thu, Jul 24, 2014 at 7:09 PM, Mike Jameson mike.jame...@ettus.com wrote: Try adding '--lo-offset=10e6' as a commandline argument. Thanks for the bug report, I'll push a fix asap. FYI, the tunnel.py script has been superseded by gr-mac: https://github.com/balint256/gr-mac Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Thu, Jul 24, 2014 at 10:15 PM, Jonathan Fox 31...@cardinalmail.cua.edu wrote: I am currently running GNU Radio 3.7.4 and I am getting an error running the stock narrowband tunnel.py script. This is what I am getting: [root@cobra narrowband]# ./tunnel.py -f 146.0M -a addr=10.2.8.104 linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_104100; UHD_003.007.001-64-g92b0b7ab Using Volk machine: sse4_2_64 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 500 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 -- Detecting internal GPSDO Found an internal GPSDO -- found -- Setting references to the internal GPSDO -- Initializing time to the internal GPSDO No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Traceback (most recent call last): File ./tunnel.py, line 296, in module main() File ./tunnel.py, line 259, in main options) File ./tunnel.py, line 103, in __init__ options.verbose) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 199, in __init__ freq, lo_offset, gain, spec, antenna, clock_source) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 70, in __init__ self._freq = self.set_freq(freq, lo_offset) File /home/fox/Documents/GNU_radio/Cranial/narrowband/uhd_interface.py, line 120, in set_freq r = self.u.set_center_freq(uhd.tune_request(freq, lo_offset)) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/__init__.py, line 52, in __init__ super(tune_request_t, self).__init__(*args) File /usr/local/lib64/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 792, in __init__ this = _uhd_swig.new_tune_request_t(*args) NotImplementedError: Wrong number of arguments for overloaded function 'new_tune_request_t'. Possible C/C++ prototypes are: uhd::tune_request_t(double) uhd::tune_request_t(double,double) I am not too sure what to do, I have looked up the error but I couldn't find a solution. Anyone know what to do? Also, the benchmark scripts work, it is just the tunnel script that doesn't. Thanks Jonathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] On tunnel.py
Hi, I just want to add to this. In the software community we get to benefit from field experts, people who are doing focused research and people who want to explore something new, just because they have fun doing it. This all means we get to benefit from different approaches, which each ending up bringing something different to the table. It also why I believe software evolution is so much faster than other fields. One thing that is nice with gnu-radio, especially today, is the ability to explore radio cheaply and without necessarily having an electronics background going in. Starting small and building up is the way to go. André-John Sent from my phone. Envoyé depuis mon téléphone. On 2013-04-01, at 11:14, Martin Braun (CEL) martin.br...@kit.edu wrote: Hi Alex, you raise a lot of valid points, but I just have to add something for the record (and yes, I realize that's not what you said): Students are *not* to be blamed here. First, I know a lot of students who are doing brilliant work on GNU Radio (there's a lot of students at our lab working on great projects, and lots of other universities do fantastic work as well). Second, I've seen a lot of people complain that 'tunnel.py doesn't work', and they weren't all students. Most importantly, and that's why I'm writing this: I don't want to discourage students and universities from using GNU Radio. Please, go ahead and try it, make mistakes, play around with the examples (just don't expect them to be an end-all solution). You'll find it highly educational as well as extremely versatile. MB On Fri, Mar 29, 2013 at 12:25:10PM -0500, Alex Zhang wrote: Totally agree to stop using the tunnel.py! Just want to add some my thoughts. There is a fact that the main users of USRP/GNURadio are the students from universities. Firstly, these people lack the experience on the communications development, either in software designing or in wireless communications theory. Secondly, the reasons why they select the USRP/GNURadio as the development platform for their research, as my understanding is that they (including I) expect the USRP/GNURadio can provide a very quick solution to build a experimental physical layer for the research over this platform. Actually, most of the time, this pressure comes from their professors who are only focused on advanced research of a narrow area, but don't tolerate too much time of a student on the whole system development. This is the background in which why so many people always try to find the out-of-the-box solution in GNURadio/USRP. I don't want to put negative points to this kind of expectation, but it seems to be just reality. It may give us a hint how the GNURadio/USRP is evolving from the customers' expect. USRP/GNURadio are great work in establishing a flexible framework of software defined radio. But as Tom said, the communications itself is very very hard. How to help the customer to build a robust and strong radio communication system in their specific research needs is really a big challenge. I think the community needs more technical discussion the communications and signal processing theory in practical ways, besides the software development only. Also, the GNURadio itself need more evolution on the demonstrative solutions of the communications, like the OFDM in improving. And of course, this is a open source community. The GNURadio needs everyone's contribution, including both issues reports and new developments, new applications. -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] On tunnel.py
Please, everyone, listen up. There's been a ton of traffic on the mailing list regarding tunnel.py (and I bet I know why). I want you all to pay close attention to what I'm going to say regarding how to get tunnel.py to work for you: Stop using tunnel.py. It's old. It hasn't had any significant work or updates in years. Meanwhile, we've made huge leaps in capabilities and features in GNU Radio. A lot has changed, including the switch to the UHD drivers, which also impacts how things work. You can do better. The stream tags and message passing system provide a significant amount of new capabilities that can help us make much better digital transceivers. Johnathan Corgan recently wrote to the mailing list discussing other projects working on improving these examples: https://lists.gnu.org/archive/html/discuss-gnuradio/2013-03/msg00014.html Take a look at the work that's been going into the OFDM examples lately. Martin Braun and Ben Reynwar have used stream tags effectively to provide information on packet boundaries and trigger conditions for receiver synchronization. And they've done it all in GRC so it's easier to understand the flowgraph, modify it, and hopefully even replace blocks. [1] Also, recognize that tunnel.py and the benchmark scripts are provided as /examples/. They were never meant nor installed as applications. They are there to help you understand how to put blocks together and interact with Python, C++, callback functions, OS tools, etc. etc. But they are not going to solve you digital transmission problems. GNU Radio is a platform to develop radio applications. You have to use it as a development tool, not an out-of-the-box solution. I say this because I want us to do better as a community. We've been held back for too long because people think that the benchmark and tunnel.py scripts are the final word in GNU Radio's digital communications capabilities. But that's what you are for! You can help us improve it, like Ben and Martin did with the OFDM work. It's not easy, but communications is not easy. In fact, it's very, very hard. Tom [1] There's still a bug in the new OFDM work. Marin, Johnathan C. and myself figured it out yesterday, but I'm still formatting the right way to patch it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] On tunnel.py
Totally agree to stop using the tunnel.py! Just want to add some my thoughts. There is a fact that the main users of USRP/GNURadio are the students from universities. Firstly, these people lack the experience on the communications development, either in software designing or in wireless communications theory. Secondly, the reasons why they select the USRP/GNURadio as the development platform for their research, as my understanding is that they (including I) expect the USRP/GNURadio can provide a very quick solution to build a experimental physical layer for the research over this platform. Actually, most of the time, this pressure comes from their professors who are only focused on advanced research of a narrow area, but don't tolerate too much time of a student on the whole system development. This is the background in which why so many people always try to find the out-of-the-box solution in GNURadio/USRP. I don't want to put negative points to this kind of expectation, but it seems to be just reality. It may give us a hint how the GNURadio/USRP is evolving from the customers' expect. USRP/GNURadio are great work in establishing a flexible framework of software defined radio. But as Tom said, the communications itself is very very hard. How to help the customer to build a robust and strong radio communication system in their specific research needs is really a big challenge. I think the community needs more technical discussion the communications and signal processing theory in practical ways, besides the software development only. Also, the GNURadio itself need more evolution on the demonstrative solutions of the communications, like the OFDM in improving. And of course, this is a open source community. The GNURadio needs everyone's contribution, including both issues reports and new developments, new applications. On Fri, Mar 29, 2013 at 11:39 AM, Tom Rondeau t...@trondeau.com wrote: Please, everyone, listen up. There's been a ton of traffic on the mailing list regarding tunnel.py (and I bet I know why). I want you all to pay close attention to what I'm going to say regarding how to get tunnel.py to work for you: Stop using tunnel.py. It's old. It hasn't had any significant work or updates in years. Meanwhile, we've made huge leaps in capabilities and features in GNU Radio. A lot has changed, including the switch to the UHD drivers, which also impacts how things work. You can do better. The stream tags and message passing system provide a significant amount of new capabilities that can help us make much better digital transceivers. Johnathan Corgan recently wrote to the mailing list discussing other projects working on improving these examples: https://lists.gnu.org/archive/html/discuss-gnuradio/2013-03/msg00014.html Take a look at the work that's been going into the OFDM examples lately. Martin Braun and Ben Reynwar have used stream tags effectively to provide information on packet boundaries and trigger conditions for receiver synchronization. And they've done it all in GRC so it's easier to understand the flowgraph, modify it, and hopefully even replace blocks. [1] Also, recognize that tunnel.py and the benchmark scripts are provided as /examples/. They were never meant nor installed as applications. They are there to help you understand how to put blocks together and interact with Python, C++, callback functions, OS tools, etc. etc. But they are not going to solve you digital transmission problems. GNU Radio is a platform to develop radio applications. You have to use it as a development tool, not an out-of-the-box solution. I say this because I want us to do better as a community. We've been held back for too long because people think that the benchmark and tunnel.py scripts are the final word in GNU Radio's digital communications capabilities. But that's what you are for! You can help us improve it, like Ben and Martin did with the OFDM work. It's not easy, but communications is not easy. In fact, it's very, very hard. Tom [1] There's still a bug in the new OFDM work. Marin, Johnathan C. and myself figured it out yesterday, but I'm still formatting the right way to patch it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?
The XCVR2450 hardware is incapable of full-duplex operation. It *cannot* transmit and receive at the same time. Yes, you are right but consider we are transmitting ping requests just for a very short moment (since they are also containing only 84 bytes) with a frequency of 1 Hz. Hence, we are occupying the channel only for a very short-termed moment. We have right now in this moment found out or at least got a clue why it isn't running. We have inserted a sleep of roughly 50ms before the self.tb.txpath.send_pkt(payload) in order to give the RX/TX switching some time. The packet is now sent back and the ping request indicates a delay of 56ms (including the sleeping delay of 50ms). Does anybody has a clue why the RX/TX switching is not established fast enough? Is there some code missing what dictates the UHD interface to switch? In another application using UHD natively we are not experiencing such a strange behavior. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?
We are now trying to establish an TCP/IP connection between both USRP2s with the tunnel.py script. Unfortunately, it says Destination Host unreachable when pinging the other USRP. We should have set up the tunnel correct as some packets are received and transmitted after having configured the IP address. The pinged USRPs is indicating the received icmp packet but there is still no confirmed ping-request though. Short answer; dont do that. Yes, this particular USRP is a network device, but that is completely unrelated to the purpose of tunnel.py. You probably have to play with routing tables to make this work... Why is that unrelated to the purpose of tunnel.py? Shouldnt a simple ping request be a basic application of using this TUN/TAP application? Anyway, we have now set up the routing table correctly by using TUN instead of TAP. As we are transmitting the ping from one of the USRPs, we are also receiving them at the RX-USRP which is answering with a ping reply: RX-USRP: - TIMEOUT Rx: ok = True len(payload) = 84 Tx: len(payload) = 84 send now! UTIMEOUT - Observing the IP dataflow via Wireshark (at RX-USRP) confirms that. However, we are NOT receiving this ping reply and the transmitting USRP. It seems, like it cannot transmit and receive simultaneously. Exactky the same happens if we swap the role of transmitting and receiving USRPs. Anybody has an idea how we could overcome this problem? Basically, we want to measure the latency of a real application. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?
We are now trying to establish an TCP/IP connection between both USRP2s with the tunnel.py script. Unfortunately, it says Destination Host unreachable when pinging the other USRP. We should have set up the tunnel correct as some packets are received and transmitted after having configured the IP address. The pinged USRPs is indicating the received icmp packet but there is still no confirmed ping-request though. Short answer; dont do that. Yes, this particular USRP is a network device, but that is completely unrelated to the purpose of tunnel.py. You probably have to play with routing tables to make this work... Why is that unrelated to the purpose of tunnel.py? Shouldnt a simple ping request be a basic application of using this TUN/TAP application? Anyway, we have now set up the routing table correctly by using TUN instead of TAP. As we are transmitting the ping from one of the USRPs, we are also receiving them at the RX-USRP which is answering with a ping reply: RX-USRP: - TIMEOUT Rx: ok = True len(payload) = 84 Tx: len(payload) = 84 send now! UTIMEOUT - Observing the IP dataflow via Wireshark (at RX-USRP) confirms that. However, we are NOT receiving this ping reply and the transmitting USRP. It seems, like it cannot transmit and receive simultaneously. Exactky the same happens if we swap the role of transmitting and receiving USRPs. Anybody has an idea how we could overcome this problem? Basically, we want to measure the latency of a real application. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?
The XCVR2450 hardware is incapable of full-duplex operation. It *cannot* transmit and receive at the same time. On Wed, 01 Feb 2012 18:05:53 +0100, Florian Schlembach wrote: We are now trying to establish an TCP/IP connection between both USRP2s with the tunnel.py script. Unfortunately, it says Destination Host unreachable when pinging the other USRP. We should have set up the tunnel correct as some packets are received and transmitted after having configured the IP address. The pinged USRPs is indicating the received icmp packet but there is still no confirmed ping-request though. Short answer; dont do that. Yes, this particular USRP is a network device, but that is completely unrelated to the purpose of tunnel.py. You probably have to play with routing tables to make this work... Why is that unrelated to the purpose of tunnel.py? Shouldnt a simple ping request be a basic application of using this TUN/TAP application? Anyway, we have now set up the routing table correctly by using TUN instead of TAP. As we are transmitting the ping from one of the USRPs, we are also receiving them at the RX-USRP which is answering with a ping reply: RX-USRP: - TIMEOUT Rx: ok = True len(payload) = 84 Tx: len(payload) = 84 send now! UTIMEOUT - Observing the IP dataflow via Wireshark (at RX-USRP) confirms that. However, we are NOT receiving this ping reply and the transmitting USRP. It seems, like it cannot transmit and receive simultaneously. Exactky the same happens if we swap the role of transmitting and receiving USRPs. Anybody has an idea how we could overcome this problem? Basically, we want to measure the latency of a real application. ___ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). We have now found out that we need a sampling rate of at least 2Msps which means we have to set the bandwidth to at least 2MHz (I read sth about that the USRPs have problems with higher decimation rates): ./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M ./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M The OFDM (bpsk) example is now working and all packets seems to be transmitted. Unfortunately, not all of the packets could be demodulated correctly as they are marked as ok: False - lets say a quarter of them. This would yield a really bad performance in terms of a reliable transmission. We also played around with the distance and the alignment of the omni antennas but ultimately, we could not get rid of the false packets. Have you encountered a similar bad performance? Have you also encountered such a strange behavior regarding the lower sampling rate? What else could we try? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On Tue, Jan 31, 2012 at 8:28 AM, Florian Schlembach florian.schlemb...@tu-ilmenau.de wrote: But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). We have now found out that we need a sampling rate of at least 2Msps which means we have to set the bandwidth to at least 2MHz (I read sth about that the USRPs have problems with higher decimation rates): ./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M ./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M The OFDM (bpsk) example is now working and all packets seems to be transmitted. Unfortunately, not all of the packets could be demodulated correctly as they are marked as ok: False - lets say a quarter of them. This would yield a really bad performance in terms of a reliable transmission. We also played around with the distance and the alignment of the omni antennas but ultimately, we could not get rid of the false packets. Have you encountered a similar bad performance? Have you also encountered such a strange behavior regarding the lower sampling rate? What else could we try? There is not channel coding on the packets. A packet of 1500 bytes is is 12000 bits. If a single bit is incorrect, the CRC check will fail and the packet is marked as bad. You'll have to take the OFDM basic examples and extend them with error correcting codes to get anything like reliable performance from it. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun martin.br...@kit.edu wrote: On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote: We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM) Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange. Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version? We are totally clueless, so we appreciate any idea/help! This won't really help, but I remember we had exactly the same troubles here. This was before UHD was even released, so I doubt that's the reason. Unfortunately, I can't remember how (or: if) we fixed it :( but I'll keep you updated if my memory comes up with something. But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). MB The benchmark OFDM scripts were made as simple examples of OFDM and were not made very robust. I can get them working within an office space fairly easily, but I seem to be the only one. When I moved everything over the using the UHD interface, I tested everything OTA successfully, so they do still work. One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. Try backing off on that (to around 0.2 - 0.3) and try again. You won't get much range from this signal, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation. If you need more range use an external amp. On Tue, Jan 31, 2012 at 8:28 AM, Tom Rondeau t...@trondeau.com wrote: On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun martin.br...@kit.eduwrote: On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote: We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM) Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange. Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version? We are totally clueless, so we appreciate any idea/help! This won't really help, but I remember we had exactly the same troubles here. This was before UHD was even released, so I doubt that's the reason. Unfortunately, I can't remember how (or: if) we fixed it :( but I'll keep you updated if my memory comes up with something. But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). MB The benchmark OFDM scripts were made as simple examples of OFDM and were not made very robust. I can get them working within an office space fairly easily, but I seem to be the only one. When I moved everything over the using the UHD interface, I tested everything OTA successfully, so they do still work. One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. Try backing off on that (to around 0.2 - 0.3) and try again. You won't get much range from this signal, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On 31/01/12 08:37 AM, Andrew Davis wrote: One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation. It's not the DAC that's typically the problem, it's the final RF amplifier on the daughter-card, and that's not precisely predictable from the software side. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On 31/01/12 08:28 AM, Florian Schlembach wrote: But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). We have now found out that we need a sampling rate of at least 2Msps which means we have to set the bandwidth to at least 2MHz (I read sth about that the USRPs have problems with higher decimation rates): ./benchmark_tx.py -f 2.400G -A TX/RX --tx-amplitude=0.2 -v -W 2M ./benchmark_rx.py -f 2.400G -A TX/RX --rx-gain=35 -v -W 2M The OFDM (bpsk) example is now working and all packets seems to be transmitted. Unfortunately, not all of the packets could be demodulated correctly as they are marked as ok: False - lets say a quarter of them. This would yield a really bad performance in terms of a reliable transmission. We also played around with the distance and the alignment of the omni antennas but ultimately, we could not get rid of the false packets. Have you encountered a similar bad performance? Have you also encountered such a strange behavior regarding the lower sampling rate? What else could we try? __ Frequency offset is the usual cause of such problems. The master oscillators on a USRP vary between about 10PPM and 20PPM, which at higher frequencies means on offset of several kHz. A narrow-band signal suffers much more from frequency offset issues that a wideband one--the frequency error constitutes a larger fraction of the overall signal. Frequency offset errors are normal in any radio communications system--since master oscillator frequencies are *never* perfect. Real-world systems typically have an FLL or AFT somewhere in the receive chain to compensate. This is why the last IF filter on a narrowband FM receiver is usually wider than would be suggested by the modulation bandwidth, and why there's usually some kind of AFT feedback. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?
Ok, that definitely makes sense if there is no error correction is implemented. We are now trying to establish an TCP/IP connection between both USRP2s with the tunnel.py script. Unfortunately, it says Destination Host unreachable when pinging the other USRP. We should have set up the tunnel correct as some packets are received and transmitted after having configured the IP address. The pinged USRPs is indicating the received icmp packet but there is still no confirmed ping-request though. Do you have an idea why the pinging is not working after having established the tunnel.py connection? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark tx.py (OFDM) with XCVR2450?
On 01/31/2012 02:48 PM, Florian Schlembach wrote: Ok, that definitely makes sense if there is no error correction is implemented. We are now trying to establish an TCP/IP connection between both USRP2s with the tunnel.py script. Unfortunately, it says Destination Host unreachable when pinging the other USRP. We should have set up the tunnel correct as some packets are received and transmitted after having configured the IP address. The pinged USRPs is indicating the received icmp packet but there is still no confirmed ping-request though. Short answer; dont do that. Yes, this particular USRP is a network device, but that is completely unrelated to the purpose of tunnel.py. You probably have to play with routing tables to make this work... Do you have an idea why the pinging is not working after having established the tunnel.py connection? Try pinging a service that is running on the remote virtual interface on host PC0 from the local virtual interface on host PC1. _josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
That's kinda odd now that I think about it, I had a similar problem and on an oscilloscope it looked like DAC clipping, but I could have been non-linearity in the final amp, what kind of problems do XCVR2450 have at high outputs? On Tue, Jan 31, 2012 at 9:00 AM, Marcus D. Leech mle...@ripnet.com wrote: ** On 31/01/12 08:37 AM, Andrew Davis wrote: One thing that I noticed was that the --tx-amp=0.8. That's very high for OFDM with it's large PAPR. I'm thinking that too, there really should be some kind of warning when you drive the DAC to saturation. It's not the DAC that's typically the problem, it's the final RF amplifier on the daughter-card, and that's not precisely predictable from the software side. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On 01/31/2012 08:21 PM, Andrew Davis wrote: That's kinda odd now that I think about it, I had a similar problem and on an oscilloscope it looked like DAC clipping, but I could have been non-linearity in the final amp, what kind of problems do XCVR2450 have at high outputs? All amplifiers will have non-linear operating regions up near their maximum output power. Clipping in the DAC shouldn't be approached until the signal magnitudes approach +/- 1.0. I don't believe the XCVR2450 is special in this regard. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote: We have now extended our tests to the tests with two USRP2s with daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is receiving any packets. We checked the spectrum and tuned the gains as well. (OFDM) Now, we played with the benchmark files and tunnel.py located in the narrowband folder and therefore changed the modulation scheme from BPSK to GMSK and ultimately receiving all the packets!! That's strange. Does anybody knows what code be the problem that we can't establish any connection using higher order modulation schemes? Could it possibly be our slightly outdated UHD version? We are totally clueless, so we appreciate any idea/help! This won't really help, but I remember we had exactly the same troubles here. This was before UHD was even released, so I doubt that's the reason. Unfortunately, I can't remember how (or: if) we fixed it :( but I'll keep you updated if my memory comes up with something. But fiddling with gain values is often useful; even if you've already done that I recommend trying again, by reducing tx-amplitude and the actual gain values, shifting the terminals around (perhaps they're too close?). MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpx9MLweYYZj.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?
Hey guys, we are trying to get run the tunnel.py / benchmark_rx.py (OFDM) in order to measure the datarate between two USRP2 (located with distance of 1 m) with daughterboards XCVR2450. We are running the benchmark_tx/rx.py as follows: benchmark_tx.py -f 2.4G --tx-gain=10 --tx-amplitude=0.8 -v benchmark_rx.py -f 2.4G --rx-gain=4 -v We already tried to tune the parameters by analyzing the spectrum by gnuradio-companion. It looks reasonable and the SNR is round about 20 dB which should be fine? Unfortunately, we don't get any packets transmitted. The RX side always says TIMEOUT. Our configuration is as follows: - Ubuntu 10.04 - gnuradio 3.5.1 (installed freshly) - UHD firmware version 003.003.001 - XCVR2450 Has anybody already got the tunnel.py/benchmark_tx.py run with a similar configuration? Has anybody an idea what we are doing wrong? Thanks in advance for your help! Best Regards, Florian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
From: Tuan (Johnny) Ta ta.tu...@gmail.com To: Marcus D. Leech mle...@ripnet.com; david.barto...@yahoo.com Cc: discuss-gnuradio@gnu.org Sent: Monday, October 31, 2011 6:01 PM Subject: Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread. My setting: USRP2 XCVR2450 Ubuntu 10.04 (32bit) The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply. I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis. Can anyone help me? Thank you, Johnny On Thu, Oct 20, 2011 at 11:24 AM, Marcus D. Leech mle...@ripnet.com wrote: On 20/10/2011 10:25 AM, David Barton wrote: I have been troubleshooting an issue with possible packet relflections and cannot figure out the cause. I am running tunnel.py on two USRP2s that are cabled together with a 20dB attenuator between them. The settings I am using on both sides for tunnel.py are: Tx Gain: 15 dB Rx Gain: 10 dB Carrier Threshold: -80 Rx Tunnel Freq: 400 MHz Modulation: GMSK Bit Rate: 1Mb/sec When I use VLC to stream a video from computer A to computer B over the USRP link it works ok but there are alot of reflected packs being recorded by computer A. The same thing happens when I try to stream from computer A to computer B. This also occurs when I use iperf to test the link. Strangely, though there are NO reflected packets when I ping between the computers. Below is a paste of some of the output from computer A. I put in a timestamp on the left of when events occur. I also put in an explicit statement to print out when tunnel is backing off and for how long. I added sequence number to make it blatantly obvious that the computer is receiving its own packet. Any packet with a sequence number beginning originates from computer A. If the packet originated from computer B it shows up at RX_packet=none. As it shows computer A is receiving its own packets! [ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186 [ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310 [ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021 [ 63.61 ] Backing off for 0.001 sec [ 63.62 ] Backing off for 0.002 sec [ 63.62 ] Backing off for 0.004 sec [ 63.63 ] Backing off for 0.008 sec [ 63.64 ] Backing off for 0.016 sec [ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448 [ 63.66 ] Backing off for 0.032 sec [ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186 [ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310 [ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448 [ 63.67 ] Backing off for 0.064 sec [ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021 [ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70 [ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150 [ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248 [ 63.72 ] Backing off for 0.001 sec [ 63.72 ] Backing off for 0.002 sec [ 63.73 ] Backing off for 0.004 sec [ 63.74 ] Backing off for 0.008 sec [ 63.75 ] Backing off for 0.016 sec [ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70 [ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448 [ 63.76 ] Backing off for 0.032 sec [ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150 [ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448 [ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248 [ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566 [ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987 [ 63.78 ] Backing off for 0.001 sec [ 63.79 ] Backing off for 0.002 sec [ 63.79 ] Backing off for 0.004 sec [ 63.79 ] Backing off for 0.008 sec [ 63.8 ] Backing off for 0.016 sec [ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566 [ 63.82 ] Backing off for 0.032 sec [ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448 [ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987 [ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
On 01/11/11 08:02 PM, Tuan (Johnny) Ta wrote: Thanks for the explanation. I managed to get the system working by introducing a delay before every packet transmission. I know it's a hack but that's the quickest method I can think of. The minimum delay that I can get it to work is 11ms. It seems quite large. Is this reasonable for the turn-around time (from TX to RX) of the XCVR2450? Johnny That sounds like the right order-of-magnitude, yes. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread. My setting: USRP2 XCVR2450 Ubuntu 10.04 (32bit) The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply. I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis. Can anyone help me? Thank you, Johnny On Thu, Oct 20, 2011 at 11:24 AM, Marcus D. Leech mle...@ripnet.com wrote: On 20/10/2011 10:25 AM, David Barton wrote: I have been troubleshooting an issue with possible packet relflections and cannot figure out the cause. I am running tunnel.py on two USRP2s that are cabled together with a 20dB attenuator between them. The settings I am using on both sides for tunnel.py are: Tx Gain: 15 dB Rx Gain: 10 dB Carrier Threshold: -80 Rx Tunnel Freq: 400 MHz Modulation: GMSK Bit Rate: 1Mb/sec When I use VLC to stream a video from computer A to computer B over the USRP link it works ok but there are alot of reflected packs being recorded by computer A. The same thing happens when I try to stream from computer A to computer B. This also occurs when I use iperf to test the link. Strangely, though there are NO reflected packets when I ping between the computers. Below is a paste of some of the output from computer A. I put in a timestamp on the left of when events occur. I also put in an explicit statement to print out when tunnel is backing off and for how long. I added sequence number to make it blatantly obvious that the computer is receiving its own packet. Any packet with a sequence number beginning originates from computer A. If the packet originated from computer B it shows up at RX_packet=none. As it shows computer A is receiving its own packets! [ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186 [ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310 [ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021 [ 63.61 ] Backing off for 0.001 sec [ 63.62 ] Backing off for 0.002 sec [ 63.62 ] Backing off for 0.004 sec [ 63.63 ] Backing off for 0.008 sec [ 63.64 ] Backing off for 0.016 sec [ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448 [ 63.66 ] Backing off for 0.032 sec [ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186 [ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310 [ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448 [ 63.67 ] Backing off for 0.064 sec [ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021 [ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70 [ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150 [ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248 [ 63.72 ] Backing off for 0.001 sec [ 63.72 ] Backing off for 0.002 sec [ 63.73 ] Backing off for 0.004 sec [ 63.74 ] Backing off for 0.008 sec [ 63.75 ] Backing off for 0.016 sec [ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70 [ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448 [ 63.76 ] Backing off for 0.032 sec [ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150 [ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448 [ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248 [ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566 [ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987 [ 63.78 ] Backing off for 0.001 sec [ 63.79 ] Backing off for 0.002 sec [ 63.79 ] Backing off for 0.004 sec [ 63.79 ] Backing off for 0.008 sec [ 63.8 ] Backing off for 0.016 sec [ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566 [ 63.82 ] Backing off for 0.032 sec [ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448 [ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987 [ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321 [ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855 [ 63.84 ] Backing off for 0.001 sec [ 63.84 ] Backing off for 0.002 sec [ 63.85 ] Backing off for 0.004 sec [ 63.85 ]
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
On 10/31/2011 06:01 PM, Tuan (Johnny) Ta wrote: I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread. My setting: USRP2 XCVR2450 Ubuntu 10.04 (32bit) The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply. I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis. Can anyone help me? Thank you, Johnny We used to have this problem back in the day with packet-radio, using analog FM transceivers--they were often notoriously sluggish in turning around the TX/RX logic. You might try zero-stuffing the TX frames--that's basically what we did back in the day. Although the XCVR2450 short turn around fairly quickly, it's not infinitely quick. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
Marcus, What do you mean my zero-stuffing the TX frames? And how would it help with the turn-around time of the XCVR2450 daughterboard? Do you mean I should transmit a zero-filled packet before any real packet, so that the receiving side (A in my scenario) has time to switch back to receiving before the real packet arrives? Johnny On Mon, Oct 31, 2011 at 6:22 PM, Marcus D. Leech mle...@ripnet.com wrote: ** On 10/31/2011 06:01 PM, Tuan (Johnny) Ta wrote: I have been running into problems using tunnel.py as well so instead of creating a new post I thought I'll just continue this thread. My setting: USRP2 XCVR2450 Ubuntu 10.04 (32bit) The problem I have is that after running tunnel, whenever I do ping, my system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts an ARP packet to find the MAC address of B's IP. B gets the ARP request, immediately sends an ARP response back to A with its MAC. However, in my system, A never gets the ARP reply. I seriously can't think of a reason for this. I can guess a possible cause is that B sends the ARP reply too quickly that A doesn't have enough time to go from transmit mode to receive mode (XCVR2450 is a half-duplex daughterboard). But I don't know how to verify this hypothesis. Can anyone help me? Thank you, Johnny We used to have this problem back in the day with packet-radio, using analog FM transceivers--they were often notoriously sluggish in turning around the TX/RX logic. You might try zero-stuffing the TX frames--that's basically what we did back in the day. Although the XCVR2450 short turn around fairly quickly, it's not infinitely quick. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
On 10/31/2011 06:40 PM, Tuan (Johnny) Ta wrote: Marcus, What do you mean my zero-stuffing the TX frames? And how would it help with the turn-around time of the XCVR2450 daughterboard? Do you mean I should transmit a zero-filled packet before any real packet, so that the receiving side (A in my scenario) has time to switch back to receiving before the real packet arrives? The transmit side assumes that the combination of RX-to-TX and TX-to-RX transition experienced by both sides is non-zero. So, you get the transmit side to simply send some idle 0s, and *then* the actual start-of-frame data, etc. What happens in these situations in my experience is that the start-of-frame gets missed during the switchover interval. So if the transmit side sends zeros (or, really, anything other than the start-of-frame sequence) for a little while after commencing a transmit burst, you're less likely to run into TX-to-RX transition issues. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue
I have been troubleshooting an issue with possible packet relflections and cannot figure out the cause. I am running tunnel.py on two USRP2s that are cabled together with a 20dB attenuator between them. The settings I am using on both sides for tunnel.py are: Tx Gain: 15 dB Rx Gain: 10 dB Carrier Threshold: -80 Rx Tunnel Freq: 400 MHz Modulation: GMSK Bit Rate: 1Mb/sec When I use VLC to stream a video from computer A to computer B over the USRP link it works ok but there are alot of reflected packs being recorded by computer A. The same thing happens when I try to stream from computer A to computer B. This also occurs when I use iperf to test the link. Strangely, though there are NO reflected packets when I ping between the computers. Below is a paste of some of the output from computer A. I put in a timestamp on the left of when events occur. I also put in an explicit statement to print out when tunnel is backing off and for how long. I added sequence number to make it blatantly obvious that the computer is receiving its own packet. Any packet with a sequence number beginning originates from computer A. If the packet originated from computer B it shows up at RX_packet=none. As it shows computer A is receiving its own packets! [ 63.61 ] Tx: seq_no = 100054 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100055 | len(payload) = 186 [ 63.61 ] Tx: seq_no = 100056 | len(payload) = 1310 [ 63.61 ] Tx: seq_no = 100057 | len(payload) = 1448 [ 63.61 ] Tx: seq_no = 100058 | len(payload) = 1021 [ 63.61 ] Backing off for 0.001 sec [ 63.62 ] Backing off for 0.002 sec [ 63.62 ] Backing off for 0.004 sec [ 63.63 ] Backing off for 0.008 sec [ 63.64 ] Backing off for 0.016 sec [ 63.64 ] Rx: ok = True | seq_no = 100054 | len(payload) = 1448 [ 63.66 ] Backing off for 0.032 sec [ 63.64 ] Rx: ok = True | seq_no = 100055 | len(payload) = 186 [ 63.66 ] Rx: ok = True | seq_no = 100056 | len(payload) = 1310 [ 63.66 ] Rx: ok = True | seq_no = 100057 | len(payload) = 1448 [ 63.67 ] Backing off for 0.064 sec [ 63.67 ] Rx: ok = True | seq_no = 100058 | len(payload) = 1021 [ 63.72 ] Tx: seq_no = 100059 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100060 | len(payload) = 70 [ 63.72 ] Tx: seq_no = 100061 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100062 | len(payload) = 150 [ 63.72 ] Tx: seq_no = 100063 | len(payload) = 1448 [ 63.72 ] Tx: seq_no = 100064 | len(payload) = 248 [ 63.72 ] Backing off for 0.001 sec [ 63.72 ] Backing off for 0.002 sec [ 63.73 ] Backing off for 0.004 sec [ 63.74 ] Backing off for 0.008 sec [ 63.75 ] Backing off for 0.016 sec [ 63.74 ] Rx: ok = True | seq_no = 100060 | len(payload) = 70 [ 63.75 ] Rx: ok = True | seq_no = 100061 | len(payload) = 1448 [ 63.76 ] Backing off for 0.032 sec [ 63.75 ] Rx: ok = True | seq_no = 100062 | len(payload) = 150 [ 63.76 ] Rx: ok = True | seq_no = 100063 | len(payload) = 1448 [ 63.76 ] Rx: ok = True | seq_no = 100064 | len(payload) = 248 [ 63.78 ] Tx: seq_no = 100065 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100066 | len(payload) = 566 [ 63.78 ] Tx: seq_no = 100067 | len(payload) = 1448 [ 63.78 ] Tx: seq_no = 100068 | len(payload) = 987 [ 63.78 ] Backing off for 0.001 sec [ 63.79 ] Backing off for 0.002 sec [ 63.79 ] Backing off for 0.004 sec [ 63.79 ] Backing off for 0.008 sec [ 63.8 ] Backing off for 0.016 sec [ 63.8 ] Rx: ok = True | seq_no = 100066 | len(payload) = 566 [ 63.82 ] Backing off for 0.032 sec [ 63.82 ] Rx: ok = True | seq_no = 100067 | len(payload) = 1448 [ 63.82 ] Rx: ok = True | seq_no = 100068 | len(payload) = 987 [ 63.84 ] Tx: seq_no = 100069 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100070 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100071 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100072 | len(payload) = 321 [ 63.84 ] Tx: seq_no = 100073 | len(payload) = 1448 [ 63.84 ] Tx: seq_no = 100074 | len(payload) = 855 [ 63.84 ] Backing off for 0.001 sec [ 63.84 ] Backing off for 0.002 sec [ 63.85 ] Backing off for 0.004 sec [ 63.85 ] Backing off for 0.008 sec [ 63.86 ] Backing off for 0.016 sec [ 63.87 ] Backing off for 0.032 sec [ 63.86 ] Rx: ok = True | seq_no = 100070 | len(payload) = 1448 [ 63.89 ] Rx: ok = True | seq_no = 100071 | len(payload) = 1448 [ 63.89 ] Rx: ok = True | seq_no = 100072 | len(payload) = 321 [ 63.89 ] Rx: ok = True | seq_no = 100073 | len(payload) = 1448 [ 63.9 ] Backing off for 0.064 sec [ 63.9 ] Rx: ok = True | seq_no = 100074 | len(payload) = 855 Does anyone have any idea why this could be occurring? I thought maybe it would be a physical reflection but dont understand why ping packets would not be reflected in that case. Thanks, Dave___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: tunnel.py MAC address
Here is what you need to do SIOCSIFHWADDR = 0x8924 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) ioctl(s, SIOCSIFHWADDR, struct.pack(16sH6s, ifname, socket.AF_UNIX, hwaddr)) Andrew On 03/24/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Message: 11 Date: Thu, 24 Mar 2011 06:45:51 -0700 (PDT) From: David Bartondavid.barto...@yahoo.com Subject: [Discuss-gnuradio] tunnel.py MAC address To:discuss-gnuradio@gnu.org Message-ID:230441.44013...@web120209.mail.ne1.yahoo.com Content-Type: text/plain; charset=iso-8859-1 When I run tunnel.py and configure the grX interface IP address I noticed using ifconfig that a seemingly random MAC address is assigned to the gr interface. Does ayone know if there is any logic to how the address is created? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM tunnel.py HELP REQUIRED
To follow up with Chuck's question, I'm also having problem running tunnel using OFDM. The individual transmissions between the 2 USRPs were fine (albeit that I had to manually adjust the center frequency of 1 USRP (A) to cope with the frequency offset). I had B operating at 2412MHz and A at 2411.96MHz. The 40kHz offset was figured out by running usrp_fft on A while B is transmitting at 2412MHz. My reasoning for the need of manually adjust A's center frequency is that the synchronization block implemented right now can't track the offset that large. The current synchronization algorithm is due to Schmidt and Cox. I had gone through their paper but didn't find any limit to when the algorithm starts to break. I did some calculation to find the relationship of the offset to the subcarrier spacing. The DAC runs at 128MSps, I have interpolation = 128 (lowering this gives me overrun, I have a duo-core 1.66GHz laptop with 2.5GB of RAM). So my bandwidth is 128/128 = 1MHz. If the FFT length is 512 then the subcarrier spacing is 1000/512 = 1.95kHz. 40kHz offset would be 20.48 subcarrier spacing. If the FFT length is 32 then the subcarrier spacing is 1000/32 = 31.25kHz. 40kHz offset would be 1.28 subcarrier spacing. I don't know the significances of those numbers yet. Hopefully someone with better knowledge of OFDM synchronization can shred some lights. So USRP A can send to B, and B can send to A. But tunnel wouldn't work. This really puzzles me. The *BIG QUESTION* that I want to know is that whether anyone has had tunnel to work with OFDM. So that I can zero out the possibility of software bugs in tunnel.py. Thank you very much, Tuan On Fri, Jul 9, 2010 at 3:34 AM, chuck lorres chucklor...@hotmail.comwrote: Hi, For past one week I have been trying to run tunnel.py in ofdm folder. I have successfully run tunnel.py in digital folder as well as benchmark_ofdm_*.py with 0 packet loss. I have tried different set of parameter settings but to no avail. If any body has successfully ran the tunnel.py in ofdm folder, please help me out. I would request the senior members of this forum to guide me in solving this issue. Thank you. Regards, Chuck. -- Hotmail: Free, trusted and rich email service. Get it now.https://signup.live.com/signup.aspx?id=60969 ___ 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] OFDM tunnel.py HELP REQUIRED
Hi,For past one week I have been trying to run tunnel.py in ofdm folder. I have successfully run tunnel.py in digital folder as well as benchmark_ofdm_*.py with 0 packet loss.I have tried different set of parameter settings but to no avail. If any body has successfully ran the tunnel.py in ofdm folder, please help me out. I would request the senior members of this forum to guide me in solving this issue.Thank you.Regards,Chuck. _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About tunnel.py
Hello Juan, according to the FAQ ( http://gnuradio.org/redmine/wiki/1/UsrpFAQGen http://gnuradio.org/redmine/wiki/1/UsrpFAQGen ): u = USRP a = audio (sound card) O = overrun (PC not keeping up with received data from usrp or audio card) U = underrun (PC not providing data quickly enough) uOuO == USRP overrun (USRP samples dropped because they weren't read in time I don't know what B means. Juan Quiroz-2 wrote: I'm trying to connect two computers using tunnel.py example but it fails with a message uO, I'm working with Ubuntu 9.04, openSUSE 11.1 and GNU radio 3.2.2. Everything was fine when I did it with GNU radio 3.1.3 and both computers with openSUSE 11.1Please can somebody tell me what uO means? specially that B JhonQ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/About-tunnel.py-tp28638207p28681357.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About tunnel.py again
I'm trying to connect two computers using tunnel.py example but it fails with a message uO, I'm working with Ubuntu 9.04, openSUSE 11.1 and GNU radio 3.2.2. Everything was fine when I did it with GNU radio 3.1.3 and both computers with openSUSE 11.1Please can somebody tell me what means? JhonQ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About tunnel.py again
On Tue, May 25, 2010 at 10:03:32AM -0700, Juan Quiroz wrote:
I'm trying to connect two computers using tunnel.py example but it fails
with a message uO, I'm working with Ubuntu
9.04, openSUSE 11.1 and GNU radio 3.2.2. Everything was fine when I did
it with GNU radio 3.1.3 and both computers with openSUSE 11.1Please can
somebody tell me what means?
JhonQ
A quick look at the code reveals that it means that the transmitter
has backed off because it detected carrier.
while 1:
payload = os.read(self.tun_fd, 10*1024)
if not payload:
self.tb.send_pkt(eof=True)
break
if self.verbose:
print Tx: len(payload) = %4d % (len(payload),)
delay = min_delay
while self.tb.carrier_sensed():
sys.stderr.write('B')
time.sleep(delay)
if delay 0.050:
delay = delay * 2 # exponential back-off
self.tb.send_pkt(payload)
Try changing the carrier threshold using the -c command line option.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About tunnel.py
I'm trying to connect two computers using tunnel.py example but it fails with a message uO, I'm working with Ubuntu 9.04, openSUSE 11.1 and GNU radio 3.2.2. Everything was fine when I did it with GNU radio 3.1.3 and both computers with openSUSE 11.1Please can somebody tell me what uO means? specially that B JhonQ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] about tunnel.py
On Mon, Apr 26, 2010 at 8:57 PM, lishan...@126.com wrote: Thank you for you answer. Do you mean I can not achieve the goal by modifying its softare code beause of hardware restriction ? I have nothing to do except using more usrps?Thank you! You cannot use two instances to tunnel.py to create two network interfaces with a single usrp. One could, potentially, modify a single instance of tunnel.py to configure a single usrp with two daughterboards to support two network interfaces. I don't believe that this has ever been attempted though. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] about tunnel.py
Hi all, I want to use tunnel.py to make a usrp with two daughter boards work as two pieces of wireless cards. The first time I run tunnel.py, it works well, and generate gr0. But when I run tunnel.py for the second time (in another terminal) to configure the other daughter board, it turned out error Unable to find usrp1. Is it possible to generate two wireless cards with only one usrp with two doughter boards instead of with two usrps? If it is, what should I do? Thank you! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] about tunnel.py
Hi all, I want to use tunnel.py to make a usrp with two daughter boards work as two pieces of wireless cards. The first time I run tunnel.py, it works well, and generate gr0. But when I run tunnel.py for the second time (in another terminal) to configure the other daughter board, it turned out error Unable to find usrp1. Is it possible to generate two wireless cards with only one usrp with two doughter boards instead of with two usrps? If it is, what should I do? Thank you! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about tunnel.py
2010/4/26 lishan_wh lishan...@126.com: Hi all, I want to use tunnel.py to make a usrp with two daughter boards work as two pieces of wireless cards. The first time I run tunnel.py, it works well, and generate gr0. But when I run tunnel.py for the second time (in another terminal) to configure the other daughter board, it turned out error Unable to find usrp1. Is it possible to generate two wireless cards with only one usrp with two doughter boards instead of with two usrps? If it is, what should I do? No. At least not with the current implementation. The first run of tunnel.py opens up the usrp connection and any subsequent instances will fail since the usrp is already in use. The daughterboards are configured through the usrp interface, so you can't manipulate them independently from different programs. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re:Re: [Discuss-gnuradio] about tunnel.py
Thomas， Thank you for you answer. Do you mean I can not achieve the goal by modifying its softare code beause of hardware restriction ? I have nothing to do except using more usrps?Thank you! lishan_whbrbr在2010-04-26 21:55:57，Thomas Tsou tt...@vt.edu 写道： 2010/4/26 lishan_wh lishan...@126.com: Hi all, I want to use tunnel.py to make a usrp with two daughter boards work as two pieces of wireless cards. The first time I run tunnel.py, it works well, and generate gr0. But when I run tunnel.py for the second time (in another terminal) to configure the other daughter board, it turned out error Unable to find usrp1. Is it possible to generate two wireless cards with only one usrp with two doughter boards instead of with two usrps? If it is, what should I do? No. At least not with the current implementation. The first run of tunnel.py opens up the usrp connection and any subsequent instances will fail since the usrp is already in use. The daughterboards are configured through the usrp interface, so you can't manipulate them independently from different programs. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] modify tunnel.py to supprot usrp2
Hello, When I modified the code of tunnel.py, I met a problem. I want to direct use the eth0 interface, not add a gr0. But there was no device, /dev/eth0, dose anybody has the experience. Can I open eht0?? BTW, dose anybody know the relationship between BER and sensitivity. The word, sensitivity, comes from iwconfig command. Thank for your help. ^_^ -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] port tunnel.py from usrp to usrp2
Dear all: I want to run tunnel.py by USRP2. What sould I do? I trace the tunnel.py code. Do I modify the portion of USRP initialing?? The usrp_swig.py and the usrp2.py is different. The following information is my developmental environment: OS:Fedora 2.6.27.15-170.2.24.fc10.i686.PAE Gnu radio: the latest version(I download on 2009.03.02) Hardware: USRP2 Thanks for your help. Shih-Shen -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] port tunnel.py from usrp to usrp2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shih-shen Lu wrote: Dear all: I want to run tunnel.py by USRP2. What sould I do? I trace the tunnel.py code. Do I modify the portion of USRP initialing?? The usrp_swig.py and the usrp2.py is different. The following information is my developmental environment: OS:Fedora 2.6.27.15-170.2.24.fc10.i686.PAE Gnu radio: the latest version(I download on 2009.03.02) Hardware: USRP2 Thanks for your help. Shih-Shen This should get you started: http://www.nabble.com/Modifications-in-benchmark_rx.py-for-USRP2-td22234620.html To warn you - I don't recall if I got the transmit-side of benchmark (and therefore tunnel.py) working properly with my USRP2. But you can see the changes required for talking to a USRP2 instead of USRP1. Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrV2dgfOzzR5bXIgRAnRMAJ9ASslY0wRpBbZvChruNR4yNKKBKQCeKKqI 9Xx5Dg9WJGxqX9oTl/f3gWg= =3osc -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
