[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] On tunnel.py

From: Tom Rondeau
Subject: [Discuss-gnuradio] On tunnel.py
Date: Fri, 29 Mar 2013 12:39:20 -0400

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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]