Re: Creating a real usable phone using OsmocomBB
Hello folks, Just my two cents: one factor that seems to be overlooked in the C1xx vs. GTA0x decision is the support for different GSM RF bands. From my reading of the OsmocomBB wiki, it appears that all those C1xx phones support only EGSM and DCS1800 bands, but not PCS1900. It seems like most current active developers are located in world regions where EGSM and DCS1800 bands are used, but in my area the only usable GSM band is PCS1900, or maybe GSM850 too: haven't been able to try the latter as I don't have any devices that support it. OTOH, my Neo Freerunner (which is currently doing shelf duty as a paperweight lacking functional source-enabled Calypso fw) supports the PCS1900 band in addition to EGSM and DCS1800. But if the community goes the C1xx route and produces GPL code that runs fully on the Calypso, no PC needed, does power mgmt and implements some UI on the Calypso-controlled LCD and keypad, I expect no difficulty with taking that code, replacing the Calypso-based UI with some simple protocol for interfacing with the UI over the modem UART (maybe not the same as the infamous AT command interface, but doing the same job on the same level of abstraction), and running it on my GTA02, hence I'm not complaining. As far as the power management etc advantages of the simpler phones without an application processor: does anyone know of any basic Leonardo-style phones which are like the famous C1xx, but support the PCS1900 band, are physically available, and documented no worse than C1xx in terms of the availability of schematics and docs for display and other non-Calypso components? The fact that C1xx phones can be bought in 1000 unit quantities is great news for those living in areas with EGSM/DCS1800 services, but doesn't do much good for those living in PCS1900/GSM850 lands... MS
I'm running a C117 on PCS1900 with no problems, in the USA. It was an old Tracfone I fixed the bootloader on and re-flashed. I have no idea if PCS1900 type C117 phones are widely available - but I do know they exist. Interestingly, I recently saw one in the local Walgreens for $20, brand new. Loki On Mon, Dec 12, 2011 at 9:12 AM, Michael Sokolov <msokolov@ivan.harhan.org> wrote:
Hello folks,
Just my two cents: one factor that seems to be overlooked in the C1xx vs. GTA0x decision is the support for different GSM RF bands. From my reading of the OsmocomBB wiki, it appears that all those C1xx phones support only EGSM and DCS1800 bands, but not PCS1900. It seems like most current active developers are located in world regions where EGSM and DCS1800 bands are used, but in my area the only usable GSM band is PCS1900, or maybe GSM850 too: haven't been able to try the latter as I don't have any devices that support it.
OTOH, my Neo Freerunner (which is currently doing shelf duty as a paperweight lacking functional source-enabled Calypso fw) supports the PCS1900 band in addition to EGSM and DCS1800.
But if the community goes the C1xx route and produces GPL code that runs fully on the Calypso, no PC needed, does power mgmt and implements some UI on the Calypso-controlled LCD and keypad, I expect no difficulty with taking that code, replacing the Calypso-based UI with some simple protocol for interfacing with the UI over the modem UART (maybe not the same as the infamous AT command interface, but doing the same job on the same level of abstraction), and running it on my GTA02, hence I'm not complaining.
As far as the power management etc advantages of the simpler phones without an application processor: does anyone know of any basic Leonardo-style phones which are like the famous C1xx, but support the PCS1900 band, are physically available, and documented no worse than C1xx in terms of the availability of schematics and docs for display and other non-Calypso components?
The fact that C1xx phones can be bought in 1000 unit quantities is great news for those living in areas with EGSM/DCS1800 services, but doesn't do much good for those living in PCS1900/GSM850 lands...
MS
But if the community goes the C1xx route and produces GPL code that runs fully on the Calypso, no PC needed, does power mgmt and implements some UI on the Calypso-controlled LCD and keypad, I expect no difficulty with taking that code, replacing the Calypso-based UI with some simple protocol for interfacing with the UI over the modem UART (maybe not the same as the infamous AT command interface, but doing the same job on the same level of abstraction), and running it on my GTA02, hence I'm not complaining. That's exactly what I was thinking about, since running the layer23 on the Application CPU is not a so good idea, it renders the phone usable only for a small period of time(since,in that configuration, you cannot suspend the AP CPU because it has to run the telephony code).
maybe not the same as the infamous AT command interface Why is AT bad? what other protocol do you propose?
Denis.
On Mon, Dec 12, 2011 at 07:02:21PM +0100, Denis 'GNUtoo' Carikli wrote:
maybe not the same as the infamous AT command interface
Why is AT bad? what other protocol do you propose?
I've you've ever tried to write any fully-fledged AT command parser (like the various incarnations of Openmoko gsmd/libgsm, fso gsmd, ofono, etc.) then you know why. It's nice for human beings, but it's horribly overloaded for any machine based parsing, especially if you only have one channels and need to deal with unsolicited results overlapping with synchronous request/response type commands at the same time. In any interface where you have asynchronous signalling, each command should be tagged with an identifier, which is contained in the corresponding response. This is done e.g. very nicely in IMAP and you can have as many outstanding/executing commands in parallel as you want, without any difficulty parsing the responses whatsoever. Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
13.12.2011 02:02, Denis 'GNUtoo' Carikli пишет:
That's exactly what I was thinking about, since running the layer23 on the Application CPU is not a so good idea, it renders the phone usable only for a small period of time(since,in that configuration, you cannot suspend the AP CPU because it has to run the telephony code).
I've probably missed this part of discussion. Could you re-iterate: is it technical limitations that prevent us from porting layer23 onto calypso BP or it's simply lack of manpower? bye, Max.
On Tue, Dec 13, 2011 at 12:56:08PM +0800, suraev@stud.ntnu.no wrote:
13.12.2011 02:02, Denis 'GNUtoo' Carikli пишет:
That's exactly what I was thinking about, since running the layer23 on the Application CPU is not a so good idea, it renders the phone usable only for a small period of time(since,in that configuration, you cannot suspend the AP CPU because it has to run the telephony code).
I've probably missed this part of discussion. Could you re-iterate: is it technical limitations that prevent us from porting layer23 onto calypso BP or it's simply lack of manpower?
It's really only the latter. There are probably a number of external references that need to be resolved (we don't have a full libc/libm in the target), as well as issues related to unaligned accesses. Also, the current 'mobile' code probably needs to be split into the actual 'logic' code (L2, L3, cell [re]selection, etc.) and the 'application' part (the VTY based interface we have right now). The higher-level interface of the 'logic' code and the application needs to be defined, probably as some kind of message queue of primitives. A first incremental step could be to move L2 (LAPDm) into the phone and use RSLms to talk with the existing PC-based 'mobile' application over the UART. Regards, Harald. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Harald Welte wrote:
There are probably a number of external references that need to be resolved (we don't have a full libc/libm in the target),
Look at libpayload. It's a libc-like project for writing coreboot payloads, ie. running on bare metal, and implements some of libc either on it's own or by borrowing from other OS projects. BSD license.
Also, the current 'mobile' code probably needs to be split into the actual 'logic' code (L2, L3, cell [re]selection, etc.) and the 'application' part (the VTY based interface we have right now).
I think this is a great first step, and a very easy way to get involved for someone who is not yet so experienced with GSM, but already has a good understanding of C on PCs. //Peter
Peter Stuge wrote:
Also, the current 'mobile' code probably needs to be split into the
actual 'logic' code (L2, L3, cell [re]selection, etc.) and the 'application' part (the VTY based interface we have right now).
I think this is a great first step, and a very easy way to get involved for someone who is not yet so experienced with GSM, but already has a good understanding of C on PCs.
i think it would help if we look at the VTY commands and what they tell the stack and what they receive as response. i suggest defining "MMI_*" message primitves for an interface. other applications, like the UI could use and connect to the same interface. (possibly other applications like AT command interface) i suggest defining the if at 28c3.
Andreas Eversberg wrote:
Peter Stuge wrote:
Also, the current 'mobile' code probably needs to be split into the
actual 'logic' code (L2, L3, cell [re]selection, etc.) and the 'application' part (the VTY based interface we have right now).
I think this is a great first step, and a very easy way to get involved for someone who is not yet so experienced with GSM, but already has a good understanding of C on PCs.
i think it would help if we look at the VTY commands and what they tell the stack and what they receive as response. i suggest defining "MMI_*" message primitves for an interface. other applications, like the UI could use and connect to the same interface. (possibly other applications like AT command interface) i suggest defining the if at 28c3.
+1 //Peter
13.12.2011 16:30, Peter Stuge пишет:
Look at libpayload. It's a libc-like project for writing coreboot payloads, ie. running on bare metal, and implements some of libc either on it's own or by borrowing from other OS projects. BSD license.
There's also uClibc port http://linux-c6x.org/wiki/index.php/Main_Page for another TI dsp. But I'm not sure how much efforts it'll take to port it to calypso and others. cheers, Max.
participants (7)
-
Andreas Eversberg -
Denis 'GNUtoo' Carikli -
Harald Welte -
Lokkju Brennr -
msokolov＠ivan.Harhan.ORG -
Peter Stuge -
suraev＠stud.ntnu.no