Openmoko - User contributions [en]

GSM network registration

2008-03-17T14:15:08Z

Henrikp:

We'd like to know the real network registration status by our NEO devices in the world. Please provide some information about your NEO status! The question list as below:

1. What NEO device you are using? GTA01 or GTA02

2. Where is your location and what is your network provider? eg. T-Mobile, San Francisco in USA

3. When you boot the NEO, how long it takes to register the network? eg. in normal case, it should be able to register to a network in 1~2 minutes immediately.

4. What is your GSM firmware version? you can get this number by an AT command. Using SSH to your NEO, then type this command:
[http://wiki.openmoko.org/wiki/USB_Networking How to use SSH] [http://wiki.openmoko.org/wiki/Gsmd How to use libgsmd-tool]
root@fic-gta02:~# libgsmd-tool -m atcmd
AT+CGMR
STR=`AT+CGMR'
RSTR=`+CGMR: "HW: GTA02BV5, GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko6"'

5. What is your IMEI code? by this AT command like previous steps.
AT+CGSN
STR=`AT+CGSN'
RSTR=`+CGSN: 000000000000000'

6. if NEO takes over 3 minutes to register to the network or it just re-register to the network again and again. Please attach your gsm log file ('/tmp/gsm.log') to our bugzilla, we already created a bug for [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1024 this issue].

----

{| border="1"
| Owner || Location ||| Network Provider || Device || firmware || IMEI || Status || GSM log
|-
| [mailto:erin_yueh@openmoko.com Erin Yueh] || Taipei, Taiwan || TW mobile || GTA02BV5 || Moko6 || NO || Normal, can register to the network immediately|| no
|-
| [mailto:marcus.bauer@gmail.com Marcus Bauer] || Nice, France || Orange || GTA01Bv4 || Moko4 || YES || Registers immediately and stays registered for ~10 minutes before the re-registering loop starts once per minute|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=554&action=view log]
|-
| [mailto:ahvenas@gmail.com Henrik Pihl] || Kuressaare, Estonia || Elisa || GTA01Bv4 || Moko4 || YES || Normal, can register to the network immediately, but starts reconnecting to the network in the first minutes.|| [http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=555&action=view log]
|}

Manually using GPRS

2008-03-11T20:13:08Z

Henrikp: /* Some APN names for reference */

You need to have [[GSM]] parts already initialized, with modem logged in to the network, for this to work. It is best to test it by doing test call. The GPRS connection is made using the PPP protocol to a server identified by an "APN" at the network operator.

The program that implements PPP on Linux is [[pppd]], which we need to configure and run to get a connection. When that is working, we can configure pppd to wait until it's needed before it connects, and to disconnect if the connection becomes idle. Further, we can start pppd in the background during the boot process.

== Configuring pppd for manual connections ==

You'll need /etc/ppp/peers/gprs:
<pre>
/dev/ttySAC0 115200
connect /etc/ppp/gprs-connect-chat
crtscts
lock
hide-password
defaultroute
usepeerdns
disconnect /etc/ppp/gprs-disconnect-chat
holdoff 3
ipcp-accept-local
lcp-echo-failure 8
lcp-echo-interval 3
noauth
noipdefault
novj
novjccomp
replacedefaultroute
persist
lcp-echo-interval 3
lcp-echo-failure 12
</pre>

This options where mentioned before with that strange comment. Mine worked fine for me without those.

<pre>
# very long timeouts (unwise?)
lcp-echo-interval 300
lcp-echo-failure 40000
</pre>

Depending on the APN, you may need password authentication using CHAP or PAP. You can add the following default line for "password-less" connections:

<pre>
# client server secret IP addresses
* * "" *
</pre>

For CHAP, lines in /etc/ppp/chap-secrets are used. For PAP, the lines are in /etc/ppp/pap-secrets. The client should match the "user" option in pppd the config file (below). You can use * to mean any here, but the option user "" doesn't mean empty!

For example:

<pre>
# Secrets for authentication using CHAP
# client server secret IP addresses
"user" * "password" *
</pre>

For this you need the following options in /etc/ppp/peers/gprs:

<pre>
# username to use for authentication, should match "client" in /etc/ppp/{chap,pap}-secrets
user "user"
</pre>

And you'll need /etc/ppp/gprs-connect-chat (needs "chmod +x"):

<pre>
#!/bin/sh -e
exec chat -v\
ABORT BUSY\
ABORT DELAYED\
ABORT "NO ANSWER"\
ABORT "NO DIALTONE"\
ABORT VOICE\
ABORT ERROR\
ABORT RINGING\
TIMEOUT 3\
"" ATZ\
OK-\\k\\k\\k\\d+++ATH-OK ATE1\
OK AT+CFUN=0\
OK \\dAT+CFUN=1\
ERROR AT+CPIN\?\
"+CPIN: READY-AT+CPIN=\"2222\"-OK" AT\
TIMEOUT 60\
OK AT+COPS\
OK AT+CGDCONT=1,\"IP\",\"internet\"\
OK ATD*99#\
CONNECT \d\c
</pre>

You will need to adjust the APN name "internet" in at+cgdcont line to match what your network operator provides. See below in the table "Some APN names for reference" for the right settings for your operator.

Also good to have is /etc/ppp/gprs-disconnect-chat (needs "chmod +x"):

<pre>
#!/bin/sh -e
/usr/sbin/chat -v\
ABORT OK\
ABORT BUSY\
ABORT DELAYED\
ABORT "NO ANSWER"\
ABORT "NO CARRIER"\
ABORT "NO DIALTONE"\
ABORT VOICE\
ABORT ERROR\
ABORT RINGING\
TIMEOUT 12\
"" \\k\\k\\k\\d+++ATH\
"NO CARRIER-AT-OK" ""
</pre>

You need a proper /etc/resolv.conf:

<pre>
ln -sf /var/run/resolv.conf /etc
</pre>

If needed put your nameserver for usb-net into /var/run/resolv.conf, not in /etc.

=== Required fixes ===

The image does not set a correct resolv.conf. i do so with an

<pre>
echo nameserver 192.168.0.201 > /var/run/resolv.conf
</pre>

in the right place. because a post-up in /etc/network/interfaces is not supported i do that in /etc/network/if-up.d/08setupdns

another problem is pppd's /etc/ppp/ip-down.d/92removedns which does not properly remove the link when shuting down ppp. my fix is this script:

<pre>
#!/bin/sh
ACTUALCONF=/var/run/resolv.conf
PPPCONF=/var/run/ppp/resolv.conf
if [ -f $PPPCONF ] ; then
if [ -f $ACTUALCONF ] ; then
if [ ! -h $ACTUALCONF -o ! "`readlink $ACTUALCONF 2>&1`" = "$PPPCONF" ] ; then
mv $ACTUALCONF $ACTUALCONF.ppporig
fi
fi

ln -sf $PPPCONF $ACTUALCONF
fi
</pre>

=== Starting pppd ===

Then, after initializing GSM, you should be able to initialize GPRS by `pppd call gprs`. Good luck!

To dial in - and get verbose output on the terminal - use pppd
<pre>
pppd debug nodetach call gprs
</pre>

The config above will establish a 'persist'ant link over gprs. The battery will run low in less than an hour. See an example for an on-demand config below.

=== Some APN names for reference ===

{| border="1"
! Country
! Carrier
! Plan
! APN
! user/password if required
! Working pppd scripts
|-
| Estonia || Elisa || Any, behind NAT || internet || ||
|-
| Estonia || EMT || Any, behind NAT || internet.emt.ee || ||
|-
| Finland || Saunalahti || Any || internet.saunalahti || ||
|-
| Finland || Sonera || Any, behind NAT || internet || ||
|-
| Finland || Sonera || Any, public IP || prointernet || ||
|-
| France || SFR || 10.x.x.x? || websfr || || under tests
|-
| France || SFR || 10.x.x.x? || wapsfr[1]|| || under tests
|-
| France || Orange || ??? || orange.fr || || under tests
|-
| Germany || E-Plus || BASE (and others?) || internet.eplus.de || eplus gprs ||
|-
| Germany || T-Mobile || || internet.t-mobile || ||
|-
| Germany || Vodafone || Any, behind NAT || web.vodafone.de || ||
|-
| Norway || Netcom || Any || internet.netcom.no || ||
|-
| Switzerland || Swisscom || e.g. Natel Basic Liberty, behind NAT || gprs.swisscom.ch || ||
|-
| UK || T-Mobile|| || general.t-mobile.uk || ||
|-
| UK || Virgin || || goto.virginmobile.uk || user ||
|-
| UK || [http://www.filesaveas.com/gprs.html other providers] || || || ||
|-
| USA || Cingular (AT&T) || Less than full internet || wap.cingular || ||
|-
| USA || T-mobile || Anything less than full internet || wap.voicestream.com || ||
|-
| USA || T-mobile || Regular internet plan || internet2.voicestream.com || || [[T-Mobile pppd scripts]]
|-
| USA || T-mobile || "VPN" internet plan || internet3.voicestream.com || ||
|-
|}

[1] connected through a WAP proxy (slower, but the only way to access Vodafone live! and SFR portal)

== Starting pppd automatically ==

Once you have finished debugging your gprs-connect-chat and gprs options files, you may wish to automatically connect whenever needed and hang up when finished. Make sure you understand the impact of this change to your carrier plan billing. This is not recommended unless you have a large-use or unlimited data plan. These scripts do NOT prompt you before connecting.

=== On-demand connection settings ===

Additional settings are needed if you want the actual connection to be up only while there is traffic. In the 'gprs' file above, insert the following, making sure 'nodetach' is commented out. If 'nodetach' is on, the boot process will stop when it starts pppd. Also remove the option 'persist' mentioned above.

<pre>

# Wait until needed before connecting
demand

# Disconnect if idle for given amount of seconds
idle 20

</pre>

=== Start on boot (method 1) ===

Add the following definition to /etc/network/interfaces:
<pre>
auto ppp0
iface ppp0 inet ppp
provider gprs
</pre>

That should be it. Now you can use 'ifup ppp0' and 'ifdown ppp0' manually too.

=== Start on boot (method 2) ===

Create the following file as /etc/ppp/ppp_on_boot (needs chmod +x). The /etc/init.d/ppp script will call it to set up the daemon.
<pre>
#!/bin/sh
#
# Rename this file to ppp_on_boot and pppd will be fired up as
# soon as the system comes up, connecting to `provider'.
#
# If you also make this file executable, and replace the first line
# with just "#!/bin/sh", the commands below will be executed instead.
#

# The location of the ppp daemon itself (shouldn't need to be changed)
PPPD=/usr/sbin/pppd

# The default provider to connect to
$PPPD call gprs

# Additional connections, which would just use settings from
# /etc/ppp/options.<tty>
#$PPPD ttyS0
#$PPPD ttyS1
#$PPPD ttyS2
#$PPPD ttyS3
</pre>

Finally, you need to add the /etc/init.d/ppp script to the init process by creating symbolic links from the appropriate directories. I chose the following:

<pre>
/etc/rc0.d/K25ppp
/etc/rc1.d/K45ppp
/etc/rc2.d/S45ppp
/etc/rc3.d/S45ppp
/etc/rc4.d/S45ppp
/etc/rc5.d/S45ppp
/etc/rc6.d/K25ppp
</pre>

== See also ==
* [[pppd]]
* [[Manually using GSM]]
* [[Manually using Bluetooth]]

{{Languages|Manually_using_GPRS}}
[[Category:Documentation]]
[[Category:Developer software]]

[[Category:Guides]]

Manually using GSM

2008-03-11T06:28:56Z

Henrikp: /* Powering up the GSM Modem */

'''When men were real men and typed their own AT commands...'''

Thankfully, this may now be partially obsolete.
The [[Dialer|dialer]] now works!

This is a short guide how to manually get GSM going.

== Requirements ==

* GTA01Bv2 or GTA01Bv3 with very recent u-boot bootloader, providing usbtty (serial over USB) support)
* Do not connect any debug board!

== Walk-Through ==

=== Booting the system ===

* Make sure the rootfs you use has 'auto usb0' in /etc/network/interfaces
* Configure the host's usb0 interface to 192.168.0.200 netmask 255.255.255.0 See [[USB_Networking]]
* ssh to root@192.168.0.201

=== Disabling the getty ===

Our default images all have a getty running on /dev/ttySAC0, please edit /etc/inittab and disable the getty on that port

=== Reducing the loglevel ===

