Re: [Discuss-gnuradio] gnuradio and android

[Albin Stigö]

It would definitely be a great thing is GRC was slightly more language agnostic!

On Thu, Jul 30, 2015 at 6:21 PM, Tom Rondeau <address@hidden> wrote:
> 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
>>
>>
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>