[Mep-dev] Tuesday Challenge for 14 April 2009

[Michelle]

Hello everyone – thank you so much for all the great input on the question of Android!

I think that the concern that Philip raises about standard SDR software is valid, but we should also seriously consider Android. Here is why.

"Although Android is built on top of the Linux kernel, the platform has very little in common with the conventional desktop Linux stack. In fact, during a presentation at the Google IO conference, Google engineer Patrick Brady stated unambiguously that Android is not Linux." (http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-android-for-developers.ars)

Well, that sounds like a big strike against it. The article referenced above continues, 

“The problem with Google's approach is that it makes Android an island. The highly insular nature of the platform prevents Android users and developers from taking advantage of the rich ecosystem of existing third-party Linux applications. Android doesn't officially support native C programs at all, so it won't be possible to port your favorite GTK+ or Qt applications to Android. It's also not possible to run existing MIDP applications on Android because it uses an incompatible virtual machine. 

Other prominent mobile Linux platform initiatives have taken a very different approach and are making extensive use of existing desktop Linux technologies. Maemo, OpenMoko, ALP, MOTOMAGX, Moblin, and Qt Extended all provide some kind of portability glide path between the desktop and other mobile platforms. For example, it's trivially easy to port an existing GTK+ desktop application to Moblin, ALP, and Maemo devices. 

The downside of the GTK+ approach compared to Android is that the GTK+ application will have to be modified to accommodate the hardware capabilities, form factor, and toolkit deviations for each individual device. Android attempts to circumvent that problem by providing its own universal runtime and toolkit. It is too early to judge whether Android's approach is successful because the number of Android-based devices is still somewhat limited.”

It's my understanding that developing MEP upon embedded linux means we must necessarily develop for one architecture at a time. For example, the TI OMAP. 

My software design experience has been primarily low-level algorithm implementation on proprietary DSP architectures, where the narrowness and particularity of the work was worth it because of the volume of sales of the devices. Porting the software wasn’t even a consideration. 

So, what are some reasons for considering Android for MEP?

My feeling is that porting MEP to as many processers as possible should be a very strong consideration, and here is why. 

We don’t have the budget to buy large volumes of any one particular processor or modem. We don’t have fully staffed software teams for either TI OMAP or Atom 330, the two processors that are the strongest contenders to support MEP. Ending up with a command-line interface to a particular SDR attached to a development board is not the finish line. 

We want to make MEP easy to use. This final point shouldn’t be swept past without some emphasis. The feedback that we got from last year’s Dayton survey (done for AMSAT) was that making MEP fun and easy to use was very important to people that were highly likely to buy or assemble a MEP station. Most of these people are going to have certain expectations about usability and user interface. 

If we develop MEP as an embedded linux system, then how difficult is it to port it to another architecture? How difficult is it to produce the type of operator experience that something like Android enables? In the article above, I took notice of this line,

“For example, it's trivially easy to port an existing GTK+ desktop application to Moblin, ALP, and Maemo devices.”

Moblin caught my eye immediately after we got the Atom Smash up and running, but I haven’t investigated it more than reading their home page and realizing that it might be useful. If it’s true, then the reason I find value in Android – portability across many processors – can be found in embedded linux. I’m hoping that the list can help me out here and educate me on whether or not this is true. 

I’m not an Android expert by any means – I was introduced to it by Frank Brickle some months ago, and got an opportunity to run Android on BeagleBoard at the Embedded Systems Conference. The reason Android is worth discussion is because it already does a lot of what we want to do, and it’s open source. (http://source.android.com/download)

Android is, from an operator perspective, a radio UI. It supports drop-in applications with spiffy UI elements and a useful developer tool set. From the article above, 

“Android supplies a comprehensive and well-organized assortment of high-level APIs for building applications and leveraging the underlying functionality of the platform. The APIs provide an extremely high level of abstraction, which makes them relatively intuitive and easy to use.”

The application stack of Android is a new way of doing things. It needs study and if it shows promise, then we should learn from it. 

If the Open Handset Alliance (http://www.openhandsetalliance.com/) fails, or “turns evil” and wanders off into ProprietaryLand, there isn’t
anything stopping us from branching off and maintaining what works. Large companies with large amounts of communications markets at stake and large numbers of customers are making large bets on Android. This makes it well worth scrutinizing to make sure that we know what we’re getting into, or what we’re deciding to avoid. 

Android means a very high degree of portability and (ideally) a common developer experience across all sorts of different hardware. Android MEP would run as easily on TI OMAP as on the Atom as on the Snapdragon, etc. The applications would be written once, and could be written quickly, with uniform UI elements and uniform and stable interprocess communications.

Finally, this doesn’t necessarily have to be either/or. It can be both/and. A common air interface means that Mutant Android MEP can communicate with Mongrel Beagle MEP or Nuclear Waste MEP. 

I want people to coalesce around work they find interesting, and if there is critical mass to get an Android MEP off the ground, then I’ll help however I can. 

What I hear so far is that embedded linux is preferred by the active participants on mep-dev. Would Moblin (http://moblin.org/) fit the bill?

More soon!

-Michelle W5NYV

Potestatem obscuri lateris
nescis.


----- Original Message
----
From: Philip Balister
<philip at balister.org>
To:
mep-dev at uppermeadow.com
Sent: Wednesday, April 15,
2009 2:21:27 PM
Subject: Re: [Mep-dev]
Tuesday Challenge for 14 April 2009

Robert McGwier wrote:
>
http://venturebeat.com/2008/09/16/first-android-phone-to-hit-stores-on-oct-17-sprint-android-phone-coming-next-year/
> 
> I hardly think we are
likely to see the complete evaporation of this
> while cellular
telephone companies are actually using it.

My concern is it may be
difficult to build standard SDR software such as 
GNU radio on it. We need
to figure it out a bit more. I do know people 
much closer to Android so
I'll try and figure out what the deal is.

So far, I am just confused
:)

Philip