{{note|You don't need this in kernel builds with patchset ≥ 1288}}

To keep the kernel from writing to /dev/ttySAC0, you need to use <code>dmesg -n1</code>.

=== Powering up the GSM Modem ===

* verify there is no getty or any other app running on /dev/ttySAC0
root@fic-gta01:~$ lsof | grep ttySAC0

* If gsmd is using the GSM modem, shut it down with

<pre>
root@fic-gta01:~$ /etc/init.d/gsmd stop
</pre>

* power-up the GSM Modem
root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

=== Connecting to GSM Modem (using socat) ===

* If you have the command socat (built and installed):
root@fic-gta01:~$ socat - file:/dev/ttySAC0,crtscts,crnl
AT-Command Interpreter ready

=== Connecting to GSM Modem (using cu) ===

If you don't have socat, you can use cu, although it has problems with file permissions and hardware flow control.

* change permissions on ttySAC0
root@fic-gta01:~$ chown uucp.uucp /dev/ttySAC0
* setup /usr/spool/uucp
root@fic-gta01:~$ mkdir -p /usr/spool/uucp
root@fic-gta01:~$ chown uucp.uucp /usr/spool/uucp
* enable CTS/RTS flow control
root@fic-gta01:~$ stty -F /dev/ttySAC0 crtscts
* access the GSM Modem UART
root@fic-gta01:~$ cu -l /dev/ttySAC0
Connected.
AT-Command Interpreter Ready
OK

''If it hangs on "Connected" message then probably your device has a non-working GSM modem - check [http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=256 Bug #256], also you may want to try powering off the modem then on again as this worked for me''

'''cu seems to have problems with the hardware flow control. The one way I always managed to get GSM working is to start cu first and then on a different console issue the stty command.'''
--[[User:DanielWillmann|DanielWillmann]] 01:15, 20 March 2007 (CET)

* close the connection with <Return>~~.<Return>
OK
~[fic-gta01].

Disconnected.
root@fic-gta01:/$

=== Using it manually ===
==== Registering with the Network ====

* enter the following [[Hardware:AT_Commands]]:
<pre>
ATE1
OK
AT+CFUN=1
ERROR
AT+CPIN="...."
OK
AT+COPS
OK
</pre>

==== List available carriers ====

This can take a few seconds to process but will list the available carriers
<pre>
AT+COPS=?
</pre>

==== Answering an incoming call ====
<pre>
RING
ATA
OK
</pre>

==== Dialling an outgoing call ====

To actually be able to talk you have to configure your audio accordingly

<pre>
root@fic-gta01:~$ cd /etc/alsa/
root@fic-gta01:/etc/alsa$ wget http://opensource.wolfsonmicro.com/~gg/neo1973/gsmheadset.working.state
root@fic-gta01:/etc/alsa$ alsactl -f /etc/alsa/gsmheadset.working.state restore
</pre>

Up the "Amp right" volume to hear the speaker on both ears, then dial (note the ''';''' at the end of the dial string, this signifies a voice call, if you omit the ; it is regarded as a data call).

<pre>
ATD012340234;
</pre>

If you get NO CARRIER, try...

<pre>
ATD+xxyzzzzzzz
</pre>

ie, ATD+<country_code><area_code><phone_number>

==== Hanging up ====
<pre>
ATH
OK
</pre>

=== Using [[gsmd]] ===

You can use the [[gsmd]] and [[Gsmd#libgsmd-tool | libgsmd-tool]] programs to have a slightly more high-level interface to the GSM Modem. It's still console based, though.

For further instructions, see [[gsmd]]

=== Using tui ===

Tui (available from [http://www.sf.net/projects/tui sourceforge]) is able to do all this. It is still text-based, but input-rxvt can take data from touchscreen, so you can actually do the calls using your finger. It also plays wav file on incoming call, so it is theoretically usable. It even does caller id.

=== Manually using GPRS ===

See [[Manually using GPRS]]

{{Languages|Manually_using_GSM}}
[[Category:Documentation]]
[[Category:Developer software]]

Neo 1973 and Neo FreeRunner gsm modem

2008-03-10T19:12:26Z

Henrikp: /* Avoiding Infinite Echos */

This page is about the [[Neo1973]] GTA01 (and GTA02) GSM Modem, based on the Ti Calypso chipset.

== [[Hardware:AT Commands|AT command]] interface ==

=== Sending Commands ===
To send commands to the GSM modem, you may use
cu -l /dev/ttySAC0
or use gsmd and libgsmd-tool for a less direct method.

If you connect directly (via cu) you must `chown uucp.uucp /dev/ttySAC0` first since cu is picky about permissions.

libgsmd-tool is less functional than the direct raw connection to the modem.

{|
Note: If you use cu -l /dev/ttySAC0 to enter commands, type "~." to quit
|}

=== Standard AT commands ===
The GSM modem follows GSM [http://www.3gpp.org/ftp/Specs/html-info/0705.htm TS07.05], [http://www.3gpp.org/ftp/Specs/html-info/0707.htm 07.07] and [http://www.3gpp.org/ftp/Specs/html-info/0710.htm 07.10] very closely.

[http://www.3gpp.org/specs/numbering.htm 3gpp.org] has information about 3G and GSM specifications

=== TI proprietary AT commands ===

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, OpenMoko cannot provide a reference documentation to those commands. Using the standards-compliant '''AT+CLAC''', you will notice that the non-standard commands also show up in the command listing.

You will also notice that those non-standard commands are prefixed with '''AT%''' rather than '''AT+''' for the standards-compliant commands.

Thus, we welcome our user and developer community to play with those commands and document them here. Since we never have released any NDA documentation to our community, there is no legal issue.

Note that the syntax and the interpretation of the output of the commands listed here are only educated guesses and should not be relied on. Part of the proprietary command set has identical or similar usage as on other modems in the market, some of which have fully opened specifications and information about these commands can be taken from their datasheets (some known similar modems with open specs: ''BenQ M22A'' and ''M23A'', ''Enfora Enabler-G [http://www.enfora.com/index.cgi?CONTENT_ID=376&User:LANGUAGE=en II] / [http://www.enfora.com/index.cgi?CONTENT_ID=377&User:LANGUAGE=en III]'' and ''SPT 1834'').

==== AT%VER ====
Prints the firmware component versions.

The modem's response looks like this on an un-updated phase-0 [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phone:

%VER: aci sean non_clearcase 15:11:24 17/04/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: l2r a086 ** NONE ** 10:21:37 28/03/07
%VER: ra a086 ** NONE ** 10:25:01 28/03/07
%VER: rlp a086 ** NONE ** 10:25:12 28/03/07
%VER: fad a086 ** NONE ** 10:18:09 28/03/07
%VER: t30 a086 ** NONE ** 10:29:01 28/03/07

For a [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phase 1 phone, produced start of september:

%VER: aci sean non_clearcase 12:32:56 24/08/07
%VER: cc a086 ** NONE ** 14:07:10 08/06/07
%VER: dl a086 ** NONE ** 14:07:46 08/06/07
%VER: mm a086 ** NONE ** 14:11:52 08/06/07
%VER: rr a086 ** NONE ** 14:13:01 08/06/07
%VER: sim a086 ** NONE ** 14:13:54 08/06/07
%VER: sms a086 ** NONE ** 14:14:20 08/06/07
%VER: ss a086 ** NONE ** 14:15:52 08/06/07
%VER: alr a086 ** NONE ** 14:06:38 08/06/07
%VER: l2r a086 ** NONE ** 14:10:36 08/06/07
%VER: ra a086 ** NONE ** 14:12:32 08/06/07
%VER: rlp a086 ** NONE ** 14:12:40 08/06/07
%VER: fad a086 ** NONE ** 14:08:06 08/06/07

For a [[Neo1973_Hardware#GTA01Bv3|GTA01Bv3]] phase 0 phone:

%VER: aci sean non_clearcase 10:46:06 29/08/06
%VER: cc a086 non_clearcase 14:53:59 28/08/06
%VER: dl a086 non_clearcase 14:54:40 28/08/06
%VER: mm a086 non_clearcase 14:59:25 28/08/06
%VER: rr a086 non_clearcase 15:00:11 28/08/06
%VER: sim a086 non_clearcase 15:00:57 28/08/06
%VER: sms a086 non_clearcase 15:01:23 28/08/06
%VER: ss a086 non_clearcase 15:02:22 28/08/06
%VER: alr a086 non_clearcase 14:53:19 28/08/06
%VER: l2r a086 non_clearcase 14:58:02 28/08/06
%VER: ra a086 non_clearcase 14:59:50 28/08/06
%VER: rlp a086 non_clearcase 14:59:56 28/08/06
%VER: fad a086 non_clearcase 14:55:04 28/08/06
%VER: t30 a086 non_clearcase 15:02:27 28/08/06

The second column lists firmware component names (e.g. aci = AT Command Interface). The third column is the user name of the engineer who last modified given component. The rightmost column is probably the last time someone worked on it (Please note that the name 'sean' here is not Sean Moss-Pultz :) while a086 is an anonymous TI engineer's nick, meaning that the component has not been modified at FIC).

==== AT%A ====
Print values from an ADC.

This command is not listed in AT+CLAC output but it is triggered by any input that starts with AT%A except AT%ALS (''Alternative Line Service'') and AT%ATR, which are other proprietary AT commands. So for example AT%ABCD,HELLO will also run this commands. On my Neo modem it prints a line containing nine values of the form ADC <number> = <value>:

AT%A
EXT: I
ADC 0 = e19, ADC 1 = 0, ADC 2 = d, ADC 3 = 6ea, ADC 4 = a25, ADC 5 = 9fc, ADC 6 = 96d, ADC 7 = 0, ADC 8 = 6

It would seem there's an ADC (analog-to-digital converter) module in the modem with nine input lines connected to it and the values on these lines are reported by this command in hexadecimal format. The values change over time. Inputs 1 and 7 always show zero on my modem, input 1 value changes slightly (+/- 20), while values on inputs 3, 4, 5, 6 and 8 change seemingly randomly in the range 0x000 - 0xfff (it would seem the chip is 12-bit).

==== AT%NRG ====
The AT%NRG (''Network registration and service selection'') is an expansion of the AT+COPS command. It allows specifying the service state of the registration, in addition to AT+COPS functionality. It doesn't however allow listing all present operators (use AT+COPS for this).

==== AT%EM ====
Execution of ''Engineering Mode'' commands. Allows viewing the information accessible to the modem but not available through standard GSM AT commands set such as detailed information on the current Serving Cell (the one we're registered with), its neighbouring cells, the GPRS/EDGE availability and SIM card data.

Citing Enfora Inc. Application Note EDG0108TN01:
''The purpose of Engineering Mode (EM) is to provide means to observe the behavior of the mobile station and the settings of the network as counterpart and therefore defines a lot of possibilities to analyze the network. The EM can be used for observation of a defined data set during functional test and field test.''

''Warning: The display of certain parameters is dependent on the wireless network sending the correct information in the System Information Packets. There is no guaranty that the information is always forwarded from the network. At times data may not be present to display in the Engineering Mode responses.''

Syntax:
AT%EM=<mode>,<command>
Allowed <mode> values:
* 2 - AT command mode
* 3 - PCO mode
I only describe the AT mode commands here. Commands are in range 1 to 13:
AT%EM=2,1 Serving Cell Information
AT%EM=2,2 Serving Cell GPRS Information
AT%EM=2,3 Neighbour Cell Information
AT%EM=2,4 Location and Paging Parameters
AT%EM=2,5 PLMN Parameters
AT%EM=2,6 Ciphering, Hopping, DTX Parameters
AT%EM=2,7 Power Parameters
AT%EM=2,8 Identity Parameters
AT%EM=2,9 Firmware components versions
AT%EM=2,10 GMM Information
AT%EM=2,11 GRLC Information
AT%EM=2,12 AMR Configuration Information
AT%EM=2,13 PDP Information

===== Serving Cell Information (2,1) =====
Response format:
%EM: <afrcn>,<c1>,<c2>,<rxlev>,<bsic>,<cell_id>,<dsc>,<txlev>,<tn>,<rlt>,<tav>,<rxlev_f>,<rxlev_s>,<rxqual_f>,<rxqual_s>,<lac>,<cba>,<cbq>,<cell_type_ind>,<vocoder>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || arfcn || Current Channel Number ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentifier ||
|-
|7 || dsc || Downlink Signaling Counter || current counter value
|-
|8 || txlev || Transmit Power Level ||
|-
|9 || tn || Timeslot Number ||
|-
|10 || rlt || Radio Link Timeout Counter ||
|-
|11 || tav || Timing Advance ||
|-
|12 || rxlev_f || Received Field Strength full ||
|-
|13 || rxlev_s || Received Field Strength sub ||
|-
|14 || rxqual_f || Received Quality full ||
|-
|15 || rxqual_s || Received Quality sub ||
|-
|16 || lac || Location Area Code ||
|-
|17 || cba || Cell Bar Access ||
|-
|18 || cbq || Cell Bar Qualifier ||
|-
|19 || Cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|20 || vocoder || Vocoder || Sig/speech/efr/amr/14.4/9.6/4.8/2.4
|}

According to http://www.qrctech.com/freq_chart_24x36.pdf, frequencies can be calculated using the arfcn field like this:
if 172 < arfcn < 252 then freq = 869 + (arfcn -127) x 0.2 MHz # 850 band
if 511 < arfcn < 811 then freq = 1930 + (arfcn - 511) x 0.2 MHz # 1900 band
if 1 < arfcn < 124 then freq = 935 + (arfcn * 0.2) MHz # 900 band (original alloc)
if 974 < arfcn < 1023 then freq = 925 + (arfcn - 974) x 0.2 MHz # 900 band E-GSM
if 511 < arfcn < 886 then freq = 1805 + (arfcn - 511) x 0.2 MHz # 1800 band

Notice the 1800 and 1900 bands have the same channel ids and nearly the same algorithm with a different starting point.

===== Serving Cell GPRS Information (2,2) =====
Response format:
%EM: <nts>,<nmo>,<spgc_ccch_sup>,<priority_access_thr>,<cba>,<rac>,<tav>,<dsc>,<c31>,<c32>,<band_ind>,<pfc_supp_n_w>,<ccn_mode_sts>,<Psi_sts_suppt>,<edge_support>,<epcr_support>,<bep_period>,<bss_paging_coord>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || nts || PCCCH_TIMESLOT || Number of downlink timeslots
|-
|2 || nmo || Network Mode of Operation ||
|-
|3 || spgc_ccch_sup || Network Control-spgc_ccch_sup || Network support for split paging
|-
|4 || priority_access_thr || Network Control-Priority_Access_Threshold || packet access to the NW according to priority level
|-
|5 || cba || Cell Bar Access ||
|-
|6 || rac || Routing Area Code ||
|-
|7 || tav || Timing Advance ||
|-
|8 || dsc || Downlink Signal Counter ||
|-
|9 || c31 || Cell-reselect Criterion C31 ||
|-
|10 || c32 || Cell-reselect Criterion C32 ||
|-
|11 || band_ind || Band Indicator ||
|-
|12 || pfc_supp_n_w || PFC Support ||
|-
|13 || ccn_mode_sts || CCN Mode ||
|-
|14 || Psi_sts_suppt || PSI Support ||
|-
|15 || edge_support || EDGE Support ||
|-
|16 || epcr_support || EPCR Support ||
|-
|17 || bep_period || BEP Period ||
|-
|18 || bss_paging_coord || BSS Paging ||
|}

===== Neighbour Cell Information (2,3) =====
The first line of response is of the format %EM: <number of cells listed>, where the maximum seems to be 6, one cell for each channel. The next sixteen lines list the values of each of the parameters for each of the cells.
{|
! Parameter no. !! Short name !! Meaning !! Remarks
|-
|1 || arfcn || BCCH channel ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentity ||
|-
|7 || lac || Location Area Code ||
|-
|8 || frame_offset || Frame Offset ||
|-
|9 || time_alignmnt || Time Alignment ||
|-
|10 || cba || Cell Bar Access ||
|-
|11 || cbq || Cell Bar Qualifier ||
|-
|12 || cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|13 || rac || Routing Area Code ||
|-
|14 || cell_resel_offset || Cell-reselection Offset ||
|-
|15 || temp_offset || Temporary Offset ||
|-
|16 || rxlev_acc_min || Rxlen access min ||
|}
My Neo1973 reports:
AT%EM=2,3
%EM: 6
763,766,771,778,780,773
20,8,14,18,17,8
20,8,14,18,17,8
73,46,54,51,13,12
6753,10951,3531,0,1933,1924
100,100,300,300,300,100
80229,961995,0,1166923,0,2715553
3504,724,0,3724,4,1112
0,0,0,0,0,0
0,0,0,0,0,0
2,2,2,2,2,2
0,0,0,0,0,0
0,0,0,0,0,0
0,0,0,0,0,0
10,10,10,10,10,10

OK

===== Location and Paging Parameters (2,4) =====
Response format:
%EM: <bs_pa_mfrms>,<t3212>,<mcc[0]><mcc[1]><mcc[2]>,<mnc[0]><mnc[1]><mnc[2]>,<tmsi>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || bs_pa_mfrms || BS PA MFRMS paging repeat period
|-
|2 || t3212 || Periodic location updating interval
|-
|3 || mcc || [http://en.wikipedia.org/wiki/Mobile_country_code Mobile Country Code]
|-
|4 || mnc || [http://en.wikipedia.org/wiki/Mobile_Network_Code Mobile Network Code]
|-
|5 || tmsi || [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] (in binary)
|}
The MCC and MNC values are the same values that are used to form the Mobile Operator names used by the standard AT+COPS and AT+COPN commands in numeric format. The TMSI is the same number that [http://wiki.openmoko.org/wiki/GTA01_gsm_modem#Identity_Parameters_.282.2C8.29 AT%EM=2,8] gives, just in a different format.

===== PLMN Parameters (2,5) =====
Response format:
%EM: <no_creq_max>,<reest_flag>,<txpwr_max>,<rxlev_min>,<rel_cs>,<sgsnr_rel>,<mscr_rel>,<net_rel>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || no_creq_max || Max. number or retries for channel requests
|-
|2 || reest_flag || Re-establishment Flag
|-
|3 || txpwr_max || MS TXPWR MAX CCCH
|-
|4 || rxlev_min || Rxlev_access_min
|-
|5 || rel_cs || Release Cause (only the last release cause is remembered)
|-
|6 || sgsnr_rel || SGSNR Release
|-
|7 || mscr_rel || MSCR Release
|-
|8 || net_rel || Network Release Info
|}
===== Ciphering, Hopping, DTX Parameters (2,6) =====
{{todo|Fill in}}
===== Power Parameters (2,7) =====
The output consits of two lines, first line containing 12 comma-separated values and the second line 18 comma-separated values, such as:
AT%EM=2,7
%EM: 1,1,0,0,0,1,1,0,0,0,1,0
6,0,0,0,0,1,1,1,4,0,0,0,0,1,0,0,0,0

OK
On the first line (called Classmark 2) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Revision Level ||
|-
|2 || Controlled Early Classmark Sending || 1 means enabled
|-
|3 || A5/1 Encryption algorithm || 0 means available
|-
|4 || RF Power capability ||
|-
|5 || Pseudo-synchronisation capability || 1 means present
|-
|6 || SS Screening Indicator ||
|-
|7 || SMS capability ||
|-
|8 || Frequency capability ||
|-
|9 || Classmark 3 options || 1 means supported
|-
|10 || CM Service Prompt || 1 means supported
|-
|11 || A5/3 Encryption algorithm || 1 means available
|-
|12 || A5/2 Encryption algorithm || 1 means available
|}
On the second line (called Classmark 3) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Multiband support ||
|-
|2 || A5/7 Encryption algorithm || 1 means available
|-
|3 || A5/6 Encryption algorithm || 1 means available
|-
|4 || A5/5 Encryption algorithm || 1 means available
|-
|5 || A5/4 Encryption algorithm || 1 means available
|-
|6 || Valid Radio capability 2 || ??
|-
|7 || Associated Radio capability 2 ||
|-
|8 || Valid Radio capability 1 || ??
|-
|9 || Associated Radio capability 1 ||
|-
|10 || Valid R Support || ??
|-
|11 || R Support || R-GSM Class
|-
|12 || Valid Multi-slot Class || ??
|-
|13 || Multi-slot Class ||
|-
|14 || Unicode 2 treatment ||
|-
|15 || Extended Measurement capability || 1 means supported
|-
|16 || Valid Switch-measure-value || ??
|-
|17 || Switch-measure-value ||
|-
|18 || Switch-measure-switch-value ||
|}

===== Identity Parameters (2,8) =====
Response format:
%EM: <imeisv>
<imsi>
<tmsi>

OK
The IMEISV line contains 20 numbers separated by commas, the numbers on positions 5 to 18 are the digits of the [http://en.wikipedia.org/wiki/IMEI IMEI] number as returned by AT+CGSN. The second line contains another 20 numbers and the numbers on positions 5 to 19 form the digits of your SIM card's [http://en.wikipedia.org/wiki/IMSI IMSI] number, as returned by the AT+CIMI command. The last line contains the [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] number in plain format (ten digits).

===== Firmware components versions (2,9) =====
Prints version information for different components of the modem's firmware. The format and the scope of the information presented is identical to that in [[#AT%VER|AT%VER]] output with the exception that only a subset of all of the components are listed:
AT%EM=2,9
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07

OK
===== GMM Information (2,10) =====
{{todo|Fill in}}
===== GRLC Information (2,11) =====
{{todo|Fill in}}
===== AMR Configuration Information (2,12) =====
{{todo|Fill in}}
===== PDP Information (2,13) =====
{{todo|Fill in}}

=== GSM Modem OpenMoko commands ===

The Ti calypso GSM Modem firmware has been extended by OpenMoko specific AT
commands. This page documents those commands.

==== AT@POFF ====

Powers off the GSM Modem. No parameters/options.

==== AT@ST ====

configure the sidetone level for voice calls generated inside the GSM Modem. This should normally be off, since the sidetone in GTA01/GTA02 is generated inside the the [[WM8753|wolfson audio codec]].

AT@ST?
+ST: -5
OK
AT@ST=?
@ST: (-26,-23,-20,-17,-14,-11,-8,-5,-2,1)
OK
AT@ST="-26"
OK

-26 means turn off the sidetone totally.

==== AT@AUL ====

audio table load.

AT@AUL="0"
OK
AT@AUL=?
@AUL:(0)

This audio table is a collection of audio parameters for GSM calibrated by hardware engineers,

Mode of microphone
Gain of microphone
FM PGA gain setting
Bias setting for microphone
FIR coefficients
ANR parameters
Level of side tone
AEC parameters
Echo suppressor
Mode of speaker
Gain of speaker
Extra gain for AUDIO_SPEAKER_HANDSET and AUDIO_SPEAKER_HANDFREE modes
Enable/Disable filter
Enable/Disable high-pass filter
FIR coefficients
IIR uplink/downlink coefficients
Limiter parameters
Level of speaker
Mode of speaker
State of speaker
Sampling frequency
Level of volume
AGC parameters
DRC parameters

The audio table will be stored in the flash file system within GSM modem, you can load it through this command.

For now, we only provide one configuration, that is "0".

If AT@AUL="0" responds with ERROR, it means there's no audio table existing and the GSM firmware will use default values.

== Wakeup of CPU from GSM Modem ==

=== Problem description ===

For power management reasons, it is absolutely neccessary that only the minimal
required parts of the device are powered at any given time. If you carry your
Neo in your pocket, then all it should do is stay online with the GSM network,
and notify you in case there's an incoming call/sms (like other phones).

During that time, the Neo1973 Application Processor (s3c24xx) is suspended,
i.e. not powered at all. The SDRAM is in self-refresh mode.

In this suspend mode (which Samsung calls by the funny name of POWER_OFF), the
processor is not able to receive any data from the GSM Modem. Nor is it able
to detect incoming characters and wake up the CPU. The only wake up sources
are a certain set of external interrupts (EINT).

Thus, the GSM Modem GPIO line IO1 was connected with the Samsung EINT1, and
the GSM Modem firmware contains some special logic to generate an interrupt
(and thus wake-up event) to the CPU.

=== Logic for problem solution ===

Preconditions
# The default state of GSM Modem output IO1 is logical LOW.

Anytime the modem has pending data on the MODEM-UART channel, it
# checks if CTS_MODEM permits sending of data
## if CTS_MODEM permits sending of UART data, go to '4.2'
# [implicit: CTS_MODEM does not permit sending of UART data]
## set IO1 line to logical HIGH level
## buffer modem data [until buffer is full, after which data gets discarded]
# wait until CTS_MODEM permits sending of UART data
# as soon as CTS_MODEM permits sending of UART data,
## set IO1 back to logical LOW level
## start sending of UART data
# once all data is transmitted, return to idle state. When next data item is to be transmitted, start again from '1'

=== Software implementation ===

{{note|This is the plan, it has not been fully implemented yet}}

# a firmware post may-16-2007 needs to be present in the gsm modem. This is true for all phones bought during phase 1 in the online shop. However, I currently don't really know what firmware version was present in the GTA01Bv4 that we sent to phase 0.
# the suspend code probably still needs to correctly configure the RTS/CTS lines (i.e. put them in GPIO mode, and set them to their desired "don't send any more characters" level)

So in this case, any data from the GSM modem will wake up the cpu for processing of that data. The GSM modem has some internal buffer (I don't know how big right now) that should be sufficient for buffering the data until the CPU is alive.

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside OpenMoko staff.

== Power On, Power Off, and Reset of the GTA01 GSM Modem ==

=== GSM Modem Connections ===

The GTA01 GSM modem communicates via a standard serial port to the host system. The port operates at 115200 baud, 8 bits, no parity, and requires hardware flow control (RTSCTS) to operate. Due to the fact that the host CPU has only a pair of serial ports but there are three devices that wish to use them, the GSM modem port is actually shared with the serial console (the third device is the GPS chip, which has exclusive use of the second serial port).

A GPIO (General Purpose IO) pin controls the switching of the serial port between the console and the GSM modem. Another GPIO is used to turn on the power to the GSM modem. On older versions of the GTA01 a third GPIO could be used to reset the GSM modem; this signal proved to cause difficulties with the modem, and on all the GTA01 units sold this GPIO line is not connected. The driver combines the the switching of the serial port to the GSM modem and the power-on signal to the modem into a single operation; the two cannot be controlled independently from user-space (at the time of this writing).

It is important to note that the GPIO controlling the power-on of the GSM modem can only signal to the modem to turn itself on -- turning this GPIO off does not power off the GSM modem. Instead, the '''AT@POFF''' sequence must be sent to the modem in order to perform a power off.

Further complicating power control of the GTA01 GSM modem is the fact that the modem draws power from the battery/charger side of the power management circuitry -- this means that turning off the power to the host CPU on the GTA01 does not turn off the power to the modem. In real-world operation, this means that unless the shutdown procedure for the host cpu's operating system issues the '''AT@POFF''' command to power off the GSM modem, the modem will remain turned on, drawing power from the battery even thought the host CPU is completely powered off.

=== The Power-On Sequence ===

The sharing of the serial port between the console and the GSM modem results in the need for a very specific power-on and power-off sequence. Two major problems exist that must be avoided: infinite echos, and RTSCTS lockup.

==== Avoiding Infinite Echos ====

By default, the serial port is initialized in "echo" mode -- meaning that any characters sent to the serial port from the console will be echoed back to the console. Upon power-up or reset, the GSM modem also echos back characters it receives. So unless action is taken to disable the serial port's echo before the GSM modem is powered on, an infinite echo will result. The modem will print the standard "Interpretor Ready" message, which will be echoed back to it by the serial port driver, the modem will echo that back to the serial port again (adding some error text to the message), the serial port will echo that again, and this continues until buffers in either or both the serial port and the modem fill up, and one of them ceases to transmit.

Once in this situation, it is difficult for software (such as gsmd) to gain synchronization of commands and responses.

The best solution is to avoid the problem to begin with. Simply ensure that the serial port is set to "no-echo" mode before the GSM modem is enabled and powered up. This sequence illustrates how this is normally done:

stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

(Note that the stty command argument syntax is somewhat unusual: "-echo" means "disable echo", while "echo" means "enable echo".)

==== Avoiding RTSCTS Lockup ====

Hardware flow control uses additional signals in addition to the serial data in and out signals on the serial port to control the flow of the data. Specifically, when hardware flow control is enabled, a given endpoint is expected to assert its RTS (Request To Send) line when it has data to transmit, and not transit that data until it sees a CTS (Clear TO Send) signal from the other end. In this fashion, buffer overruns and data loss are avoided.

The GSM modem requires that hardware flow control be enabled in order to communicate with the host. However, the console lacks the RTS and CTS signals and thus is unable to communicate if hardware flow control is enabled. But what really makes this problem serious is that if hardware flow control is enabled while the serial port is switched to the console, and the (small) transmit buffer for the port fills (such as a kernel log message), the Linux kernel will lock up, and become completely non-responsive. There is no recovery mechanism for this other than to disconnect the device from its USB port or charger, and remove the battery.

One solution to this is to disable the use of the serial port as a console for the kernel. However, this is greatly inconvenient - the knowledgeable user with a debug board will usually wish to have a console available, and the novice user will probably wish to avoid changing the u-boot variables in order to disable the console. So, a better approach is to avoid this situation by taking great care when powering-up, resetting, or powering-down the modem. The following sequence illustrates how to switch the serial port back to the console mode safely:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

=== Resetting the GSM Modem ===

The GSM modem can be effectively reset by changing the state of the Power-On GPIO from off to on -- in other words, just disable the GSM modem and re-enable it. The safe way to accomplish this is to combine the two sequences above:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

It should be noted that this reset sequence will also power up the modem if it is not enabled and powered up to begin with. For this reason, the reset sequence above should be used for both power-up and reset purposes.

=== Powering Off the GSM Modem ===

Powering off the GSM modem on the GTA01 can only be done by issuing the '''AT@POFF''' command to the device. In order to issue this command, it is usually necessary to return it to a known state. So the normal mechanism is to issue the reset operation (above), wait for a short period of time (1 second seems to be sufficient), and send the '''AT@POFF''' command. This should be followed by an additional short delay (to allow the text to be transmitted), and then the serial port can be switched back to the console. The following script accomplishes this:

### Reset the modem to place it in a known state
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

### Now enable hardware flow control, and transmit the sequence
stty -F /dev/ttySAC0 crtscts
sleep 1
echo -e "AT@POFF\r" >/dev/ttySAC0
sleep 1

### Finally, we disable flow control, and switch back the port
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

=== Eliminating echo on the non-neo end of phone calls ===
Here is the modified /etc/gsmhandset.state that eliminates echo during calls (at least for [[User:Wurp]]): http://drivehq.com/file/df.aspx/publish/sagacis/PublicFolder/handset.sagacis.state
[[Category:Hardware ]]
[[Category:Supported Phone| ]]
[[Category:Neo1973 Hardware]]
[[Category:Neo1973 Hardware]]
[[Category:GSM]]

Neo 1973 and Neo FreeRunner gsm modem

2008-03-10T19:12:11Z

Henrikp: /* Avoiding RTSCTS Lockup */

This page is about the [[Neo1973]] GTA01 (and GTA02) GSM Modem, based on the Ti Calypso chipset.

== [[Hardware:AT Commands|AT command]] interface ==

=== Sending Commands ===
To send commands to the GSM modem, you may use
cu -l /dev/ttySAC0
or use gsmd and libgsmd-tool for a less direct method.

If you connect directly (via cu) you must `chown uucp.uucp /dev/ttySAC0` first since cu is picky about permissions.

libgsmd-tool is less functional than the direct raw connection to the modem.

{|
Note: If you use cu -l /dev/ttySAC0 to enter commands, type "~." to quit
|}

=== Standard AT commands ===
The GSM modem follows GSM [http://www.3gpp.org/ftp/Specs/html-info/0705.htm TS07.05], [http://www.3gpp.org/ftp/Specs/html-info/0707.htm 07.07] and [http://www.3gpp.org/ftp/Specs/html-info/0710.htm 07.10] very closely.

[http://www.3gpp.org/specs/numbering.htm 3gpp.org] has information about 3G and GSM specifications

=== TI proprietary AT commands ===

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, OpenMoko cannot provide a reference documentation to those commands. Using the standards-compliant '''AT+CLAC''', you will notice that the non-standard commands also show up in the command listing.

You will also notice that those non-standard commands are prefixed with '''AT%''' rather than '''AT+''' for the standards-compliant commands.

Thus, we welcome our user and developer community to play with those commands and document them here. Since we never have released any NDA documentation to our community, there is no legal issue.

Note that the syntax and the interpretation of the output of the commands listed here are only educated guesses and should not be relied on. Part of the proprietary command set has identical or similar usage as on other modems in the market, some of which have fully opened specifications and information about these commands can be taken from their datasheets (some known similar modems with open specs: ''BenQ M22A'' and ''M23A'', ''Enfora Enabler-G [http://www.enfora.com/index.cgi?CONTENT_ID=376&User:LANGUAGE=en II] / [http://www.enfora.com/index.cgi?CONTENT_ID=377&User:LANGUAGE=en III]'' and ''SPT 1834'').

==== AT%VER ====
Prints the firmware component versions.

The modem's response looks like this on an un-updated phase-0 [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phone:

%VER: aci sean non_clearcase 15:11:24 17/04/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: l2r a086 ** NONE ** 10:21:37 28/03/07
%VER: ra a086 ** NONE ** 10:25:01 28/03/07
%VER: rlp a086 ** NONE ** 10:25:12 28/03/07
%VER: fad a086 ** NONE ** 10:18:09 28/03/07
%VER: t30 a086 ** NONE ** 10:29:01 28/03/07

For a [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phase 1 phone, produced start of september:

%VER: aci sean non_clearcase 12:32:56 24/08/07
%VER: cc a086 ** NONE ** 14:07:10 08/06/07
%VER: dl a086 ** NONE ** 14:07:46 08/06/07
%VER: mm a086 ** NONE ** 14:11:52 08/06/07
%VER: rr a086 ** NONE ** 14:13:01 08/06/07
%VER: sim a086 ** NONE ** 14:13:54 08/06/07
%VER: sms a086 ** NONE ** 14:14:20 08/06/07
%VER: ss a086 ** NONE ** 14:15:52 08/06/07
%VER: alr a086 ** NONE ** 14:06:38 08/06/07
%VER: l2r a086 ** NONE ** 14:10:36 08/06/07
%VER: ra a086 ** NONE ** 14:12:32 08/06/07
%VER: rlp a086 ** NONE ** 14:12:40 08/06/07
%VER: fad a086 ** NONE ** 14:08:06 08/06/07

For a [[Neo1973_Hardware#GTA01Bv3|GTA01Bv3]] phase 0 phone:

%VER: aci sean non_clearcase 10:46:06 29/08/06
%VER: cc a086 non_clearcase 14:53:59 28/08/06
%VER: dl a086 non_clearcase 14:54:40 28/08/06
%VER: mm a086 non_clearcase 14:59:25 28/08/06
%VER: rr a086 non_clearcase 15:00:11 28/08/06
%VER: sim a086 non_clearcase 15:00:57 28/08/06
%VER: sms a086 non_clearcase 15:01:23 28/08/06
%VER: ss a086 non_clearcase 15:02:22 28/08/06
%VER: alr a086 non_clearcase 14:53:19 28/08/06
%VER: l2r a086 non_clearcase 14:58:02 28/08/06
%VER: ra a086 non_clearcase 14:59:50 28/08/06
%VER: rlp a086 non_clearcase 14:59:56 28/08/06
%VER: fad a086 non_clearcase 14:55:04 28/08/06
%VER: t30 a086 non_clearcase 15:02:27 28/08/06

The second column lists firmware component names (e.g. aci = AT Command Interface). The third column is the user name of the engineer who last modified given component. The rightmost column is probably the last time someone worked on it (Please note that the name 'sean' here is not Sean Moss-Pultz :) while a086 is an anonymous TI engineer's nick, meaning that the component has not been modified at FIC).

==== AT%A ====
Print values from an ADC.

This command is not listed in AT+CLAC output but it is triggered by any input that starts with AT%A except AT%ALS (''Alternative Line Service'') and AT%ATR, which are other proprietary AT commands. So for example AT%ABCD,HELLO will also run this commands. On my Neo modem it prints a line containing nine values of the form ADC <number> = <value>:

AT%A
EXT: I
ADC 0 = e19, ADC 1 = 0, ADC 2 = d, ADC 3 = 6ea, ADC 4 = a25, ADC 5 = 9fc, ADC 6 = 96d, ADC 7 = 0, ADC 8 = 6

It would seem there's an ADC (analog-to-digital converter) module in the modem with nine input lines connected to it and the values on these lines are reported by this command in hexadecimal format. The values change over time. Inputs 1 and 7 always show zero on my modem, input 1 value changes slightly (+/- 20), while values on inputs 3, 4, 5, 6 and 8 change seemingly randomly in the range 0x000 - 0xfff (it would seem the chip is 12-bit).

==== AT%NRG ====
The AT%NRG (''Network registration and service selection'') is an expansion of the AT+COPS command. It allows specifying the service state of the registration, in addition to AT+COPS functionality. It doesn't however allow listing all present operators (use AT+COPS for this).

==== AT%EM ====
Execution of ''Engineering Mode'' commands. Allows viewing the information accessible to the modem but not available through standard GSM AT commands set such as detailed information on the current Serving Cell (the one we're registered with), its neighbouring cells, the GPRS/EDGE availability and SIM card data.

Citing Enfora Inc. Application Note EDG0108TN01:
''The purpose of Engineering Mode (EM) is to provide means to observe the behavior of the mobile station and the settings of the network as counterpart and therefore defines a lot of possibilities to analyze the network. The EM can be used for observation of a defined data set during functional test and field test.''

''Warning: The display of certain parameters is dependent on the wireless network sending the correct information in the System Information Packets. There is no guaranty that the information is always forwarded from the network. At times data may not be present to display in the Engineering Mode responses.''

Syntax:
AT%EM=<mode>,<command>
Allowed <mode> values:
* 2 - AT command mode
* 3 - PCO mode
I only describe the AT mode commands here. Commands are in range 1 to 13:
AT%EM=2,1 Serving Cell Information
AT%EM=2,2 Serving Cell GPRS Information
AT%EM=2,3 Neighbour Cell Information
AT%EM=2,4 Location and Paging Parameters
AT%EM=2,5 PLMN Parameters
AT%EM=2,6 Ciphering, Hopping, DTX Parameters
AT%EM=2,7 Power Parameters
AT%EM=2,8 Identity Parameters
AT%EM=2,9 Firmware components versions
AT%EM=2,10 GMM Information
AT%EM=2,11 GRLC Information
AT%EM=2,12 AMR Configuration Information
AT%EM=2,13 PDP Information

===== Serving Cell Information (2,1) =====
Response format:
%EM: <afrcn>,<c1>,<c2>,<rxlev>,<bsic>,<cell_id>,<dsc>,<txlev>,<tn>,<rlt>,<tav>,<rxlev_f>,<rxlev_s>,<rxqual_f>,<rxqual_s>,<lac>,<cba>,<cbq>,<cell_type_ind>,<vocoder>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || arfcn || Current Channel Number ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentifier ||
|-
|7 || dsc || Downlink Signaling Counter || current counter value
|-
|8 || txlev || Transmit Power Level ||
|-
|9 || tn || Timeslot Number ||
|-
|10 || rlt || Radio Link Timeout Counter ||
|-
|11 || tav || Timing Advance ||
|-
|12 || rxlev_f || Received Field Strength full ||
|-
|13 || rxlev_s || Received Field Strength sub ||
|-
|14 || rxqual_f || Received Quality full ||
|-
|15 || rxqual_s || Received Quality sub ||
|-
|16 || lac || Location Area Code ||
|-
|17 || cba || Cell Bar Access ||
|-
|18 || cbq || Cell Bar Qualifier ||
|-
|19 || Cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|20 || vocoder || Vocoder || Sig/speech/efr/amr/14.4/9.6/4.8/2.4
|}

According to http://www.qrctech.com/freq_chart_24x36.pdf, frequencies can be calculated using the arfcn field like this:
if 172 < arfcn < 252 then freq = 869 + (arfcn -127) x 0.2 MHz # 850 band
if 511 < arfcn < 811 then freq = 1930 + (arfcn - 511) x 0.2 MHz # 1900 band
if 1 < arfcn < 124 then freq = 935 + (arfcn * 0.2) MHz # 900 band (original alloc)
if 974 < arfcn < 1023 then freq = 925 + (arfcn - 974) x 0.2 MHz # 900 band E-GSM
if 511 < arfcn < 886 then freq = 1805 + (arfcn - 511) x 0.2 MHz # 1800 band

Notice the 1800 and 1900 bands have the same channel ids and nearly the same algorithm with a different starting point.

===== Serving Cell GPRS Information (2,2) =====
Response format:
%EM: <nts>,<nmo>,<spgc_ccch_sup>,<priority_access_thr>,<cba>,<rac>,<tav>,<dsc>,<c31>,<c32>,<band_ind>,<pfc_supp_n_w>,<ccn_mode_sts>,<Psi_sts_suppt>,<edge_support>,<epcr_support>,<bep_period>,<bss_paging_coord>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || nts || PCCCH_TIMESLOT || Number of downlink timeslots
|-
|2 || nmo || Network Mode of Operation ||
|-
|3 || spgc_ccch_sup || Network Control-spgc_ccch_sup || Network support for split paging
|-
|4 || priority_access_thr || Network Control-Priority_Access_Threshold || packet access to the NW according to priority level
|-
|5 || cba || Cell Bar Access ||
|-
|6 || rac || Routing Area Code ||
|-
|7 || tav || Timing Advance ||
|-
|8 || dsc || Downlink Signal Counter ||
|-
|9 || c31 || Cell-reselect Criterion C31 ||
|-
|10 || c32 || Cell-reselect Criterion C32 ||
|-
|11 || band_ind || Band Indicator ||
|-
|12 || pfc_supp_n_w || PFC Support ||
|-
|13 || ccn_mode_sts || CCN Mode ||
|-
|14 || Psi_sts_suppt || PSI Support ||
|-
|15 || edge_support || EDGE Support ||
|-
|16 || epcr_support || EPCR Support ||
|-
|17 || bep_period || BEP Period ||
|-
|18 || bss_paging_coord || BSS Paging ||
|}

===== Neighbour Cell Information (2,3) =====
The first line of response is of the format %EM: <number of cells listed>, where the maximum seems to be 6, one cell for each channel. The next sixteen lines list the values of each of the parameters for each of the cells.
{|
! Parameter no. !! Short name !! Meaning !! Remarks
|-
|1 || arfcn || BCCH channel ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentity ||
|-
|7 || lac || Location Area Code ||
|-
|8 || frame_offset || Frame Offset ||
|-
|9 || time_alignmnt || Time Alignment ||
|-
|10 || cba || Cell Bar Access ||
|-
|11 || cbq || Cell Bar Qualifier ||
|-
|12 || cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|13 || rac || Routing Area Code ||
|-
|14 || cell_resel_offset || Cell-reselection Offset ||
|-
|15 || temp_offset || Temporary Offset ||
|-
|16 || rxlev_acc_min || Rxlen access min ||
|}
My Neo1973 reports:
AT%EM=2,3
%EM: 6
763,766,771,778,780,773
20,8,14,18,17,8
20,8,14,18,17,8
73,46,54,51,13,12
6753,10951,3531,0,1933,1924
100,100,300,300,300,100
80229,961995,0,1166923,0,2715553
3504,724,0,3724,4,1112
0,0,0,0,0,0
0,0,0,0,0,0
2,2,2,2,2,2
0,0,0,0,0,0
0,0,0,0,0,0
0,0,0,0,0,0
10,10,10,10,10,10

OK

===== Location and Paging Parameters (2,4) =====
Response format:
%EM: <bs_pa_mfrms>,<t3212>,<mcc[0]><mcc[1]><mcc[2]>,<mnc[0]><mnc[1]><mnc[2]>,<tmsi>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || bs_pa_mfrms || BS PA MFRMS paging repeat period
|-
|2 || t3212 || Periodic location updating interval
|-
|3 || mcc || [http://en.wikipedia.org/wiki/Mobile_country_code Mobile Country Code]
|-
|4 || mnc || [http://en.wikipedia.org/wiki/Mobile_Network_Code Mobile Network Code]
|-
|5 || tmsi || [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] (in binary)
|}
The MCC and MNC values are the same values that are used to form the Mobile Operator names used by the standard AT+COPS and AT+COPN commands in numeric format. The TMSI is the same number that [http://wiki.openmoko.org/wiki/GTA01_gsm_modem#Identity_Parameters_.282.2C8.29 AT%EM=2,8] gives, just in a different format.

===== PLMN Parameters (2,5) =====
Response format:
%EM: <no_creq_max>,<reest_flag>,<txpwr_max>,<rxlev_min>,<rel_cs>,<sgsnr_rel>,<mscr_rel>,<net_rel>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || no_creq_max || Max. number or retries for channel requests
|-
|2 || reest_flag || Re-establishment Flag
|-
|3 || txpwr_max || MS TXPWR MAX CCCH
|-
|4 || rxlev_min || Rxlev_access_min
|-
|5 || rel_cs || Release Cause (only the last release cause is remembered)
|-
|6 || sgsnr_rel || SGSNR Release
|-
|7 || mscr_rel || MSCR Release
|-
|8 || net_rel || Network Release Info
|}
===== Ciphering, Hopping, DTX Parameters (2,6) =====
{{todo|Fill in}}
===== Power Parameters (2,7) =====
The output consits of two lines, first line containing 12 comma-separated values and the second line 18 comma-separated values, such as:
AT%EM=2,7
%EM: 1,1,0,0,0,1,1,0,0,0,1,0
6,0,0,0,0,1,1,1,4,0,0,0,0,1,0,0,0,0

OK
On the first line (called Classmark 2) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Revision Level ||
|-
|2 || Controlled Early Classmark Sending || 1 means enabled
|-
|3 || A5/1 Encryption algorithm || 0 means available
|-
|4 || RF Power capability ||
|-
|5 || Pseudo-synchronisation capability || 1 means present
|-
|6 || SS Screening Indicator ||
|-
|7 || SMS capability ||
|-
|8 || Frequency capability ||
|-
|9 || Classmark 3 options || 1 means supported
|-
|10 || CM Service Prompt || 1 means supported
|-
|11 || A5/3 Encryption algorithm || 1 means available
|-
|12 || A5/2 Encryption algorithm || 1 means available
|}
On the second line (called Classmark 3) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Multiband support ||
|-
|2 || A5/7 Encryption algorithm || 1 means available
|-
|3 || A5/6 Encryption algorithm || 1 means available
|-
|4 || A5/5 Encryption algorithm || 1 means available
|-
|5 || A5/4 Encryption algorithm || 1 means available
|-
|6 || Valid Radio capability 2 || ??
|-
|7 || Associated Radio capability 2 ||
|-
|8 || Valid Radio capability 1 || ??
|-
|9 || Associated Radio capability 1 ||
|-
|10 || Valid R Support || ??
|-
|11 || R Support || R-GSM Class
|-
|12 || Valid Multi-slot Class || ??
|-
|13 || Multi-slot Class ||
|-
|14 || Unicode 2 treatment ||
|-
|15 || Extended Measurement capability || 1 means supported
|-
|16 || Valid Switch-measure-value || ??
|-
|17 || Switch-measure-value ||
|-
|18 || Switch-measure-switch-value ||
|}

===== Identity Parameters (2,8) =====
Response format:
%EM: <imeisv>
<imsi>
<tmsi>

OK
The IMEISV line contains 20 numbers separated by commas, the numbers on positions 5 to 18 are the digits of the [http://en.wikipedia.org/wiki/IMEI IMEI] number as returned by AT+CGSN. The second line contains another 20 numbers and the numbers on positions 5 to 19 form the digits of your SIM card's [http://en.wikipedia.org/wiki/IMSI IMSI] number, as returned by the AT+CIMI command. The last line contains the [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] number in plain format (ten digits).

===== Firmware components versions (2,9) =====
Prints version information for different components of the modem's firmware. The format and the scope of the information presented is identical to that in [[#AT%VER|AT%VER]] output with the exception that only a subset of all of the components are listed:
AT%EM=2,9
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07

OK
===== GMM Information (2,10) =====
{{todo|Fill in}}
===== GRLC Information (2,11) =====
{{todo|Fill in}}
===== AMR Configuration Information (2,12) =====
{{todo|Fill in}}
===== PDP Information (2,13) =====
{{todo|Fill in}}

=== GSM Modem OpenMoko commands ===

The Ti calypso GSM Modem firmware has been extended by OpenMoko specific AT
commands. This page documents those commands.

==== AT@POFF ====

Powers off the GSM Modem. No parameters/options.

==== AT@ST ====

configure the sidetone level for voice calls generated inside the GSM Modem. This should normally be off, since the sidetone in GTA01/GTA02 is generated inside the the [[WM8753|wolfson audio codec]].

AT@ST?
+ST: -5
OK
AT@ST=?
@ST: (-26,-23,-20,-17,-14,-11,-8,-5,-2,1)
OK
AT@ST="-26"
OK

-26 means turn off the sidetone totally.

==== AT@AUL ====

audio table load.

AT@AUL="0"
OK
AT@AUL=?
@AUL:(0)

This audio table is a collection of audio parameters for GSM calibrated by hardware engineers,

Mode of microphone
Gain of microphone
FM PGA gain setting
Bias setting for microphone
FIR coefficients
ANR parameters
Level of side tone
AEC parameters
Echo suppressor
Mode of speaker
Gain of speaker
Extra gain for AUDIO_SPEAKER_HANDSET and AUDIO_SPEAKER_HANDFREE modes
Enable/Disable filter
Enable/Disable high-pass filter
FIR coefficients
IIR uplink/downlink coefficients
Limiter parameters
Level of speaker
Mode of speaker
State of speaker
Sampling frequency
Level of volume
AGC parameters
DRC parameters

The audio table will be stored in the flash file system within GSM modem, you can load it through this command.

For now, we only provide one configuration, that is "0".

If AT@AUL="0" responds with ERROR, it means there's no audio table existing and the GSM firmware will use default values.

== Wakeup of CPU from GSM Modem ==

=== Problem description ===

For power management reasons, it is absolutely neccessary that only the minimal
required parts of the device are powered at any given time. If you carry your
Neo in your pocket, then all it should do is stay online with the GSM network,
and notify you in case there's an incoming call/sms (like other phones).

During that time, the Neo1973 Application Processor (s3c24xx) is suspended,
i.e. not powered at all. The SDRAM is in self-refresh mode.

In this suspend mode (which Samsung calls by the funny name of POWER_OFF), the
processor is not able to receive any data from the GSM Modem. Nor is it able
to detect incoming characters and wake up the CPU. The only wake up sources
are a certain set of external interrupts (EINT).

Thus, the GSM Modem GPIO line IO1 was connected with the Samsung EINT1, and
the GSM Modem firmware contains some special logic to generate an interrupt
(and thus wake-up event) to the CPU.

=== Logic for problem solution ===

Preconditions
# The default state of GSM Modem output IO1 is logical LOW.

Anytime the modem has pending data on the MODEM-UART channel, it
# checks if CTS_MODEM permits sending of data
## if CTS_MODEM permits sending of UART data, go to '4.2'
# [implicit: CTS_MODEM does not permit sending of UART data]
## set IO1 line to logical HIGH level
## buffer modem data [until buffer is full, after which data gets discarded]
# wait until CTS_MODEM permits sending of UART data
# as soon as CTS_MODEM permits sending of UART data,
## set IO1 back to logical LOW level
## start sending of UART data
# once all data is transmitted, return to idle state. When next data item is to be transmitted, start again from '1'

=== Software implementation ===

{{note|This is the plan, it has not been fully implemented yet}}

# a firmware post may-16-2007 needs to be present in the gsm modem. This is true for all phones bought during phase 1 in the online shop. However, I currently don't really know what firmware version was present in the GTA01Bv4 that we sent to phase 0.
# the suspend code probably still needs to correctly configure the RTS/CTS lines (i.e. put them in GPIO mode, and set them to their desired "don't send any more characters" level)

So in this case, any data from the GSM modem will wake up the cpu for processing of that data. The GSM modem has some internal buffer (I don't know how big right now) that should be sufficient for buffering the data until the CPU is alive.

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside OpenMoko staff.

== Power On, Power Off, and Reset of the GTA01 GSM Modem ==

=== GSM Modem Connections ===

The GTA01 GSM modem communicates via a standard serial port to the host system. The port operates at 115200 baud, 8 bits, no parity, and requires hardware flow control (RTSCTS) to operate. Due to the fact that the host CPU has only a pair of serial ports but there are three devices that wish to use them, the GSM modem port is actually shared with the serial console (the third device is the GPS chip, which has exclusive use of the second serial port).

A GPIO (General Purpose IO) pin controls the switching of the serial port between the console and the GSM modem. Another GPIO is used to turn on the power to the GSM modem. On older versions of the GTA01 a third GPIO could be used to reset the GSM modem; this signal proved to cause difficulties with the modem, and on all the GTA01 units sold this GPIO line is not connected. The driver combines the the switching of the serial port to the GSM modem and the power-on signal to the modem into a single operation; the two cannot be controlled independently from user-space (at the time of this writing).

It is important to note that the GPIO controlling the power-on of the GSM modem can only signal to the modem to turn itself on -- turning this GPIO off does not power off the GSM modem. Instead, the '''AT@POFF''' sequence must be sent to the modem in order to perform a power off.

Further complicating power control of the GTA01 GSM modem is the fact that the modem draws power from the battery/charger side of the power management circuitry -- this means that turning off the power to the host CPU on the GTA01 does not turn off the power to the modem. In real-world operation, this means that unless the shutdown procedure for the host cpu's operating system issues the '''AT@POFF''' command to power off the GSM modem, the modem will remain turned on, drawing power from the battery even thought the host CPU is completely powered off.

=== The Power-On Sequence ===

The sharing of the serial port between the console and the GSM modem results in the need for a very specific power-on and power-off sequence. Two major problems exist that must be avoided: infinite echos, and RTSCTS lockup.

==== Avoiding Infinite Echos ====

By default, the serial port is initialized in "echo" mode -- meaning that any characters sent to the serial port from the console will be echoed back to the console. Upon power-up or reset, the GSM modem also echos back characters it receives. So unless action is taken to disable the serial port's echo before the GSM modem is powered on, an infinite echo will result. The modem will print the standard "Interpretor Ready" message, which will be echoed back to it by the serial port driver, the modem will echo that back to the serial port again (adding some error text to the message), the serial port will echo that again, and this continues until buffers in either or both the serial port and the modem fill up, and one of them ceases to transmit.

Once in this situation, it is difficult for software (such as gsmd) to gain synchronization of commands and responses.

The best solution is to avoid the problem to begin with. Simply ensure that the serial port is set to "no-echo" mode before the GSM modem is enabled and powered up. This sequence illustrates how this is normally done:

stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on

(Note that the stty command argument syntax is somewhat unusual: "-echo" means "disable echo", while "echo" means "enable echo".)

==== Avoiding RTSCTS Lockup ====

Hardware flow control uses additional signals in addition to the serial data in and out signals on the serial port to control the flow of the data. Specifically, when hardware flow control is enabled, a given endpoint is expected to assert its RTS (Request To Send) line when it has data to transmit, and not transit that data until it sees a CTS (Clear TO Send) signal from the other end. In this fashion, buffer overruns and data loss are avoided.

The GSM modem requires that hardware flow control be enabled in order to communicate with the host. However, the console lacks the RTS and CTS signals and thus is unable to communicate if hardware flow control is enabled. But what really makes this problem serious is that if hardware flow control is enabled while the serial port is switched to the console, and the (small) transmit buffer for the port fills (such as a kernel log message), the Linux kernel will lock up, and become completely non-responsive. There is no recovery mechanism for this other than to disconnect the device from its USB port or charger, and remove the battery.

One solution to this is to disable the use of the serial port as a console for the kernel. However, this is greatly inconvenient - the knowledgeable user with a debug board will usually wish to have a console available, and the novice user will probably wish to avoid changing the u-boot variables in order to disable the console. So, a better approach is to avoid this situation by taking great care when powering-up, resetting, or powering-down the modem. The following sequence illustrates how to switch the serial port back to the console mode safely:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

=== Resetting the GSM Modem ===

The GSM modem can be effectively reset by changing the state of the Power-On GPIO from off to on -- in other words, just disable the GSM modem and re-enable it. The safe way to accomplish this is to combine the two sequences above:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

It should be noted that this reset sequence will also power up the modem if it is not enabled and powered up to begin with. For this reason, the reset sequence above should be used for both power-up and reset purposes.

=== Powering Off the GSM Modem ===

Powering off the GSM modem on the GTA01 can only be done by issuing the '''AT@POFF''' command to the device. In order to issue this command, it is usually necessary to return it to a known state. So the normal mechanism is to issue the reset operation (above), wait for a short period of time (1 second seems to be sufficient), and send the '''AT@POFF''' command. This should be followed by an additional short delay (to allow the text to be transmitted), and then the serial port can be switched back to the console. The following script accomplishes this:

### Reset the modem to place it in a known state
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

### Now enable hardware flow control, and transmit the sequence
stty -F /dev/ttySAC0 crtscts
sleep 1
echo -e "AT@POFF\r" >/dev/ttySAC0
sleep 1

### Finally, we disable flow control, and switch back the port
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

=== Eliminating echo on the non-neo end of phone calls ===
Here is the modified /etc/gsmhandset.state that eliminates echo during calls (at least for [[User:Wurp]]): http://drivehq.com/file/df.aspx/publish/sagacis/PublicFolder/handset.sagacis.state
[[Category:Hardware ]]
[[Category:Supported Phone| ]]
[[Category:Neo1973 Hardware]]
[[Category:Neo1973 Hardware]]
[[Category:GSM]]

Neo 1973 and Neo FreeRunner gsm modem

2008-03-10T19:11:54Z

Henrikp: /* Resetting the GSM Modem */

This page is about the [[Neo1973]] GTA01 (and GTA02) GSM Modem, based on the Ti Calypso chipset.

== [[Hardware:AT Commands|AT command]] interface ==

=== Sending Commands ===
To send commands to the GSM modem, you may use
cu -l /dev/ttySAC0
or use gsmd and libgsmd-tool for a less direct method.

If you connect directly (via cu) you must `chown uucp.uucp /dev/ttySAC0` first since cu is picky about permissions.

libgsmd-tool is less functional than the direct raw connection to the modem.

{|
Note: If you use cu -l /dev/ttySAC0 to enter commands, type "~." to quit
|}

=== Standard AT commands ===
The GSM modem follows GSM [http://www.3gpp.org/ftp/Specs/html-info/0705.htm TS07.05], [http://www.3gpp.org/ftp/Specs/html-info/0707.htm 07.07] and [http://www.3gpp.org/ftp/Specs/html-info/0710.htm 07.10] very closely.

[http://www.3gpp.org/specs/numbering.htm 3gpp.org] has information about 3G and GSM specifications

=== TI proprietary AT commands ===

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, OpenMoko cannot provide a reference documentation to those commands. Using the standards-compliant '''AT+CLAC''', you will notice that the non-standard commands also show up in the command listing.

You will also notice that those non-standard commands are prefixed with '''AT%''' rather than '''AT+''' for the standards-compliant commands.

Thus, we welcome our user and developer community to play with those commands and document them here. Since we never have released any NDA documentation to our community, there is no legal issue.

Note that the syntax and the interpretation of the output of the commands listed here are only educated guesses and should not be relied on. Part of the proprietary command set has identical or similar usage as on other modems in the market, some of which have fully opened specifications and information about these commands can be taken from their datasheets (some known similar modems with open specs: ''BenQ M22A'' and ''M23A'', ''Enfora Enabler-G [http://www.enfora.com/index.cgi?CONTENT_ID=376&User:LANGUAGE=en II] / [http://www.enfora.com/index.cgi?CONTENT_ID=377&User:LANGUAGE=en III]'' and ''SPT 1834'').

==== AT%VER ====
Prints the firmware component versions.

The modem's response looks like this on an un-updated phase-0 [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phone:

%VER: aci sean non_clearcase 15:11:24 17/04/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: l2r a086 ** NONE ** 10:21:37 28/03/07
%VER: ra a086 ** NONE ** 10:25:01 28/03/07
%VER: rlp a086 ** NONE ** 10:25:12 28/03/07
%VER: fad a086 ** NONE ** 10:18:09 28/03/07
%VER: t30 a086 ** NONE ** 10:29:01 28/03/07

For a [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phase 1 phone, produced start of september:

%VER: aci sean non_clearcase 12:32:56 24/08/07
%VER: cc a086 ** NONE ** 14:07:10 08/06/07
%VER: dl a086 ** NONE ** 14:07:46 08/06/07
%VER: mm a086 ** NONE ** 14:11:52 08/06/07
%VER: rr a086 ** NONE ** 14:13:01 08/06/07
%VER: sim a086 ** NONE ** 14:13:54 08/06/07
%VER: sms a086 ** NONE ** 14:14:20 08/06/07
%VER: ss a086 ** NONE ** 14:15:52 08/06/07
%VER: alr a086 ** NONE ** 14:06:38 08/06/07
%VER: l2r a086 ** NONE ** 14:10:36 08/06/07
%VER: ra a086 ** NONE ** 14:12:32 08/06/07
%VER: rlp a086 ** NONE ** 14:12:40 08/06/07
%VER: fad a086 ** NONE ** 14:08:06 08/06/07

For a [[Neo1973_Hardware#GTA01Bv3|GTA01Bv3]] phase 0 phone:

%VER: aci sean non_clearcase 10:46:06 29/08/06
%VER: cc a086 non_clearcase 14:53:59 28/08/06
%VER: dl a086 non_clearcase 14:54:40 28/08/06
%VER: mm a086 non_clearcase 14:59:25 28/08/06
%VER: rr a086 non_clearcase 15:00:11 28/08/06
%VER: sim a086 non_clearcase 15:00:57 28/08/06
%VER: sms a086 non_clearcase 15:01:23 28/08/06
%VER: ss a086 non_clearcase 15:02:22 28/08/06
%VER: alr a086 non_clearcase 14:53:19 28/08/06
%VER: l2r a086 non_clearcase 14:58:02 28/08/06
%VER: ra a086 non_clearcase 14:59:50 28/08/06
%VER: rlp a086 non_clearcase 14:59:56 28/08/06
%VER: fad a086 non_clearcase 14:55:04 28/08/06
%VER: t30 a086 non_clearcase 15:02:27 28/08/06

The second column lists firmware component names (e.g. aci = AT Command Interface). The third column is the user name of the engineer who last modified given component. The rightmost column is probably the last time someone worked on it (Please note that the name 'sean' here is not Sean Moss-Pultz :) while a086 is an anonymous TI engineer's nick, meaning that the component has not been modified at FIC).

==== AT%A ====
Print values from an ADC.

This command is not listed in AT+CLAC output but it is triggered by any input that starts with AT%A except AT%ALS (''Alternative Line Service'') and AT%ATR, which are other proprietary AT commands. So for example AT%ABCD,HELLO will also run this commands. On my Neo modem it prints a line containing nine values of the form ADC <number> = <value>:

AT%A
EXT: I
ADC 0 = e19, ADC 1 = 0, ADC 2 = d, ADC 3 = 6ea, ADC 4 = a25, ADC 5 = 9fc, ADC 6 = 96d, ADC 7 = 0, ADC 8 = 6

It would seem there's an ADC (analog-to-digital converter) module in the modem with nine input lines connected to it and the values on these lines are reported by this command in hexadecimal format. The values change over time. Inputs 1 and 7 always show zero on my modem, input 1 value changes slightly (+/- 20), while values on inputs 3, 4, 5, 6 and 8 change seemingly randomly in the range 0x000 - 0xfff (it would seem the chip is 12-bit).

==== AT%NRG ====
The AT%NRG (''Network registration and service selection'') is an expansion of the AT+COPS command. It allows specifying the service state of the registration, in addition to AT+COPS functionality. It doesn't however allow listing all present operators (use AT+COPS for this).

==== AT%EM ====
Execution of ''Engineering Mode'' commands. Allows viewing the information accessible to the modem but not available through standard GSM AT commands set such as detailed information on the current Serving Cell (the one we're registered with), its neighbouring cells, the GPRS/EDGE availability and SIM card data.

Citing Enfora Inc. Application Note EDG0108TN01:
''The purpose of Engineering Mode (EM) is to provide means to observe the behavior of the mobile station and the settings of the network as counterpart and therefore defines a lot of possibilities to analyze the network. The EM can be used for observation of a defined data set during functional test and field test.''

''Warning: The display of certain parameters is dependent on the wireless network sending the correct information in the System Information Packets. There is no guaranty that the information is always forwarded from the network. At times data may not be present to display in the Engineering Mode responses.''

Syntax:
AT%EM=<mode>,<command>
Allowed <mode> values:
* 2 - AT command mode
* 3 - PCO mode
I only describe the AT mode commands here. Commands are in range 1 to 13:
AT%EM=2,1 Serving Cell Information
AT%EM=2,2 Serving Cell GPRS Information
AT%EM=2,3 Neighbour Cell Information
AT%EM=2,4 Location and Paging Parameters
AT%EM=2,5 PLMN Parameters
AT%EM=2,6 Ciphering, Hopping, DTX Parameters
AT%EM=2,7 Power Parameters
AT%EM=2,8 Identity Parameters
AT%EM=2,9 Firmware components versions
AT%EM=2,10 GMM Information
AT%EM=2,11 GRLC Information
AT%EM=2,12 AMR Configuration Information
AT%EM=2,13 PDP Information

===== Serving Cell Information (2,1) =====
Response format:
%EM: <afrcn>,<c1>,<c2>,<rxlev>,<bsic>,<cell_id>,<dsc>,<txlev>,<tn>,<rlt>,<tav>,<rxlev_f>,<rxlev_s>,<rxqual_f>,<rxqual_s>,<lac>,<cba>,<cbq>,<cell_type_ind>,<vocoder>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || arfcn || Current Channel Number ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentifier ||
|-
|7 || dsc || Downlink Signaling Counter || current counter value
|-
|8 || txlev || Transmit Power Level ||
|-
|9 || tn || Timeslot Number ||
|-
|10 || rlt || Radio Link Timeout Counter ||
|-
|11 || tav || Timing Advance ||
|-
|12 || rxlev_f || Received Field Strength full ||
|-
|13 || rxlev_s || Received Field Strength sub ||
|-
|14 || rxqual_f || Received Quality full ||
|-
|15 || rxqual_s || Received Quality sub ||
|-
|16 || lac || Location Area Code ||
|-
|17 || cba || Cell Bar Access ||
|-
|18 || cbq || Cell Bar Qualifier ||
|-
|19 || Cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|20 || vocoder || Vocoder || Sig/speech/efr/amr/14.4/9.6/4.8/2.4
|}

According to http://www.qrctech.com/freq_chart_24x36.pdf, frequencies can be calculated using the arfcn field like this:
if 172 < arfcn < 252 then freq = 869 + (arfcn -127) x 0.2 MHz # 850 band
if 511 < arfcn < 811 then freq = 1930 + (arfcn - 511) x 0.2 MHz # 1900 band
if 1 < arfcn < 124 then freq = 935 + (arfcn * 0.2) MHz # 900 band (original alloc)
if 974 < arfcn < 1023 then freq = 925 + (arfcn - 974) x 0.2 MHz # 900 band E-GSM
if 511 < arfcn < 886 then freq = 1805 + (arfcn - 511) x 0.2 MHz # 1800 band

Notice the 1800 and 1900 bands have the same channel ids and nearly the same algorithm with a different starting point.

===== Serving Cell GPRS Information (2,2) =====
Response format:
%EM: <nts>,<nmo>,<spgc_ccch_sup>,<priority_access_thr>,<cba>,<rac>,<tav>,<dsc>,<c31>,<c32>,<band_ind>,<pfc_supp_n_w>,<ccn_mode_sts>,<Psi_sts_suppt>,<edge_support>,<epcr_support>,<bep_period>,<bss_paging_coord>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || nts || PCCCH_TIMESLOT || Number of downlink timeslots
|-
|2 || nmo || Network Mode of Operation ||
|-
|3 || spgc_ccch_sup || Network Control-spgc_ccch_sup || Network support for split paging
|-
|4 || priority_access_thr || Network Control-Priority_Access_Threshold || packet access to the NW according to priority level
|-
|5 || cba || Cell Bar Access ||
|-
|6 || rac || Routing Area Code ||
|-
|7 || tav || Timing Advance ||
|-
|8 || dsc || Downlink Signal Counter ||
|-
|9 || c31 || Cell-reselect Criterion C31 ||
|-
|10 || c32 || Cell-reselect Criterion C32 ||
|-
|11 || band_ind || Band Indicator ||
|-
|12 || pfc_supp_n_w || PFC Support ||
|-
|13 || ccn_mode_sts || CCN Mode ||
|-
|14 || Psi_sts_suppt || PSI Support ||
|-
|15 || edge_support || EDGE Support ||
|-
|16 || epcr_support || EPCR Support ||
|-
|17 || bep_period || BEP Period ||
|-
|18 || bss_paging_coord || BSS Paging ||
|}

===== Neighbour Cell Information (2,3) =====
The first line of response is of the format %EM: <number of cells listed>, where the maximum seems to be 6, one cell for each channel. The next sixteen lines list the values of each of the parameters for each of the cells.
{|
! Parameter no. !! Short name !! Meaning !! Remarks
|-
|1 || arfcn || BCCH channel ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentity ||
|-
|7 || lac || Location Area Code ||
|-
|8 || frame_offset || Frame Offset ||
|-
|9 || time_alignmnt || Time Alignment ||
|-
|10 || cba || Cell Bar Access ||
|-
|11 || cbq || Cell Bar Qualifier ||
|-
|12 || cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|13 || rac || Routing Area Code ||
|-
|14 || cell_resel_offset || Cell-reselection Offset ||
|-
|15 || temp_offset || Temporary Offset ||
|-
|16 || rxlev_acc_min || Rxlen access min ||
|}
My Neo1973 reports:
AT%EM=2,3
%EM: 6
763,766,771,778,780,773
20,8,14,18,17,8
20,8,14,18,17,8
73,46,54,51,13,12
6753,10951,3531,0,1933,1924
100,100,300,300,300,100
80229,961995,0,1166923,0,2715553
3504,724,0,3724,4,1112
0,0,0,0,0,0
0,0,0,0,0,0
2,2,2,2,2,2
0,0,0,0,0,0
0,0,0,0,0,0
0,0,0,0,0,0
10,10,10,10,10,10

OK

===== Location and Paging Parameters (2,4) =====
Response format:
%EM: <bs_pa_mfrms>,<t3212>,<mcc[0]><mcc[1]><mcc[2]>,<mnc[0]><mnc[1]><mnc[2]>,<tmsi>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || bs_pa_mfrms || BS PA MFRMS paging repeat period
|-
|2 || t3212 || Periodic location updating interval
|-
|3 || mcc || [http://en.wikipedia.org/wiki/Mobile_country_code Mobile Country Code]
|-
|4 || mnc || [http://en.wikipedia.org/wiki/Mobile_Network_Code Mobile Network Code]
|-
|5 || tmsi || [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] (in binary)
|}
The MCC and MNC values are the same values that are used to form the Mobile Operator names used by the standard AT+COPS and AT+COPN commands in numeric format. The TMSI is the same number that [http://wiki.openmoko.org/wiki/GTA01_gsm_modem#Identity_Parameters_.282.2C8.29 AT%EM=2,8] gives, just in a different format.

===== PLMN Parameters (2,5) =====
Response format:
%EM: <no_creq_max>,<reest_flag>,<txpwr_max>,<rxlev_min>,<rel_cs>,<sgsnr_rel>,<mscr_rel>,<net_rel>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || no_creq_max || Max. number or retries for channel requests
|-
|2 || reest_flag || Re-establishment Flag
|-
|3 || txpwr_max || MS TXPWR MAX CCCH
|-
|4 || rxlev_min || Rxlev_access_min
|-
|5 || rel_cs || Release Cause (only the last release cause is remembered)
|-
|6 || sgsnr_rel || SGSNR Release
|-
|7 || mscr_rel || MSCR Release
|-
|8 || net_rel || Network Release Info
|}
===== Ciphering, Hopping, DTX Parameters (2,6) =====
{{todo|Fill in}}
===== Power Parameters (2,7) =====
The output consits of two lines, first line containing 12 comma-separated values and the second line 18 comma-separated values, such as:
AT%EM=2,7
%EM: 1,1,0,0,0,1,1,0,0,0,1,0
6,0,0,0,0,1,1,1,4,0,0,0,0,1,0,0,0,0

OK
On the first line (called Classmark 2) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Revision Level ||
|-
|2 || Controlled Early Classmark Sending || 1 means enabled
|-
|3 || A5/1 Encryption algorithm || 0 means available
|-
|4 || RF Power capability ||
|-
|5 || Pseudo-synchronisation capability || 1 means present
|-
|6 || SS Screening Indicator ||
|-
|7 || SMS capability ||
|-
|8 || Frequency capability ||
|-
|9 || Classmark 3 options || 1 means supported
|-
|10 || CM Service Prompt || 1 means supported
|-
|11 || A5/3 Encryption algorithm || 1 means available
|-
|12 || A5/2 Encryption algorithm || 1 means available
|}
On the second line (called Classmark 3) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Multiband support ||
|-
|2 || A5/7 Encryption algorithm || 1 means available
|-
|3 || A5/6 Encryption algorithm || 1 means available
|-
|4 || A5/5 Encryption algorithm || 1 means available
|-
|5 || A5/4 Encryption algorithm || 1 means available
|-
|6 || Valid Radio capability 2 || ??
|-
|7 || Associated Radio capability 2 ||
|-
|8 || Valid Radio capability 1 || ??
|-
|9 || Associated Radio capability 1 ||
|-
|10 || Valid R Support || ??
|-
|11 || R Support || R-GSM Class
|-
|12 || Valid Multi-slot Class || ??
|-
|13 || Multi-slot Class ||
|-
|14 || Unicode 2 treatment ||
|-
|15 || Extended Measurement capability || 1 means supported
|-
|16 || Valid Switch-measure-value || ??
|-
|17 || Switch-measure-value ||
|-
|18 || Switch-measure-switch-value ||
|}

===== Identity Parameters (2,8) =====
Response format:
%EM: <imeisv>
<imsi>
<tmsi>

OK
The IMEISV line contains 20 numbers separated by commas, the numbers on positions 5 to 18 are the digits of the [http://en.wikipedia.org/wiki/IMEI IMEI] number as returned by AT+CGSN. The second line contains another 20 numbers and the numbers on positions 5 to 19 form the digits of your SIM card's [http://en.wikipedia.org/wiki/IMSI IMSI] number, as returned by the AT+CIMI command. The last line contains the [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] number in plain format (ten digits).

===== Firmware components versions (2,9) =====
Prints version information for different components of the modem's firmware. The format and the scope of the information presented is identical to that in [[#AT%VER|AT%VER]] output with the exception that only a subset of all of the components are listed:
AT%EM=2,9
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07

OK
===== GMM Information (2,10) =====
{{todo|Fill in}}
===== GRLC Information (2,11) =====
{{todo|Fill in}}
===== AMR Configuration Information (2,12) =====
{{todo|Fill in}}
===== PDP Information (2,13) =====
{{todo|Fill in}}

=== GSM Modem OpenMoko commands ===

The Ti calypso GSM Modem firmware has been extended by OpenMoko specific AT
commands. This page documents those commands.

==== AT@POFF ====

Powers off the GSM Modem. No parameters/options.

==== AT@ST ====

configure the sidetone level for voice calls generated inside the GSM Modem. This should normally be off, since the sidetone in GTA01/GTA02 is generated inside the the [[WM8753|wolfson audio codec]].

AT@ST?
+ST: -5
OK
AT@ST=?
@ST: (-26,-23,-20,-17,-14,-11,-8,-5,-2,1)
OK
AT@ST="-26"
OK

-26 means turn off the sidetone totally.

==== AT@AUL ====

audio table load.

AT@AUL="0"
OK
AT@AUL=?
@AUL:(0)

This audio table is a collection of audio parameters for GSM calibrated by hardware engineers,

Mode of microphone
Gain of microphone
FM PGA gain setting
Bias setting for microphone
FIR coefficients
ANR parameters
Level of side tone
AEC parameters
Echo suppressor
Mode of speaker
Gain of speaker
Extra gain for AUDIO_SPEAKER_HANDSET and AUDIO_SPEAKER_HANDFREE modes
Enable/Disable filter
Enable/Disable high-pass filter
FIR coefficients
IIR uplink/downlink coefficients
Limiter parameters
Level of speaker
Mode of speaker
State of speaker
Sampling frequency
Level of volume
AGC parameters
DRC parameters

The audio table will be stored in the flash file system within GSM modem, you can load it through this command.

For now, we only provide one configuration, that is "0".

If AT@AUL="0" responds with ERROR, it means there's no audio table existing and the GSM firmware will use default values.

== Wakeup of CPU from GSM Modem ==

=== Problem description ===

For power management reasons, it is absolutely neccessary that only the minimal
required parts of the device are powered at any given time. If you carry your
Neo in your pocket, then all it should do is stay online with the GSM network,
and notify you in case there's an incoming call/sms (like other phones).

During that time, the Neo1973 Application Processor (s3c24xx) is suspended,
i.e. not powered at all. The SDRAM is in self-refresh mode.

In this suspend mode (which Samsung calls by the funny name of POWER_OFF), the
processor is not able to receive any data from the GSM Modem. Nor is it able
to detect incoming characters and wake up the CPU. The only wake up sources
are a certain set of external interrupts (EINT).

Thus, the GSM Modem GPIO line IO1 was connected with the Samsung EINT1, and
the GSM Modem firmware contains some special logic to generate an interrupt
(and thus wake-up event) to the CPU.

=== Logic for problem solution ===

Preconditions
# The default state of GSM Modem output IO1 is logical LOW.

Anytime the modem has pending data on the MODEM-UART channel, it
# checks if CTS_MODEM permits sending of data
## if CTS_MODEM permits sending of UART data, go to '4.2'
# [implicit: CTS_MODEM does not permit sending of UART data]
## set IO1 line to logical HIGH level
## buffer modem data [until buffer is full, after which data gets discarded]
# wait until CTS_MODEM permits sending of UART data
# as soon as CTS_MODEM permits sending of UART data,
## set IO1 back to logical LOW level
## start sending of UART data
# once all data is transmitted, return to idle state. When next data item is to be transmitted, start again from '1'

=== Software implementation ===

{{note|This is the plan, it has not been fully implemented yet}}

# a firmware post may-16-2007 needs to be present in the gsm modem. This is true for all phones bought during phase 1 in the online shop. However, I currently don't really know what firmware version was present in the GTA01Bv4 that we sent to phase 0.
# the suspend code probably still needs to correctly configure the RTS/CTS lines (i.e. put them in GPIO mode, and set them to their desired "don't send any more characters" level)

So in this case, any data from the GSM modem will wake up the cpu for processing of that data. The GSM modem has some internal buffer (I don't know how big right now) that should be sufficient for buffering the data until the CPU is alive.

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside OpenMoko staff.

== Power On, Power Off, and Reset of the GTA01 GSM Modem ==

=== GSM Modem Connections ===

The GTA01 GSM modem communicates via a standard serial port to the host system. The port operates at 115200 baud, 8 bits, no parity, and requires hardware flow control (RTSCTS) to operate. Due to the fact that the host CPU has only a pair of serial ports but there are three devices that wish to use them, the GSM modem port is actually shared with the serial console (the third device is the GPS chip, which has exclusive use of the second serial port).

A GPIO (General Purpose IO) pin controls the switching of the serial port between the console and the GSM modem. Another GPIO is used to turn on the power to the GSM modem. On older versions of the GTA01 a third GPIO could be used to reset the GSM modem; this signal proved to cause difficulties with the modem, and on all the GTA01 units sold this GPIO line is not connected. The driver combines the the switching of the serial port to the GSM modem and the power-on signal to the modem into a single operation; the two cannot be controlled independently from user-space (at the time of this writing).

It is important to note that the GPIO controlling the power-on of the GSM modem can only signal to the modem to turn itself on -- turning this GPIO off does not power off the GSM modem. Instead, the '''AT@POFF''' sequence must be sent to the modem in order to perform a power off.

Further complicating power control of the GTA01 GSM modem is the fact that the modem draws power from the battery/charger side of the power management circuitry -- this means that turning off the power to the host CPU on the GTA01 does not turn off the power to the modem. In real-world operation, this means that unless the shutdown procedure for the host cpu's operating system issues the '''AT@POFF''' command to power off the GSM modem, the modem will remain turned on, drawing power from the battery even thought the host CPU is completely powered off.

=== The Power-On Sequence ===

The sharing of the serial port between the console and the GSM modem results in the need for a very specific power-on and power-off sequence. Two major problems exist that must be avoided: infinite echos, and RTSCTS lockup.

==== Avoiding Infinite Echos ====

By default, the serial port is initialized in "echo" mode -- meaning that any characters sent to the serial port from the console will be echoed back to the console. Upon power-up or reset, the GSM modem also echos back characters it receives. So unless action is taken to disable the serial port's echo before the GSM modem is powered on, an infinite echo will result. The modem will print the standard "Interpretor Ready" message, which will be echoed back to it by the serial port driver, the modem will echo that back to the serial port again (adding some error text to the message), the serial port will echo that again, and this continues until buffers in either or both the serial port and the modem fill up, and one of them ceases to transmit.

Once in this situation, it is difficult for software (such as gsmd) to gain synchronization of commands and responses.

The best solution is to avoid the problem to begin with. Simply ensure that the serial port is set to "no-echo" mode before the GSM modem is enabled and powered up. This sequence illustrates how this is normally done:

stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on

(Note that the stty command argument syntax is somewhat unusual: "-echo" means "disable echo", while "echo" means "enable echo".)

==== Avoiding RTSCTS Lockup ====

Hardware flow control uses additional signals in addition to the serial data in and out signals on the serial port to control the flow of the data. Specifically, when hardware flow control is enabled, a given endpoint is expected to assert its RTS (Request To Send) line when it has data to transmit, and not transit that data until it sees a CTS (Clear TO Send) signal from the other end. In this fashion, buffer overruns and data loss are avoided.

The GSM modem requires that hardware flow control be enabled in order to communicate with the host. However, the console lacks the RTS and CTS signals and thus is unable to communicate if hardware flow control is enabled. But what really makes this problem serious is that if hardware flow control is enabled while the serial port is switched to the console, and the (small) transmit buffer for the port fills (such as a kernel log message), the Linux kernel will lock up, and become completely non-responsive. There is no recovery mechanism for this other than to disconnect the device from its USB port or charger, and remove the battery.

One solution to this is to disable the use of the serial port as a console for the kernel. However, this is greatly inconvenient - the knowledgeable user with a debug board will usually wish to have a console available, and the novice user will probably wish to avoid changing the u-boot variables in order to disable the console. So, a better approach is to avoid this situation by taking great care when powering-up, resetting, or powering-down the modem. The following sequence illustrates how to switch the serial port back to the console mode safely:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on

=== Resetting the GSM Modem ===

The GSM modem can be effectively reset by changing the state of the Power-On GPIO from off to on -- in other words, just disable the GSM modem and re-enable it. The safe way to accomplish this is to combine the two sequences above:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

It should be noted that this reset sequence will also power up the modem if it is not enabled and powered up to begin with. For this reason, the reset sequence above should be used for both power-up and reset purposes.

=== Powering Off the GSM Modem ===

Powering off the GSM modem on the GTA01 can only be done by issuing the '''AT@POFF''' command to the device. In order to issue this command, it is usually necessary to return it to a known state. So the normal mechanism is to issue the reset operation (above), wait for a short period of time (1 second seems to be sufficient), and send the '''AT@POFF''' command. This should be followed by an additional short delay (to allow the text to be transmitted), and then the serial port can be switched back to the console. The following script accomplishes this:

### Reset the modem to place it in a known state
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

### Now enable hardware flow control, and transmit the sequence
stty -F /dev/ttySAC0 crtscts
sleep 1
echo -e "AT@POFF\r" >/dev/ttySAC0
sleep 1

### Finally, we disable flow control, and switch back the port
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

=== Eliminating echo on the non-neo end of phone calls ===
Here is the modified /etc/gsmhandset.state that eliminates echo during calls (at least for [[User:Wurp]]): http://drivehq.com/file/df.aspx/publish/sagacis/PublicFolder/handset.sagacis.state
[[Category:Hardware ]]
[[Category:Supported Phone| ]]
[[Category:Neo1973 Hardware]]
[[Category:Neo1973 Hardware]]
[[Category:GSM]]

Neo 1973 and Neo FreeRunner gsm modem

2008-03-10T19:11:35Z

Henrikp: /* Powering Off the GSM Modem */

This page is about the [[Neo1973]] GTA01 (and GTA02) GSM Modem, based on the Ti Calypso chipset.

== [[Hardware:AT Commands|AT command]] interface ==

=== Sending Commands ===
To send commands to the GSM modem, you may use
cu -l /dev/ttySAC0
or use gsmd and libgsmd-tool for a less direct method.

If you connect directly (via cu) you must `chown uucp.uucp /dev/ttySAC0` first since cu is picky about permissions.

libgsmd-tool is less functional than the direct raw connection to the modem.

{|
Note: If you use cu -l /dev/ttySAC0 to enter commands, type "~." to quit
|}

=== Standard AT commands ===
The GSM modem follows GSM [http://www.3gpp.org/ftp/Specs/html-info/0705.htm TS07.05], [http://www.3gpp.org/ftp/Specs/html-info/0707.htm 07.07] and [http://www.3gpp.org/ftp/Specs/html-info/0710.htm 07.10] very closely.

[http://www.3gpp.org/specs/numbering.htm 3gpp.org] has information about 3G and GSM specifications

=== TI proprietary AT commands ===

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, OpenMoko cannot provide a reference documentation to those commands. Using the standards-compliant '''AT+CLAC''', you will notice that the non-standard commands also show up in the command listing.

You will also notice that those non-standard commands are prefixed with '''AT%''' rather than '''AT+''' for the standards-compliant commands.

Thus, we welcome our user and developer community to play with those commands and document them here. Since we never have released any NDA documentation to our community, there is no legal issue.

Note that the syntax and the interpretation of the output of the commands listed here are only educated guesses and should not be relied on. Part of the proprietary command set has identical or similar usage as on other modems in the market, some of which have fully opened specifications and information about these commands can be taken from their datasheets (some known similar modems with open specs: ''BenQ M22A'' and ''M23A'', ''Enfora Enabler-G [http://www.enfora.com/index.cgi?CONTENT_ID=376&User:LANGUAGE=en II] / [http://www.enfora.com/index.cgi?CONTENT_ID=377&User:LANGUAGE=en III]'' and ''SPT 1834'').

==== AT%VER ====
Prints the firmware component versions.

The modem's response looks like this on an un-updated phase-0 [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phone:

%VER: aci sean non_clearcase 15:11:24 17/04/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: l2r a086 ** NONE ** 10:21:37 28/03/07
%VER: ra a086 ** NONE ** 10:25:01 28/03/07
%VER: rlp a086 ** NONE ** 10:25:12 28/03/07
%VER: fad a086 ** NONE ** 10:18:09 28/03/07
%VER: t30 a086 ** NONE ** 10:29:01 28/03/07

For a [[Neo1973_Hardware#GTA01Bv4|GTA01Bv4]] phase 1 phone, produced start of september:

%VER: aci sean non_clearcase 12:32:56 24/08/07
%VER: cc a086 ** NONE ** 14:07:10 08/06/07
%VER: dl a086 ** NONE ** 14:07:46 08/06/07
%VER: mm a086 ** NONE ** 14:11:52 08/06/07
%VER: rr a086 ** NONE ** 14:13:01 08/06/07
%VER: sim a086 ** NONE ** 14:13:54 08/06/07
%VER: sms a086 ** NONE ** 14:14:20 08/06/07
%VER: ss a086 ** NONE ** 14:15:52 08/06/07
%VER: alr a086 ** NONE ** 14:06:38 08/06/07
%VER: l2r a086 ** NONE ** 14:10:36 08/06/07
%VER: ra a086 ** NONE ** 14:12:32 08/06/07
%VER: rlp a086 ** NONE ** 14:12:40 08/06/07
%VER: fad a086 ** NONE ** 14:08:06 08/06/07

For a [[Neo1973_Hardware#GTA01Bv3|GTA01Bv3]] phase 0 phone:

%VER: aci sean non_clearcase 10:46:06 29/08/06
%VER: cc a086 non_clearcase 14:53:59 28/08/06
%VER: dl a086 non_clearcase 14:54:40 28/08/06
%VER: mm a086 non_clearcase 14:59:25 28/08/06
%VER: rr a086 non_clearcase 15:00:11 28/08/06
%VER: sim a086 non_clearcase 15:00:57 28/08/06
%VER: sms a086 non_clearcase 15:01:23 28/08/06
%VER: ss a086 non_clearcase 15:02:22 28/08/06
%VER: alr a086 non_clearcase 14:53:19 28/08/06
%VER: l2r a086 non_clearcase 14:58:02 28/08/06
%VER: ra a086 non_clearcase 14:59:50 28/08/06
%VER: rlp a086 non_clearcase 14:59:56 28/08/06
%VER: fad a086 non_clearcase 14:55:04 28/08/06
%VER: t30 a086 non_clearcase 15:02:27 28/08/06

The second column lists firmware component names (e.g. aci = AT Command Interface). The third column is the user name of the engineer who last modified given component. The rightmost column is probably the last time someone worked on it (Please note that the name 'sean' here is not Sean Moss-Pultz :) while a086 is an anonymous TI engineer's nick, meaning that the component has not been modified at FIC).

==== AT%A ====
Print values from an ADC.

This command is not listed in AT+CLAC output but it is triggered by any input that starts with AT%A except AT%ALS (''Alternative Line Service'') and AT%ATR, which are other proprietary AT commands. So for example AT%ABCD,HELLO will also run this commands. On my Neo modem it prints a line containing nine values of the form ADC <number> = <value>:

AT%A
EXT: I
ADC 0 = e19, ADC 1 = 0, ADC 2 = d, ADC 3 = 6ea, ADC 4 = a25, ADC 5 = 9fc, ADC 6 = 96d, ADC 7 = 0, ADC 8 = 6

It would seem there's an ADC (analog-to-digital converter) module in the modem with nine input lines connected to it and the values on these lines are reported by this command in hexadecimal format. The values change over time. Inputs 1 and 7 always show zero on my modem, input 1 value changes slightly (+/- 20), while values on inputs 3, 4, 5, 6 and 8 change seemingly randomly in the range 0x000 - 0xfff (it would seem the chip is 12-bit).

==== AT%NRG ====
The AT%NRG (''Network registration and service selection'') is an expansion of the AT+COPS command. It allows specifying the service state of the registration, in addition to AT+COPS functionality. It doesn't however allow listing all present operators (use AT+COPS for this).

==== AT%EM ====
Execution of ''Engineering Mode'' commands. Allows viewing the information accessible to the modem but not available through standard GSM AT commands set such as detailed information on the current Serving Cell (the one we're registered with), its neighbouring cells, the GPRS/EDGE availability and SIM card data.

Citing Enfora Inc. Application Note EDG0108TN01:
''The purpose of Engineering Mode (EM) is to provide means to observe the behavior of the mobile station and the settings of the network as counterpart and therefore defines a lot of possibilities to analyze the network. The EM can be used for observation of a defined data set during functional test and field test.''

''Warning: The display of certain parameters is dependent on the wireless network sending the correct information in the System Information Packets. There is no guaranty that the information is always forwarded from the network. At times data may not be present to display in the Engineering Mode responses.''

Syntax:
AT%EM=<mode>,<command>
Allowed <mode> values:
* 2 - AT command mode
* 3 - PCO mode
I only describe the AT mode commands here. Commands are in range 1 to 13:
AT%EM=2,1 Serving Cell Information
AT%EM=2,2 Serving Cell GPRS Information
AT%EM=2,3 Neighbour Cell Information
AT%EM=2,4 Location and Paging Parameters
AT%EM=2,5 PLMN Parameters
AT%EM=2,6 Ciphering, Hopping, DTX Parameters
AT%EM=2,7 Power Parameters
AT%EM=2,8 Identity Parameters
AT%EM=2,9 Firmware components versions
AT%EM=2,10 GMM Information
AT%EM=2,11 GRLC Information
AT%EM=2,12 AMR Configuration Information
AT%EM=2,13 PDP Information

===== Serving Cell Information (2,1) =====
Response format:
%EM: <afrcn>,<c1>,<c2>,<rxlev>,<bsic>,<cell_id>,<dsc>,<txlev>,<tn>,<rlt>,<tav>,<rxlev_f>,<rxlev_s>,<rxqual_f>,<rxqual_s>,<lac>,<cba>,<cbq>,<cell_type_ind>,<vocoder>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || arfcn || Current Channel Number ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentifier ||
|-
|7 || dsc || Downlink Signaling Counter || current counter value
|-
|8 || txlev || Transmit Power Level ||
|-
|9 || tn || Timeslot Number ||
|-
|10 || rlt || Radio Link Timeout Counter ||
|-
|11 || tav || Timing Advance ||
|-
|12 || rxlev_f || Received Field Strength full ||
|-
|13 || rxlev_s || Received Field Strength sub ||
|-
|14 || rxqual_f || Received Quality full ||
|-
|15 || rxqual_s || Received Quality sub ||
|-
|16 || lac || Location Area Code ||
|-
|17 || cba || Cell Bar Access ||
|-
|18 || cbq || Cell Bar Qualifier ||
|-
|19 || Cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|20 || vocoder || Vocoder || Sig/speech/efr/amr/14.4/9.6/4.8/2.4
|}

According to http://www.qrctech.com/freq_chart_24x36.pdf, frequencies can be calculated using the arfcn field like this:
if 172 < arfcn < 252 then freq = 869 + (arfcn -127) x 0.2 MHz # 850 band
if 511 < arfcn < 811 then freq = 1930 + (arfcn - 511) x 0.2 MHz # 1900 band
if 1 < arfcn < 124 then freq = 935 + (arfcn * 0.2) MHz # 900 band (original alloc)
if 974 < arfcn < 1023 then freq = 925 + (arfcn - 974) x 0.2 MHz # 900 band E-GSM
if 511 < arfcn < 886 then freq = 1805 + (arfcn - 511) x 0.2 MHz # 1800 band

Notice the 1800 and 1900 bands have the same channel ids and nearly the same algorithm with a different starting point.

===== Serving Cell GPRS Information (2,2) =====
Response format:
%EM: <nts>,<nmo>,<spgc_ccch_sup>,<priority_access_thr>,<cba>,<rac>,<tav>,<dsc>,<c31>,<c32>,<band_ind>,<pfc_supp_n_w>,<ccn_mode_sts>,<Psi_sts_suppt>,<edge_support>,<epcr_support>,<bep_period>,<bss_paging_coord>
{|
! Parameter no. !! Name !! Meaning !! Remarks
|-
|1 || nts || PCCCH_TIMESLOT || Number of downlink timeslots
|-
|2 || nmo || Network Mode of Operation ||
|-
|3 || spgc_ccch_sup || Network Control-spgc_ccch_sup || Network support for split paging
|-
|4 || priority_access_thr || Network Control-Priority_Access_Threshold || packet access to the NW according to priority level
|-
|5 || cba || Cell Bar Access ||
|-
|6 || rac || Routing Area Code ||
|-
|7 || tav || Timing Advance ||
|-
|8 || dsc || Downlink Signal Counter ||
|-
|9 || c31 || Cell-reselect Criterion C31 ||
|-
|10 || c32 || Cell-reselect Criterion C32 ||
|-
|11 || band_ind || Band Indicator ||
|-
|12 || pfc_supp_n_w || PFC Support ||
|-
|13 || ccn_mode_sts || CCN Mode ||
|-
|14 || Psi_sts_suppt || PSI Support ||
|-
|15 || edge_support || EDGE Support ||
|-
|16 || epcr_support || EPCR Support ||
|-
|17 || bep_period || BEP Period ||
|-
|18 || bss_paging_coord || BSS Paging ||
|}

===== Neighbour Cell Information (2,3) =====
The first line of response is of the format %EM: <number of cells listed>, where the maximum seems to be 6, one cell for each channel. The next sixteen lines list the values of each of the parameters for each of the cells.
{|
! Parameter no. !! Short name !! Meaning !! Remarks
|-
|1 || arfcn || BCCH channel ||
|-
|2 || c1 || Path Loss Criterion C1 ||
|-
|3 || c2 || Cell-reselection Criterion C2 ||
|-
|4 || rxlev || Received Field Strength || (rxlev/2)+2 gives the AT+CSQ response value
|-
|5 || bsic || Base Station ID Code ||
|-
|6 || cell_id || Cell Indentity ||
|-
|7 || lac || Location Area Code ||
|-
|8 || frame_offset || Frame Offset ||
|-
|9 || time_alignmnt || Time Alignment ||
|-
|10 || cba || Cell Bar Access ||
|-
|11 || cbq || Cell Bar Qualifier ||
|-
|12 || cell_type_ind || Cell Type Indicator || NA/GSM/GPRS
|-
|13 || rac || Routing Area Code ||
|-
|14 || cell_resel_offset || Cell-reselection Offset ||
|-
|15 || temp_offset || Temporary Offset ||
|-
|16 || rxlev_acc_min || Rxlen access min ||
|}
My Neo1973 reports:
AT%EM=2,3
%EM: 6
763,766,771,778,780,773
20,8,14,18,17,8
20,8,14,18,17,8
73,46,54,51,13,12
6753,10951,3531,0,1933,1924
100,100,300,300,300,100
80229,961995,0,1166923,0,2715553
3504,724,0,3724,4,1112
0,0,0,0,0,0
0,0,0,0,0,0
2,2,2,2,2,2
0,0,0,0,0,0
0,0,0,0,0,0
0,0,0,0,0,0
10,10,10,10,10,10

OK

===== Location and Paging Parameters (2,4) =====
Response format:
%EM: <bs_pa_mfrms>,<t3212>,<mcc[0]><mcc[1]><mcc[2]>,<mnc[0]><mnc[1]><mnc[2]>,<tmsi>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || bs_pa_mfrms || BS PA MFRMS paging repeat period
|-
|2 || t3212 || Periodic location updating interval
|-
|3 || mcc || [http://en.wikipedia.org/wiki/Mobile_country_code Mobile Country Code]
|-
|4 || mnc || [http://en.wikipedia.org/wiki/Mobile_Network_Code Mobile Network Code]
|-
|5 || tmsi || [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] (in binary)
|}
The MCC and MNC values are the same values that are used to form the Mobile Operator names used by the standard AT+COPS and AT+COPN commands in numeric format. The TMSI is the same number that [http://wiki.openmoko.org/wiki/GTA01_gsm_modem#Identity_Parameters_.282.2C8.29 AT%EM=2,8] gives, just in a different format.

===== PLMN Parameters (2,5) =====
Response format:
%EM: <no_creq_max>,<reest_flag>,<txpwr_max>,<rxlev_min>,<rel_cs>,<sgsnr_rel>,<mscr_rel>,<net_rel>
{|
! Parameter no. !! Name !! Meaning
|-
|1 || no_creq_max || Max. number or retries for channel requests
|-
|2 || reest_flag || Re-establishment Flag
|-
|3 || txpwr_max || MS TXPWR MAX CCCH
|-
|4 || rxlev_min || Rxlev_access_min
|-
|5 || rel_cs || Release Cause (only the last release cause is remembered)
|-
|6 || sgsnr_rel || SGSNR Release
|-
|7 || mscr_rel || MSCR Release
|-
|8 || net_rel || Network Release Info
|}
===== Ciphering, Hopping, DTX Parameters (2,6) =====
{{todo|Fill in}}
===== Power Parameters (2,7) =====
The output consits of two lines, first line containing 12 comma-separated values and the second line 18 comma-separated values, such as:
AT%EM=2,7
%EM: 1,1,0,0,0,1,1,0,0,0,1,0
6,0,0,0,0,1,1,1,4,0,0,0,0,1,0,0,0,0

OK
On the first line (called Classmark 2) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Revision Level ||
|-
|2 || Controlled Early Classmark Sending || 1 means enabled
|-
|3 || A5/1 Encryption algorithm || 0 means available
|-
|4 || RF Power capability ||
|-
|5 || Pseudo-synchronisation capability || 1 means present
|-
|6 || SS Screening Indicator ||
|-
|7 || SMS capability ||
|-
|8 || Frequency capability ||
|-
|9 || Classmark 3 options || 1 means supported
|-
|10 || CM Service Prompt || 1 means supported
|-
|11 || A5/3 Encryption algorithm || 1 means available
|-
|12 || A5/2 Encryption algorithm || 1 means available
|}
On the second line (called Classmark 3) we have:
{|
! Value no. !! Meaning !! Remarks
|-
|1 || Multiband support ||
|-
|2 || A5/7 Encryption algorithm || 1 means available
|-
|3 || A5/6 Encryption algorithm || 1 means available
|-
|4 || A5/5 Encryption algorithm || 1 means available
|-
|5 || A5/4 Encryption algorithm || 1 means available
|-
|6 || Valid Radio capability 2 || ??
|-
|7 || Associated Radio capability 2 ||
|-
|8 || Valid Radio capability 1 || ??
|-
|9 || Associated Radio capability 1 ||
|-
|10 || Valid R Support || ??
|-
|11 || R Support || R-GSM Class
|-
|12 || Valid Multi-slot Class || ??
|-
|13 || Multi-slot Class ||
|-
|14 || Unicode 2 treatment ||
|-
|15 || Extended Measurement capability || 1 means supported
|-
|16 || Valid Switch-measure-value || ??
|-
|17 || Switch-measure-value ||
|-
|18 || Switch-measure-switch-value ||
|}

===== Identity Parameters (2,8) =====
Response format:
%EM: <imeisv>
<imsi>
<tmsi>

OK
The IMEISV line contains 20 numbers separated by commas, the numbers on positions 5 to 18 are the digits of the [http://en.wikipedia.org/wiki/IMEI IMEI] number as returned by AT+CGSN. The second line contains another 20 numbers and the numbers on positions 5 to 19 form the digits of your SIM card's [http://en.wikipedia.org/wiki/IMSI IMSI] number, as returned by the AT+CIMI command. The last line contains the [http://en.wikipedia.org/wiki/TMSI Temporary Mobile Subscriber Identity] number in plain format (ten digits).

===== Firmware components versions (2,9) =====
Prints version information for different components of the modem's firmware. The format and the scope of the information presented is identical to that in [[#AT%VER|AT%VER]] output with the exception that only a subset of all of the components are listed:
AT%EM=2,9
%VER: alr a086 ** NONE ** 10:15:48 28/03/07
%VER: dl a086 ** NONE ** 10:17:34 28/03/07
%VER: rr a086 ** NONE ** 10:25:37 28/03/07
%VER: mm a086 ** NONE ** 10:23:09 28/03/07
%VER: cc a086 ** NONE ** 10:16:39 28/03/07
%VER: ss a086 ** NONE ** 10:28:52 28/03/07
%VER: sim a086 ** NONE ** 10:26:45 28/03/07
%VER: sms a086 ** NONE ** 10:27:21 28/03/07

OK
===== GMM Information (2,10) =====
{{todo|Fill in}}
===== GRLC Information (2,11) =====
{{todo|Fill in}}
===== AMR Configuration Information (2,12) =====
{{todo|Fill in}}
===== PDP Information (2,13) =====
{{todo|Fill in}}

=== GSM Modem OpenMoko commands ===

The Ti calypso GSM Modem firmware has been extended by OpenMoko specific AT
commands. This page documents those commands.

==== AT@POFF ====

Powers off the GSM Modem. No parameters/options.

==== AT@ST ====

configure the sidetone level for voice calls generated inside the GSM Modem. This should normally be off, since the sidetone in GTA01/GTA02 is generated inside the the [[WM8753|wolfson audio codec]].

AT@ST?
+ST: -5
OK
AT@ST=?
@ST: (-26,-23,-20,-17,-14,-11,-8,-5,-2,1)
OK
AT@ST="-26"
OK

-26 means turn off the sidetone totally.

==== AT@AUL ====

audio table load.

AT@AUL="0"
OK
AT@AUL=?
@AUL:(0)

This audio table is a collection of audio parameters for GSM calibrated by hardware engineers,

Mode of microphone
Gain of microphone
FM PGA gain setting
Bias setting for microphone
FIR coefficients
ANR parameters
Level of side tone
AEC parameters
Echo suppressor
Mode of speaker
Gain of speaker
Extra gain for AUDIO_SPEAKER_HANDSET and AUDIO_SPEAKER_HANDFREE modes
Enable/Disable filter
Enable/Disable high-pass filter
FIR coefficients
IIR uplink/downlink coefficients
Limiter parameters
Level of speaker
Mode of speaker
State of speaker
Sampling frequency
Level of volume
AGC parameters
DRC parameters

The audio table will be stored in the flash file system within GSM modem, you can load it through this command.

For now, we only provide one configuration, that is "0".

If AT@AUL="0" responds with ERROR, it means there's no audio table existing and the GSM firmware will use default values.

== Wakeup of CPU from GSM Modem ==

=== Problem description ===

For power management reasons, it is absolutely neccessary that only the minimal
required parts of the device are powered at any given time. If you carry your
Neo in your pocket, then all it should do is stay online with the GSM network,
and notify you in case there's an incoming call/sms (like other phones).

During that time, the Neo1973 Application Processor (s3c24xx) is suspended,
i.e. not powered at all. The SDRAM is in self-refresh mode.

In this suspend mode (which Samsung calls by the funny name of POWER_OFF), the
processor is not able to receive any data from the GSM Modem. Nor is it able
to detect incoming characters and wake up the CPU. The only wake up sources
are a certain set of external interrupts (EINT).

Thus, the GSM Modem GPIO line IO1 was connected with the Samsung EINT1, and
the GSM Modem firmware contains some special logic to generate an interrupt
(and thus wake-up event) to the CPU.

=== Logic for problem solution ===

Preconditions
# The default state of GSM Modem output IO1 is logical LOW.

Anytime the modem has pending data on the MODEM-UART channel, it
# checks if CTS_MODEM permits sending of data
## if CTS_MODEM permits sending of UART data, go to '4.2'
# [implicit: CTS_MODEM does not permit sending of UART data]
## set IO1 line to logical HIGH level
## buffer modem data [until buffer is full, after which data gets discarded]
# wait until CTS_MODEM permits sending of UART data
# as soon as CTS_MODEM permits sending of UART data,
## set IO1 back to logical LOW level
## start sending of UART data
# once all data is transmitted, return to idle state. When next data item is to be transmitted, start again from '1'

=== Software implementation ===

{{note|This is the plan, it has not been fully implemented yet}}

# a firmware post may-16-2007 needs to be present in the gsm modem. This is true for all phones bought during phase 1 in the online shop. However, I currently don't really know what firmware version was present in the GTA01Bv4 that we sent to phase 0.
# the suspend code probably still needs to correctly configure the RTS/CTS lines (i.e. put them in GPIO mode, and set them to their desired "don't send any more characters" level)

So in this case, any data from the GSM modem will wake up the cpu for processing of that data. The GSM modem has some internal buffer (I don't know how big right now) that should be sufficient for buffering the data until the CPU is alive.

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside OpenMoko staff.

== Power On, Power Off, and Reset of the GTA01 GSM Modem ==

=== GSM Modem Connections ===

The GTA01 GSM modem communicates via a standard serial port to the host system. The port operates at 115200 baud, 8 bits, no parity, and requires hardware flow control (RTSCTS) to operate. Due to the fact that the host CPU has only a pair of serial ports but there are three devices that wish to use them, the GSM modem port is actually shared with the serial console (the third device is the GPS chip, which has exclusive use of the second serial port).

A GPIO (General Purpose IO) pin controls the switching of the serial port between the console and the GSM modem. Another GPIO is used to turn on the power to the GSM modem. On older versions of the GTA01 a third GPIO could be used to reset the GSM modem; this signal proved to cause difficulties with the modem, and on all the GTA01 units sold this GPIO line is not connected. The driver combines the the switching of the serial port to the GSM modem and the power-on signal to the modem into a single operation; the two cannot be controlled independently from user-space (at the time of this writing).

It is important to note that the GPIO controlling the power-on of the GSM modem can only signal to the modem to turn itself on -- turning this GPIO off does not power off the GSM modem. Instead, the '''AT@POFF''' sequence must be sent to the modem in order to perform a power off.

Further complicating power control of the GTA01 GSM modem is the fact that the modem draws power from the battery/charger side of the power management circuitry -- this means that turning off the power to the host CPU on the GTA01 does not turn off the power to the modem. In real-world operation, this means that unless the shutdown procedure for the host cpu's operating system issues the '''AT@POFF''' command to power off the GSM modem, the modem will remain turned on, drawing power from the battery even thought the host CPU is completely powered off.

=== The Power-On Sequence ===

The sharing of the serial port between the console and the GSM modem results in the need for a very specific power-on and power-off sequence. Two major problems exist that must be avoided: infinite echos, and RTSCTS lockup.

==== Avoiding Infinite Echos ====

By default, the serial port is initialized in "echo" mode -- meaning that any characters sent to the serial port from the console will be echoed back to the console. Upon power-up or reset, the GSM modem also echos back characters it receives. So unless action is taken to disable the serial port's echo before the GSM modem is powered on, an infinite echo will result. The modem will print the standard "Interpretor Ready" message, which will be echoed back to it by the serial port driver, the modem will echo that back to the serial port again (adding some error text to the message), the serial port will echo that again, and this continues until buffers in either or both the serial port and the modem fill up, and one of them ceases to transmit.

Once in this situation, it is difficult for software (such as gsmd) to gain synchronization of commands and responses.

The best solution is to avoid the problem to begin with. Simply ensure that the serial port is set to "no-echo" mode before the GSM modem is enabled and powered up. This sequence illustrates how this is normally done:

stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on

(Note that the stty command argument syntax is somewhat unusual: "-echo" means "disable echo", while "echo" means "enable echo".)

==== Avoiding RTSCTS Lockup ====

Hardware flow control uses additional signals in addition to the serial data in and out signals on the serial port to control the flow of the data. Specifically, when hardware flow control is enabled, a given endpoint is expected to assert its RTS (Request To Send) line when it has data to transmit, and not transit that data until it sees a CTS (Clear TO Send) signal from the other end. In this fashion, buffer overruns and data loss are avoided.

The GSM modem requires that hardware flow control be enabled in order to communicate with the host. However, the console lacks the RTS and CTS signals and thus is unable to communicate if hardware flow control is enabled. But what really makes this problem serious is that if hardware flow control is enabled while the serial port is switched to the console, and the (small) transmit buffer for the port fills (such as a kernel log message), the Linux kernel will lock up, and become completely non-responsive. There is no recovery mechanism for this other than to disconnect the device from its USB port or charger, and remove the battery.

One solution to this is to disable the use of the serial port as a console for the kernel. However, this is greatly inconvenient - the knowledgeable user with a debug board will usually wish to have a console available, and the novice user will probably wish to avoid changing the u-boot variables in order to disable the console. So, a better approach is to avoid this situation by taking great care when powering-up, resetting, or powering-down the modem. The following sequence illustrates how to switch the serial port back to the console mode safely:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on

=== Resetting the GSM Modem ===

The GSM modem can be effectively reset by changing the state of the Power-On GPIO from off to on -- in other words, just disable the GSM modem and re-enable it. The safe way to accomplish this is to combine the two sequences above:

stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/gta01-pm-gsm.0/power_on

It should be noted that this reset sequence will also power up the modem if it is not enabled and powered up to begin with. For this reason, the reset sequence above should be used for both power-up and reset purposes.

=== Powering Off the GSM Modem ===

Powering off the GSM modem on the GTA01 can only be done by issuing the '''AT@POFF''' command to the device. In order to issue this command, it is usually necessary to return it to a known state. So the normal mechanism is to issue the reset operation (above), wait for a short period of time (1 second seems to be sufficient), and send the '''AT@POFF''' command. This should be followed by an additional short delay (to allow the text to be transmitted), and then the serial port can be switched back to the console. The following script accomplishes this:

### Reset the modem to place it in a known state
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
stty -F /dev/ttySAC0 -echo
echo "1" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

### Now enable hardware flow control, and transmit the sequence
stty -F /dev/ttySAC0 crtscts
sleep 1
echo -e "AT@POFF\r" >/dev/ttySAC0
sleep 1

### Finally, we disable flow control, and switch back the port
stty -F /dev/ttySAC0 -crtscts
echo "0" >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on

=== Eliminating echo on the non-neo end of phone calls ===
Here is the modified /etc/gsmhandset.state that eliminates echo during calls (at least for [[User:Wurp]]): http://drivehq.com/file/df.aspx/publish/sagacis/PublicFolder/handset.sagacis.state
[[Category:Hardware ]]
[[Category:Supported Phone| ]]
[[Category:Neo1973 Hardware]]
[[Category:Neo1973 Hardware]]
[[Category:GSM]]

Manually using GPRS

2008-03-08T12:45:48Z

Henrikp: /* Some APN names for reference */

You need to have [[GSM]] parts already initialized, with modem logged in to the network, for this to work. It is best to test it by doing test call. The GPRS connection is made using the PPP protocol to a server identified by an "APN" at the network operator.

The program that implements PPP on Linux is [[pppd]], which we need to configure and run to get a connection. When that is working, we can configure pppd to wait until it's needed before it connects, and to disconnect if the connection becomes idle. Further, we can start pppd in the background during the boot process.

== Configuring pppd for manual connections ==

You'll need /etc/ppp/peers/gprs:
<pre>
/dev/ttySAC0 115200
connect /etc/ppp/gprs-connect-chat
crtscts
lock
hide-password
defaultroute
usepeerdns
disconnect /etc/ppp/gprs-disconnect-chat
holdoff 3
ipcp-accept-local
lcp-echo-failure 8
lcp-echo-interval 3
noauth
noipdefault
novj
novjccomp
replacedefaultroute
persist
lcp-echo-interval 3
lcp-echo-failure 12
</pre>

This options where mentioned before with that strange comment. Mine worked fine for me without those.

<pre>
# very long timeouts (unwise?)
lcp-echo-interval 300
lcp-echo-failure 40000
</pre>

Depending on the APN, you may need password authentication using CHAP or PAP. You can add the following default line for "password-less" connections:

<pre>
# client server secret IP addresses
* * "" *
</pre>

For CHAP, lines in /etc/ppp/chap-secrets are used. For PAP, the lines are in /etc/ppp/pap-secrets. The client should match the "user" option in pppd the config file (below). You can use * to mean any here, but the option user "" doesn't mean empty!

For example:

<pre>
# Secrets for authentication using CHAP
# client server secret IP addresses
"user" * "password" *
</pre>

For this you need the following options in /etc/ppp/peers/gprs:

<pre>
# username to use for authentication, should match "client" in /etc/ppp/{chap,pap}-secrets
user "user"
</pre>

And you'll need /etc/ppp/gprs-connect-chat (needs "chmod +x"):

<pre>
#!/bin/sh -e
exec chat -v\
ABORT BUSY\
ABORT DELAYED\
ABORT "NO ANSWER"\
ABORT "NO DIALTONE"\
ABORT VOICE\
ABORT ERROR\
ABORT RINGING\
TIMEOUT 3\
"" ATZ\
OK-\\k\\k\\k\\d+++ATH-OK ATE1\
OK AT+CFUN=0\
OK \\dAT+CFUN=1\
ERROR AT+CPIN\?\
"+CPIN: READY-AT+CPIN=\"2222\"-OK" AT\
TIMEOUT 60\
OK AT+COPS\
OK AT+CGDCONT=1,\"IP\",\"internet\"\
OK ATD*99#\
CONNECT \d\c
</pre>

You will need to adjust the APN name "internet" in at+cgdcont line to match what your network operator provides. See below in the table "Some APN names for reference" for the right settings for your operator.

Also good to have is /etc/ppp/gprs-disconnect-chat (needs "chmod +x"):

<pre>
#!/bin/sh -e
/usr/sbin/chat -v\
ABORT OK\
ABORT BUSY\
ABORT DELAYED\
ABORT "NO ANSWER"\
ABORT "NO CARRIER"\
ABORT "NO DIALTONE"\
ABORT VOICE\
ABORT ERROR\
ABORT RINGING\
TIMEOUT 12\
"" \\k\\k\\k\\d+++ATH\
"NO CARRIER-AT-OK" ""
</pre>

You need a proper /etc/resolv.conf:

<pre>
ln -sf /var/run/resolv.conf /etc
</pre>

If needed put your nameserver for usb-net into /var/run/resolv.conf, not in /etc.

=== Required fixes ===

The image does not set a correct resolv.conf. i do so with an

<pre>
echo nameserver 192.168.0.201 > /var/run/resolv.conf
</pre>

in the right place. because a post-up in /etc/network/interfaces is not supported i do that in /etc/network/if-up.d/08setupdns

another problem is pppd's /etc/ppp/ip-down.d/92removedns which does not properly remove the link when shuting down ppp. my fix is this script:

<pre>
#!/bin/sh
ACTUALCONF=/var/run/resolv.conf
PPPCONF=/var/run/ppp/resolv.conf
if [ -f $PPPCONF ] ; then
if [ -f $ACTUALCONF ] ; then
if [ ! -h $ACTUALCONF -o ! "`readlink $ACTUALCONF 2>&1`" = "$PPPCONF" ] ; then
mv $ACTUALCONF $ACTUALCONF.ppporig
fi
fi

ln -sf $PPPCONF $ACTUALCONF
fi
</pre>

=== Starting pppd ===

Then, after initializing GSM, you should be able to initialize GPRS by `pppd call gprs`. Good luck!

To dial in - and get verbose output on the terminal - use pppd
<pre>
pppd debug nodetach call gprs
</pre>

The config above will establish a 'persist'ant link over gprs. The battery will run low in less than an hour. See an example for an on-demand config below.

=== Some APN names for reference ===

{| border="1"
! Country
! Carrier
! Plan
! APN
! user/password if required
! Working pppd scripts
|-
| Estonia || EMT || Any, behind NAT || internet.emt.ee || ||
|-
| Finland || Saunalahti || Any || internet.saunalahti || ||
|-
| Finland || Sonera || Any, behind NAT || internet || ||
|-
| Finland || Sonera || Any, public IP || prointernet || ||
|-
| France || SFR || 10.x.x.x? || websfr || || under tests
|-
| France || SFR || 10.x.x.x? || wapsfr[1]|| || under tests
|-
| France || Orange || ??? || orange.fr || || under tests
|-
| Germany || E-Plus || BASE (and others?) || internet.eplus.de || eplus gprs ||
|-
| Germany || T-Mobile || || internet.t-mobile || ||
|-
| Germany || Vodafone || Any, behind NAT || web.vodafone.de || ||
|-
| Norway || Netcom || Any || internet.netcom.no || ||
|-
| Switzerland || Swisscom || e.g. Natel Basic Liberty, behind NAT || gprs.swisscom.ch || ||
|-
| UK || T-Mobile|| || general.t-mobile.uk || ||
|-
| UK || [http://www.filesaveas.com/gprs.html other providers] || || || ||
|-
| USA || Cingular (AT&T) || Less than full internet || wap.cingular || ||
|-
| USA || T-mobile || Anything less than full internet || wap.voicestream.com || ||
|-
| USA || T-mobile || Regular internet plan || internet2.voicestream.com || || [[T-Mobile pppd scripts]]
|-
| USA || T-mobile || "VPN" internet plan || internet3.voicestream.com || ||
|-
|}

[1] connected through a WAP proxy (slower, but the only way to access Vodafone live! and SFR portal)

== Starting pppd automatically ==

Once you have finished debugging your gprs-connect-chat and gprs options files, you may wish to automatically connect whenever needed and hang up when finished. Make sure you understand the impact of this change to your carrier plan billing. This is not recommended unless you have a large-use or unlimited data plan. These scripts do NOT prompt you before connecting.

=== On-demand connection settings ===

Additional settings are needed if you want the actual connection to be up only while there is traffic. In the 'gprs' file above, insert the following, making sure 'nodetach' is commented out. If 'nodetach' is on, the boot process will stop when it starts pppd. Also remove the option 'persist' mentioned above.

<pre>

# Wait until needed before connecting
demand

# Disconnect if idle for given amount of seconds
idle 20

</pre>

=== Start on boot (method 1) ===

Add the following definition to /etc/network/interfaces:
<pre>
auto ppp0
iface ppp0 inet ppp
provider gprs
</pre>

That should be it. Now you can use 'ifup ppp0' and 'ifdown ppp0' manually too.

=== Start on boot (method 2) ===

Create the following file as /etc/ppp/ppp_on_boot (needs chmod +x). The /etc/init.d/ppp script will call it to set up the daemon.
<pre>
#!/bin/sh
#
# Rename this file to ppp_on_boot and pppd will be fired up as
# soon as the system comes up, connecting to `provider'.
#
# If you also make this file executable, and replace the first line
# with just "#!/bin/sh", the commands below will be executed instead.
#

# The location of the ppp daemon itself (shouldn't need to be changed)
PPPD=/usr/sbin/pppd

# The default provider to connect to
$PPPD call gprs

# Additional connections, which would just use settings from
# /etc/ppp/options.<tty>
#$PPPD ttyS0
#$PPPD ttyS1
#$PPPD ttyS2
#$PPPD ttyS3
</pre>

Finally, you need to add the /etc/init.d/ppp script to the init process by creating symbolic links from the appropriate directories. I chose the following:

<pre>
/etc/rc0.d/K25ppp
/etc/rc1.d/K45ppp
/etc/rc2.d/S45ppp
/etc/rc3.d/S45ppp
/etc/rc4.d/S45ppp
/etc/rc5.d/S45ppp
/etc/rc6.d/K25ppp
</pre>

== See also ==
* [[pppd]]
* [[Manually using GSM]]
* [[Manually using Bluetooth]]

{{Languages|Manually_using_GPRS}}
[[Category:Documentation]]
[[Category:Developer software]]

[[Category:Guides]]

Manually using GPRS

2008-03-08T12:30:49Z

Henrikp: /* Some APN names for reference */

You need to have [[GSM]] parts already initialized, with modem logged in to the network, for this to work. It is best to test it by doing test call. The GPRS connection is made using the PPP protocol to a server identified by an "APN" at the network operator.

The program that implements PPP on Linux is [[pppd]], which we need to configure and run to get a connection. When that is working, we can configure pppd to wait until it's needed before it connects, and to disconnect if the connection becomes idle. Further, we can start pppd in the background during the boot process.

== Configuring pppd for manual connections ==

You'll need /etc/ppp/peers/gprs:
<pre>
/dev/ttySAC0 115200
connect /etc/ppp/gprs-connect-chat
crtscts
lock
hide-password
defaultroute
usepeerdns
disconnect /etc/ppp/gprs-disconnect-chat
holdoff 3
ipcp-accept-local
lcp-echo-failure 8
lcp-echo-interval 3
noauth
noipdefault
novj
novjccomp
replacedefaultroute
persist
lcp-echo-interval 3
lcp-echo-failure 12
</pre>

This options where mentioned before with that strange comment. Mine worked fine for me without those.

<pre>
# very long timeouts (unwise?)
lcp-echo-interval 300
lcp-echo-failure 40000
</pre>

Depending on the APN, you may need password authentication using CHAP or PAP. You can add the following default line for "password-less" connections:

<pre>
# client server secret IP addresses
* * "" *
</pre>

For CHAP, lines in /etc/ppp/chap-secrets are used. For PAP, the lines are in /etc/ppp/pap-secrets. The client should match the "user" option in pppd the config file (below). You can use * to mean any here, but the option user "" doesn't mean empty!

For example:

<pre>
# Secrets for authentication using CHAP
# client server secret IP addresses
"user" * "password" *
</pre>

For this you need the following options in /etc/ppp/peers/gprs:

<pre>
# username to use for authentication, should match "client" in /etc/ppp/{chap,pap}-secrets
user "user"
</pre>

And you'll need /etc/ppp/gprs-connect-chat (needs "chmod +x"):

<pre>
#!/bin/sh -e
exec chat -v\
ABORT BUSY\
ABORT DELAYED\
ABORT "NO ANSWER"\
ABORT "NO DIALTONE"\
ABORT VOICE\
ABORT ERROR\
ABORT RINGING\
TIMEOUT 3\
"" ATZ\
OK-\\k\\k\\k\\d+++ATH-OK ATE1\
OK AT+CFUN=0\
OK \\dAT+CFUN=1\
ERROR AT+CPIN\?\
"+CPIN: READY-AT+CPIN=\"2222\"-OK" AT\
TIMEOUT 60\
OK AT+COPS\
OK AT+CGDCONT=1,\"IP\",\"internet\"\
OK ATD*99#\
CONNECT \d\c
</pre>

You will need to adjust the APN name "internet" in at+cgdcont line to match what your network operator provides. See below in the table "Some APN names for reference" for the right settings for your operator.

Also good to have is /etc/ppp/gprs-disconnect-chat (needs "chmod +x"):

<pre>
#!/bin/sh -e
/usr/sbin/chat -v\
ABORT OK\
ABORT BUSY\
ABORT DELAYED\
ABORT "NO ANSWER"\
ABORT "NO CARRIER"\
ABORT "NO DIALTONE"\
ABORT VOICE\
ABORT ERROR\
ABORT RINGING\
TIMEOUT 12\
"" \\k\\k\\k\\d+++ATH\
"NO CARRIER-AT-OK" ""
</pre>

You need a proper /etc/resolv.conf:

<pre>
ln -sf /var/run/resolv.conf /etc
</pre>

If needed put your nameserver for usb-net into /var/run/resolv.conf, not in /etc.

=== Required fixes ===

The image does not set a correct resolv.conf. i do so with an

<pre>
echo nameserver 192.168.0.201 > /var/run/resolv.conf
</pre>

in the right place. because a post-up in /etc/network/interfaces is not supported i do that in /etc/network/if-up.d/08setupdns

another problem is pppd's /etc/ppp/ip-down.d/92removedns which does not properly remove the link when shuting down ppp. my fix is this script:

<pre>
#!/bin/sh
ACTUALCONF=/var/run/resolv.conf
PPPCONF=/var/run/ppp/resolv.conf
if [ -f $PPPCONF ] ; then
if [ -f $ACTUALCONF ] ; then
if [ ! -h $ACTUALCONF -o ! "`readlink $ACTUALCONF 2>&1`" = "$PPPCONF" ] ; then
mv $ACTUALCONF $ACTUALCONF.ppporig
fi
fi

ln -sf $PPPCONF $ACTUALCONF
fi
</pre>

=== Starting pppd ===

Then, after initializing GSM, you should be able to initialize GPRS by `pppd call gprs`. Good luck!

To dial in - and get verbose output on the terminal - use pppd
<pre>
pppd debug nodetach call gprs
</pre>

The config above will establish a 'persist'ant link over gprs. The battery will run low in less than an hour. See an example for an on-demand config below.

=== Some APN names for reference ===

{| border="1"
! Country
! Carrier
! Plan
! APN
! user/password if required
! Working pppd scripts
|-
| Estonia || EMT || Any, behind nat || internet.emt.ee || ||
|-
| Finland || Saunalahti || Any || internet.saunalahti || ||
|-
| Finland || Sonera || Any, behind NAT || internet || ||
|-
| Finland || Sonera || Any, public IP || prointernet || ||
|-
| France || SFR || 10.x.x.x? || websfr || || under tests
|-
| France || SFR || 10.x.x.x? || wapsfr[1]|| || under tests
|-
| France || Orange || ??? || orange.fr || || under tests
|-
| Germany || E-Plus || BASE (and others?) || internet.eplus.de || eplus gprs ||
|-
| Germany || T-Mobile || || internet.t-mobile || ||
|-
| Germany || Vodafone || Any, behind NAT || web.vodafone.de || ||
|-
| Norway || Netcom || Any || internet.netcom.no || ||
|-
| Switzerland || Swisscom || e.g. Natel Basic Liberty, behind NAT || gprs.swisscom.ch || ||
|-
| UK || T-Mobile|| || general.t-mobile.uk || ||
|-
| UK || [http://www.filesaveas.com/gprs.html other providers] || || || ||
|-
| USA || Cingular (AT&T) || Less than full internet || wap.cingular || ||
|-
| USA || T-mobile || Anything less than full internet || wap.voicestream.com || ||
|-
| USA || T-mobile || Regular internet plan || internet2.voicestream.com || || [[T-Mobile pppd scripts]]
|-
| USA || T-mobile || "VPN" internet plan || internet3.voicestream.com || ||
|-
|}

[1] connected through a WAP proxy (slower, but the only way to access Vodafone live! and SFR portal)

== Starting pppd automatically ==

Once you have finished debugging your gprs-connect-chat and gprs options files, you may wish to automatically connect whenever needed and hang up when finished. Make sure you understand the impact of this change to your carrier plan billing. This is not recommended unless you have a large-use or unlimited data plan. These scripts do NOT prompt you before connecting.

=== On-demand connection settings ===

Additional settings are needed if you want the actual connection to be up only while there is traffic. In the 'gprs' file above, insert the following, making sure 'nodetach' is commented out. If 'nodetach' is on, the boot process will stop when it starts pppd. Also remove the option 'persist' mentioned above.

<pre>

# Wait until needed before connecting
demand

# Disconnect if idle for given amount of seconds
idle 20

</pre>

=== Start on boot (method 1) ===

Add the following definition to /etc/network/interfaces:
<pre>
auto ppp0
iface ppp0 inet ppp
provider gprs
</pre>

That should be it. Now you can use 'ifup ppp0' and 'ifdown ppp0' manually too.

=== Start on boot (method 2) ===

Create the following file as /etc/ppp/ppp_on_boot (needs chmod +x). The /etc/init.d/ppp script will call it to set up the daemon.
<pre>
#!/bin/sh
#
# Rename this file to ppp_on_boot and pppd will be fired up as
# soon as the system comes up, connecting to `provider'.
#
# If you also make this file executable, and replace the first line
# with just "#!/bin/sh", the commands below will be executed instead.
#

# The location of the ppp daemon itself (shouldn't need to be changed)
PPPD=/usr/sbin/pppd

# The default provider to connect to
$PPPD call gprs

# Additional connections, which would just use settings from
# /etc/ppp/options.<tty>
#$PPPD ttyS0
#$PPPD ttyS1
#$PPPD ttyS2
#$PPPD ttyS3
</pre>

Finally, you need to add the /etc/init.d/ppp script to the init process by creating symbolic links from the appropriate directories. I chose the following:

<pre>
/etc/rc0.d/K25ppp
/etc/rc1.d/K45ppp
/etc/rc2.d/S45ppp
/etc/rc3.d/S45ppp
/etc/rc4.d/S45ppp
/etc/rc5.d/S45ppp
/etc/rc6.d/K25ppp
</pre>

== See also ==
* [[pppd]]
* [[Manually using GSM]]
* [[Manually using Bluetooth]]

{{Languages|Manually_using_GPRS}}
[[Category:Documentation]]
[[Category:Developer software]]

[[Category:Guides]]

User:Henrikp

2007-12-10T13:51:10Z

Henrikp: /* Henrikp */

Got the device in the start of december '07.

Openmoko Local Groups: Kuressaare

2007-12-10T13:49:33Z

Henrikp: /* Kuressaare */

=== Possible Participants ===
{|border=1
!Name
!Skills
!Level of Interest
!Other
!Has Device
!Has Debug Board
|-
|[[User:Henrikp|Henrik Pihl]]
|Just an interested poweruser, might be contributing with porting existing software
|GPRS/GPS?
|computer repairtechnician
|[[ Image:Moko.jpg |center]]
|
|}

Openmoko Local Groups

2007-12-10T13:46:45Z

Henrikp: /* Europe */

__TOC__
'''OpenMoko Local Groups...'''

* can be used for developers to meet and get to know each other
* can be used for developing
* may provide the room for real-life discussions away from mailinglists/wiki
* can support early support handling their GTA01Bv4 and exchange experiences
* fasten the community's cohesion
* give motivation

{|border="1"
!
!Has Device
|-
|If you have a device, on your local group's page, please add:
|[[Image: Moko.jpg|center]]
<nowiki>[[Image: Moko.jpg|center]]</nowiki>
|-
!
!Has Debug Board
|-
|If you have a debug board, please add:
|[[Image: MokoBox.jpg|center]]
<nowiki>[[Image: MokoBox.jpg|center]]</nowiki>
|}

Such as with [[OpenMoko_Local_Groups:_Singapore | Singapore]] or [[OpenMoko_Local_Groups:_San_Francisco | San Francisco]]

== Europe ==

* Austria
** [[OpenMoko_Local_Groups: Vienna|Vienna]]

* Belgium
** [[OpenMoko_local_Groups: Antwerp|Antwerp]]

* [[OpenMoko_Local_Groups:_Denmark|Denmark]]
** [[OpenMoko_Local_Groups: Copenhagen|Copenhagen]]
** [[OpenMoko_Local_Groups: Aalborg|Aalborg]]

* Estonia
** [[OpenMoko_Local_Groups: Kuressaare|Kuressaare]]

* Finland
** [[OpenMoko_Local_Groups: Helsinki|Helsinki]]

* France
** [[OpenMoko_Local_Groups: Paris|Paris]]
** [[OpenMoko_Local_Groups: Toulouse|Toulouse]]

* Germany
** [[OpenMoko_Local_Groups: Berlin|Berlin]]
** [[OpenMoko_Local_Groups: Braunschweig|Braunschweig]]
** [[OpenMoko_Local_Groups: Duesseldorf|Duesseldorf]]
** [[OpenMoko_Local_Groups: Frankfurt Main|Frankfurt Main]]
** [[OpenMoko_Local_Groups: Freiburg im Breisgau|Freiburg im Breisgau]]
** [[OpenMoko_Local_Groups: OWL|OWL]]
** [[OpenMoko_Local_Groups: Ingolstadt|Ingolstadt]]
** [[OpenMoko_Local_Groups: Ulm|Ulm]]

* Greece
** [[OpenMoko_Local_Groups: Athens|Athens]]

* Italy
** [[OpenMoko_Local_Groups: Milan|Milan]]
** [[OpenMoko_Local_Groups: Turin|Turin]]

* [[OpenMoko_Local_Groups:_Netherlands|Netherlands]]
** [[OpenMoko_Local_Groups: Amsterdam|Amsterdam]]
** [[OpenMoko_Local_Groups: Den Haag|Den Haag/The Hague]]
** [[OpenMoko_Local_Groups: Eindhoven|Eindhoven]]
** [[OpenMoko_Local_Groups: Ede|Ede]]

* [[OpenMoko_Local_Groups:_Norway|Norway]]
** [[OpenMoko_Local_Groups:_Oslo|Oslo]]
** [[OpenMoko_Local_Groups: Trondheim|Trondheim]]

* Poland
** [[OpenMoko_Local_Groups: Warsaw|Warsaw]]
** [[OpenMoko_Local_Groups: Szczecin|Szczecin]]

* [[OpenMoko_Local_Groups:_Portugal|Portugal]]
** [[OpenMoko_Local_Groups: Braga|Braga]]

* Romania
** [[OpenMoko_Local_Groups: Bucharest|Bucharest]]

* Russia
** [[OpenMoko_Local_Groups: Moscow|Moscow]]
** [[OpenMoko_Local_Groups: Saint-Petersburg|Saint-Petersburg]]

* Slovakia
** [[OpenMoko_Local_Groups: Bratislava|Bratislava]]

* Spain
** [[OpenMoko_Local_Groups: Madrid|Madrid]]

* Sweden
** [[OpenMoko_Local_Groups: Gothenburg|Gothenburg]]
** [[OpenMoko_Local_Groups: Linkoping|Linköping]]
** [[OpenMoko_Local_Groups: Umea|Umeå]]

* [[OpenMoko_Local_Groups: Switzerland|Switzerland]]
** [[OpenMoko_Local_Groups: Bern|Bern]]

* UK
** England
*** [[OpenMoko_Local_Groups: Birmingham|Birmingham]]
*** [[OpenMoko_Local_Groups: London|London]]
*** [[OpenMoko_Local_Groups: East Midlands|East Midlands]]

** Scotland
*** [[OpenMoko_Local_Groups: Fife|Fife]]
*** [[OpenMoko_Local_Groups: Edinburgh|Edinburgh]]

* Ukraine
** [[OpenMoko_Local_Groups: Lugansk|Lugansk]]

== Oceania ==

* Australia
** [[OpenMoko_Local_Groups: Adelaide|Adelaide]]
** [[OpenMoko_Local_Groups: Canberra|Canberra]]
** [[OpenMoko_Local_Groups: Melbourne|Melbourne]]
** [[OpenMoko_Local_Groups: Perth|Perth]]
** [[OpenMoko_Local_Groups: Sydney|Sydney]]

* New Zealand
** [[OpenMoko_Local_Groups: Auckland|Auckland]]
** [[OpenMoko_Local_Groups: Christchurch|Christchurch]]

== Asia ==
* India
** [[OpenMoko_Local_Groups: Delhi|Delhi]]
* Singapore
** [[OpenMoko_Local_Groups: Singapore|Singapore]]

== USA ==
* Alabama
** [[OpenMoko_Local_Groups: Alabama|Alabama]]

* Arizona
** [[OpenMoko_Local_Groups: Arizona|Arizona]]

* Arkansas
** [[OpenMoko_Local_Groups: Arkansas|Arkansas]]

* California
** [[OpenMoko_Local_Groups: San Diego|San Diego]]
** [[OpenMoko_Local_Groups: San Francisco|San Francisco]]
** [[OpenMoko_Local_Groups: Sacramento|Sacramento]]
** [[OpenMoko_Local_Groups: Los Angeles|Los Angeles]]
** [[OpenMoko_Local_Groups: Santa Barbara|Santa Barbara]]

* Colorado
** [[OpenMoko_Local_Groups: Colorado Springs|Colorado Springs]]
** [[OpenMoko_Local_Groups: Denver|Denver]]

* District of Columbia
** [[OpenMoko_Local_Groups: Washington DC Metro | Washington DC Metro]]

* Florida
** [[OpenMoko_Local_Groups: Central Florida | Central Florida]]

* Georgia
** [[OpenMoko_Local_Groups: Atlanta | Atlanta]]

* Illinois
** [[OpenMoko_Local_Groups: Chicago|Chicago]]

* Indiana
** [[OpenMoko_Local_Groups: Bloomington|Bloomington]]

* Iowa
** [[OpenMoko_Local_Groups: Iowa-Ames | Iowa-Ames]]

* Massachusetts
** [[OpenMoko_Local_groups: Boston|Boston]]

* Michigan
** [[OpenMoko_Local_Groups: Detroit|Detroit]]

* New Jersey
** [[OpenMoko_Local_Groups: Stevens Institute of Technology, Hoboken NJ | Stevens Institute of Technology, Hoboken NJ ]]

* New York
** [[OpenMoko_Local_Groups: NYC Metro | NYC Metro]]

* North Carolina
** [[OpenMoko Local_Groups: Charlotte | Charlotte]]

* Ohio
** [[OpenMoko_Local_Groups: Cleveland|Cleveland]]

* Oregon
** [[OpenMoko_Local_Groups: Eugene|Eugene]]
** [[OpenMoko_Local_Groups: Portland|Portland]]

* Texas
** [[OpenMoko_Local_Groups: North Texas|North Texas]]
** [[OpenMoko_Local_Groups: Central Texas|Central Texas]]

* Utah
** [[OpenMoko_Local_Groups: Salt Lake|Salt Lake]]

* Virginia
** [[OpenMoko_Local_Groups: Virginia|Virginia]]

== Canada ==
* Alberta
** [[OpenMoko_Local_Groups: Calgary|Calgary]]
** [[OpenMoko_Local_Groups: Edmonton|Edmonton]]
** [[OpenMoko_Local_Groups: Pincher Creek|Pincher Creek]]
* British Columbia
** [[OpenMoko_Local_Groups: Vancouver|Vancouver]]
* Ontario
** [[OpenMoko_Local_Groups: Ottawa|Ottawa]]
** [[OpenMoko_Local_Groups: Toronto|Toronto]]
* Quebec
** [[OpenMoko_Local_Groups: Montreal|Montreal]]

== South America ==
* Brasil
** [[OpenMoko_Local_Groups: Belo Horizonte|Belo Horizonte]]
* Colombia
** [[OpenMoko_Local_Groups: Bogota|Bogotá]]
* Uruguay
** [[OpenMoko_Local_Groups: Montevideo]]

== Africa ==
* South Africa
**[[OpenMoko_Local_Groups: Cape Town|Cape Town]]

[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]

Openmoko Local Groups

2007-12-10T13:43:10Z

Henrikp: /* Europe */

__TOC__
'''OpenMoko Local Groups...'''

* can be used for developers to meet and get to know each other
* can be used for developing
* may provide the room for real-life discussions away from mailinglists/wiki
* can support early support handling their GTA01Bv4 and exchange experiences
* fasten the community's cohesion
* give motivation

{|border="1"
!
!Has Device
|-
|If you have a device, on your local group's page, please add:
|[[Image: Moko.jpg|center]]
<nowiki>[[Image: Moko.jpg|center]]</nowiki>
|-
!
!Has Debug Board
|-
|If you have a debug board, please add:
|[[Image: MokoBox.jpg|center]]
<nowiki>[[Image: MokoBox.jpg|center]]</nowiki>
|}

Such as with [[OpenMoko_Local_Groups:_Singapore | Singapore]] or [[OpenMoko_Local_Groups:_San_Francisco | San Francisco]]

== Europe ==

* Austria
** [[OpenMoko_Local_Groups: Vienna|Vienna]]

* Belgium
** [[OpenMoko_local_Groups: Antwerp|Antwerp]]

* [[OpenMoko_Local_Groups:_Denmark|Denmark]]
** [[OpenMoko_Local_Groups: Copenhagen|Copenhagen]]
** [[OpenMoko_Local_Groups: Aalborg|Aalborg]]

* [[OpenMoko_Local_Groups:_Estonia|Estonia]]
** [[OpenMoko_Local_Groups: Kuressaare|Kuressaare]]

* Finland
** [[OpenMoko_Local_Groups: Helsinki|Helsinki]]

* France
** [[OpenMoko_Local_Groups: Paris|Paris]]
** [[OpenMoko_Local_Groups: Toulouse|Toulouse]]

* Germany
** [[OpenMoko_Local_Groups: Berlin|Berlin]]
** [[OpenMoko_Local_Groups: Braunschweig|Braunschweig]]
** [[OpenMoko_Local_Groups: Duesseldorf|Duesseldorf]]
** [[OpenMoko_Local_Groups: Frankfurt Main|Frankfurt Main]]
** [[OpenMoko_Local_Groups: Freiburg im Breisgau|Freiburg im Breisgau]]
** [[OpenMoko_Local_Groups: OWL|OWL]]
** [[OpenMoko_Local_Groups: Ingolstadt|Ingolstadt]]
** [[OpenMoko_Local_Groups: Ulm|Ulm]]

* Greece
** [[OpenMoko_Local_Groups: Athens|Athens]]

* Italy
** [[OpenMoko_Local_Groups: Milan|Milan]]
** [[OpenMoko_Local_Groups: Turin|Turin]]

* [[OpenMoko_Local_Groups:_Netherlands|Netherlands]]
** [[OpenMoko_Local_Groups: Amsterdam|Amsterdam]]
** [[OpenMoko_Local_Groups: Den Haag|Den Haag/The Hague]]
** [[OpenMoko_Local_Groups: Eindhoven|Eindhoven]]
** [[OpenMoko_Local_Groups: Ede|Ede]]

* [[OpenMoko_Local_Groups:_Norway|Norway]]
** [[OpenMoko_Local_Groups:_Oslo|Oslo]]
** [[OpenMoko_Local_Groups: Trondheim|Trondheim]]

* Poland
** [[OpenMoko_Local_Groups: Warsaw|Warsaw]]
** [[OpenMoko_Local_Groups: Szczecin|Szczecin]]

* [[OpenMoko_Local_Groups:_Portugal|Portugal]]
** [[OpenMoko_Local_Groups: Braga|Braga]]

* Romania
** [[OpenMoko_Local_Groups: Bucharest|Bucharest]]

* Russia
** [[OpenMoko_Local_Groups: Moscow|Moscow]]
** [[OpenMoko_Local_Groups: Saint-Petersburg|Saint-Petersburg]]

* Slovakia
** [[OpenMoko_Local_Groups: Bratislava|Bratislava]]

* Spain
** [[OpenMoko_Local_Groups: Madrid|Madrid]]

* Sweden
** [[OpenMoko_Local_Groups: Gothenburg|Gothenburg]]
** [[OpenMoko_Local_Groups: Linkoping|Linköping]]
** [[OpenMoko_Local_Groups: Umea|Umeå]]

* [[OpenMoko_Local_Groups: Switzerland|Switzerland]]
** [[OpenMoko_Local_Groups: Bern|Bern]]

* UK
** England
*** [[OpenMoko_Local_Groups: Birmingham|Birmingham]]
*** [[OpenMoko_Local_Groups: London|London]]
*** [[OpenMoko_Local_Groups: East Midlands|East Midlands]]

** Scotland
*** [[OpenMoko_Local_Groups: Fife|Fife]]
*** [[OpenMoko_Local_Groups: Edinburgh|Edinburgh]]

* Ukraine
** [[OpenMoko_Local_Groups: Lugansk|Lugansk]]

== Oceania ==

* Australia
** [[OpenMoko_Local_Groups: Adelaide|Adelaide]]
** [[OpenMoko_Local_Groups: Canberra|Canberra]]
** [[OpenMoko_Local_Groups: Melbourne|Melbourne]]
** [[OpenMoko_Local_Groups: Perth|Perth]]
** [[OpenMoko_Local_Groups: Sydney|Sydney]]

* New Zealand
** [[OpenMoko_Local_Groups: Auckland|Auckland]]
** [[OpenMoko_Local_Groups: Christchurch|Christchurch]]

== Asia ==
* India
** [[OpenMoko_Local_Groups: Delhi|Delhi]]
* Singapore
** [[OpenMoko_Local_Groups: Singapore|Singapore]]

== USA ==
* Alabama
** [[OpenMoko_Local_Groups: Alabama|Alabama]]

* Arizona
** [[OpenMoko_Local_Groups: Arizona|Arizona]]

* Arkansas
** [[OpenMoko_Local_Groups: Arkansas|Arkansas]]

* California
** [[OpenMoko_Local_Groups: San Diego|San Diego]]
** [[OpenMoko_Local_Groups: San Francisco|San Francisco]]
** [[OpenMoko_Local_Groups: Sacramento|Sacramento]]
** [[OpenMoko_Local_Groups: Los Angeles|Los Angeles]]
** [[OpenMoko_Local_Groups: Santa Barbara|Santa Barbara]]

* Colorado
** [[OpenMoko_Local_Groups: Colorado Springs|Colorado Springs]]
** [[OpenMoko_Local_Groups: Denver|Denver]]

* District of Columbia
** [[OpenMoko_Local_Groups: Washington DC Metro | Washington DC Metro]]

* Florida
** [[OpenMoko_Local_Groups: Central Florida | Central Florida]]

* Georgia
** [[OpenMoko_Local_Groups: Atlanta | Atlanta]]

* Illinois
** [[OpenMoko_Local_Groups: Chicago|Chicago]]

* Indiana
** [[OpenMoko_Local_Groups: Bloomington|Bloomington]]

* Iowa
** [[OpenMoko_Local_Groups: Iowa-Ames | Iowa-Ames]]

* Massachusetts
** [[OpenMoko_Local_groups: Boston|Boston]]

* Michigan
** [[OpenMoko_Local_Groups: Detroit|Detroit]]

* New Jersey
** [[OpenMoko_Local_Groups: Stevens Institute of Technology, Hoboken NJ | Stevens Institute of Technology, Hoboken NJ ]]

* New York
** [[OpenMoko_Local_Groups: NYC Metro | NYC Metro]]

* North Carolina
** [[OpenMoko Local_Groups: Charlotte | Charlotte]]

* Ohio
** [[OpenMoko_Local_Groups: Cleveland|Cleveland]]

* Oregon
** [[OpenMoko_Local_Groups: Eugene|Eugene]]
** [[OpenMoko_Local_Groups: Portland|Portland]]

* Texas
** [[OpenMoko_Local_Groups: North Texas|North Texas]]
** [[OpenMoko_Local_Groups: Central Texas|Central Texas]]

* Utah
** [[OpenMoko_Local_Groups: Salt Lake|Salt Lake]]

* Virginia
** [[OpenMoko_Local_Groups: Virginia|Virginia]]

== Canada ==
* Alberta
** [[OpenMoko_Local_Groups: Calgary|Calgary]]
** [[OpenMoko_Local_Groups: Edmonton|Edmonton]]
** [[OpenMoko_Local_Groups: Pincher Creek|Pincher Creek]]
* British Columbia
** [[OpenMoko_Local_Groups: Vancouver|Vancouver]]
* Ontario
** [[OpenMoko_Local_Groups: Ottawa|Ottawa]]
** [[OpenMoko_Local_Groups: Toronto|Toronto]]
* Quebec
** [[OpenMoko_Local_Groups: Montreal|Montreal]]

== South America ==
* Brasil
** [[OpenMoko_Local_Groups: Belo Horizonte|Belo Horizonte]]
* Colombia
** [[OpenMoko_Local_Groups: Bogota|Bogotá]]
* Uruguay
** [[OpenMoko_Local_Groups: Montevideo]]

== Africa ==
* South Africa
**[[OpenMoko_Local_Groups: Cape Town|Cape Town]]

[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]

Openmoko Local Groups: Kuressaare

2007-12-10T13:37:59Z

Henrikp:

Openmoko Local Groups

2007-12-10T13:30:09Z

Henrikp: /* Europe */

__TOC__
'''OpenMoko Local Groups...'''

* can be used for developers to meet and get to know each other
* can be used for developing
* may provide the room for real-life discussions away from mailinglists/wiki
* can support early support handling their GTA01Bv4 and exchange experiences
* fasten the community's cohesion
* give motivation

{|border="1"
!
!Has Device
|-
|If you have a device, on your local group's page, please add:
|[[Image: Moko.jpg|center]]
<nowiki>[[Image: Moko.jpg|center]]</nowiki>
|-
!
!Has Debug Board
|-
|If you have a debug board, please add:
|[[Image: MokoBox.jpg|center]]
<nowiki>[[Image: MokoBox.jpg|center]]</nowiki>
|}

Such as with [[OpenMoko_Local_Groups:_Singapore | Singapore]] or [[OpenMoko_Local_Groups:_San_Francisco | San Francisco]]

== Europe ==

* Austria
** [[OpenMoko_Local_Groups: Vienna|Vienna]]

* Belgium
** [[OpenMoko_local_Groups: Antwerp|Antwerp]]

* [[OpenMoko_Local_Groups:_Denmark|Denmark]]
** [[OpenMoko_Local_Groups: Copenhagen|Copenhagen]]
** [[OpenMoko_Local_Groups: Aalborg|Aalborg]]

* Estonia
** [[OpenMoko_Local_Groups: Kuressaare|Kuressaare]]

* Finland
** [[OpenMoko_Local_Groups: Helsinki|Helsinki]]

* France
** [[OpenMoko_Local_Groups: Paris|Paris]]
** [[OpenMoko_Local_Groups: Toulouse|Toulouse]]

* Germany
** [[OpenMoko_Local_Groups: Berlin|Berlin]]
** [[OpenMoko_Local_Groups: Braunschweig|Braunschweig]]
** [[OpenMoko_Local_Groups: Duesseldorf|Duesseldorf]]
** [[OpenMoko_Local_Groups: Frankfurt Main|Frankfurt Main]]
** [[OpenMoko_Local_Groups: Freiburg im Breisgau|Freiburg im Breisgau]]
** [[OpenMoko_Local_Groups: OWL|OWL]]
** [[OpenMoko_Local_Groups: Ingolstadt|Ingolstadt]]
** [[OpenMoko_Local_Groups: Ulm|Ulm]]

* Greece
** [[OpenMoko_Local_Groups: Athens|Athens]]

* Italy
** [[OpenMoko_Local_Groups: Milan|Milan]]
** [[OpenMoko_Local_Groups: Turin|Turin]]

* [[OpenMoko_Local_Groups:_Netherlands|Netherlands]]
** [[OpenMoko_Local_Groups: Amsterdam|Amsterdam]]
** [[OpenMoko_Local_Groups: Den Haag|Den Haag/The Hague]]
** [[OpenMoko_Local_Groups: Eindhoven|Eindhoven]]
** [[OpenMoko_Local_Groups: Ede|Ede]]

* [[OpenMoko_Local_Groups:_Norway|Norway]]
** [[OpenMoko_Local_Groups:_Oslo|Oslo]]
** [[OpenMoko_Local_Groups: Trondheim|Trondheim]]

* Poland
** [[OpenMoko_Local_Groups: Warsaw|Warsaw]]
** [[OpenMoko_Local_Groups: Szczecin|Szczecin]]

* [[OpenMoko_Local_Groups:_Portugal|Portugal]]
** [[OpenMoko_Local_Groups: Braga|Braga]]

* Romania
** [[OpenMoko_Local_Groups: Bucharest|Bucharest]]

* Russia
** [[OpenMoko_Local_Groups: Moscow|Moscow]]
** [[OpenMoko_Local_Groups: Saint-Petersburg|Saint-Petersburg]]

* Slovakia
** [[OpenMoko_Local_Groups: Bratislava|Bratislava]]

* Spain
** [[OpenMoko_Local_Groups: Madrid|Madrid]]

* Sweden
** [[OpenMoko_Local_Groups: Gothenburg|Gothenburg]]
** [[OpenMoko_Local_Groups: Linkoping|Linköping]]

* [[OpenMoko_Local_Groups: Switzerland|Switzerland]]
** [[OpenMoko_Local_Groups: Bern|Bern]]

* UK
** England
*** [[OpenMoko_Local_Groups: Birmingham|Birmingham]]
*** [[OpenMoko_Local_Groups: London|London]]
*** [[OpenMoko_Local_Groups: East Midlands|East Midlands]]

** Scotland
*** [[OpenMoko_Local_Groups: Fife|Fife]]
*** [[OpenMoko_Local_Groups: Edinburgh|Edinburgh]]

* Ukraine
** [[OpenMoko_Local_Groups: Lugansk|Lugansk]]

== Oceania ==

* Australia
** [[OpenMoko_Local_Groups: Adelaide|Adelaide]]
** [[OpenMoko_Local_Groups: Canberra|Canberra]]
** [[OpenMoko_Local_Groups: Melbourne|Melbourne]]
** [[OpenMoko_Local_Groups: Perth|Perth]]
** [[OpenMoko_Local_Groups: Sydney|Sydney]]

* New Zealand
** [[OpenMoko_Local_Groups: Auckland|Auckland]]
** [[OpenMoko_Local_Groups: Christchurch|Christchurch]]

== Asia ==
* India
** [[OpenMoko_Local_Groups: Delhi|Delhi]]
* Singapore
** [[OpenMoko_Local_Groups: Singapore|Singapore]]

== USA ==
* Alabama
** [[OpenMoko_Local_Groups: Alabama|Alabama]]

* Arizona
** [[OpenMoko_Local_Groups: Arizona|Arizona]]

* Arkansas
** [[OpenMoko_Local_Groups: Arkansas|Arkansas]]

* California
** [[OpenMoko_Local_Groups: San Diego|San Diego]]
** [[OpenMoko_Local_Groups: San Francisco|San Francisco]]
** [[OpenMoko_Local_Groups: Sacramento|Sacramento]]
** [[OpenMoko_Local_Groups: Los Angeles|Los Angeles]]
** [[OpenMoko_Local_Groups: Santa Barbara|Santa Barbara]]

* Colorado
** [[OpenMoko_Local_Groups: Colorado Springs|Colorado Springs]]
** [[OpenMoko_Local_Groups: Denver|Denver]]

* District of Columbia
** [[OpenMoko_Local_Groups: Washington DC Metro | Washington DC Metro]]

* Florida
** [[OpenMoko_Local_Groups: Central Florida | Central Florida]]

* Georgia
** [[OpenMoko_Local_Groups: Atlanta | Atlanta]]

* Illinois
** [[OpenMoko_Local_Groups: Chicago|Chicago]]

* Indiana
** [[OpenMoko_Local_Groups: Bloomington|Bloomington]]

* Iowa
** [[OpenMoko_Local_Groups: Iowa-Ames | Iowa-Ames]]

* Massachusetts
** [[OpenMoko_Local_groups: Boston|Boston]]

* Michigan
** [[OpenMoko_Local_Groups: Detroit|Detroit]]

* New Jersey
** [[OpenMoko_Local_Groups: Stevens Institute of Technology, Hoboken NJ | Stevens Institute of Technology, Hoboken NJ ]]

* New York
** [[OpenMoko_Local_Groups: NYC Metro | NYC Metro]]

* North Carolina
** [[OpenMoko Local_Groups: Charlotte | Charlotte]]

* Ohio
** [[OpenMoko_Local_Groups: Cleveland|Cleveland]]

* Oregon
** [[OpenMoko_Local_Groups: Eugene|Eugene]]
** [[OpenMoko_Local_Groups: Portland|Portland]]

* Texas
** [[OpenMoko_Local_Groups: North Texas|North Texas]]
** [[OpenMoko_Local_Groups: Central Texas|Central Texas]]

* Utah
** [[OpenMoko_Local_Groups: Salt Lake|Salt Lake]]

* Virginia
** [[OpenMoko_Local_Groups: Virginia|Virginia]]

== Canada ==
* Alberta
** [[OpenMoko_Local_Groups: Calgary|Calgary]]
** [[OpenMoko_Local_Groups: Edmonton|Edmonton]]
** [[OpenMoko_Local_Groups: Pincher Creek|Pincher Creek]]
* British Columbia
** [[OpenMoko_Local_Groups: Vancouver|Vancouver]]
* Ontario
** [[OpenMoko_Local_Groups: Ottawa|Ottawa]]
** [[OpenMoko_Local_Groups: Toronto|Toronto]]
* Quebec
** [[OpenMoko_Local_Groups: Montreal|Montreal]]

== South America ==
* Brasil
** [[OpenMoko_Local_Groups: Belo Horizonte|Belo Horizonte]]
* Colombia
** [[OpenMoko_Local_Groups: Bogota|Bogotá]]
* Uruguay
** [[OpenMoko_Local_Groups: Montevideo]]

== Africa ==
* South Africa
**[[OpenMoko_Local_Groups: Cape Town|Cape Town]]

[[Category:Community]]
[[Category:Neo1973 Phase 1 related]]

Toolchain

2007-12-10T08:47:11Z

Henrikp: /* Downloading and installing the toolchain */

= Introduction =

A toolchain is a set of tools that allows you to compile code. For OpenMoko, we have to differenciate the following use-cases:

* Developing a single application

For this, you should use a prebuilt toolchain from the OpenMoko project. Here you can find a recipe to get started with this toolchain leading you through a series of steps to compile a project and run it on your target device. You might have heard about [[OpenEmbedded]], however as an application programmer, you should '''not''' be using [[OpenEmbedded]].

* System Integration and customizing a distribution

For this task, you should use [[OpenEmbedded]] which builds its own cross compiler during the bootstrapping/build process. System Integration and customizing a distribution is out of scope of this page.

= Prerequisites =

You should be reasonably familiar with Linux and its command line tools, have an x86-compatible computer with at least 1G of free disk space. You should have experience with compiling programs from source using your local compiler. The remainder of this document will also assume you have write access in your home directory (~) and <tt>/usr/local/</tt>. If this is not the case, please call your local administrator for help.

= Downloading and installing the toolchain =

The prebuilt toolchain can be downloaded from [[http://downloads.openmoko.org/toolchains downloads.openmoko.org]]:

mkdir ~/sources
cd ~/sources
wget http://downloads.openmoko.org/toolchains/openmoko-x86_64-arm-linux-gnueabi-toolchain.tar.bz2

or

wget http://downloads.openmoko.org/toolchains/openmoko-i686-arm-linux-gnueabi-toolchain.tar.bz2

Next, you want to extract it on your filesystem. This toolchain is ''not'' relocatable, it needs to be installed into <tt>/usr/local/openmoko/</tt>:

cd /
tar xjvf ~/sources/openmoko-XYZ-arm-linux-gnueabi-toolchain.tar.bz2

The prebuilt toolchain is for x86_64 or i686 now. You could build it on your own with OE:

bitbake meta-toolchain-openmoko

Finally, everytime you want to use this toolchain, you need to alter some environment variables, so that your tools will be found. The toolchain provides a script to do that, so the only thing you need to do is to source it:

source /usr/local/openmoko/arm/setup-env

= Using the toolchain to build a sample project =

In your home directory:

cp -r /usr/local/openmoko/arm/share/openmoko-sample2 ~/
. /usr/local/openmoko/arm/setup-env
om-conf openmoko-sample2
<modify it if you want and make>

If you want to install this project on host for staging usage later, a shared library, for example, you can then call <tt>make install</tt> to install it into the configured prefix.

make install

== Packaging your application ==

We have included a script to make an ipkg out of your application.

om-make-ipkg openmoko-sample2

Now you got openmoko-sample2_0.1_armv4t.ipk , you can `scp' it to your
neo and install it:

scp openmoko-sample2_0.1_armv4t.ipk root@192.168.0.202:
ssh root@192.168.0.202 ipkg install openmoko-sample2_0.1_armv4t.ipk

Note that while you can redistribute the generated ipkg, be aware that this is a bare-bones ipk that contains no further information, i.e. you will lack library dependencies.

You could supply the version number, a description, and an author / contacts string in a control file if you know how to use it:

om-make-ipkg myapp myapp_control

A template of myapp_control:

Package: $appname
Version: 0.1
Description: package built by openmoko toolchain
Section: openmoko/applications
Priority: optional
Maintainer: $USER
Architecture: armv4t
Homepage: http://www.openmoko.org/
Depends:
Source: ${SRC}

{{todo|hint how to get the package included in OE}}

= Where to go from here =

{{todo|write}}

= Advanced topics =

== Installing additional libraries into the toolchain ==

{{todo|write}}

= Troubleshooting =

{{todo|write}}

{{Languages|Toolchain}}

[[Category:OpenMoko]]

Neo1973: GTA01Bv4 versus GTA02 comparison/ee

2007-12-08T14:29:33Z

Henrikp: /* Neo1973 GTA01Bv4 ja GTA02 riistvaraline erinevus */

== Neo1973 GTA01Bv4 ja [[GTA02#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|GTA02]] riistvaraline erinevus ==

{| border="1"
!Tunnus
!GTA01Bv4
!GTA02
|-
|Müük
|Ostetav: https://direct.openmoko.com/
|Ei ole veel valmis. Loe siit: http://wiki.openmoko.org/wiki/Community_Updates
|-
|Mõõtmed (ei ole erinevusi)
|120.7 x 62 x 18.5 mm
|120.7 x 62 x 18.5 mm
|-
|Kaal
|184 g
|184 g (kinnitamata)
|-
|Ekraan (ei ole erinevusi)
|2.8" 480x640, 285 ppi (pikselit tolli kohta),
|2.8" 480x640, 285 ppi, [http://lists.openmoko.org/pipermail/community/2006-December/000576.html hiljem võibolla mitme-puuteline]
|-
|[[Neo1973_Hardware#microSD-Card|Andmemahutavus]]
|64 MB integreeritud välkmälu (laiendatav [http://lists.openmoko.org/pipermail/community/2007-February/003156.html igas suuruses microSD või MicroSDHC mälukaardiga])
| [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html 256 MB] integreeritud välkmälu.
Laiendatav [http://www.techtree.com/India/News/Samsung_Readies_8GB_microSD_Card/551-81172-581.html igas suuruses microSD või MicroSDHC mälukaardiga]
|-
|[[Neo1973_Hardware#Processor|Protsessor (CPU)]]
|Samsung s3c2410 SoC @ 266 MHz[http://lists.openmoko.org/pipermail/announce/2007-January/000000.html]
|[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=SC32442&&ppmi= Samsung 2442] @ 400 MHz SoC
|-
|Graafikakiirendi
|
|[http://www.smediatech.com/product3362.htm SMedia 3362 2D/3D graafikakiirendi] [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html lists.openmoko.org teadeanne]
|-
|[[Neo1973_Hardware#RAM|Operatiivmälu (RAM)]]
|128 MB
|128 MB
|-
|Traadita ühendus
|Kolmesageduslik GSM, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (ei ole EDGE), Bluetooth 2.0 EDR
|Kolmesageduslik GSM, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (ei ole EDGE), Bluetooth 2.0 EDR; WiFi: [http://lists.openmoko.org/pipermail/announce/2007-April/000012.html Atheros AR6K] (Vaata ka [[AR6K]]) (802.11 b/g)
|-
|Sisseehitatud seadmed
|Assisteeritud GPS, 2 nuppu
|Assisteeritud GPS, 2 nuppu; 2x3D [[Accelerometer|kiirendusandurit]]
|-
|GPSi riistvara
|Global Locate (nüüdseks Broadcom) Hammerhead
|u-blox/Atmel ATR0635 [http://lists.openmoko.org/pipermail/community/2007-October/011013.html]
|-
|Heli
|Sisseehitatud stereokõlarid, stereokuularid
|Sisseehitatud monokõlar, stereokuularid
|-
|WiFi
|ei
|jah
|-
|Kiirendusandur
|ei
|jah
|-
|Tarkvara
|Äärmiselt vigane. Enamus tarkvara peab lisama või panema tööle.
|Algeline PDA kaasas. Tavalised kasutajad saavad ise teha tarkvara.
|-
|Aku
|Vahetatav [[Neo1973_Battery|1.2 Ah aku]] USB 1.1 kaudu laetav
|Vahetatav [[Neo1973_Battery|1.7 Ah aku]] USB 1.1 kaudu laetav, või 1000mA välja andev seinalaadija[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=956]. Omab ka kulonilugejat täpse laengu väljalugemiseks[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=957]
|-
|USB Hosti tugi
|Jah, kuid on vaja välist +5V
|Jah, oma toitega ühendus [http://lists.openmoko.org/pipermail/neo1973-hardware/2007-October/000280.html]
|-
|Kasutuseks valmis
|Mitte eriti. [[Developer_preview|Mida ikka oodata arendaja eelvaatega GTA01-st]].
|Jah.
|-
|Hind (ei sisalda transporti ja sinu riigi makse)
|300 dollarit (~3200 krooni, baasmudel), 450 dollarit (~4800 krooni) Sisaldab lisariistvara arenduseks. (Kõik seadmed saadetakse Ameerika Ühendriikidest)
|450 dollarit (~4800 krooni, baasmudel), 600 dollarit (~6500 krooni) Sisaldab lisariistvara arenduseks.
|-
|}

{{Languages|Neo1973: GTA01Bv4 versus GTA02 comparison}}

[[Category:Neo1973 Phase 1 related]]
[[Category:Neo1973 Phase 2 related]]
[[Category:Information]]

Flashing the Neo 1973

2007-12-08T14:23:39Z

Henrikp: /* Actually flashing things into the device */

This describes how to update your Neo1973 to the latest software. We'll update the kernel, the root filesystem and optionally u-boot [[partitions]] in the internal flash memory.

{{warning|If you're updating u-boot and don't have a [[Debug Board]], you might render your unit unusable if the flashing procedure is interrupted}}

{{warning|If you upload a rootfs image that is smaller than the previous one it won't work - you need to attach to bootloader, [[Nand_erase|erase NAND]] and then upload your rootfs first}}

== Files to download ==

MacOS X users: please refer to [[MacOS_X]]. Users without Linux please refer to [[No_Linux]] for the moment.

The rootfs & kernel images you download need to match. The loadable modules for the kernel are in /lib/modules/ on the rootfs [[partition]] - if you get the wrong combination, you will get some error messages during bootup that it cannot access /lib/modules/x.y.z-moko123 - in this case swap either the kernel or the rootfs to match the other's version. Unfortunately the rootfs filename does not seem to tell what kernel version it is compatible with, you just have to try a few. '''NOTE:''' At least some combinations seem to boot up fine even if the module versions mismatch so be sure to check the console while it's booting after flashing.

The "moko123" in the error message example above indicates the openmoko patchset version.

Necessary files are at:
*http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/neo1973/?C=M;O=D

*http://buildhost.automated.it/OM2007.2/?M=D (Location of more current unofficial builds.)

A list of download locations can be found at [[Repositories]]. See [[Phase 1 Software Testing]] for a list of tested images.

Changelogs can be found at:
*http://cia.vc/stats/project/openembedded/.rss

*http://cia.vc/stats/project/openmoko/.rss

Get:
* [[dfu-util]] (the precompiled binary on http://buildhost.openmoko.org is for Linux/i386)
** (this is the part that runs on the PC, that pushes the files across the USB to the phone)
* openmoko-devel-image-fic-gta01-2007********.rootfs.jffs2
* uImage-2.6.21.*-moko*-r*_0_****_0-fic-gta01.bin
* for phase 0 (Bv03) phones:
** Tested by a few people: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin MD5SUM: 60c5aeba1bd6642b05b3a5e6f2dafe83
** Tested by hrw: u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2062.bin MD5SUM: 716f1eba9b0f2be4a0a3be4a56724935
* for phase 1 phones, uboot update should not be necessary.

== Preparing the device for DFU mode ==

You'll need to boot your openmoko into uboot menu. To do this:

* Unplug all usb devices from the host.
* Hold the phone's [[Neo1973 AUX Button | AUX button]] and then press the phone's [[Neo1973 Power Button | POWER button]].
** You'll need to hold the POWER button for about 4 seconds before the device will turn on. Otherwise the screen will only flash white for a second and the phone won't power up.
* The u-boot menu should appear.
* Plug Neo1973 into host with supplied USB cable. (Plug the phone directly into the host not via a hub.)

'''Note:''' If the bootloader remains inactive for about 30 seconds, that is no keypresses or no use of the serial console, the device will automatically power down.
You can prevent this by just pressing the AUX button every 30 seconds or so or by telling the bootloader to not exhibit this behaviour.
To do so, please connect to the bootloader:

<pre>
cu -l /dev/ttyACM0
GTA01Bv4 # setenv boot_menu_timeout 65000
GTA01Bv4 # saveenv
</pre>

(You may have to install the uucp package to have access to cu.)

No further navigation is needed in u-boot - the device will automatically start flashing the images when told to do so by dfu-util below. After flashing all the files, you can choose the "Boot" option to boot the newly flashed stuff.

== Actually flashing things into the device ==

Double check that u-boot matches your hardware version. You'll probably only want to update u-boot if you have the [[debug board]] for fixing failed u-boot updates. You can also check the current [[partitions]].

Note: It may be necessary to run the application as root (at least in ubuntu).

Note: In case there are more than one available usb devices use -d 0x1457:0x5119 option.

To update u-boot:

Warning: Do not update u-boot unless you have [[debug board]] or are really sure about what you are doing. Flashing a wrong u-boot image will brick your device! Note especially that image below is for GTA01B_v03, not GTA01B_v04

./dfu-util -a u-boot -R -D u-boot-gta01bv3-r8_70124c2602ae2d4c5d3dba05b482d91548242de8_0_2040.bin

To update the kernel:
./dfu-util -a kernel -R -D ./uImage-2.6.21.1-moko10-r0_0_1883_0-fic-gta01.bin
Flashing the kernel will probably take less than 1 minute. If you're having trouble, you may want to compare the output that you see to a "known good" [[Flashing openmoko/Known good kernel flash U-Boot output | U-Boot]]/[[Flashing openmoko/Known good kernel flash dmesg output | dmesg]]/[[Flashing openmoko/Known good kernel flash dfu-util output | dfu-util]] output.

To update the root filesystem:
./dfu-util -a rootfs -R -D ./Openmoko-devel-image-fic-gta01-20070501054014.rootfs.jffs2

Flashing the root filesystem will probably take around 13 minutes. Here is some "known good" output from [[Flashing openmoko/Known good rootfs flash U-Boot output | U-Boot]], [[Flashing openmoko/Known good rootfs flash dmesg output | dmesg]], and [[Flashing openmoko/Known good rootfs flash dfu-util output | dfu-util]].

Notice that it's not normally necessary to update the modules anymore. It's just for people with special needs.

...now, you'll end up with system that boots, but does not see audio/SD card. You'll need to download corresponding modules.tgz and copy them over to openmoko. - UPDATE: GTA01 phones appear to not need this step, as long as you have installed a kernel that matches the version of the modules contained in the root image ('uname -r' will show the kernel version, and 'ls /lib/modules/' will show the modules that are present).

VERY IMPORTANT NOTE (I would consider that as a design flaw - either dfu-util should do it automatically): If you upload rootfs image that is smaller that previous one it won't work - you need to attach to the u-boot bootloader, erase NAND first and then upload your rootfs:

<pre>
cu -l /dev/ttyACM0
GTA01Bv3 # nand erase rootfs
</pre>

Old versions of u-boot are buggy: You may have to press the AUX button every 25 seconds or so to prevent the phone from going to sleep while being flashed. It also does not erase rootfs before flashing it... to do that, do minicom /dev/ttyACM0, then nand erase clean rootfs.

Good luck!

== Where to go from here ==

So, now you have one of the more recent kernel and rootfs images, or one of the (semi)official ones, whats next?

You probably want to set up [[USB_Networking]] and then configure your Neo1973 some more.

Do not forget to update your Neo1973 using

ipkg update && ipkg upgrade

and have a look at additional ipkg [[repositories]].

== Troubleshooting notes ==

If you're facing errors in seemingly random places during the flashing of images, most likely the USB hub or cable through which your Neo1973 is connected is of too poor quality. It is recommended that you always connect the phone directly to the host when using dfu-util.

If dfu-util reports a message like the following, before it starts flashing:<pre>
Resetting USB...
not at least 2 device changes found ?!?
Lost device after RESET?</pre> just retry the command - it should work on a second run.

This message can also occur if you connect the usb cable before you are in the bootloader menu. You must carefully follow the sequence described at the beginning of this article and not connect the USB cable too early.

dfu-util does not seem to be able to download files if run from linux running under
VMWare on a Windows OS host.

See other notes on [[Dfu-util]] page.

[[Category:OpenMoko| ]]

Neo1973: GTA01Bv4 versus GTA02 comparison/ee

2007-12-08T11:28:06Z

Henrikp: /* Neo1973 GTA01Bv4 ja GTA02 riistvaraline erinevus */

== Neo1973 GTA01Bv4 ja [[GTA02#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|GTA02]] riistvaraline erinevus ==

{| border="1"
!Tunnus
!GTA01Bv4
!GTA02
|-
|Müük
|Ostetav: https://direct.openmoko.com/
|Ei ole veel valmis. Loe siit: http://wiki.openmoko.org/wiki/Community_Updates
|-
|Mõõtmed (ei ole erinevusi)
|120.7 x 62 x 18.5 mm
|120.7 x 62 x 18.5 mm
|-
|Kaal
|184 g
|184 g (kinnitamata)
|-
|Ekraan (ei ole erinevusi)
|2.8" 480x640, 285 ppi (pikselit tolli kohta),
|2.8" 480x640, 285 ppi, [http://lists.openmoko.org/pipermail/community/2006-December/000576.html hiljem võibolla mitme-puuteline]
|-
|[[Neo1973_Hardware#microSD-Card|Andmemahutavus]]
|64 MB integreeritud välkmälu (laiendatav [http://lists.openmoko.org/pipermail/community/2007-February/003156.html igas suuruses microSD või MicroSDHC mälukaardiga])
| [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html 256 MB] integreeritud välkmälu.
Laiendatav [http://www.techtree.com/India/News/Samsung_Readies_8GB_microSD_Card/551-81172-581.html igas suuruses microSD või MicroSDHC mälukaardiga]
|-
|[[Neo1973_Hardware#Processor|Protsessor (CPU)]]
|Samsung s3c2410 SoC @ 266 MHz ([http://lists.openmoko.org/pipermail/announce/2007-January/000000.html Source])
|[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=SC32442&&ppmi= Samsung 2442] @ 400 MHz SoC
|-
|Graafikakiirendi
|
|[http://www.smediatech.com/product3362.htm SMedia 3362 2D/3D graafikakiirendi] [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html lists.openmoko.org teadeanne]
|-
|[[Neo1973_Hardware#RAM|Operatiivmälu (RAM)]]
|128 MB
|128 MB
|-
|Traadita ühendus
|Kolmesageduslik GSM, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (ei ole EDGE), Bluetooth 2.0 EDR
|Kolmesageduslik GSM, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (ei ole EDGE), Bluetooth 2.0 EDR; WiFi: [http://lists.openmoko.org/pipermail/announce/2007-April/000012.html Atheros AR6K] (Vaata ka [[AR6K]]) (802.11 b/g)
|-
|Sisseehitatud seadmed
|Assisteeritud GPS, 2 nuppu
|Assisteeritud GPS, 2 nuppu; 2x3D [[Accelerometer|kiirendusandurit]]
|-
|GPSi riistvara
|Global Locate (nüüdseks Broadcom) Hammerhead
|u-blox/Atmel ATR0635 [http://lists.openmoko.org/pipermail/community/2007-October/011013.html]
|-
|Heli
|Sisseehitatud stereokõlarid, stereokuularid
|Sisseehitatud monokõlar, stereokuularid
|-
|WiFi
|ei
|jah
|-
|Kiirendusandur
|ei
|jah
|-
|Tarkvara
|Äärmiselt vigane. Enamus tarkvara peab lisama või panema tööle.
|Algeline PDA kaasas. Tavalised kasutajad saavad ise teha tarkvara.
|-
|Aku
|Vahetatav [[Neo1973_Battery|1.2 Ah aku]] USB 1.1 kaudu laetav
|Vahetatav [[Neo1973_Battery|1.7 Ah aku]] USB 1.1 kaudu laetav, või 1000mA välja andev seinalaadija[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=956]. Omab ka kulonilugejat täpse laengu väljalugemiseks[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=957]
|-
|USB Hosti tugi
|Jah, kuid on vaja välist +5V
|Jah, oma toitega ühendus [http://lists.openmoko.org/pipermail/neo1973-hardware/2007-October/000280.html]
|-
|Kasutuseks valmis
|Mitte eriti. [[Developer_preview|Mida ikka oodata arendaja eelvaatega GTA01-st]].
|Jah.
|-
|Hind (ei sisalda transporti ja sinu riigi makse)
|300 dollarit (~3200 krooni, baasmudel), 450 dollarit (~4800 krooni) Sisaldab lisariistvara arenduseks. (Kõik seadmed saadetakse Ameerika Ühendriikidest)
|450 dollarit (~4800 krooni, baasmudel), 600 dollarit (~6500 krooni) Sisaldab lisariistvara arenduseks.
|-
|}

{{Languages|Neo1973: GTA01Bv4 versus GTA02 comparison}}

[[Category:Neo1973 Phase 1 related]]
[[Category:Neo1973 Phase 2 related]]
[[Category:Information]]

Neo1973: GTA01Bv4 versus GTA02 comparison/ee

2007-12-08T10:56:11Z

Henrikp:

== Neo1973 GTA01Bv4 ja [[GTA02#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|GTA02]] riistvaraline erinevus ==

{| border="1"
!Tunnus
!GTA01Bv4
!GTA02
|-
|Müük
|Ostetav: https://direct.openmoko.com/
|Ei ole veel valmis. Loe siit: http://wiki.openmoko.org/wiki/Community_Updates
|-
|Mõõtmed (ei ole erinevusi)
|120.7 x 62 x 18.5 mm
|120.7 x 62 x 18.5 mm
|-
|Kaal
|184 g
|184 g (kinnitamata)
|-
|Ekraan (ei ole erinevusi)
|2.8" 480x640, 285 ppi (pikselit tolli kohta),
|2.8" 480x640, 285 ppi, [http://lists.openmoko.org/pipermail/community/2006-December/000576.html hiljem võibolla mitme-puuteline]
|-
|[[Neo1973_Hardware#microSD-Card|Andmemahutavus]]
|64 MB integreeritud välkmälu (laiendatav [http://lists.openmoko.org/pipermail/community/2007-February/003156.html igas suuruses microSD või MicroSDHC mälukaardiga])
| [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html 256 MB] integreeritud välkmälu.
Laiendatav [http://www.techtree.com/India/News/Samsung_Readies_8GB_microSD_Card/551-81172-581.html igas suuruses microSD või MicroSDHC mälukaardiga]
|-
|[[Neo1973_Hardware#Processor|CPU]]
|Samsung s3c2410 SoC @ 266 MHz ([http://lists.openmoko.org/pipermail/announce/2007-January/000000.html Source])
|[http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=SC32442&&ppmi= Samsung 2442] @ 400 MHz SoC
|-
|Graphics Accelerator
|
|[http://www.smediatech.com/product3362.htm SMedia 3362 2D/3D Graphics Accelerator] [http://lists.openmoko.org/pipermail/announce/2007-June/000013.html lists.openmoko.org announcement]
|-
|[[Neo1973_Hardware#RAM|RAM]]
|128 MB
|128 MB
|-
|Wireless
|Tri-band GSM, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (Not EDGE), Bluetooth 2.0 EDR
|Tri-band GSM, GPRS Class12/CS4/[http://lists.openmoko.org/pipermail/community/2007-September/010400.html B] 2.5G (Not EDGE), Bluetooth 2.0 EDR; WiFi: [http://lists.openmoko.org/pipermail/announce/2007-April/000012.html Atheros AR6K] (See also [[AR6K]]) (802.11 b/g)
|-
|Embedded devices
|Assisted GPS, 2 buttons
|Assisted GPS, 2 buttons; 2x3D [[Accelerometer]]s
|-
|GPS Hardware
|Global Locate (now Broadcom) Hammerhead
|u-blox/Atmel ATR0635 [http://lists.openmoko.org/pipermail/community/2007-October/011013.html]
|-
|Sound
|Built-in stereo speakers, stereo handset
|Built-in mono speaker, stereo handset
|-
|WiFi
|no
|yes
|-
|Accelerometer
|no
|yes
|-
|Software
|Extremely buggy. Most software needs to be added or made to work.
|Basic PDA included. Software can be created by normal users.
|-
|Battery
|Replaceable [[Neo1973_Battery|1.2 Ah battery]] charged via USB 1.1
|Replaceable [[Neo1973_Battery|1.7 Ah battery]] charged via USB 1.1, or wall charger supplying 1000mA[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=956]. Also has a coulomb counter for accurate charge reading[http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=957]
|-
|USB Host Support
|Yes, but external +5V is required
|Yes, powered port [http://lists.openmoko.org/pipermail/neo1973-hardware/2007-October/000280.html]
|-
|Ready for use
|Not really. [[Developer_preview|What to expect from the Developer preview GTA01]].
|Yes.
|-
|Price (not including shipping costs and applicable taxes for your country)
|USD 300 (base model), USD 450 including additional development hardware. (All units are shipped from the U.S.)
|USD 450 (base model), USD 600 including additional development hardware.
|-
|}

{{Languages|Neo1973: GTA01Bv4 versus GTA02 comparison}}

[[Category:Neo1973 Phase 1 related]]
[[Category:Neo1973 Phase 2 related]]
[[Category:Information]]

Manually using Bluetooth

2007-12-08T09:49:01Z

Henrikp: /* Bluetooth networking with a Windows XP system */

{{InProgress}}
Bluetooth is one of the core functions of the Neo1973, however it is basically unimplemented on the software side at the moment.
Hardware problems in the P1 phone mean that the CPU has to be active in order to wake on external bluetooth events, which will reduce the battery life to some 2 days at best in standby.

This page details how to use bluetooth from the command line.
We have quite a lot of plans about what exactly Bluetooth should be used for.

== Power it up ==

Power up the adapter by clicking on the bluetooth icon in the top bar and selecting power on.

The old way to do it is a shell command:

root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on

At the shell, "hciconfig" should print information about the adapter if it powered up properly:

hciconfig

The devices should show as UP. If not you can use

hciconfig <device> up

== Bluetooth Functions ==

===Configuring Bluetooth on OpenMoko 2007.2 (August 27 snapshot with kernel 2.6.21.6-moko11) ===

In file /etc/bluetooth/hcid.conf you should change the passkey from BlueZ to something numeric. For testing you may use "0000". Also, you can set the name to "Neo (%d)".

=== Scanning for bluetooth devices ===

hcitool scan

This will list the addresses of any discoverable bluetooth devices in the vicinity

=== passkey agent example ===

There should be a passkey agent built into openmoko, but for now you can start up the example passkey agent and set the pin code there. This will allow for new pairings to be made when you attempt a connection.

passkey-agent --default 0000 &

Note: the passkey-agent is not required in OpenMoko 2007.2 with kernel 2.6.21.6 as of at least since August 27 (maybe earlier).

=== HID (Human Input Device) ===

==== Being able to use HID devices ====

We want to be able to use a bluetooth keyboard to type into the various applications of our Neo1973.
To use a Bluetooth Keyboard type: (11:22:33:44:55:66 is the Address of your BT-Keyboard)

hidd --connect 11:22:33:44:55:66

and press "Connect" on your BT-KB. Alternately, if you know that only one BT-Keyboard is within range, you can just:

hidd --search

to find and connect to any BT-Keyboard.

Tested on:
* [http://www.logitech.com/index.cfm/products/details/US/EN,CRID=2166,CONTENTID=10717 Logitech Dinovo Edge]
* [http://www.nokia.es/A4181580 Nokia SU-8W]. Switched on the BT keyboard, scanned for BT address and ran the connect statement above. Works fine.
* [http://blog.russnelson.com/chordite Chordite]. This keyboard uses the Broadcom BCM2042 BT keyboard controller along with a custom driver.
* The freedom keyboard from freedominput.com and its many rebranded models (they look like this: [http://rabenfrost.net/openmoko/keyboard.jpg]) need 'modprobe uinput' to circumvent the 'Can't open input device: No such file or directory (2)' error of 'hidd --search' but it still not works on openmoko but on my ubuntu box - maybe another kernel module is missing?

==== Acting as HID device ====

We want to be able to use the Neo1973 as a HID device, being able to use it as controller for presentations.

=== RFCOMM ===

Here's how to connect to an external Bluetooth GPS and read NMEA data (Tested with a Holux GPSSlim236 and a Nokia LD-3W ).

First, switch on the GPS and identify the BT address:

hcitool scan

Then, edit /etc/bluetooth/rfcomm.conf, which by default has all settings commented out, to something like this:

rfcomm0 {
# Automatically bind the device at startup
bind no;
# Bluetooth address of the device
device 00:11:22:33:44:55;
# RFCOMM channel for the connection (check your GPS docs for details)
channel 1;
# Description of the connection
comment "Bluetooth GPS";
}

Restart the BT services:

root@neo:~$ /etc/init.d/bluetooth stop
root@neo:~$ /etc/init.d/bluetooth start

You should now be able to bind the GPS to /dev/rfcomm0, like this:

root@neo:~$ rfcomm bind 0

Confirm the connect:

root@neo:~$ rfcomm
rfcomm0: 00:11:22:33:44:55 channel 1 clean

... and watch the NMEA strings coming from your GPS:

root@neo:~$ cat /dev/rfcomm0
$GPGGA,111748.000,5907.6964,N,01121.1787,E,1,06,1.2,57.7,M,40.1,M,,0000*6F
$GPRMC,111748.000,A,5907.6964,N,01121.1787,E,0.00,94.94,160807,,,A*50
$GPVTG,94.94,T,,M,0.00,N,0.0,K,A*3D

If you have nothing better to do, you can now pinpoint my office :-).

=== OBEX ===

=== Networking ===

=== Bluetooth networking with a Linux system ===

Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.

On the laptop

* Start bluetooth
elara /home/alphaone # /etc/init.d/bluetooth start

* Start pand as server
elara /home/alphaone # pand -s

* As soon as pand is started on the phone configure your IP address
elara /home/alphaone # ip a add 10.0.0.1/24 dev bnep0
elara /home/alphaone # ip l set bnep0 up

* Configure IP forwarding and masquerading to your liking (see [[USB_Networking]]). You can even set up Udev rules to do this for you once the bnep0 interface appears.

On the Neo

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
00:0E:6D:C0:0l:6A Sho
00:20:E0:5A:FE:C8 BlueZ (0)

* Connect to the laptop pand
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8

* Configure your IP address
ip a add 10.0.0.2/24 dev bnep0
ip r add default via 10.0.0.1

* Enjoy

=== Bluetooth networking with a Windows XP system ===

This was tested with a Windows XP SP2 on a IBM Thinkpad T41 with the Widcomm BT stack

* Start bluetooth on Windows XP

* Enable "Network Access" in the Bluetooth configuration

* Scan for the Neo and pair with the Neo (right click, select pair)

On the Neo

* Enable PAN support on the Neo by changing Autostart from false to true in /etc/bluetooth/network.service

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
<laptop_bt_address> Thinkpad
...

* Connect to the laptop pand
pand -c <laptop_bt_address> -r PANU -d NAP -e bnep0 -A -E -S
(add '-n' to see the pand status messages until you get it right)

For some reason, I was not able to initiate PAN connections from the Neo, I got 'Permission denied (13)' even when I had explicitly allowed the Neo to connect (right click on Neo icon, set properties, on Authorization tab). But initiating 'PAN User' from Windows worked when executing on Neo:
pand -l -r PANU -d NAP -e bnep0 -A -E -S
(add '-n' to see the pand status messages until you get it right)

* Configure your IP address. It should work like when connecting to Linux:
ip a add 10.0.0.2/24 dev bnep0
ip r add default via 10.0.0.1
If this does not work, the IP stacks may have auto-assigned network addresses to themselves. You can look this up with 'ifconfig' on the Neo and with 'ipconfig' on Windows.

* You should now be able to ssh/putty from Windows to your Neo. Enjoy!
By setting up the Windows Bluetooth connection properly, it should also be possible to share the Internet Connection of the Windows box with the Neo.

=== PPP Networking ===

If you are unable to use the 'BNEP' method described above, you may be able to use [[PPP]] and a DUN (dialup-networking) emulation mode. On the Neo:

* Edit the /etc/default/bluetooth file and set the following options:
RFCOMM_ENABLE=true
DUND_ENABLE=true
DUND_OPTIONS="--listen --persist call dun"

* Create an /etc/ppp/peers/dun file with options like the following:
115200
192.168.2.202:192.168.2.200
passive
local
noipdefault
noauth
nodefaultroute

* Restart bluetooth (/etc/init.d/bluetooth stop ; /etc/init.d/bluetooth start)

To connect from a MacOS 10.3 client:

* Open "Applications/Utilities/Bluetooth Serial Utility"

* Click on "New"

* Choose a name, then click "Choose Device"

* Locate your Neo, then select the "LAN Access Point" service. If your device is not found, or if this service does not show up, then you will need to troubleshoot and fix that before continuing. Bluetooth is designed for short-range communication, so make sure that the devices are physically close to each other.

* Select "Port type: RS-232" and "Show in Network Preferences". Click OK.

* Open the Network Preferences page then "Show: Network Port Configurations". Enable the new device that you defined in the previous step and drag it to the bottom of the device list (so that it will not interfere with your other network connections)

* Choose "Show: <your-device-name>", then click "Modem"

* Select "Null Modem 115200" from the list of available devices. Uncheck "Wait for dial tone" and "Enable error correction and compression in modem". Optionally check "Show modem status in menu bar".

* Click "Connect". If everything worked, you will end up with a 'ppp0' device on your Mac with a local address of 192.168.2.200 and you will be able to access your Neo at 192.168.2.202.

=== A2DP quickie ===

It's now possible (if a little hackish) to stream mp3 to a bluetooth headset. It's a known problem that the playback rate changes (pitch varies). Timing issues are also likely the reason for gaps in playback.

If the bluez packages are recent enough, you can use a shortcut. I'll document it here and leave the longer version below (the long version also demonstrates the API used by the GUI to manage headsets)

Create /etc/asound.conf with your bluetooth headset's address filled in:

pcm.!default {
type bluetooth
device "xx:xx:xx:xx:xx:xx"
}

then play a song

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay

or for smoother results...

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:song.wav
aplay song.wav

=== A2DP ===

If that doesn't work... all the more hackish... install required packages:

echo "src/gz python http://www.angstrom-distribution.org/unstable/feed/armv4t/python/" >> /etc/ipkg/angstrom-python.conf
echo "src/gz base http://www.angstrom-distribution.org/unstable/feed/armv4t/base/" >> /etc/ipkg/angstrom-base.conf
ipkg update ; ipkg install python-core python-xml python-dbus bluez-utils bluez-utils-alsa

Create /etc/asound.conf:

pcm.!default {
type bluetooth
}
ctl.!default {
type bluetooth
}
pcm.bluetooth {
type bluetooth
}
ctl.bluetooth {
type bluetooth
}

Run the passkey agent (see above in this page)

Fill in your bluetooth headset address below and execute the python script (with your headset turned on)

#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
conn = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')
path = audio.CreateDevice('00:0D:3C:44:33:22')
audio.ChangeDefaultDevice(path)
sink = dbus.Interface(bus.get_object(conn, path), 'org.bluez.audio.Sink')
sink.Connect()

FINALLY: play a song

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay

=== Headset Audio ===

[[Neo1973_Audio_Subsystem]] has detail about alsa settings and a proposal for audio scenario management.

To try this out, follow the instructions in the a2dp section to install software and run the passkey agent.

Remove or disable the stuff you put in asound.conf. When using a voice headset, the application uses the regular system audio device and it gets routed to bluetooth in the codec.

Put the headset in pairing mode. Replace the bluetooth address below with your headset's and run the python script:

#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
conn = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')
path = audio.CreateHeadset('00:0B:2E:39:33:22')
audio.ChangeDefaultHeadset(path)
headset = dbus.Interface (bus.get_object(conn, path), 'org.bluez.audio.Headset')
headset.Connect()
headset.Play()

Now place a call and try to route it to bluetooth (after it's in progress):

alsactl -f /etc/gsmbluetooth.state restore

You may also be able to listen to system audio given the right state file:

alsactl -f /etc/systembluetooth.state restore
madplay song.mp3

=== Bluetooth networking with a Linux system - More secure way ===

''Check this, probably needs some corrections''

Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.

On the laptop

* check these options in /etc/bluetooth/hcid.conf
security auto;
passkey "your pin";
lm master;

* Start bluetooth
# /etc/init.d/bluetooth start

* Start pand as server
pand --listen --role NAP --encrypt

* Add in /etc/network/interfaces (see [[USB_Networking]])
auto bnep0
iface bnep0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.1.0/24
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -P FORWARD ACCEPT

On the Neo

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
00:20:E0:5A:FE:C8 laptop

* Set pin
root@fic-gta01:~$ passkey-agent 'your pin' 00:20:E0:5A:FE:C8 &

* Connect to the laptop pand
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8

* Configure your IP address
root@fic-gta01:~$ ifconfig bnep0 192.168.1.2
root@fic-gta01:~$ route add default gateway 192.168.1.1

* Enjoy

== Further reading ==

http://www.holtmann.org/papers/bluetooth/ols2006_slides.pdf
http://wiki.bluez.org/wiki/Audio#org.bluez.Audio

{{Languages|Manually_using_Bluetooth}}
[[Category:Neo1973 Hardware]]
[[Bluetooth]]

Manually using Bluetooth

2007-12-08T09:37:12Z

Henrikp: /* Bluetooth networking with a Windows XP system */

{{InProgress}}
Bluetooth is one of the core functions of the Neo1973, however it is basically unimplemented on the software side at the moment.
Hardware problems in the P1 phone mean that the CPU has to be active in order to wake on external bluetooth events, which will reduce the battery life to some 2 days at best in standby.

This page details how to use bluetooth from the command line.
We have quite a lot of plans about what exactly Bluetooth should be used for.

== Power it up ==

Power up the adapter by clicking on the bluetooth icon in the top bar and selecting power on.

The old way to do it is a shell command:

root@fic-gta01:~$ echo "1" > /sys/bus/platform/devices/gta01-pm-bt.0/power_on

At the shell, "hciconfig" should print information about the adapter if it powered up properly:

hciconfig

The devices should show as UP. If not you can use

hciconfig <device> up

== Bluetooth Functions ==

===Configuring Bluetooth on OpenMoko 2007.2 (August 27 snapshot with kernel 2.6.21.6-moko11) ===

In file /etc/bluetooth/hcid.conf you should change the passkey from BlueZ to something numeric. For testing you may use "0000". Also, you can set the name to "Neo (%d)".

=== Scanning for bluetooth devices ===

hcitool scan

This will list the addresses of any discoverable bluetooth devices in the vicinity

=== passkey agent example ===

There should be a passkey agent built into openmoko, but for now you can start up the example passkey agent and set the pin code there. This will allow for new pairings to be made when you attempt a connection.

passkey-agent --default 0000 &

Note: the passkey-agent is not required in OpenMoko 2007.2 with kernel 2.6.21.6 as of at least since August 27 (maybe earlier).

=== HID (Human Input Device) ===

==== Being able to use HID devices ====

We want to be able to use a bluetooth keyboard to type into the various applications of our Neo1973.
To use a Bluetooth Keyboard type: (11:22:33:44:55:66 is the Address of your BT-Keyboard)

hidd --connect 11:22:33:44:55:66

and press "Connect" on your BT-KB. Alternately, if you know that only one BT-Keyboard is within range, you can just:

hidd --search

to find and connect to any BT-Keyboard.

Tested on:
* [http://www.logitech.com/index.cfm/products/details/US/EN,CRID=2166,CONTENTID=10717 Logitech Dinovo Edge]
* [http://www.nokia.es/A4181580 Nokia SU-8W]. Switched on the BT keyboard, scanned for BT address and ran the connect statement above. Works fine.
* [http://blog.russnelson.com/chordite Chordite]. This keyboard uses the Broadcom BCM2042 BT keyboard controller along with a custom driver.
* The freedom keyboard from freedominput.com and its many rebranded models (they look like this: [http://rabenfrost.net/openmoko/keyboard.jpg]) need 'modprobe uinput' to circumvent the 'Can't open input device: No such file or directory (2)' error of 'hidd --search' but it still not works on openmoko but on my ubuntu box - maybe another kernel module is missing?

==== Acting as HID device ====

We want to be able to use the Neo1973 as a HID device, being able to use it as controller for presentations.

=== RFCOMM ===

Here's how to connect to an external Bluetooth GPS and read NMEA data (Tested with a Holux GPSSlim236 and a Nokia LD-3W ).

First, switch on the GPS and identify the BT address:

hcitool scan

Then, edit /etc/bluetooth/rfcomm.conf, which by default has all settings commented out, to something like this:

rfcomm0 {
# Automatically bind the device at startup
bind no;
# Bluetooth address of the device
device 00:11:22:33:44:55;
# RFCOMM channel for the connection (check your GPS docs for details)
channel 1;
# Description of the connection
comment "Bluetooth GPS";
}

Restart the BT services:

root@neo:~$ /etc/init.d/bluetooth stop
root@neo:~$ /etc/init.d/bluetooth start

You should now be able to bind the GPS to /dev/rfcomm0, like this:

root@neo:~$ rfcomm bind 0

Confirm the connect:

root@neo:~$ rfcomm
rfcomm0: 00:11:22:33:44:55 channel 1 clean

... and watch the NMEA strings coming from your GPS:

root@neo:~$ cat /dev/rfcomm0
$GPGGA,111748.000,5907.6964,N,01121.1787,E,1,06,1.2,57.7,M,40.1,M,,0000*6F
$GPRMC,111748.000,A,5907.6964,N,01121.1787,E,0.00,94.94,160807,,,A*50
$GPVTG,94.94,T,,M,0.00,N,0.0,K,A*3D

If you have nothing better to do, you can now pinpoint my office :-).

=== OBEX ===

=== Networking ===

=== Bluetooth networking with a Linux system ===

Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.

On the laptop

* Start bluetooth
elara /home/alphaone # /etc/init.d/bluetooth start

* Start pand as server
elara /home/alphaone # pand -s

* As soon as pand is started on the phone configure your IP address
elara /home/alphaone # ip a add 10.0.0.1/24 dev bnep0
elara /home/alphaone # ip l set bnep0 up

* Configure IP forwarding and masquerading to your liking (see [[USB_Networking]]). You can even set up Udev rules to do this for you once the bnep0 interface appears.

On the Neo

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
00:0E:6D:C0:0l:6A Sho
00:20:E0:5A:FE:C8 BlueZ (0)

* Connect to the laptop pand
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8

* Configure your IP address
ip a add 10.0.0.2/24 dev bnep0
ip r add default via 10.0.0.1

* Enjoy

=== Bluetooth networking with a Windows XP system ===

This was tested with a Windows XP SP2 on a IBM Thinkpad T41 with the Widcomm BT stack

* Start bluetooth on Windows XP

* Enable "Network Access" in the Bluetooth configuration

* Scan for the Neo and pair with the Neo (right click, select pair)

On the Neo

* Enable PAN support on the Neo by changing Autostart from false to true in /etc/bluetooth/network.service

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
<laptop_bt_address> Thinkpad
...

* Connect to the laptop pand
pand -c <laptop_bt_address> -r PANU -d NAP -e bnep0 -A -E -S
(add '-n' to see the pand status messages until you get it right)

For some reason, I was not able to initiate PAN connections from the Neo, I got 'Permission denied (13)' even when I had explicitly allowed the Neo to connect (right click on Neo icon, set properties, on Authorization tab). But initiating 'PAN User' from Windows worked when executing on Neo:
pand -l -r PANU -d NAP -e bnep0 -A -E -S
(add '-n' to see the pand status messages until you get it right)

* Configure your IP address. It should work like when connecting to Linux:
ip a add 10.0.0.2/24 dev bnep0
ip r add default via 10.0.0.1
If this does not work, the IP stacks may have auto-assigned network addresses to themselves. You can look this up with 'ifconfig' on the Neo and with 'ipconfig' on Windows.

* You should now be able to ssh/putty from Windows to your Neo. Enjoy!
By setting up the Windows Bluetooth connection properly, it should also be possible to share the Internet Connection of the Windows box with the Neo. The most easiest way is to bridge your bluetooth and local area network interface, and if you have a DHCP server on your network, bnep0 will be configured automatically after connecting with pand.

=== PPP Networking ===

If you are unable to use the 'BNEP' method described above, you may be able to use [[PPP]] and a DUN (dialup-networking) emulation mode. On the Neo:

* Edit the /etc/default/bluetooth file and set the following options:
RFCOMM_ENABLE=true
DUND_ENABLE=true
DUND_OPTIONS="--listen --persist call dun"

* Create an /etc/ppp/peers/dun file with options like the following:
115200
192.168.2.202:192.168.2.200
passive
local
noipdefault
noauth
nodefaultroute

* Restart bluetooth (/etc/init.d/bluetooth stop ; /etc/init.d/bluetooth start)

To connect from a MacOS 10.3 client:

* Open "Applications/Utilities/Bluetooth Serial Utility"

* Click on "New"

* Choose a name, then click "Choose Device"

* Locate your Neo, then select the "LAN Access Point" service. If your device is not found, or if this service does not show up, then you will need to troubleshoot and fix that before continuing. Bluetooth is designed for short-range communication, so make sure that the devices are physically close to each other.

* Select "Port type: RS-232" and "Show in Network Preferences". Click OK.

* Open the Network Preferences page then "Show: Network Port Configurations". Enable the new device that you defined in the previous step and drag it to the bottom of the device list (so that it will not interfere with your other network connections)

* Choose "Show: <your-device-name>", then click "Modem"

* Select "Null Modem 115200" from the list of available devices. Uncheck "Wait for dial tone" and "Enable error correction and compression in modem". Optionally check "Show modem status in menu bar".

* Click "Connect". If everything worked, you will end up with a 'ppp0' device on your Mac with a local address of 192.168.2.200 and you will be able to access your Neo at 192.168.2.202.

=== A2DP quickie ===

It's now possible (if a little hackish) to stream mp3 to a bluetooth headset. It's a known problem that the playback rate changes (pitch varies). Timing issues are also likely the reason for gaps in playback.

If the bluez packages are recent enough, you can use a shortcut. I'll document it here and leave the longer version below (the long version also demonstrates the API used by the GUI to manage headsets)

Create /etc/asound.conf with your bluetooth headset's address filled in:

pcm.!default {
type bluetooth
device "xx:xx:xx:xx:xx:xx"
}

then play a song

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay

or for smoother results...

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:song.wav
aplay song.wav

=== A2DP ===

If that doesn't work... all the more hackish... install required packages:

echo "src/gz python http://www.angstrom-distribution.org/unstable/feed/armv4t/python/" >> /etc/ipkg/angstrom-python.conf
echo "src/gz base http://www.angstrom-distribution.org/unstable/feed/armv4t/base/" >> /etc/ipkg/angstrom-base.conf
ipkg update ; ipkg install python-core python-xml python-dbus bluez-utils bluez-utils-alsa

Create /etc/asound.conf:

pcm.!default {
type bluetooth
}
ctl.!default {
type bluetooth
}
pcm.bluetooth {
type bluetooth
}
ctl.bluetooth {
type bluetooth
}

Run the passkey agent (see above in this page)

Fill in your bluetooth headset address below and execute the python script (with your headset turned on)

#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
conn = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')
path = audio.CreateDevice('00:0D:3C:44:33:22')
audio.ChangeDefaultDevice(path)
sink = dbus.Interface(bus.get_object(conn, path), 'org.bluez.audio.Sink')
sink.Connect()

FINALLY: play a song

madplay /media/card/song.mp3 --sample-rate=44100 --output=wave:- | aplay

=== Headset Audio ===

[[Neo1973_Audio_Subsystem]] has detail about alsa settings and a proposal for audio scenario management.

To try this out, follow the instructions in the a2dp section to install software and run the passkey agent.

Remove or disable the stuff you put in asound.conf. When using a voice headset, the application uses the regular system audio device and it gets routed to bluetooth in the codec.

Put the headset in pairing mode. Replace the bluetooth address below with your headset's and run the python script:

#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
conn = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'), 'org.bluez.audio.Manager')
path = audio.CreateHeadset('00:0B:2E:39:33:22')
audio.ChangeDefaultHeadset(path)
headset = dbus.Interface (bus.get_object(conn, path), 'org.bluez.audio.Headset')
headset.Connect()
headset.Play()

Now place a call and try to route it to bluetooth (after it's in progress):

alsactl -f /etc/gsmbluetooth.state restore

You may also be able to listen to system audio given the right state file:

alsactl -f /etc/systembluetooth.state restore
madplay song.mp3

=== Bluetooth networking with a Linux system - More secure way ===

''Check this, probably needs some corrections''

Bluetooth should behave just like our usbnet and provide full TCP/IP access to the phone. BNEP has to be used.

On the laptop

* check these options in /etc/bluetooth/hcid.conf
security auto;
passkey "your pin";
lm master;

* Start bluetooth
# /etc/init.d/bluetooth start

* Start pand as server
pand --listen --role NAP --encrypt

* Add in /etc/network/interfaces (see [[USB_Networking]])
auto bnep0
iface bnep0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.1.0/24
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -P FORWARD ACCEPT

On the Neo

* Power on bluetooth (see above)

* Scan for the laptop
root@fic-gta01:~$ hcitool scan
Scanning ...
00:20:E0:5A:FE:C8 laptop

* Set pin
root@fic-gta01:~$ passkey-agent 'your pin' 00:20:E0:5A:FE:C8 &

* Connect to the laptop pand
root@fic-gta01:~$ pand -c 00:20:E0:5A:FE:C8

* Configure your IP address
root@fic-gta01:~$ ifconfig bnep0 192.168.1.2
root@fic-gta01:~$ route add default gateway 192.168.1.1

* Enjoy

== Further reading ==

http://www.holtmann.org/papers/bluetooth/ols2006_slides.pdf
http://wiki.bluez.org/wiki/Audio#org.bluez.Audio

{{Languages|Manually_using_Bluetooth}}
[[Category:Neo1973 Hardware]]
[[Bluetooth]]