On tunnel.py

GNU Radio
1

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 C. 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 B. and Ben R. 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.

2

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 R. [email protected] wrote:

Radio. A lot has changed, including the switch to the UHD drivers,
lately. Martin B. and Ben R. have used stream tags effectively

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
[email protected]
Discuss-gnuradio Info Page

–

Alex,
Dreams can come true just believe.

3

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 Z. wrote:

either in software designing or in wireless communications theory.

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 B.
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

4

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.