[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] pktno ??!!
Hi Nathan, Thanks for your reply.I am not trying to find the pktno from benchmark_tx.py since i already tried doing that and it worked successfully. I have a file that i transmit using file source.Everything goes fine but i want to see the number of packets that i have been used to transmit my data. Thanks.. - Manjusha -- View this message in context: http://gnuradio.4.n7.nabble.com/pktno-tp40416p40419.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IEEE 802.11 a/g/p receiver
On Fri, Mar 29, 2013 at 3:08 AM, Bastian Bloessl bastian.bloe...@uibk.ac.at wrote: I'm currently working on an IEEE 802.11 a/g/p receiver and I think that meanwhile it has reached a state where others might be interested. With my desktop PC I can decode 20MHz bandwidth signals without any under runs. I tested it with quite a lot of 11a devices and also with 11p prototypes. Currently, it lacks a good algorithm for channel estimation and is thus limited to BSPK and QPSK. If you are interested you can find some more information on our website: http://www.ccs-labs.org/software/gr-ieee802-11/ This is good example of using stream tags and async messaging in a flowgraph. Nice work! Johnathan ___ 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
[Discuss-gnuradio] UHD source headers in next
Greetings, Trying to use usrp_source in a C++ application; it seems there is a mismatch between where the headers are installed and where they are supposed to be installed. The heqaders are installed in: include/gnuradio/gr_uhd/ but usrp_source.h has an include: #include uhd/api.h and gives compiler error. As far as I can see I'm using the latest code: v3.6.4.1-989-g2caaabf8 Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD source headers in next
On Fri, Mar 29, 2013 at 1:54 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Mar 29, 2013 at 1:49 PM, Alexandru Csete oz9...@gmail.com wrote: Greetings, Trying to use usrp_source in a C++ application; it seems there is a mismatch between where the headers are installed and where they are supposed to be installed. The heqaders are installed in: include/gnuradio/gr_uhd/ but usrp_source.h has an include: #include uhd/api.h and gives compiler error. As far as I can see I'm using the latest code: v3.6.4.1-989-g2caaabf8 Alex Yep, that's a mistake. I'll fix that now. Tom Done. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failures on Ubuntu 12.04 32-bit
I just tried the build on my 32-bit Ubuntu 10.04 VM and got the following error: [ 70%] Building CXX object gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc: In member function ‘bool gr::digital::packet_header_default::header_formatter(long int, unsigned char*, const std::vectorgr_tag_t, std::allocatorgr_tag_t )’: /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc:71: error: ‘memset’ was not declared in this scope make[2]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o] Error 1 make[1]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2 make: *** [all] Error 2 I added #include string.h to the top of the file, and it seems to have completed the build for that file. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 29, 2013, at 1:53 PM, Tom Rondeau t...@trondeau.com wrote: Ralph, Marcus, et al., I've pushed a fix just now for the 32-bit OS problem. See issue #529 for the problem/solution. Tom On Thu, Mar 28, 2013 at 5:02 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 28, 2013 at 3:56 PM, Marcus D. Leech mle...@ripnet.com wrote: Just tried to do a build now, from latest GIT. Attached is the make.log file. This Ubuntu 12.04 system is up-to-date as of today. Boost is 1.48 GCC is 4.6.3 Swig is 2.0.4 -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Working off-list with Ralph, we found the problem. Seems specific to 32-bit machines, though. I have to figure out what the right fix is, but I'll get to that soon. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failures on Ubuntu 12.04 32-bit
On Fri, Mar 29, 2013 at 2:23 PM, Tommy Tracy II tj...@virginia.edu wrote: I just tried the build on my 32-bit Ubuntu 10.04 VM and got the following error: [ 70%] Building CXX object gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc: In member function ‘bool gr::digital::packet_header_default::header_formatter(long int, unsigned char*, const std::vectorgr_tag_t, std::allocatorgr_tag_t )’: /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc:71: error: ‘memset’ was not declared in this scope make[2]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o] Error 1 make[1]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2 make: *** [all] Error 2 I added #include string.h to the top of the file, and it seems to have completed the build for that file. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 Tommy, Try adding: #include string.h Into packet_header_default.h and let me know how that works. Tom On Mar 29, 2013, at 1:53 PM, Tom Rondeau t...@trondeau.com wrote: Ralph, Marcus, et al., I've pushed a fix just now for the 32-bit OS problem. See issue #529 for the problem/solution. Tom On Thu, Mar 28, 2013 at 5:02 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 28, 2013 at 3:56 PM, Marcus D. Leech mle...@ripnet.com wrote: Just tried to do a build now, from latest GIT. Attached is the make.log file. This Ubuntu 12.04 system is up-to-date as of today. Boost is 1.48 GCC is 4.6.3 Swig is 2.0.4 -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Working off-list with Ralph, we found the problem. Seems specific to 32-bit machines, though. I have to figure out what the right fix is, but I'll get to that soon. 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] Build failures on Ubuntu 12.04 32-bit
That was successful. Build complete. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 29, 2013, at 2:26 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Mar 29, 2013 at 2:23 PM, Tommy Tracy II tj...@virginia.edu wrote: I just tried the build on my 32-bit Ubuntu 10.04 VM and got the following error: [ 70%] Building CXX object gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc: In member function ‘bool gr::digital::packet_header_default::header_formatter(long int, unsigned char*, const std::vectorgr_tag_t, std::allocatorgr_tag_t )’: /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc:71: error: ‘memset’ was not declared in this scope make[2]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o] Error 1 make[1]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2 make: *** [all] Error 2 I added #include string.h to the top of the file, and it seems to have completed the build for that file. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 Tommy, Try adding: #include string.h Into packet_header_default.h and let me know how that works. Tom On Mar 29, 2013, at 1:53 PM, Tom Rondeau t...@trondeau.com wrote: Ralph, Marcus, et al., I've pushed a fix just now for the 32-bit OS problem. See issue #529 for the problem/solution. Tom On Thu, Mar 28, 2013 at 5:02 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 28, 2013 at 3:56 PM, Marcus D. Leech mle...@ripnet.com wrote: Just tried to do a build now, from latest GIT. Attached is the make.log file. This Ubuntu 12.04 system is up-to-date as of today. Boost is 1.48 GCC is 4.6.3 Swig is 2.0.4 -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Working off-list with Ralph, we found the problem. Seems specific to 32-bit machines, though. I have to figure out what the right fix is, but I'll get to that soon. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] E1XX updates for dreaded Ssssssss
I have pushed updates into the E1XX package feeds that should resolve the S some people have been seeing. Here is a quick summary of the changes: * UHD 3.5.2 (includes CBX) * Updated kernel (fpga interface timing change, Add support for CIFS and Multicast) * GnuRadio 3.6.4.1 You can install these with: # opkg update # opkg upgrade while you are connected to the internet. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build failures on Ubuntu 12.04 32-bit
On Fri, Mar 29, 2013 at 2:34 PM, Tommy Tracy II tj...@virginia.edu wrote: That was successful. Build complete. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 Thanks. That fix has been pushed. Tom On Mar 29, 2013, at 2:26 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Mar 29, 2013 at 2:23 PM, Tommy Tracy II tj...@virginia.edu wrote: I just tried the build on my 32-bit Ubuntu 10.04 VM and got the following error: [ 70%] Building CXX object gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc: In member function ‘bool gr::digital::packet_header_default::header_formatter(long int, unsigned char*, const std::vectorgr_tag_t, std::allocatorgr_tag_t )’: /home/tjt7a/src/gnuradio/gr-digital/lib/packet_header_default.cc:71: error: ‘memset’ was not declared in this scope make[2]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o] Error 1 make[1]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2 make: *** [all] Error 2 I added #include string.h to the top of the file, and it seems to have completed the build for that file. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 Tommy, Try adding: #include string.h Into packet_header_default.h and let me know how that works. Tom On Mar 29, 2013, at 1:53 PM, Tom Rondeau t...@trondeau.com wrote: Ralph, Marcus, et al., I've pushed a fix just now for the 32-bit OS problem. See issue #529 for the problem/solution. Tom On Thu, Mar 28, 2013 at 5:02 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 28, 2013 at 3:56 PM, Marcus D. Leech mle...@ripnet.com wrote: Just tried to do a build now, from latest GIT. Attached is the make.log file. This Ubuntu 12.04 system is up-to-date as of today. Boost is 1.48 GCC is 4.6.3 Swig is 2.0.4 -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Working off-list with Ralph, we found the problem. Seems specific to 32-bit machines, though. I have to figure out what the right fix is, but I'll get to that soon. 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] UHD source headers in next
On Fri, Mar 29, 2013 at 6:56 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Mar 29, 2013 at 1:54 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Mar 29, 2013 at 1:49 PM, Alexandru Csete oz9...@gmail.com wrote: Greetings, Trying to use usrp_source in a C++ application; it seems there is a mismatch between where the headers are installed and where they are supposed to be installed. The heqaders are installed in: include/gnuradio/gr_uhd/ but usrp_source.h has an include: #include uhd/api.h and gives compiler error. As far as I can see I'm using the latest code: v3.6.4.1-989-g2caaabf8 Alex Yep, that's a mistake. I'll fix that now. Tom Done. Thanks for the quick fix. It works now. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py command not working
There's stuff missing in tunnel.py. The receiver has to return ICMP echo reply. Instead it writes to the tunnel socket. The packet will get to the kernel but will be promptly dropped as it has a source address that does not originate locally. Add code in tunnel.py to do an icmp echo reply. On Wed, Mar 27, 2013 at 11:54 AM, Nada ABDELKADER nada.abdelka...@etu.upmc.fr wrote: Hi, I tried to run tunnel.py on my machine (Ubuntu 11.10) with 2 USRPs (usrp1). from one side I launched: ./tunnel.py --tx-freq 2.4G --rx-freq 2.4001G -a=name=dev1 -A TX/RX --bitrate 500k -v then : sudo ifconfig gr0 192.168.200.1 from another terminal (on the same machine): ./tunnel.py --rx-freq 2.4G --tx-freq 2.4001G -a=name=dev0 -A TX/RX --bitrate 500k -v sudo ifconfig gr1 192.168.200.2 But when I run ping from both sides I see nothing displayed! Is what I've done correct? Is it possible to use one machine? What did I miss? Can you help me plz! Best Regards, Nada --**--** This message was sent using IMP, the Internet Messaging Program. __**_ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/**listinfo/discuss-gnuradiohttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- M. Ranganathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Check for gr-ctrlport
Is there a recommended or preferred way an application should check for the availability of control port? I can see some #ifdef GR_CTRLPORT in the gnuradio headers but that is only defined while compiling gnuradio. If there is a safe check I could perform at cmake time I would prefer that. Thanks in advance. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
