Re: [Discuss-gnuradio] gnuradio and android

[Volker Schroer]

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

 
 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