[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS: gnokii/Docs/protocol dancall.txt,NONE,1.1
From: |
Ladislav Michl <address@hidden> |
Subject: |
CVS: gnokii/Docs/protocol dancall.txt,NONE,1.1 |
Date: |
Mon, 24 Feb 2003 06:01:50 -0500 |
Update of /cvsroot/gnokii/gnokii/Docs/protocol
In directory subversions:/tmp/cvs-serv10913/Docs/protocol
Added Files:
dancall.txt
Log Message:
give people some starting point...
--- NEW FILE ---
Document describing protocol used in Dancall phones.
The data provided is for information purposes only.
Some of the frames might be hazardous to your phone. Be careful!!!
We do not take any responsibility or liability for damages, etc.
Last update 24.02.2003
~~~~~~~~~~~~~~~~~~~~~~
Assembled by
Ladislav Michl <address@hidden>
Thanx to
Vojta Bouberle
NOTE: this information isn't (and can't be) complete. If you know anything
about features not listed here or you noticed a bug in this list, please
notify us via e-mail. Thank you.
Frame format for CBUS:
Request from Computer/Answer from Phone:
{ SrcDEV, DestDEV, FrameLenLo, FrameLenHi, MsgType1, MsgType2, {blk}, CSum }
where SrcDEV, DestDEV: 0x19: phone
0x38: PC (wakeup msg)
0x34: PC (normal msg)
FrameLenLo: length of data frame, low byte.
FrameLenHi: length of data frame, high byte.
MsgType1, MsgType2: see List
{blk}: main frame
CSum: XOR on frame's all members
Packet ack from Phone:
{ 0x19, DestDEV, FrameLenLo, FrameLenHi, MsgType1, MsgType2, {block}, CSum }
where DestDEV: taken from original request packet
FrameLenLo: length of data frame, low byte.
FrameLenHi: length of data frame, high byte.
MsgType1: taken from original request packet plus one
MsgType2: taken from original request packet
{blk}: MsgType1 and MsgType2 taken from original
request packet
CSum: XOR on frame's all members
Packet ack from Computer:
{ SrcDEV, 0x19, FrameLenLo, FrameLenHi, MsgType1, MsgType2, {blk}, CSum }
where SrcDEV: taken from response packet
FrameLenLo: length of data frame, low byte.
FrameLenHi: length of data frame, high byte.
MsgType1: taken from response packet plus one
MsgType2: taken from response packet
{blk}: MsgType1 and MsgType2 taken from response packet
CSum: XOR on frame's all members
Response from Phone:
{ 0x19, DestDEV, FrameLenLo, FrameLenHi, MsgType1, MsgType2, {blk}, CSum }
where DestDEV: taken from original request packet
FrameLenLo: length of data frame, low byte.
FrameLenHi: length of data frame, high byte.
MsgType1, MsgType2: see List
{blk}: MsgType1 and MsgType2 taken from original
request packet
CSum: XOR on frame's all members
Port settings:
Speed 9600 bps, Bits 8, Parity None, Stop Bits 1, DTR 1, RTS 0
CBUS bus has only one wire for transmition and reception.
Because of this characteristics of the phone connector, every time that the
PC writes into the phone it is writing as well into its own Rx. So every
time the PC sends info into the phone it finds that same information in its
own Rx buffers, like a mirror copy. This should be discarded.
The communications is made like an old cb radio, only one
talking at a time. Communication is made (basically) this way:
o computer sends request
-> phone got request (checksum matches)
o phone sends 0xa5
-> phone understood request
o phone sends ack packet
-> computer got response (checksum matches)
o computer sends 0xa5
-> phone got 0xa5
o phone sends response
-> computer got response (checksum matches)
o computer sends 0xa5
-> phone got 0xa5
o computer sends ack packet
-> phone got ack packet (checksum matches)
o phone sends 0xa5
If 0xa5 is not sent in 10ms (wild guess ;)) the last
packet is repeated at most three times.
Example 1 (setting SMS center number)
Computer: 34 19 3c 68 18 00 41 54 4.<h..AT
2b 43 53 43 41 3d 22 2b +CSCA="+
34 32 30 36 30 32 39 39 42060299
39 39 39 32 22 0d 5f 9992"._
Phone: a5 %
Phone: 19 34 3d 68 02 00 3c 68 .4=h..<h
2e .
Computer: a5 %
Phone: 19 34 3e 68 04 00 4f 4b .4>h..OK
0d 0a 7c ..|
Computer: a5 %
Computer: 34 19 3f 68 02 00 3e 68 4.?h..>h
2e .
Phone: a5 %
Example 2 (querying number of SMSes on SIM)
Computer: 34 19 3c 68 12 00 41 54 4.<h..AT
2b 43 50 4d 53 3d 22 53 +CPMS="S
4d 22 2c 22 53 4d 22 0d M","SM".
44 D
Phone: a5 %
Phone: 19 34 3d 68 02 00 3c 68 .4=h..<h
2e .
Computer: a5 %
Phone: 19 34 3e 68 1c 00 2b 43 .4>h..+C
50 4d 53 3a 20 22 53 4d PMS: "SM
22 2c 30 2c 31 30 2c 22 ",0,10,"
53 4d 22 2c 30 2c 31 30 SM",0,10
0d 0a 70 ..p
Computer: a5 %
Computer: 34 19 3f 68 02 00 3e 68 4.?h..>h
2e .
Phone: a5 %
Phone: 19 34 3e 68 04 00 4f 4b .4>h..OK
0d 0a 7c ..|
Computer: a5 %
Phone: 34 19 3f 68 02 00 3e 68 4.?h..>h
2e .
Computer: a5 %
You have to implement collision protocol. ie, you should listen for
what you are transmitting, and if it does not come back, you have
collision.
Note: Bosch bought Dancall in 1997. Question for curious reader: which protocol
is used by Bosch phones?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- CVS: gnokii/Docs/protocol dancall.txt,NONE,1.1,
Ladislav Michl <address@hidden> <=
- Prev by Date:
CVS: gnokii/smsd ChangeLog,1.19,1.20 lowlevel.c,1.31,1.32 smsd.c,1.34,1.35
- Next by Date:
CVS: gnokii ChangeLog,1.504,1.505
- Previous by thread:
CVS: gnokii/smsd ChangeLog,1.19,1.20 lowlevel.c,1.31,1.32 smsd.c,1.34,1.35
- Next by thread:
CVS: gnokii ChangeLog,1.504,1.505
- Index(es):