.BR "<logo filename>"
.RB [ "<GSMnet id>" ]
.br
+.BR "mdsms --ring-send"
+.RB options...
+.BR "<dest. phone>"
+.BR "<ring filename>"
+.br
options:
.RB [ "-c <cfgfile>" ]
.RB [ "-d <device>" ]
.RS
.TP
.B Nokia Communicator 9000/9000i
-All modes except \fB--logo-send\fP and Nokia multiparts supported.
+All modes except \fB--logo-send\fP supported.
.TP
.B Nokia Communicator 9110
-All modes except Nokia multiparts supported. This is the only device
-with \fB--logo-send\fP capability for now.
+All modes supported. This is the only device with \fB--logo-send\fP capability for now.
.TP
-.B Siemens M20
+.B Siemens A1
Firmware revision 2.0 required. All modes except \fB--logo-send\fP supported.
.RE
.BR -d | --device\ < device >
Specify serial device to communicate with your mobile. If only bare name is
specified, "\fB/dev/\fP" is prepended automatically. This device name is used
-subsequently with
+consequently with
.BR -l | --lockfile
option, see below.
.TP
.BR -r | --readtime\ < sec >
Maximum response read timeout before command retry.
.B mdsms
-sends the requested \fBAT\fP-style command to
-<<<<<<< mdsms.1.in
-.B MobilDock
-and expects response. Unfortunately when the voice call is in progress,
-.B MobilDock
-\80will block any serial device communication and it is impossible to differentiate
-between calling
-.B MobilDock
-and stucked/disconnected one. After exceeding this time interval,
+sends the requested \fBAT\fP-style command to the device and expects response.
+After exceeding this time interval,
.B mdsms
-is terminated immediately,
-.B maxretry
-parameter notwithstanding. Standard value is
-=======
-.B Nokia
-and expects response. After exceeding this time interval,
-.B sms9110
reissues the last command until the maximum retry count (\fBmaxretry\fP) is exhausted.
Standard value is
->>>>>>> 1.5.2.2
.BR DEF_READTIME
-<<<<<<< mdsms.1.in
-\80seconds and should be enough for any voice call.
-=======
seconds and should be enough for standard
-.B Nokia
-responses.
->>>>>>> 1.5.2.2
+.B mobiles
+responses. This is the only point where
+.B --send-mobildock
+differs the behaviour from regular
+.B --send
+option. Unfortunately when
+.B MobilDock
+has a voice call in progress, it will block any serial device
+communication with \fBSiemens A1\fP and it is impossible to differentiate between call-in-progress
+.B MobilDock
+and stucked/disconnected one, so the parameter
+.B readtime
+has very large value, see further. After exceeding this time interval,
+.B mdsms
+is terminated immediately,
+.B maxretry
+parameter notwithstanding. Standard value of this parameter is
+.BR DEF_READTIME_MOBILDOCK
+seconds and should be enough for any voice call.
.TP
.BR -t | --chartime\ < msec >
+\fB(This paragraph\fP
+.BR "doesn't"
+\fBapply to Nokia 9110 or similiar smart devices but the functionality has been
+retained just to be on the safe side.)\fP
Although the fixed used baudrate of
.B 19200
is pretty low, MobilDock/Siemens A1 couple
When full rate communication was used, occasional longer SMS data corruption
was observed. Argument is given in milliseconds and its default value is
.BR DEF_CHARTIME ms.
+.TP
+.BR -T | --cmdtime\ < msec >
\fB(This paragraph\fP
.BR "doesn't"
-\fBapply to Nokia 9110 but the functionality has been
+\fBapply to Nokia 9110 or similiar smart devices but the functionality has been
retained just to be on the safe side.)\fP
-.TP
-.BR -T | --cmdtime\ < msec >
This delay is given before sending any
.B AT-style
-command to Nokia.
+command to the device.
Its primary purpose is to let any previous entered commands to finish and
to clear any input before actually sending our own command. Also all Siemens
devices are known that they strongly dislike fast edge-to-edge communication
and to satisfy these requirements this delay was considered as the best
approach.
-\fB(This sentence\fP
-.BR "doesn't"
-\fBapply to Nokia 9110 but the functionality has been
-retained just to be on the safe side.)\fP
The default value is
.BR DEF_CMDTIME ms.
.TP
-<<<<<<< mdsms.1.in
-\80.BR -f | --file
+.BR -f | --file
When parameter <\fBmsg text\fP> has been specified, by using this option
\fBmdsms\fP will read the file with the <\fBmsg text\fP> filename instead
and send its \fBcontents\fP as the SMS message.
+This parameter is applicable only together with \fB--send\fP or \fB--send-mobildock\fP mode.
.TP
-=======
->>>>>>> 1.5.2.2
.BR -v | --verbose
Increase verbosity level by one. Currently the maximum defined level is
.BR 3 ,
for section
.BR CONFIGURATION .
.TP
-.RB < "logo filename" >
-Here you specifify the filename of the logo file to be uploaded. Currently
-recognized file formats are \fBNOL\fP (Nokia logo?) and \fBNGG\fP (Nokia
-Group Graphics). These formats are proprietary by \fBKESSLER Wireless Design\fP
-and \fBsms9110\fP currently "can't" edit them. More info can be found on:
-.RS
-.B http:/ /www.kessler-design.com/wireless/operatorlogo.php3
-.RE
-.TP
-<<<<<<< mdsms.1.in
-\80.RB < "msg text" >
+.RB < "msg text" >
Here you write the exact body of the message. This parameter should be
specified only as one component, although if more found they are concatenated
with separating space (" "). But this practice is discouraged as
then read from
.I stdin
(standard input stream).
-=======
+This parameter is applicable only together with \fB--send\fP or \fB--send-mobildock\fP mode.
+.TP
+.RB < "logo filename" >
+Here you specifify the filename of the logo file to be uploaded. Currently
+recognized file formats are \fBNOL\fP (Nokia logo?) and \fBNGG\fP (Nokia
+Group Graphics). These formats are proprietary by \fBKESSLER Wireless Design\fP
+and \fBmdsms\fP currently "can't" edit them.
+This parameter is applicable only together with \fB--logo send\fP mode.
+More info can be found on:
+.RS
+.B http:/ /www.kessler-design.com/wireless/operatorlogo.php3
+.RE
+.TP
.RB < "GSMnet id" >
Specify GSM network code to be set on the logo being uploaded. Upon upload to
Nokia phone each operator logo has a GSM network code binded with it. When
of network code from \fBNOL\fP. The default if this parameter is not specified
is ~\fB WORD_NET \fP~ for \fBNOL\fP files and ~\fB WORD_GROUP \fP~ for
\fBNGG\fP files.
->>>>>>> 1.5.2.2
+This parameter is applicable only together with \fB--logo send\fP mode.
.SH CONFIGURATION
-.B sms9110
+.B mdsms
reads ~\fB CONFIG_MAIN \fP~ followed by ~\fB$HOME CONFIG_HOME \fP~
configuration files. The content of these files (and also any file read by
.BR -c | --config
.SH OPERATION
Upon startup
-.B sms9110
+.B mdsms
locks the port (see option
.BR -l | --lockfile
for details) and opens the serial device with specified baudrate (default
\fB DEF_BAUD \fP baud), software handshaking (XON/XOFF style), 8 bits,
no parity. Then issues the following commands:
.TP
-.BR AT <ESCAPE>
+.BR AT <ESCAPE><CTRL-Z>
.B AT
-<<<<<<< mdsms.1.in
-\80is used to fool MobilDock and pass the following
-.B <CTRL-Z>
-(ascii decimal code 26) character to Siemens A1 and break it from eventual
-=======
-is used to fool Nokia and pass the following
-.B <ESCAPE>
-(ascii decimal code 27) character to Nokia and break it from eventual
->>>>>>> 1.5.2.2
+is used to fool
+.B MobilDock
+(if present, otherwise it is harmlesss anyway) and pass the following
+.B <ESCAPE><CTRL-Z>
+(ascii decimal code 27 followed by 26) characters to the device and break it from eventual
.B AT+CMGS
mode in which it may errorneously remain from previous sessions.
.TP
.B AT
-Test the responsiveness of Nokia.
+Test the responsiveness of the device.
.TP
\fBAT+CSCA="\fPsmc # from user\fB"\fP
This command is omitted if
is not specified by user (or specified/overriden as empty string \fB""\fP
.TP
\fBAT+CSCA?\fP
-<<<<<<< mdsms.1.in
Query the currently set SMC center number to include it later to the
header of SMS PDU format where it is required. If \fBAT+CSCA="\fP...\fB"\fP
was issued before, this number should match it but no sanity checks are
-currently do so.
+currently do so. Also it is used to detect possibly unset SMS center.
+.TP
+.RB "Mode-dependent."
+Here are executed the commands listed for each of the specified operation
+mode separately.
+.TP
+\fBAT\fP
+Check that the mobile survived our torture.
+
+.TP
+The following operations are dependant on the operation:
+.TP
+.BR --send / --send-mobildock :
+.RS
+.TP
+\fBAT+CMGF=0\fP, if fails \fBAT+CMGF=1\fP
+Set the default SMS message format to PDU type (preferred) or text mode (if
+PDU not available). Next \fB+CMGS\fP command is dependant on the mode selected
+by this one.
+.TP
+\fBAT+CMGS=\fP# chars if \fB+CMGF=0\fP
+This command physically sends the message and the resulting "\fB+CMGS:\fP" output
+is catched and returned as
+.B MR
+(message reference) number to the user. \fB# chars\FP corresonds to total data
+bytes sent to the phone (so the half of the hex-string, SMSC is included).
+SMSC number is preceding the rest of PDU to be conformant with GSM Phase 2
+specification. Siemens M1 or Siemens M20 rev. 1.x are known that
+.RB "don't"
+like this SMSC number, I have to get in touch with such device to be able to autodetect
+it properly (mail me if you want to be helpful).
+.TP
+\fBAT+CMGS="\fPphone # from user\fB"\fP if \fB+CMGF=1\fP
+The same as the previous command except that the message is text as pure text
+terminated with \fB<CTRL-Z>\fP character. SMSC number is not present anywhere
+in this mode.
+.RE
.TP
-\80\fBAT+CMGF=0\fP
-Set the default SMS message format to PDU type. Currently Siemens A1
-.RB "doesn't"
-support any other SMS format anyway.
-=======
-Query the currently set SMC center number to detect possibly unset SMS center.
+.BR --logo-send / --ring-send :
+.RS
.TP
\fBAT+CSMP=81,,0,245\fP
Sets PDU type to 81 (\fBSMS-SUBMIT\fP + integer-type for \fBvalidity\fP
0 (standard non-converted SMS) and DCS (data coding scheme) to 0xF5
(\fBdata coding\fP/\fBmessage class\fP, \fB8-bit data\fP + \fBmobile-equipment\fP
specific).
->>>>>>> 1.5.2.2
.TP
-<<<<<<< mdsms.1.in
-\80\fBAT+CMGS=\fP# chars
-=======
\fBAT+CMGS="\fPphone # from user\fB"\fP
->>>>>>> 1.5.2.2
This command physically sends the message and the resulting "\fB+CMGS:\fP" output
is catched and returned as
.B MR
Resets back PDU type to 17 (\fBSMS-SUBMIT\fP + integer-type for \fBvalidity\fP),
PID (protocol identifier) to 0 (standard non-converted SMS) and DCS (data coding
scheme) to 0 (\fBalphabet indication\fP, \fBdefault 7-bit alphabet\fP).
+.RE
.TP
-\fBAT\fP
-Check that Nokia survived the sending of the message.
+.BR --receive :
+Receiving of messages is performed using direct routing of incoming data to TE (Terminal Equipment).
+No SMSes are stored to SIM card/device memory and then read back as one may expect.
+There are slight advantages of better response times (SIM card access is very slow) and
+saving EEPROM writes to SIMcard. Unfortunately there is one big advantage that when
+.B mdsms
+suddenly stops/crashes without switching the device back to SIM-store mode, messages
+being consequently received are lost on the dead end of serial port.
+.B mdsms
+tries very hard to restore the device state before its termination but sometimes it just
+.RB "isn't"
+possible. Due to this fact \fBnever kill mdsms with SIGKILL (-9) signal\fP, use standard
+SIGTERM instead, please. Also one fact resulting of this behaviour is that messages
+with Class-2 (SIM store) specific routing are really stored to SIM card and as such are
+not processed in any way by
+.BR mdsms .
+Safer SIM store/retrieve mechanism may be implemented in future versions. Command sequence used in
+.B --receive
+mode follows:
+.RS
+.TP
+\fBAT+CMGF=0\fP, if fails \fBAT+CMGF=1\fP
+Set the default SMS message format to PDU type (preferred) or text mode (if
+PDU mode not available).
+.TP
+\fBAT+CNMI=,2\fP
+Set the message routing to go directly to TE (Terminal Equipment), see the discussion
+in paragraph above for more. Also right before starting attempt to send this command,
+\fBAT+CNMI=,0\fP is set to be tried before finishing
+.BR mdsms
+to restore the original device behaviour.
+.TP
+\fBAT+CSDH=0\fP
+We
+.RB "aren't"
+really much interested in additional non-standard values of
+PID (Protocol IDentifier), DCS (Data Coding Scheme) etc.
+.TP
+data wait
+In this point the device lock file is removed, retry count is set to infinite value
+(see discussion in
+.B --maxretry
+parameter) and
+.B mdsms
+starts to passively listen for any incoming data. Possible dial-out mode is being
+detected afterwards, otherwise message receive sequence follows as described below.
+.TP
+\fB+CMT:\fP read
+Any waiting \fB+CMT\fP incoming message indications are read and processed. Format
+being processed (text/PDU) depends on the actual value of \fBAT+CMGF\fP set before. Any
+possible \fB+CMTI:\fP input is discarded as we are not interested in SIM-store
+directed messages.
+.TP
+receive restart
+After processing all the messages, the whole initialization sequence is restarted as
+the device configuration may have changed or lost during the data wait phase.
+.RE
.SH SEE ALSO
.TP
User personalized local configuration file
.SH AUTHOR
-.B sms9110
+.B mdsms
was written by Jan Kratochvil who should be responsible for all the bugs
included. Please see the file "\fBAUTHORS\fP"
shipped with the original distribution archive for more details.
git://git.jankratochvil.net / mdsms.git / blobdiff