[prev in list] [next in list] [prev in thread] [next in thread]
List: gnuradio-discuss
Subject: Re: [Discuss-gnuradio] On tunnel.py
From: Alex Zhang <cingular.alex () gmail ! com>
Date: 2013-03-29 17:25:10
Message-ID: CA+FEAnc1tc7RWGyXhnhrsr+nFYEcjz1pHQUnYU19G9t6SD6XuA () mail ! gmail ! com
[Download RAW message or body]
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 <tom@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.*
[Attachment #3 (text/html)]
<div dir="ltr"><div style>Totally agree to stop using the tunnel.py!</div><div \
style><br></div><div style>Just want to add some my \
thoughts.</div><div><br></div>There is a fact that the main users of USRP/GNURadio \
are the students from universities.<div style> Firstly, these people lack the \
experience on the communications development, either in software designing or in \
wireless communications theory.</div><div style>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. </div> <div \
style><br></div><div style>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.</div> <div \
style>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. </div> <div style>Also, the GNURadio \
itself need more evolution on the demonstrative solutions of the communications, like \
the OFDM in improving.</div><div style><br></div><div style>And of course, this is a \
open source community. The GNURadio needs everyone's contribution, including both \
issues reports and new developments, new applications.</div> </div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 29, 2013 at 11:39 \
AM, Tom Rondeau <span dir="ltr"><<a href="mailto:tom@trondeau.com" \
target="_blank">tom@trondeau.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Please, everyone, listen up.<br> <br>
There's been a ton of traffic on the mailing list regarding tunnel.py<br>
(and I bet I know why). I want you all to pay close attention to what<br>
I'm going to say regarding how to get tunnel.py to work for you:<br>
<br>
Stop using tunnel.py.<br>
<br>
It's old. It hasn't had any significant work or updates in years.<br>
Meanwhile, we've made huge leaps in capabilities and features in GNU<br>
Radio. A lot has changed, including the switch to the UHD drivers,<br>
which also impacts how things work.<br>
<br>
You can do better. The stream tags and message passing system provide<br>
a significant amount of new capabilities that can help us make much<br>
better digital transceivers. Johnathan Corgan recently wrote to the<br>
mailing list discussing other projects working on improving these<br>
examples:<br>
<a href="https://lists.gnu.org/archive/html/discuss-gnuradio/2013-03/msg00014.html" \
target="_blank">https://lists.gnu.org/archive/html/discuss-gnuradio/2013-03/msg00014.html</a><br>
<br>
Take a look at the work that's been going into the OFDM examples<br>
lately. Martin Braun and Ben Reynwar have used stream tags effectively<br>
to provide information on packet boundaries and trigger conditions for<br>
receiver synchronization. And they've done it all in GRC so it's<br>
easier to understand the flowgraph, modify it, and hopefully even<br>
replace blocks. [1]<br>
<br>
Also, recognize that tunnel.py and the benchmark scripts are provided<br>
as /examples/. They were never meant nor installed as applications.<br>
They are there to help you understand how to put blocks together and<br>
interact with Python, C++, callback functions, OS tools, etc. etc. But<br>
they are not going to solve you digital transmission problems.<br>
<br>
GNU Radio is a platform to develop radio applications. You have to use<br>
it as a development tool, not an out-of-the-box solution.<br>
<br>
I say this because I want us to do better as a community. We've been<br>
held back for too long because people think that the benchmark and<br>
tunnel.py scripts are the final word in GNU Radio's digital<br>
communications capabilities. But that's what you are for! You can help<br>
us improve it, like Ben and Martin did with the OFDM work. It's not<br>
easy, but communications is not easy. In fact, it's very, very hard.<br>
<br>
Tom<br>
<br>
[1] There's still a bug in the new OFDM work. Marin, Johnathan C. and<br>
myself figured it out yesterday, but I'm still formatting the right<br>
way to patch it.<br>
<br>
_______________________________________________<br>
Discuss-gnuradio mailing list<br>
<a href="mailto:Discuss-gnuradio@gnu.org">Discuss-gnuradio@gnu.org</a><br>
<a href="https://lists.gnu.org/mailman/listinfo/discuss-gnuradio" \
target="_blank">https://lists.gnu.org/mailman/listinfo/discuss-gnuradio</a><br> \
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br>Alex,<div><i><font \
face="garamond, serif" size="4">Dreams can come true – just believe.</font></i></div> \
</div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic