Re: [Discuss-gnuradio] gnuradio and android

[Tom Rondeau]

On Thu, Jul 30, 2015 at 2:11 PM, Albin Stigö <address@hidden> wrote:

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

Well, GNU Radio only has two ways of running: C++ and Python where Python is generally the default. So "agnostic" isn't going to happen, nor is it really the right way to think about it. You'll always need to translate the GRC representation down to a language that we use. The main issue is to make sure that GRC has a generator for the languages, so if there every is a third of fourth way supported, it's "just" another generator class.

Tom

 

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
>

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio