Re: [Discuss-gnuradio] gnuradio and android

[Tom Rondeau]

On Thu, Jul 23, 2015 at 4:06 PM, Volker Schroer <address@hidden> wrote:

Tom,

thank you for your comments.

I agree to your objection that android is java based. But I think most of the gnuradio users  ( not developers ) are  not willing (or not able ) to code in java. gnuradio is python based at least to glue blocks together.

So my conclusion would be : either support python on android or to generate java code from grc.
But I'm unsure which of the many approaches of python for android will win, if any.

Nevertheless both would require gnuradio based on qt5.

I just ported some other qt4 based projects to qt5 and it wasn't really a great problem.
So I'd try contribute to migrate gnuradio to qt5.

But some questions: Do you intend to use PyQt4 ( which should support qt5, too) or do you plan PyQt5 ? And which would be the best gnuradio repository to start from ?

-- Volker

We plan on moving to QT5 and therefore support PyQT5. But this is the kind of change that will happen only with a new API release (3.8) because it's a change in the dependencies. We haven't made any moves on this, yet, but the plan is to switch over. Having done some QT5/QT4 work recently, it looks like the changes are fairly minimal and mostly semantic, so moving shouldn't be a huge deal from that perspective.

As for the Java/Python issue, we're working under the assumption that we split the design process between C++ and Java. GNU Radio in this case will exist in the C++ level and build using the Android NDK. The application is a fairly separate piece that provides the user interface such as controls and ways to visualize and interact with the radio.

The benefit of this approach is that we provide two domains of expertise. GNU Radio on one level and App development on the other level. App developers will be more used to Java and all of the tools, techniques, and libraries out there for Android are Java based. They need to know little to nothing about radio, and the radio developers need to know little to nothing about app design and development. This just needs a defined interface between the two domains. Currently, my GrTemplate assumes everything is going through the JNI. That's what my paper and demo at SRIF will be about in September.

However, we're moving to a new model to make this separation work better, but that's still under development. We want all command and control to go over ControlPort, and we'll be using ZMQ for any time we might need to stream data. ControlPort is great for snapshots of data and setting and getting of parameters in a flowgraph, but isn't designed for streaming. And we have some plans in mind for streamlining all of this to avoid dependency overload.

I have a ControlPort client setup done in Java now for Android apps, and I'll be pushing that out publicly soon (hopefully next week). This will allow us to easily bridge between app-space and gnuradio-space. The extra benefit of this is decoupling those two in general, not just for Android. The example app that I'm working on is a Performance Monitor tool for Android, so you can use your Android phone/tablet to connect to a running flowgraph elsewhere for monitoring purposes.

The main reason for this is to acknowledge that we're generally not the right people to be designing apps and user interfaces. I'd rather people who do that well work on that level, and so we are trying to remove for them the burden of having to work with GNU Radio. All they will hopefully need is the interfaces agreed upon between the radio designer and the app designer.

One of the main things that I see we need to have happen here is to have GRC produce C++ flowgraphs that will be able to fit into the model that the NDK needs.

Tom

 

 
 Am 23.07.2015 um 15:43 schrieb Tom Rondeau:

On Wed, Jul 22, 2015 at 4:47 PM, Volker Schroer <address@hidden> wrote:

Hi!
I watched the development of gnuradio for android. But I'm not very familiar with java, so I searched for a way to run gnuradio python scripts without or with little modifications on android.

I detected the python_for_android project and wrote some recipes to run gnuradio on android.

For those who are interested , see:
https://github.com/dl1ksv/python-for-android

At the moment I'm able to run things like

dial_tone or an fm receiver using the rtl dongle.

But there are a lot of things missing,  in particular a gui, support of fcd(pro+), etc.

So my question: Where to go from here: Introducing kivy to gnuradio for building gui's , or migrating qt5 ( a way I'd prefer )
Or is this only a nice finger exercise and of no special interest ?

Comments are welcome

-- Volker

Volker,

This is awesome that you're working on this and sharing your progress. Two things.

First, I think the QT5 way is where you'd want to go. We will be migrating there, anyways, likely for the 3.8 release. Having done some work recently on the gr_filter_design tool in QT4/5, it's not a huge amount of work to go between them. We'll likely do this work off the next branch for the next API version release. Anything you can contribute to this effort would be great.

As to Python, I'm skeptical how fruitful this path really is. If it's just for your own stuff, that's one thing, but Android is Java, love it or hate it. Trying to work too far away from their structure of work is dangerous, since they can decide at any moment to just kill certain efforts -- I'm a little afraid of this myself with our reliance on the NDK, even.

I'm in the boat of learning Java myself to work in this world. Easier that than trying to force other modes of operation onto this beast.

Tom