The Protocol

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 where is the number of bytes in . (there is no carriage return, etc.) 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 bs responds with: 0x06 followed by: 0x02 0x1f 0x08 0x00 "ericsson 7+1 0 "....") (31 data bytes) pc then sends: 0x06 anthony

(stx 2

7 0)

(2 data bytes)

(ack) 1050501

9602191544"

(ack)

(stx 31