|| ||Harald Welte <laforge-AT-gnumonks.org> |
|| ||baseband-devel-AT-lists.osmocom.org |
|| ||Creating a real usable phone using OsmocomBB |
|| ||Sun, 11 Dec 2011 11:54:27 +0100|
|| ||Article, Thread
I've mentioned this before, and I keep getting back to it: With all the
great work that has been put into OsmocomBB, we are "at an arms lengh"
away from being able to create a true Free Software mobile phone.
We already have the hardware drivers, protocol stack and even the
'mobile' program which can be used for making and receiving voice calls
and sending/receiving SMS text messages on real GSM networks!
While the journey has been a lot of fun and everyone involved has
learned a lot, we have so far been catering mstly about "scratching our
own itch", i.e. implementing what we needed in order to satisfy our ego
and/or to implement the ideas we had regarding cellular security.
I believe we cannot miss the bigger opportunity here to put our code
into bigger use: To create something like a very simple GSM feature
When we look at various areas of computing like Operating Systems or Web
browsers, Free Software is not just "the hobby project catching up" with
the vendors of proprietary software. Free Software can compete.
In the cellular area, we have still not managed to even implement the
most basic GSM feature phone that existed 15 years ago using proprietary
software. We need to work on closing that gap. We need to show that a
small community of Free Software developers can actually implement what
teams of hundreds of engineers did in a proprietary software setting 15
years ago - despite all the lack of hardware documentation or any kind
of positive feedback from the cellular chipset, handset or operator
If we don't at least get a 2G GSM cellphone implemented now, it will
probably not happen before 2G networks become insignificant in large
parts of the world.
This is a call to all hands, please support this project!
== Technical aspects ==
I believe the first major decision is whether we focus on
1) the Openmoko FreeRunner / Neo1973 phones
* large screen for UI with bells and whistles
* lots of RAM and Flash, even script languages or compilation on the
device itself possible
* second processor doesn't require us to run stack + UI on once CPU
* easier debugging of UI
* various existing telephony middleware and phone dialer UI projects
of which hopefully one could be recycled
2) the Motorola/Compal C1xx phones
* many more phones available, even after our software is released
* lower cost of the individual phone
* less power consumption due to only one small ARM7 core
* smaller screen also means less fancy UI requirements
* full stack + UI needs to run on calypso (L2/L3) and we'd probably
some kind of RTOS like NuttX instead of our 'bare iron' code.
==== What we need in any case ====
* power management on the baseband processor through all of the stack
(though it's mostly a driver/L1 kind of thing)
== Summary / Opinion ==
It seems like running the OsmocomBB layer1 + 'mobile' as-is on the
Openmoko baseband + application processor might be the quicker road to
progress. Sure, the power consumption will be horrible as the AP will
have to be woken up for each and every SI message, neighbor cell
measurment or paging request that ew see comining in in our paging group
(even in idle mode). But then, there is always the negative impact of
using a relatively complex system, with two processors, a complex
software stack (Linux, X11, toolkit, etc.) on one of them, etc.
On the other hand, using the C1xx phones will result in a much more
widely available result. The phones can still be bought in batches of
1,000 units, and they are small enough for lots of people to carry
around. Furthermore, the battery lifetime is far beyond anything you
would ever be able to achieve on a power-hungry smartphone platform. I
believe it would be the "smart' solution, as it means we need to get
everything integrated, etc.
What does the community on this list think? Which way shoul we go?
But maybe the best thing is to actually stat working on the power
management aspects, as we will need them in both cases.
- Harald Welte <firstname.lastname@example.org> http://laforge.gnumonks.org/
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
to post comments)