12 Dec
2011
12 Dec
'11
6:12 p.m.
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
12 Dec
12 Dec
6:27 p.m.
New subject: Creating a real usable phone using OsmocomBB
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(a)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
7:02 p.m.
New subject: Creating a real usable phone using OsmocomBB
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.
10:02 p.m.
New subject: Creating a real usable phone using OsmocomBB
On Mon, Dec 12, 2011 at 07:02:21PM +0100, Denis 'GNUtoo' Carikli wrote:
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
maybe not the
same as the infamous AT command interface
Why is AT bad? what other protocol do you propose? 
13 Dec
13 Dec
5:56 a.m.
New subject: Creating a real usable phone using OsmocomBB
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.
8:32 a.m.
New subject: Creating a real usable phone using OsmocomBB
On Tue, Dec 13, 2011 at 12:56:08PM +0800, suraev(a)stud.ntnu.no wrote:
13.12.2011 02:02, Denis 'GNUtoo' Carikli
пишет:
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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? 
9:30 a.m.
New subject: Creating a real usable phone using OsmocomBB
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
9:36 a.m.
New subject: Creating a real usable phone using OsmocomBB
Peter Stuge wrote:
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.
Also, the
current 'mobile' code probably needs to be split into the
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.
actual 'logic' code (L2, L3, cell
[re]selection, etc.) and the
'application' part (the VTY based interface we have right now).
9:50 a.m.
New subject: Creating a real usable phone using OsmocomBB
Andreas Eversberg wrote:
Peter Stuge wrote:
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
Also, the
current 'mobile' code probably needs to be split into the
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.
actual 'logic' code (L2, L3, cell
[re]selection, etc.) and the
'application' part (the VTY based interface we have right now).
10:07 a.m.
New subject: Creating a real usable phone using OsmocomBB
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.
4526
days inactive
4527
days old
baseband-devel@lists.osmocom.org
10 comments
7 participants
participants (7)
-
Andreas Eversberg -
Denis 'GNUtoo' Carikli -
Harald Welte -
Lokkju Brennr -
msokolov＠ivan.Harhan.ORG -
Peter Stuge -
suraev＠stud.ntnu.no