oliver bischoff wrote:

> hi, i am looking for the protocol used between serial port and cell phone
> (nokia or ericsson). is there a standard or is it a big secret?

> who knows more?

ok, here's some info i have on the protocol involved:

ericsson serial port communications protocol

============================================

the phone communicates at 9600,n,8,1.

if an error is made in the protocol (you send a character out of place)

the phone very annoyingly switches into aux console mode (keyboard
pass-through). what this means is that the baud rate changes down to
600bps and the phone's keypad is duplicated on the serial port. any
phone key now pressed sends a scan byte to the pc (even when entering
the pin number), while sending a similar character from the pc to the
phone causes the phone to respond as if the corresponding key was
actually pressed by the user.

to exit this aux console mode and return to normal comm's, you need to
send to the phone the following 3 bytes in sequence (shown in hex): 0a
30 08 (a short pause between the 1st and 2nd byte may be required for
reliability ?). (equivalent to typing ctrl-j 0 ctrl-h or lf 0 bs) the
phone will switch back to 9600bps.

now the protocol:

i'll refer to the cellphone as bs and the computer as pc.

i'll represent byte characters 0 to 255 decimal, in hex as 0x00 to 0xff.
printable ascii characters will be shown enlosed in "".

the following ascii codes are used extensively:

stx = 0x02 (start of text)
ack = 0x06 (acknowledge)

for every message sent by pc to bs or by bs to pc, the receiver must

always acknowledge this by replying with ack. if pc doesn't respond with
ack then bs will resend the message a further 2 times before switching
to aux console mode. for every command sent by pc to bs, bs will
therefore respond with ack before sending any reply message.

each message (either a command or a response) always consists of:

stx <byte count> <data>
where <byte count> is the number of bytes in <data>. (there is no
carriage return, etc.) <data> is the actual command or response.

commands are always at least 2 bytes. these can be followed by optional

parameters or data. sending a command of 1 byte will result in an ack as
usual but this will then be followed by a response of 0x90 0x10 which
indicates an invalid command (preceded of course by stx 0x02 since there
are 2 bytes). the 1st byte indicates the command's functional group,
while the 2nd indicates the specific command in the group.

responses always begin with the 2 command bytes themselves such that the
1st byte is incremented by 1. for example, sending the command 0x07 0x00
will result in the response 0x08 0x00 followed by the actual information
requested.

as an example, the command just mentioned is to get the phone

manufacturer and model/version as follows:

pc sends to bs:
0x02 0x02 0x07 0x00 (stx 2 7 0) (2 data bytes)

bs responds with:
0x06 (ack)
followed by:
0x02 0x1f 0x08 0x00 "ericsson 1050501 9602191544" (stx 31
7+1 0 "....") (31 data bytes)

pc then sends:
0x06 (ack)

anthony