LCA: Various topics from the mobile miniconf
| Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net. |
The Serval project accounted for a number of separate talks at linux.conf.au 2013, but it was not the only project focused on free software in mobile computing. Among the others making a showing were OpenPhoenux, which is an ongoing effort to build and support new motherboards for the venerable OpenMoko Freerunner phone, and Mozilla's Firefox OS, whose team had demonstration hardware in tow. But there were also several talks that dealt with that most mainstream of mobile Linux platforms, Android, although in offbeat ways—such as deploying cutting-edge digital radio modes like codec2 on commodity mobile handsets.
OpenPhoenux
Often, new mobile platform projects (such as Jolla with Sailfish OS)
spend a considerable amount of time searching for hardware partners
interested in building devices, but the Open Pheonux project does just
the opposite. It is plowing straight ahead at making its own phone
motherboards, with interested hackers committing to pre-orders of
small batches. The result of this approach is a more expensive
per-unit price, but the hardware reaches the community quickly. Neil
Brown presented a session explaining the goals of Open Phoenux and its
current status, with hints at what may be coming in the next few months.
In its day, the Openmoko Freerunner was an exceptional device; the hardware was open in addition to the software. But the last motherboards produced by Openmoko were made in 2009; enthusiasts have subsequently been forced to look for old stock on eBay or other second-hand markets—and even when found, the 2009-era hardware shows its age. OpenPhoenux offers a brand new motherboard that fits into the same case as the original Freerunner, but sports a faster CPU (a 1GHz ARM Cortex-A8), more RAM (512MB), a 3G-capable modem, and an assortment of new or updated sensors (GPS, FM transceiver, accelerometer, compass, gyroscope, and altimeter). In addition, the various sensors and components have shrunk enough in size since 2009 that there is even more room today, so the new motherboard can overcome limitations in the original Freerunner design, like the lack of stereo speakers.
The OpenPhoenux motherboard is called the GTA04, and it is currently in revision 4 (denoted as GTA04A4). Brown said there are about 300 of the motherboards in the wild, and users are running a variety of software environments on them (including the Replicant Android distribution, QtMoko, and a derivative of the original GTK+-based Openmoko software), with several users using the GTA04 as their primary phone. Brown devotes most of his time to making sure that the mainline Linux kernel runs on the GTA04, which he described as a work in progress. There are a number of missing drivers at the moment, including the FM transceiver and the altimeter, and there are other sensors which are simply tricky to figure out how to support. For example, he said, what is an accelerometer? In some senses, it is used as an input device, responding to the user's movement, but at the same time, in produces a constant stream of sensor data whether the user is actively using it or not. As a result, there are two interfaces that need to be supported: that of a standard input device, and that of an Industrial IO (IIO) device. The kernel's IIO subsystem has recently moved out of staging and into main, he said, but it is still overly complex and not great to work with.
Keeping the kernel running is a constant challenge, Brown said, as
there are always new bugs and old bugs reintroduced. He outlined a
dozen or so from the period between kernel 3.5 to 3.7, such as CPU
checks that incorrectly assume that cpu_is_omap34xx and
cpu_is_omap3630 are mutually exclusive conditions—which
they are not, as the GTA04 proves. There is also an ongoing struggle
to minimize power consumption on the device, which Brown described as
a nebulous challenge that touches many areas of the system at once and
can be hard to track down. " On the subject of soon-to-be-available phone hardware, Mozilla developer Ben Kero presented a
demonstration of Firefox OS running on the recently-announced
developer phones at the mobile
FOSS miniconf on Monday. Users have been able to run Firefox OS in a
simulated environment through an add-on
for quite some time, but seeing it running on actual devices is far
more compelling. The developer phones are modest compared to a
cutting edge Android device (the model on hand was the lower-end of
the two, with a 1GHz processor), but thanks to the demo it is clear to
see that Firefox OS is fast and responsive on them.
The developer phones are slated to be sold through Geekphone, a
company that specializes in unlocked, hackable phone hardware, but two
models is still not much of a selection. Several people in the
audience expressed interest in what other hardware devices Firefox OS
would be capable of running on. The good news is that Mozilla
evidently tracks the official builds of the CyanogenMod project, and
the Firefox OS build system automatically builds images for any device
supported by CyanogenMod 9 or later. Firefox OS uses the kernel and hardware adaptation from
CyanogenMod, Kero said, " Which is not to say that Android was a punching bag at the mobile
computing talks at LCA 2013; there were in fact several talks that
focused on Android specifically. But by and large, Android was seen
as the commodity test platform on which other, more interesting work
was based. Project
Grimlock, for example, is a port of the Rhino
JavaScript implementation to Android's Dalvik. Grimlock developer
Maksim Lin also presented a session on modifying Android to run as an
appliance-like operating system, like one might find in a kiosk or
digital sign: a single application, presenting a stripped down interface to the user.
As it turns out, running a kiosk-like appliance is relatively
straightforward, once one knows where to look for the undocumented
privileged APIs that Google apps routinely take advantage of. Lin
said that many of the API calls are visible when reading
through Android source, but that there are directives in the
documentation that hide them whenever the documentation is rendered to
HTML for display on a public web site. It was a thought-provoking
talk that might make one seriously consider reading the Android source
for the first time.
Pushing boundaries was a common theme outside of the mobile FOSS
miniconf as well. David
Rowe presented his recent
work on an extremely low-bitrate speech
codec called codec2 which he
has been developing for digital radio in the amateur-licensed HF and VHF bands. Codec2
can encode intelligible human speech in 1400 bits per second, which is
a fraction of the bitrate required by analog voice modes in amateur
radio. More importantly, it is significantly lower than the 2400 bits
per second needed by comparable proprietary codecs. Digital voice
modes in radio are a hot topic at the moment, and Rowe cautioned that
if proprietary offerings were allowed to be blessed into standards,
they would lock out open source, potentially for several decades to
come.
The good news is that Rowe's work on codec2 does appear to be
gaining traction with ham radio enthusiasts—and that, he said,
bodes well for its future, because ham radio groups are influential
with police, medical, and emergency services when the latter look to
establish standards. At the moment, codec2 is usable immediately with
Rowe's FreeDV, a cross-platform GUI
application. Rowe demonstrated FreeDV and compared samples encoded
with codec2 to other options. The FreeDV GUI is primarily used on
Windows, he said, because most ham radio users are Windows-based,
" A ham radio codec might sound out of place at first, considering
that ham radio is generally associated with hardware transceivers and
fixed stations, but therein lies the secret. Following Rowe's talk
was a demonstration by Joel Stanley, who showed codec2 running with
software defined radio (SDR) on an Android handset. The combination
of SDR and today's more powerful digital signal processors have the
potential to blur the lines significantly between previously-distinct
classes of communication, he said.
Stanley's demo was decidedly "homebrew" in appearance, but much of
that stems from limits imposed by trying to create a
device-vendor-neutral solution. He would have preferred to build a
dongle that could plug directly into an Android phone's microphone
port and receive HF radio, but that proved impossible because of the
incompatible pinouts used by different phone makers. Instead, Stanley
hooked the Android phone into a USB soundcard, but it did indeed
serve as a working codec2 receiver. As was the case with the Serval project talks
earlier in the event, it is intriguing to see free software used to
redefine something so widespread (and taken for granted) as a mobile
phone. It is a refreshing reminder that although Linux, through
Android, has made enormous waves in the mobile industry, those waves
do not stop at the edge of the app store.
If I see a green tinge on the
screen, at least I know it is a problem with the video
subsystem
", he said. Still, it is a fun exercise, he said, and
one that he learns from constantly. The next revision of the GTA04
boards (GTA04A5) is tentatively scheduled for March, if enough
preorders are made by that time. The exact price depends on the
number of orders, but is around the $500 range—there are plenty
of cheaper alternatives, he cautioned: the OpenPhoenux's primary
selling point is its complete openness. For now, that openness
extends beyond the motherboard: users have recently started making
their own alternative cases with 3d printers. In the future, some
project members are looking for ways to add hardware keyboards, or to
put the GTA04 into a tablet form factor with a bigger screen and battery.
Firefox OS and Android
we just tore out the Java
".
Perhaps predictably, a round of applause from the audience followed that comment.
Codec2 and digital voice radio
but we are converting them over.
"
Index entries for this article Conference linux.conf.au/2013
(Log in to post comments)
LCA: Various topics from the mobile miniconf
Posted Jan 31, 2013 8:01 UTC (Thu) by pabs (subscriber, #43278) [Link]
LCA: Various topics from the mobile miniconf
Posted Jan 31, 2013 12:28 UTC (Thu) by Catwich (guest, #89109) [Link]
LCA: Various topics from the mobile miniconf
Posted Feb 1, 2013 3:39 UTC (Fri) by pabs (subscriber, #43278) [Link]
LCA: Various topics from the mobile miniconf
Posted Feb 4, 2013 18:13 UTC (Mon) by ssam (guest, #46587) [Link]
(or are you just trolling?)
LCA: Various topics from the mobile miniconf
Posted Feb 6, 2013 0:28 UTC (Wed) by pabs (subscriber, #43278) [Link]
Even if there were a "completely" free phone, I would use a landline since there are more issues in the mobile phone space than just the devices themselves.
My point is that completely free systems are not achievable without replacing the current hardware industry with a new one. So one should always say "free enough" or "mostly free" instead of "completely free", at least until we do that.
LCA: Various topics from the mobile miniconf
Posted Jan 31, 2013 13:22 UTC (Thu) by robert_s (subscriber, #42402) [Link]
Bluetooth not an option?
Bluetooth instead of USB for Android interfacing
Posted Feb 3, 2013 12:21 UTC (Sun) by shenki (subscriber, #49715) [Link]
Yeah, I could have used Bluetooth. It would have reduced the complexity on the software side - no libusb - but I still would have used the NDK to build the codec and modem C code for Android, so it wouldn't have eliminated all of the native code.
It would have upped the complexity on the hardware side too. I would have to digitise the sound, so that means an ADC, and then interfaced that ADC with the Bluetooth device. That probably means another microcontroller, so more software to write. I'm also not sure if using Bluetooth Audio with a compression-less codec, as required to not distort the modem tones, would have been possible.
So yep, there were a bunch of other options for getting the radio signals off the air and into the phone, but a USB soundcard is a neat one for digtising and transporting the samples into the phone.
