Hello OsmocomBB list members,
To shortly introduce myself, i am a sysadmin with much spare time and a Motorola C115 mobile phone.
I came to this place after watching a recording of the OsmocomBB talk at the 27c3. That really started my interest on opensource GSM.
After reading the wikipages and the mailing list archives i downloaded the sources and had a fully compiling OsmocomBB setup within a few hours.
Great work!
After slaying some headphonecables and an usbcable i hooked my c115 onto the serialport of my pc and it booted out of the box!
Since i am neither a programmer nor an electronic engineer i thought about what i could be interested in doing that contrbiutes to OsmocomBB. (Learning a little C has not hurt too many people i think. so i am on it.)
I didnt find it at http://bb.osmocom.org/trac/wiki/AreasOfWork but in the Mailinglistarchives of April-2010 i stumbled upon Christian Vogels post "Subject: PATCH: 5x8 font". After some manual patching i made it to compile the demo app (Printing all available characters in the font from upper left corner down to the bottom. Now that looked allmost like a phone :)
It seems like there have not been any follow ups on proportional fonts and the remaining ascii characters as well as the possibility to view different sizes of fonts on the screen.
Because there is not much to see on the C115 and there is no navigationsystem of any kind implemented in the compal_e88 firmware
I typed together a ericsson clone menu structure with a total of 330 menuitems (transations english to german allmost finished) to have something to display once the proportional 5x8 fonts are finished.
now i would continue to write a menu action handler that checks if a navigation key is pressed if a entry in the menu is selected lets look if there is a PhoneMenu "muid" with the siblings "suid" the menu is drawn. if it is a sibling only a switch case list where all actions get caught and processed will handle it.
Well, what do you think about that? Should it be built in another way? Am i to early in typing menue structures while the whole "rendering" is not sorted out in any way? Does anyone work on the fonts or a UI?
I really am not able judge whether a nested structure monster like this really is the right solution. What it definitly is it is easy to read understand and extend. at least for me ;)
if someone wants it i can post the complete menu (~1200 lines) somewhere.
Best wishes, Rade
Below are some snipplets of the things i allready did:
...sniplets...
struct PhoneMenu {  int muid; /* menu uid */  const char* menuLabel_en; /* menu name, english */  const char* menuLabel_de; /* menu name, german */  char siblings; /* amount of siblings within the menu */  struct PhoneMenuSibling pms[]; /* nested structure below */ };
struct PhoneMenuSibling {  int suid; /* sibling uid */  const char* siblingLabel_en; /* label in english */  const char* siblingLabel_de; /* label in german */ };
....
A Menu looks like this:
struct PhoneMenu menu = /* the startscreen */ { 0, "Main Menu", /* menu label */ "Hauptmenü", /* menu label in german language */ 6, /* 6 items in the list below */ { {1, "Phonebook", "Telefonbuch"}, {2, "Messages", "Nachrichten"}, {3, "Call information", "Anrufinformation"}, {4, "Active call", "Aktive Verbindung"}, {5, "Settings", "Einstellungen"}, {6, "Extras", "Extras"} } };
struct PhoneMenu menu_phone_book = { 1, "Phone book", "Telefonbuch", 10, { {11, "Call Contact", "Kontak Anrufen"}, {12, "Add Contact", "Kontakt hinzufügen"}, {13, "Edit Contact", "Kontakte bearbeiten"}, {14, "Business Cards", "Visitenkarten"}, {15, "Call from SIM", "Adresse aus SIM"}, {16, "Groups", "Gruppen"}, {17, "Calling Cards", "Rufkarten"}, {18, "Options", "Optionen"}, {19, "Memory status", "Speicherverbrauch"} {10, "Special numbers", "Spezialnummern"} } };
.......
struct PhoneMenu menu_phone_book_business_cards_receive = { 143, "Receive", "empfange Visitenkarte", 2, { {1431, "Via Infrared", "via Infrarot"}, {1432, "Via Bluetooth", "via Bluetooth"} } };
Hello Rade,
It seems like there have not been any follow ups on proportional fonts and the remaining ascii characters as well as the possibility to view different sizes of fonts on the screen.
There has been a followup on 2010-10-11, which is http://lists.osmocom.org/pipermail/baseband-devel/2010-October/000665.html
This will give you a pixel-addressable framebuffer on the C123 and C155, with a choice of fonts to choose from and can draw lines and boxes.
Unfortunately this is not too useful these days, because the stack currently runs separated into layer1 (on the phone) and mobile (on the host pc), so that the indication of the loaded firmware is more or less sufficient.
Furthermore, the "nicer" fonts need quite a lot of memory, and most people still run the firmware from RAM, so memory is a scarce resource, for little gain. (in Flash the fonts wouldn't really
But I also think that some kind of user-amusement wouldn't be that bad, so please feel free to elaborate on what I've done last year.
Greetings,
Chris
Hello Christian,
On Mon, 07 Feb 2011 21:16:08 +0100 "Christian Vogel" vogelchr@vogel.cx wrote:
Hello Rade,
It seems like there have not been any follow ups on proportional fonts and the remaining ascii characters as well as the possibility to view different sizes of fonts on the screen.
There has been a followup on 2010-10-11, which is http://lists.osmocom.org/pipermail/baseband-devel/2010-October/000665.html
This looks great! Shame on me for missing this. Ill dedicate my next weekenend to getting into this.
Id like to rephrase my previous post regarding followup on the ui to: There has been a lot of progress on the GUI and fonts.
This will give you a pixel-addressable framebuffer on the C123 and C155, with a choice of fonts to choose from and can draw lines and boxes.
Just perfect! Cant wait to make those pixels talk. Ill try to get a c155 phone at the fleamarkets to also have a color lcd device for testing.
Unfortunately this is not too useful these days, because the stack currently runs separated into layer1 (on the phone) and mobile (on the host pc), so that the indication of the loaded firmware is more or less sufficient.
Thats true, but i for myself hope that one day the layer23 code is moved into the phone. At that time i would really like to have a tested, accepted in short usable UI on th osmocomBB compal phones.
Furthermore, the "nicer" fonts need quite a lot of memory, and most people still run the firmware from RAM, so memory is a scarce resource, for little gain. (in Flash the fonts wouldn't really
Well this for shure will not be the case anymore if layer23 is running on the arm7tdmi. Until now i too have not written a single bit to the flash of the phone because of my fear of bricking it but i guess i will get over it soon since as far as i understand, besides removing the bootloader and therefore making the device inaccessable, not much bad can happen.
But I also think that some kind of user-amusement wouldn't be that bad, so please feel free to elaborate on what I've done last year.
Hopefully i didnt underestimate the task too much and am able to contribute a bit osmocomBB.
Thanks for the great work!
Best wishes, Rade
Greetings,
Chris
Thats true, but i for myself hope that one day the layer23 code is moved into the phone. At that time i would really like to have a tested, accepted in short usable UI on th osmocomBB compal phones.
I second this! Now that I know just how vulnerable cell phones are to all sorts of tricks, I very much would like to be toting around a phone with completely open firmware, and as soon as possible!
I'm not much help on the GSM stack, but maybe I can give some time over to helping on this.
Scott
Hello Scott,
On Tue, 8 Feb 2011 10:17:59 +0200 Scott Weisman sweisman@pobox.com wrote:
I'm not much help on the GSM stack, but maybe I can give some time over to helping on this.
Great! Im going to look into the new fb based display driver and all the other GUI goodies done by Christian on this weekend.
Best wishes, Rade
Hi Rade, list,
On 07/02/2011 18:45, Rade Girel wrote:
Well, what do you think about that? Should it be built in another way? Am i to early in typing menue structures while the whole "rendering" is not sorted out in any way? Does anyone work on the fonts or a UI?
well, I am currently working on a UI, but not on the same level. On an Openmoko Freerunner, the application processor can control the baseband one itself, while taking care of the interface.
I happen to have written a Gtk+-based GSM daemon and telephony application, which I have recently modified to function independently of the GSM backend in use. You can find this work in the "khorben-phone" branch of the DeforaOS project, found at http://www.defora.org/:
You can obtain the source code this way: $ cvs -d:pserver:anonymous@anoncvs.defora.org:/Data/CVS co -r \ khorben-phone DeforaOS/Apps/Desktop/src/Phone (you will also need the "libSystem" library from the same project to compile it: $ cvs -d:pserver:anonymous@anoncvs.defora.org:/Data/CVS co \ DeforaOS/System/src/libSystem
So technically now, "all that is left" is to write a plug-in for osmocom in "src/modems". As of the current way the project is implemented, it seems like this plug-in would implement a telnet client and connect to port 4247 locally. I'll welcome suggestions on how to proceed otherwise in a more practical way :)
Last but not least, I had to rush to meet the submission deadline when I first heard about this possibility, but I have submitted this project for funding by the CELF forum: http://elinux.org/CELF_Open_Project_Proposal_2011 http://elinux.org/Add_Osmocore_support_to_the_DeforaOS_Phone_GSM_stack
Of course I have listed myself in the "Contractor candidates", but I expect development to be (primarily) funded through work in the Osmocom project itself, where I'll welcome anyone, and the most active current developers in particular, to add themselves here (or just ask me to get it done).
I hope taking this step sounds good to you all too, and will be good publicity whatever happens (eg whether being funded or not).
Cheers,
baseband-devel@lists.osmocom.org
-
Christian Vogel -
Pierre Pronchery -
Rade Girel -
Scott Weisman